Как стать автором
Обновить
208.15
Рейтинг
OTUS
Цифровые навыки от ведущих экспертов

Виды репликации в MongoDB

Блог компании OTUS MongoDB *Администрирование баз данных *


Привет, хабровчане! Расшифровали для вас часть урока по MongoDB от Евгения Аристова, разработчика с 20-летним стажем и автора онлайн-курса «Нереляционные базы данных». Материал, как и сам курс, будет полезен специалистам, сталкивающимся в работе с NoSQL, желающим научиться оптимизировать свои базы данных и работу с ними.

Зачем нужна репликация?


  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”} ] )

Проблемы чтения с реплики


  1. Так как запись асинхронная, она может быть уже сделана на Primary, но не доехать до Secondary, поэтому будут прочитаны старые данные с Secondary.
  2. Записав данные на основной, нельзя быть уверенным, когда остальные получат эти данные.
    Чтобы было все синхронно, каждая нода должна подтвердить получение данных. Сейчас в MongoDB есть общие настройки, а есть на каждый запрос, где можно указать, от скольки нод ожидается подтверждение запроса.
  3. Когда падает основной сервер, запускается процесс выборов (кворум) — а это уже особое отдельное «веселье».

Настроен процесс репликации может быть двумя способами


А) Ноды «слушают» друг друга, эта связь называется 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 сентября, но в течение первого месяца можно присоединиться к группе. Изучайте программу, проходите вступительный тест и присоединяйтесь!
Теги: mongodbnosql
Хабы: Блог компании OTUS MongoDB Администрирование баз данных
Всего голосов 12: ↑11 и ↓1 +10
Комментарии 8
Комментарии Комментарии 8

Похожие публикации

Лучшие публикации за сутки

Информация

Дата основания
Местоположение
Россия
Сайт
otus.ru
Численность
51–100 человек
Дата регистрации
Представитель
OTUS

Блог на Хабре