Репликация обеспечивает полную доступность данных после отказа оборудования. Базы данных размещаются и обслуживаются на нескольких узлах. В MongoDB репликация основана на принципе: первичный –вторичные узлы. Главный и единственный первичный узел реплики занимается выполнением всех операций записи, вторичные узлы, которых может быть несколько, считывают данные с первичного узла в асинхронном режиме и копируют их себе. Все данные вторичных узлов автоматически синхронизируются с данными первичного узла и содержат всегда актуальные данные.
Если первичный узел выходит из строя, то один из вторичных узлов автоматически становится первичным и принимает на себя все операции записи. А вышедший из строя первичный узел после восстановления становится вторичным.
Таким образом, репликация позволяет продолжить работу с актуальными данными в случае отказа главного первичного узла.
Отказы могут происходить по следующим причинам:
- Пропало соединение между программным приложением и базой данных
- После отключения сервера для проведения профилактических работ, сервер не загрузился вновь
- Отключено питание сервера или произошел сбой электроснабжения в центре обработки данных
- Произошел сбой работы жесткого диска на сервере базы данных
Благодаря синхронизации данных между первичным и вторичным узлами репликация позволяет обеспечить создание резервных копий базы данных. Однако это не означает, что не нужно производить обычную процедуру резервного копирования базы. Ведь данные при репликации всегда актуальны, а обычное резервное копирование создает копию данных на определенный момент времени. Резервное копирование обычно принято проводить на вторичном узле, чтобы первичный узел не простаивал.
Репликация на вторичные узлы не влияет на производительность первичного узла. Реплицированные узлы могут задерживаться на несколько секунд от первичного узла. Сделано это на тот случай, если база данных повреждена или удалена коллекция.
Для переключения на резервный узел в случае аварийной остановки не требуются специальные средства переключения, так как реплики в MongoDB переключаются автоматически, что очень удобно при внезапном отказе.
Репликация также позволяет производить распределение операций чтения данных между репликами.
В наборе реплик должно быть не меньше трех узлов. Каждый из двух узлов может быть первичным, а третий узел, в случае отказа первичного узла, помогает выбрать новый первичный узел из вторичного узла.
Журнал операций
Набор реплик состоит из двух частей: журнал операций и тактовый сигнал. Журнал операций производит репликацию, а тактовый сигнал ведет мониторинг репликации и включает отработку отказа.
Журнал операций MongoDB представляет собой коллекцию в базе данных на каждой узле. В данную коллекцию записываются любые изменения данных. Когда какие-либо данные записываются на первичный узел, то в журнал операций заносится информация об изменениях. Эта же информация переносится на вторичные узлы во время репликации.
Все записи в журнале имеются временную метку в формате BSON, которую используют вторичные узлы, чтобы определить какая запись была последней. Вторичные узлы также как и первичные ведут журнал операций и отмечают последнюю запись.
Во время записи на первичный узел набора реплик операция записи отмечается в журнале операций на первичном узле. Вторичные узлы при этом ведут свои журналы операций, которые реплицируют журнал первичного узла. При обновлении данных на вторичном узле сначала производится проверка временной метки последней записи в журнале, затем вторичный узел получает все метки с поздними записями журнала первичного узла. После этого вторичный журнал добавляет себе полученные записи. Таким образом, при отказе вторичного узла, занявшего место первичного, его журнал операций могут реплицировать остальные вторичные узлы.
Вторичные узлы почти мгновенно получают записи из журнала операций первичного узла и не отстают от первичного узла. В случае отставания вторичный узел использует временную метку последней записи в журнале операций.
Все записи в журнале операций когда-нибудь затираются новыми записями. Поэтому репликация останавливает свою работу, если вторичный узел не может понять, когда он был синхронизирован с журналом операций первичного узла. Это может повлиять на актуальность данных на вторичных узлах. Проблема решается полной синхронизацией с данными первичного узла.
Фиксация и откат
При записи данных на первичный узел может оказаться, что по каким-либо причинам записи могут не реплицироваться на вторичный узел, который после выбран в качестве первичного узла. Старый первичный узел после восстановления будет пытаться реплицировать данные с нового первичного узла. Но оказывается, что на старом первичном узле есть записи, которых нет в журнале операций нового первичного узла. В этом случае производится откат, при котором записи, которые не реплицировались на большую часть узлов, удаляются из журнала операций вторичного узла.
В случае удаления записей вторичный узел найдет их в другой реплике и восстановит. Отмененные операции записи хранятся в специальном каталоге данных на стороне узла в BSON-файле.
Еще бы примеров побольше, как эти репликации настраивать и все такое.