Развертывание кластера MongoDB

задняя часть база данных сервер MongoDB

копия данных

Набор реплик в MongoDB — это группа процессов mongod, которые поддерживают один и тот же набор данных. Наборы реплик обеспечивают избыточность и высокую доступность и являются основой для производственных развертываний.

Избыточность и доступность данных

Сохраняя одни и те же данные на разных серверах, механизм репликации обеспечивает определенную степень отказоустойчивости, то есть после сбоя базы данных служба данных остается доступной.

В некоторых случаях реплики могут повысить производительность чтения данных, поскольку пользователи могут считывать данные из разных баз данных. Хранение копий данных в разных центрах обработки данных может повысить доступность распределенных приложений. Дополнительные копии также могут храниться для других целей, таких как аварийное восстановление, оповещение или резервное копирование.

Реплика в Монго

Набор реплик Mongo состоит из нескольких узлов, несущих данные, и необязательного арбитра. Среди этих узлов есть только один первичный узел, а остальные узлы считаются вторичными узлами.

Главный узел получает все операции записи. В наборе реплик только главный узел может подтвердить{ w: "majority"}; хотя в некоторых случаях другой процесс mongod будет считать себя мастером в течение короткого периода времени. Главный узел записывает в журнал все изменения данных, напримерoplog

.

Скопируйте oplog главного узла с подчиненного узла, а затем воспроизведите изменения набора данных в соответствии с журналом, чтобы таким образом добиться согласованности данных с главным узлом. Если главный узел выходит из строя, подходящий подчиненный узел инициирует выборы, чтобы выбрать себя в качестве нового главного узла.

В набор реплик можно добавить дополнительный экземпляр mongod в качестве арбитра. Арбитр не поддерживает набор данных, его основная функция — поддерживать пульсацию между узлами и отвечать на запросы других членов набора реплик. Поскольку арбитр не поддерживает данные, он потребляет меньше ресурсов, чем полный узел. Если количество узлов в наборе реплик четное, добавление арбитра может добавить возможность иметь большинство голосов при выборе мастера.

Роль Arbiter не изменится, главный узел может быть демонстрирован на ведомый узел, а подчиненный узел также может быть продвижена на главный узел.

Асинхронная репликация

Подчиненный узел применяет операции асинхронно с главного узла. После синхронизации данных с основного узла, даже если некоторые узлы выходят из строя, набор реплик может продолжать работать.

автоматический переход на другой ресурс

Когда главный узел и другие узлы в наборе реплик отключены более чем на 10 секунд, подходящий подчиненный узел инициирует выборы, чтобы повысить себя до главного узла. Первый узел, инициировавший выборы и получивший большинство голосов в наборе реплик, становится главным узлом.

Процесс отработки отказа обычно завершается в течение минуты. Другим узлам в наборе реплик может потребоваться от 10 до 30 секунд, чтобы подтвердить, что мастер недоступен. После подтверждения начнутся выборы. Процесс выборов может занять от 10 до 30 секунд.

операция чтения

По умолчанию пользователи будут читать данные с главного узла, но пользователи также могут отправлять запросы на чтение подчиненным узлам через настройки. Асинхронная система означает, что данные на ведомом узле могут не совпадать с данными на ведущем узле.

разделение данных

Шардирование данных - распределить данные по нескольким машинам. Mongodb использует технологию Sharding для поддержки развертывания очень больших наборов данных и увеличить пропускную способность системы.

Один сервер может работать с приложениями, требующими большого объема данных и высокой пропускной способностью. Например, высокочастотные запросы могут истощить ресурсы ЦП сервера, а рабочие наборы данных, объем которых превышает объем системной памяти, могут сильно увеличить нагрузку на дисковый ввод-вывод.

Есть два способа справиться с ростом системных данных: вертикальное масштабирование и горизонтальное масштабирование.

Вертикальное масштабирование включает в себя увеличение емкости отдельного сервера, например, использование более мощного ЦП, добавление большего объема памяти или увеличение объема хранилища. Ограничения существующей технологии могут сделать невозможным выполнение одной машиной данной рабочей нагрузки. Кроме того, конфигурация оборудования, которую могут предоставить поставщики облачных услуг, также имеет определенный верхний предел. Таким образом, на практике существует верхний предел нагрузки, с которой может справиться вертикальное масштабирование.

Горизонтальное масштабирование включает в себя разделение наборов данных и распределение нагрузки между несколькими серверами. Горизонтальное масштабирование может увеличить вычислительную мощность за счет добавления новых машин. Хотя отдельная машина может быть не очень мощной, каждая машина отвечает за обработку подмножества общей нагрузки и, следовательно, может обеспечить большую эффективность, чем высокоскоростные серверы большой емкости. Горизонтальное масштабирование для увеличения вычислительной мощности системы требует только добавления новых серверов, что обходится дешевле, чем повышение производительности высокопроизводительных серверов. Недостатком является повышенная сложность развертывания и обслуживания инфраструктуры.

MongoDB поддерживает горизонтальное расширение системы за счет технологии сегментирования.

Разделенный кластер

