NoSQL / Репликация MongoDB на пальцах Опции

[Decker]

MongoDB поддерживает асинхронную репликацию данных между серверами, в целях отказоустойчивости и избыточности данных. В этой заметке я напишу об этом функционале, без которого немыслим ни один высоко нагруженный сервис. В продолжении темы Шардинг MongoDB на пальцах (желательно прочитать). И всё, как обычно, на пальцах.





Репликация — механизм синхронизации содержимого базы данных с несколькими серверами (репликами). То есть, один инстанс mongod на сервере 127.0.0.1 передает (синхронизирует) содержимое своей БД test другому инстансу mongod на сервере 127.0.0.2 (теперь это реплика). Таким образом в нашей системе создается избыточность данных: одна и та же база test обслуживается двумя серверами. И это в некотором смысле хорошо. Так как если один сервер упадет, другой перехватит его знамя и продолжит раздавать и принимать данные.



Но, как я уже мельком упомянул, в MongoDB репликация асинхронная. Это значит, что данные синхронизируются между репликами не в момент непосредственного изменения данных, а отложенно, через какое-то время. В этом есть плюс: не тратится время на репликацию в момент изменения данных (insert'ы происходят быстрее). И, как водится, минус: в определенные моменты времени данные между репликами могут быть не согласованными (читай разными).



На данный момент MongoDB поддерживает две основные парадигмы репликации: master-slave и replica sets. Ниже познакомимся подробнее с каждой из них.








Master-Slave


Парадигма Master-Slave применяется во многих СУБД. Грубо говоря, есть несколько серверов: один мастер, и два слейва. Удалить и писать в базу можно только в мастер-сервере, а читать как из мастера так и из слейвов (для этого-то они и нужны). Слейвов может быть несколько. Такая схема полезна, когда у нашей системы много запросов на получение данных. Так как приложение может обращаться к слейвам для чтения, то мы можем ± равномерно распределить нагрузку между ними.



Теперь посмотрим, как реализовать master-slave в MongoDB. Допустим у нас три машины: 127.0.0.1 будет мастером, а 127.0.0.2 и 127.0.0.3 соответственно слейвами. Для начала запустим mongod в режиме мастера:

127.0.0.1 $bin/mongod --master и другие настройки

Теперь на нашей первой машине крутится мастер, к которому можно обращаться для записи/чтения уже сейчас. Теперь на двух других серверах запустим mongod в режиме слейвов:

127.0.0.2 $bin/mongod --slave --source 127.0.0.1:порт и другие настройки
127.0.0.3 $bin/mongod --slave --source 127.0.0.1:порт и другие настройки


Стало быть наши слейвы знают, где находится мастер (параметр source ). Что произойдет далее? Если в мастер-сервер кто-то что-то писал/удалял пока мы настраивали слейвы, то слейвы автоматически и асинхронно синхронизируются с мастером, и у них будет свежая копия данных. Но всё может быть не так просто. Копнём глубже.



Для того, чтобы понять какие сложности могут возникнуть со слейвом, надо понять как работает мастер. Когда мы запустили мастера-сервер, он создал в своей базе коллекцию local.oplog.$main (лог операций). В этой коллекции хранятся все последние операции (изменения данных), которые применялись на мастере. Именно из этой коллекции по слейвам расходятся команды обновления их локальных копий. Но не зря я сказал последние операции, ибо размер лога операций ограничен (мы его можем задать сами). И в случае, если лог будет заполнен полностью, более старые операции будут удаляться из него, а новые соответственно добавляться.



Так к чему это я? А дело в том, что если слейв выпадет из системы надолго, то есть вероятность, что на мастере за это время будет применено столько новых операций, что лог заполнится и самые старые операции удалятся. А это значит, что мастер не сможет отослать введенному в строй слейву весь лог изменений и на слейве окажется не синхронная копия мастера. А это очень плохо. Нам в этом случае поможет полное копирование базы мастера на слейв. Это можно сделать операцией {resync:1} на слейве, или запуском слейва с ключом --autoresync. После таких танцев, на слейве будет точная копия мастера и наша система снова в строю.



Администрирование master-slave репликации в MongoDB простое, отчасти потому что предоставляется нормальный API. Например, можно указывать мастер-сервер на уже работающем слейве или выполнять диагностические команды или еще что-то в этом духе. Хотя возможно это не такой уж мощный функционал, но меня захватила идея автоматического администрирования репликаций: добавление новых слейвов, бэкапы, подмена мастера и прочее. Впрочем на master-slave репликациях это видно не так хорошо, как, например, на replica sets в купе с шардингом. Там, как мне кажется возможность автоматического расширения кластера представлена во всей красе. Это было небольшое отступление перед вторый способом репликации — replica sets.




Replica Sets


В официальных доках набор реплик расхваливают как панацею и приписывают магические свойства автоматической отказоустойчивости. В наборе реплик также присутствует мастер, и при том только один в каждый момент времени. Отличие же в автоматической смене мастера в случае если это необходимо (например, если прежний мастер упадет). Суть в том, что создается несколько процессов mongod с ключом --replSet и указанием имени набора.

127.0.0.1 $bin/mongod --replSet r1 и другие настройки
127.0.0.2 $bin/mongod --replSet r1 и другие настройки
127.0.0.3 $bin/mongod --replSet r1 и другие настройки


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

>config = {_id: 'r1', members: [
{_id: 0, host: '127.0.0.1:27017'},
{_id: 1, host: '127.0.0.2:27017'},
{_id: 2, host: '127.0.0.3:27017'}]
}
> rs.initiate(config);


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



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



Итак, в наборе реплик в случае падения мастера, оставшиеся сервера реплик автоматически решают кто из них станет мастером. Для программы, использующей реплицирование этот процесс прозрачный, так как драйверы MongoDB для всех языков поддерживают указание всех адресов реплик. То есть, программа всегда знает где и сколько реплик и кто из них мастер. Драйверы определяют мастера, и соответственно к нему осуществляют запрос. Это возможно благодаря тому, что каждый реплик-сервер хранит данные и о мастере и о других репликах (для этого существует команда rs.status()).



В заключении прольем свет на процесс «голосования» при выборе мастера. Так уж устроено в MongoDB, что чтобы назначить нового мастера нужно набрать больше половины «голосов» реплик-серверов. Как я уже говорил этот выбор происходит в процессе инициализации. Когда мы используем три сервера реплик, то всё в порядке, так как сам сервер за себя не может проголосовать, но зато два других могут. В итоге 1+1 больше половины. Новый мастер назначен! Но если мы используем два сервера, то нам, как ни странно, необходим третий, арбитр. Арбитр — легковесный процесс, выполняющий функцию только лишь голосования, и не хранящий данных. Создаются арбитр-процессы точно так-же как и реплик-серверы, но инициализация происходит следующим образом:

>config = {_id: 'r1', members: [
{_id: 0, host: '127.0.0.1:27017'},
{_id: 1, host: '127.0.0.2:27017'},
{_id: 2, host: '127.0.0.3:27017, arbiterOnly: true'}]
}
> rs.initiate(config);




Разумеется, выделять отдельную машину для арбитра вовсе необязательно. Его можно запустить совместно с одной из реплик.
Original source: habrahabr.ru (comments).

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