Архитектура MongoDb. Часть 3. Модель репликации MongoDb

Рубрика:

Высокая доступность в MongoDb достигается через Replica Set, который обеспечивает избыточность данных по многократным физическим серверам, включая единственную основную БД, а также несколько вторичных БД. Для непротиворечивости данных все запросы модификации (insert / update / delete) обращаются к основной БД, где осуществляется модификация и асинхронно тиражируется в другие вторичные БД.

Модель репликации MongoDB

В Replica Set элементы соединены друг с другом, чтобы обмениваться сообщениями типа "я живой". Упавший сервер, который пропустил  такое сообщение, будет обнаружен другими элементами и удален из членов в Replica Set. После того, как отказавшее вторичное устройство восстановится в будущем, оно может присоединиться к кластеру, соединяясь с первичным устройством, чтобы добавить последние обновления, начиная с того времени, как оно отказало. Если катастрофические отказы происходят в долгий период времени, когда журнал изменений от основного устройства не покрывает весь период отказа, в этом случае восстановленному вторичному устройству нужно перезагрузить все данные от основного устройства (как будто это был совершенно новый сервер).

В случае катастрофических отказов основной БД, среди оставшихся элементов будет выполнен протокол выборов лидера, чтобы назначить новое основное устройство, на основе многих факторов, таких как приоритет узла, время работы узла... и т.д. После получения решения большинством голосов будет выбран основной сервер. Заметьте, что из-за асинхронной репликации, вновь избранной основной БД не нужно наличие всех последних обновлений от отказавшей БД.

Клиентская библиотека предоставляет API для получения приложениями доступа к серверу MongoDB. При запуске клиентская библиотека соединится с некоторым элементом Replica Set и запустит команду "isMaster", чтобы собрать текущую картину набора (какое основное и какие вторичные устройства). После этого, клиентская библиотека подключается к единственному основному устройству (куда она отправит все запросы модификации БД) и некоторому числу вторичных устройств (куда она отправит запросы только для чтения). Клиентская библиотека будет периодически перезапускать команду "isMaster", чтобы обнаружить какие-либо новые элементы, присоединившиеся к набору. Когда существующий элемент в наборе откажет, соединения со всеми существующими клиентами будут сброшены, и вызывается пересинхронизация последней картины.

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

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

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

Для наиболее читаемого приложения, чтение с любых вторичных устройства может во многом улучшить производительность. Чтобы выбрать самый быстрый вторичный элемент БД для отправки запроса, клиентский драйвер периодически проверяет с помощью элементы ping-запросов и одобряет отправку запроса к элементу с самой низкой задержкой. Стоит отметить, что запрос чтения отправляется только одному узлу, в MongoDb нет кворума на чтение или чтения из нескольких узлов.

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

Другое преимущество Replica set - то, что элементы могут быть выведены из основного оборота, чтобы выполнить дорогую работу, такую как уплотнение, индексация или backup, не влияя на онлайновые клиенты, использующие живые элементы.

Читать далее: 

Часть 4. Шардинг, Map/Reduce в MongoDb

Читайте предыдущие части серии "Архитектура MongoDB":

Часть 1. Отличие от СУБД, обработка запросов в MongoDb

Часть 2. Модель хранения, обновления и транзакции в MongoDb

Автор: 
Ricky Ho, http://horicky.blogspot.com/2012/04/mongodb-architecture.html

Комментарии

Аватар пользователя giogoge