Фрагмент MongoDB Cluster имеет следующие компоненты:

  • осколок: каждый осколок содержит подмножество осколков данных. Каждый сегмент можно развернуть как набор реплик.
  • mongos: mongos действует как маршрутизатор запросов, обеспечивая интерфейс между клиентскими приложениями и сегментированными кластерами.
  • серверы конфигурации: серверы конфигурации хранят метаданные и данные конфигурации в кластере. В Mongo 3.4 сервер конфигурации должен быть развернут как набор реплик.

На следующей диаграмме показано взаимодействие между различными компонентами.

Shard Keys

MongoDB использует ключи сегментов для сегментирования данных коллекции. Ключ сегмента состоит из неизменяемого поля или поля, которое существует для каждого документа в целевой коллекции.

Ключ сегмента необходимо выбрать при сегментировании коллекции. Ключ шарда после этого изменить нельзя. Разделенная коллекция может иметь только один ключ сегмента.

Чтобы сегментировать непустую коллекцию, коллекция должна иметь индекс, начинающийся с ключа сегмента. Для пустой коллекции, если нет подходящего индекса, MongoDB создаст индекс.

Выбор ключа сегмента влияет на производительность, эффективность и масштабируемость кластера. Ключ осколка может стать узким местом для кластера, даже если машины в кластере очень мощные.

chunks

MongoDB разбивает данные на куски. В зависимости от выбранного ключа сегмента каждый размер блока имеет нижний и верхний предел.

В кластере MongoDB переносит отдельные фрагменты с помощью балансировщика сегментированного кластера. Балансировщик пытается сбалансировать фрагменты в кластере.

Преимущества шардинга

Читай пиши

MongoDB В кластере срезов MongoDB назначает нагрузку чтения и записи каждому узлу, позволяя каждому SHARD обрабатывать подмножество операций кластера. Эта возможность чтения и записи может быть расширена путем добавления большего количества поперечных осколков.

Для запросов, включающих ключи сегментов, mongos может нацеливать запрос на определенный сегмент.

Производительность хранилища

Разделение распределяет данные по узлам в кластере, при этом каждый сегмент содержит подмножество общего набора данных. По мере роста набора данных добавление сегментов может увеличить емкость хранилища кластера.

Высокая доступность

Даже когда некоторые сегменты недоступны, кластер может продолжать выполнять некоторые операции чтения/записи. В течение периода, когда отказавший сегмент недоступен, операции чтения и записи доступных сегментов не затрагиваются.

В производственной среде сегменты следует развертывать в виде наборов реплик, чтобы обеспечить избыточность и доступность данных.

Вопросы шардинга

Внедрение сегментирования в кластере требует тщательного планирования, выполнения и обслуживания.

Тщательный выбор ключей сегментов необходим для обеспечения производительности и эффективности кластера. Ключ сегмента не может быть изменен после сегментирования, и сегмент не может быть отозван.

Разделение имеет определенные эксплуатационные требования и ограничения.

Если запрос не включает ключ сегмента, mongos передает операцию выполнения запроса на сегментах в кластере. Такие запросы могут занять много времени.

Разделенные и неразделенные коллекции

База данных может одновременно иметь коллекцию Коллекции и недивидендов. Коллекция фрагментации разделена, распределена по разным шардам в кластере. Нефрагментированная коллекция хранится в основном шарде. Каждая база данных имеет свой главный шард.

Соединения с шардированным кластером

Должен быть подключен к маршруту mongos для взаимодействия с коллекцией в сегментированном кластере. Это взаимодействие включает сегментированные коллекции и несегментированные коллекции. Клиентам не разрешается напрямую подключаться к отдельным сегментам для операций чтения и записи.

Стратегия шардинга

MongoDB поддерживает две стратегии сегментирования.

хэш-шардинг

Разделение хэша — это разделение значения ключа сегмента после операции хеширования. Каждый фрагмент выделяется на основе хешированного значения.

Ключи осколков в диапазоне могут быть близкими, но хешированные результаты, скорее всего, не находятся в одном и том же фрагменте. Распределение данных на основе хеша приведет к более сбалансированному распределению данных, особенно когда ключ сегмента меняется монотонно.

Однако распределение хэшей означает, что запросы диапазона вряд ли будут нацелены на один сегмент, что приведет к широковещательным операциям.

разделение диапазона

Разделение по диапазону — это разделение данных на основе значения ключа сегмента. Каждый фрагмент выделяется на основе значения ключа сегмента.

Значения в диапазоне ключей осколков с большей вероятностью будут выделены в одном и том же чанке, и монго будут направлять запросы к осколкам, которые содержат только запрошенные данные.

Эффективность разделения диапазона зависит от ключа сегментирования. Неучтенные ключи сегментов могут привести к неравномерному распределению данных, что может уменьшить преимущества сегментирования данных или привести к снижению производительности.

Область сегментированного кластера

В сегментированном кластере области данных могут создаваться на основе ключей сегментов. Несколько осколков в кластере могут быть связаны в одном регионе. Шард может быть связан с любым количеством неконфликтующих регионов. В сбалансированном кластере MongoDB перенесет фрагменты в регионе в осколки, связанные с регионом.

Каждый регион включает один или несколько диапазонов ключей сегментов. Покрытие каждого региона всегда включает его нижнюю границу и исключает верхнюю границу.