Зачем нужна репликация?
1. Высокая доступность. Бэкап это хорошо, но нужно время на его развертывание.
2. Горизонтальное масштабирование. В случае, когда закончились физические ядра и память у сервера.
3. Бэкап лучше делать с реплики, а не с мастера.
4. Геораспределение нагрузки.
В MongoDB видов репликации из коробки немного: самый актуальный на данный момент Replicaset, а второй Master-slave, который ограничен версией 3.6 и подробно рассматриваться в этой статье не будет.
1. Запись и чтение с основного сервера
У нас есть драйвер клиентского приложения, который читает и пишет на Primary-ноду. Дальше по протоколу репликации информация, которая записывается на Primary-ноду, отправляется на Secondary-ноды.
2. Чтение с реплики
Альтернативой чтению и записи с Primary является вариант, когда драйвер может читать информацию с Secondary. При этом настройки могут быть разными, например, читать информацию предпочтительнее с Secondary, а потом с Primary или читать информацию с ближайшего по карте сети нода и т.д. Такие варианты настроек используются чаще, чем первый вариант репликации, где все идет через Primary.
3 способа сделать реплику доступной для чтения:
- Указать
db.slaveOk() - Указать в строке подключения драйвера нужные параметры
- Указать все, а потом более точечно прописать в самом запросе,
например, читай из Secondary в Южном регионе:
db.collection.find({}).readPref( secondary, [ { region: South} ] )
Проблемы чтения с реплики
- Так как запись асинхронная, она может быть уже сделана на Primary, но не доехать до Secondary, поэтому будут прочитаны старые данные с Secondary.
- Записав данные на основной, нельзя быть уверенным, когда
остальные получат эти данные.
Чтобы было все синхронно, каждая нода должна подтвердить получение данных. Сейчас в MongoDB есть общие настройки, а есть на каждый запрос, где можно указать, от скольки нод ожидается подтверждение запроса. - Когда падает основной сервер, запускается процесс выборов (кворум) а это уже особое отдельное веселье.
Настроен процесс репликации может быть двумя способами:
А) Ноды слушают друг друга, эта связь называется Heartbeat. То есть каждая нода постоянно проверяется другими на предмет живая/ неживая, для того, чтобы предпринимать какие-то действия, если что-то случилось.
Б) Одна Secondary-нода меняется на Arbiter. Это очень легковесное приложение, запускается как Mongo, практически не ест ресурсов и отвечает за то, что определяет, какую ноду в момент голосования признать главной. И это в целом рекомендуемая конфигурация.
Основные особенности этой конфигурации:
- Репликация асинхронная
- Арбитр не содержит данных, и поэтому очень легковесный
- Primary может стать Secondary и наоборот. Арбитр не может стать ни Primary, ни Secondary
- Максимальное количество реплик 50 и только 7 из них имеют право голосовать
- Arbiter можно установить и на Primary или Secondary, но делать это не рекомендуется, т.к. если этот сервер упадет, Arbiter тоже не сможет выполнить свою функцию.
Если вам интересно узнать больше о кластерных возможностях MongoDB, посмотреть запись всего демо-урока можно тут. На занятии Евгений Аристов демонстрирует отличия Replicaset от Master-slave, объясняет процесс кворума, масштабирование, шардирование и правильный подбор ключа к шардированию.
Изучение возможностей MongoDB входит в программу онлайн-курса Нереляционные базы данных. Курс предназначен для разработчиков, администраторов и других специалистов, которые сталкиваются в работе с NoSQL. На занятиях студенты на практике осваивают наиболее актуальные сегодня инструменты: Cassandra, MongoDB, Redis, ClickHouse, Tarantool, Kafka, Neo4j, RabbitMQ.
Старт уже 30 сентября, но в течение первого месяца можно присоединиться к группе. Изучайте программу, проходите вступительный тест и присоединяйтесь!
