что такое replica set mongodb
MongoDB от теории к настройке Replica Set + Arbiter
В этой статье разберем основные вопросы по MongoDB:
В нашем случае, развернули Replica Set в локальной сети. За основу взяли дистрибутив Debian 9 и 10 (если настраиваете на CentOS, там примерно всё тоже самое). Материал в статье будет интересен тем, кто первый раз знакомится с MongoDB. Все будем делать поэтапно, с пояснением по каждому моменту.
1. Установка и настройка MongoDB на наши сервера:
Если вы не знаете как поставить MongoDB на ваш Linux, всегда можно обратиться к официальному сайту: docs.mongodb.com (раздел: Install MongoDB > Install MongoDB Community Edition > Install MongoDB Community Edition on Linux >).
Перед началом всех действий, не забываем делать update, далее добавляем репозито́рий: mongodb-org.list и debian-stretch.list:
Делаем update после правки репозитория и ставим libcurl3:
Устанавливаем саму MongoDB: Install MongoDB Server on Debian 10
Данные пакеты входят в пакет выше по умолчанию:
Стартуем при запуске:
Проверяем статус установленной базы:
Повторяем те же действия для остальных. Мы использовали 3 сервера.
2. Настройка конфигурационного файла MongoDB /etc/mongod.conf. Содержимое нашего файла ниже:
Тут мы прописали «0.0.0.0», чтобы был полный охват. Обратим внимание на следующие строки:
Тут указываем имя replSet, у нас это «mongoset» (имя задаете сами для всего Replica Set):
Можно сказать, что основную работу мы сделали. Теперь немного о командах для MongoDB:
3. Создание Primary и Secondary в Replica Set или Deploy a Replica Set:
* Внимание:
Первая проблема, с которой мы столкнулись, это несоответствие версии MongoDB. Так как мы использовали разные версии Linux, при работе с sources.list внесли разные версии «mongodb-org/4.2» и «mongodb-org/4.0», из-за чего они не работали в Replica Set. На это надо обратить внимание!
* Внимание: если возникла ошибка типа:
Process: 2928 ExecStart=/usr/bin/mongod —config /etc/mongod.conf (code=exited, status=1/FAILURE)
Необходимо проверить синтаксис /etc/mongod.conf в части IP и наличие не поврежденных (удаленных) каталогов:
/var/log/mongodb и /var/lib/mongodb/. Если их нет (в нашем случае, при замене версии MongoDB, удалили все каталоги, а новые не встали), то создать и прописать права от mongodb:
Определяем какой из наших серверов будет основным или правильнее сказать Primary, и заходим в MongoDB:
После входа в MongoDB, отразится приглашение для ввода запросов:
Производим «Инициализацию реплики» только для одного (он и будет Primary): Run rs.initiate() on just one and only one mongod instance for the replica set. Для этого используем шаблон с официального сайта:
На основе шаблона, вместо «abc'» пишем наш вариант «mongoset», указанный в файле /etc/mongod.conf. Далее прописываем IP (через данный шаблон можно добавить сразу несколько серверов), мы сделаем один. Остальные добавим позже:
Итогом станет такой вывод:
Проверяем статус rs.status() и видим, что «mongoset:SECONDARY» сменилось на «mongoset:PRIMARY»:
Самый важный элемент кода выше «stateStr» : «PRIMARY»:
Ну вот, мы добавили первый сервер, который сразу стал «PRIMARY»! Продолжим.
3.1. Дальше нам надо добавить остальные сервера из нашей сети, по шаблону с официального сайта:
Добавляем второй сервер или «SECONDARY» из под «mongoset:PRIMARY»:
Итогом станет, появление следующего фрагмента в команде mongoset:PRIMARY> rs.status()
Весь вывод не отражаю, суть понятна! После добавления третьего SECONDARY у нас будут примерно такие статусы при вводе запроса rs.status():
3.2. Другой путь: при котором мы добавляем Primary и Secondary не по отдельности, а сразу все сервера, через шаблон выше:
* Внимание: может возникнуть ошибка, если на начальном этапе вы сразу добавили не один сервер, а несколько. Связанная Host Name. В нашем случае, оказалось, что при выводе команды rs.status() в поле отвечающем за информацию по IP подтянулось значение HostName. Вместо «192.168.0.5:27017», было «debian».
Как исправить? Из под строки ввода запросов MongoDB (проблемного сервера) набираем последовательно следующий список значений, со своим IP:
Если не примет последнюю команду, так как у вас скорее всего будет Secondary, пишем её так:
После чего, перепроверяем через rs.status(), может понадобиться перезагрузка MongoDB, чтобы встало верное значение. Этой же командой можно менять IP в случае переезда MongoDB Secondary с одного IP на другое.
Остальное повторно писать не буду, так же как и выше.
4. Подключение в Replica Set регулятора Arbiter
Если рассматривать «Secondary + Secondary + Primary», то такая система вполне себе рабочая, в случае отказа одного из серверов, оставшиеся два сами перевыберут нужного Primary. Если в этом будет необходимость. Но это не так круто, как использования для этих целей Arbiter. Теперь подробнее.
Обращаясь к официальному сайту, мы можем найти такой шаблон:
Но перед тем как добавлять Arbiter из под Primary, нужно еще пару шагов. Нужно создать директорию под нужды Arbiter:
Дальше ввести данные по шаблону:
И только после этого, добавить сам Arbiter (192.168.0.20):
На выводе запроса rs.status(), получим такой вывод (это часть вывода!):
В итоге у нас такая связка: «ARBITER + Secondary + Primary»
5. Эксперимент: удаляем Secondary и делаем из него Arbiter
Это скорее не раздел для действий, а эксперимент
Мы уже умеем добавлять Primary и Secondary к нему. Но, нам нужно реализовать воображаемую ситуацию: один Secondary сделать ARBITER. Для этого нам надо удалить Secondary, и добавить его уже как ARBITER.
Удаляем ранее добавленный Secondary (IP 192.168.0.5) из под Primary:
Проверяем что получилось, через rs.status(). Итогом станет, что Secondary пропадет из списка. Далее добавляем папки для ARBITER (см. выше) и сам ARBITER через команду на Primary:
Но запрос статуса, выведет вместо «stateStr» : «ARBITER», значение:
Танцы с бубном, привели к следующему решению (не призываю к действию, у вас может быть более логичное решение). Нужно почистить папку на сервере «192.168.0.5 Secondary»:
Выйти из MongoDB, а на Primary ввести запрос, проверить статус:
Надо отметить, что мой PRIMARY временно стал SECONDARY, но после активации ARBITER, все встало на свои места. В данном эксперименте были пропущенные такие шаги как:
Так как если описывать каждый шаг, статья будет в разы больше! Но суть передал максимально точно.
6. Проверка работы Replica Set
Самое главное: проверить работу базы!
И так, Тестирование. Добавим базу на Primary и просмотрим на Secondary.
PRIMARY 192.168.0.9
SECONDARY 192.168.0.14
Проверяем на Secondary:
* тут надо дать пояснение: просто так в базу через Secondary «не зайти/не увидеть»! Так как доступ к базе только из под PRIMARY. Но есть лазейка, использовать rs.slaveOk(). Но на официальном сайте крайне не рекомендуют её применять, что мы и вам советуем. Но у нас база для тестов, была не была:
Всё работает.
7. Разбираем оставшиеся вопросы
Почему важно понимать сколько у вас SECONDARY+PRIMARY+ARBITER:
Важно! Если у вас в связке «1 PRIMARY и 2 SECONDARY», то при выходе из строя PRIMARY, пройдет голосование. Выбор будет между 2х SECONDARY, кто-то из них станет PRIMARY. В итоге останется один SECONDARY и один PRIMARY.
По умолчанию выбор будет случайный среди определенных кандидатов. Можно задавать кто кем будет, назначая вес приоритета выбора.
Суть голосования: в связке с 3 серверами, голосование проходит один раз, большинством голосов: 2/3 против 1/3. Т.е. Если умрут 2 сервера из трех, то последний SECONDARY не сможет назначить себя PRIMARY, так как его голос будет 1/3 от изначальных 3. Это важно понимать!
Другой вариант, у вас 1 PRIMARY, 1 ARBITER, 3 SECONDARY, т.е. всего 5! Если у вас упадет PRIMARY, то большинством 4/5 будет переизбран новый PRIMARY из 3-х оставшихся SECONDARY. Если умрет еще один, т.е. по факту у вас уже 2 умерло, и 3 живых. Голосование пройдет как 3/5. А если умирает уже 3 сервера из 5, то голосование не пройдет, так как голоса будут 2/5 против уже умерших 3/5.
Поэтому нужно понимать сколько вы закладываете серверов и какая отказоустойчивость будет. Надеюсь наш пример и небольшие эксперименты будут для вас полезны!
Ну и на последок, если решите удалить:
MongoDB и адекватная репликация с Replica Set
Устанавливаем, запускаем и проверяем работоспособность сервера
Основной задачей в данный момент является настройка репликации.
MongoDB в отличии от MySQL поддерживает 2 формы репликации:
— реплисеты (Replica Sets)
— ведущий-ведомый (Master-Slave)
Подробности можно узнать на официальном сайте
Обыкновенная настройка Master-Slave не интересна да и не рекомендуется разработчиками. Я хочу проверить реплисеты. Для этого указываю имя реплики для всего сервера, раскоментровав отвечающую за это строку
Перезапускаю сервер для применения изменений.
Есть вероятность, что этот шаг можно было пропустить, так как при создании инстансов вручную указывается одно и тоже имя реплики для каждого процесса. Если кто то попробует — напишите в коментариях о результате
В нашем тестовом окружении необходимо запустить 3 экземпляра сервера. 3 это минимум, необходимый для «правильной» реплики: один из серверов выступает исключительно в роли арбитра и не принимает на себя никакие данные.
Он всего лишь помогает выбрать сервер, который будет PRIMARY. Это его свойство позволяет использовать в качестве арбитра сервер с минимальными ресурсами.
Для имитирования ситуации с 3 разными серверами я создам 3 процесса mongod c отдельным портом и базой:
Создание самих баз и установка необходимого владельца:
Этот сервер будет PRIMARY (Мастер)
Этот сервер будет SECONDARY (слейв)
Этот сервер будет арбитром, не принимающим данных
Подключаемся к основному серверу и настраиваем реплику из консоли mongo
Для проверки подключимся к оставшимся серверам и посмотрим их статус
Видим, что сервер видит реплику и его статус SECONDARY
Аналогично видим, что этот инстанс является частью реплики FirstReplica и выступает в качестве арбитра
Вроде как завелось. Теперь попробую создать реальные условия:
Инициируем «падение» PRIMARY сервера:
Я прибил процесс, на котором висел PRIMARY сервер. Нет процесса — нет доступа к серверу.
Вернёмся к арбитру и проверим состояние реплики:
Видно, что главный сервер недоступен («stateStr» : «(not reachable/healthy)»), а сервер с id 1 стал PRIMARY
Теперь инициируем «поднятие» основного мастера:
И снова интересуемся у арбитра как там дела у сервачков:
Как видно выше сервер после возвращения из даунтайма снова принялся за свои обязанности, став мастером всей реплики. В этом ему помогает арбитр.
На этом простом примере мы рассмотрели создание простой репликации с особенностями, присущими программному продукту MongoDB. Следует учесть, что в данном случае реплика была создана до начала работ с базой данных.
Если имеется уже настроенный продакшн-сервер, то метод создания реплики может отличаться. Обязательно потренеруйтесь в тестовом окружении.
В заключении — очистка всего нашего хозяйства:
Так как я запускал процессы вручную, то и останавливать их нужно самостоятельно.
Для этого воспользуемся db.shutdownServer()
Видим что сервер выключился и в репликации он переключился на SECONDARY
Аналогично останавливаем и остальные, но сначала арбитра, а потом наш SECONDARY
Проверяем
Нет процессов mongod, только наш, который их ищет 🙂
Если базы, которые мы создали для теста более не нужны — их тоже можно удалить. Более того, они не так уж мало занимают
Удаляем и снова проверяем
Так лучше. Люблю порядок на сервере
MongoDB и адекватная репликация с Replica Set : 5 комментариев
Доброго времени суток!
Подскажите, обязательно ли делать отдельный узел-арбитр?
Судя по этому туториалу http://37yonub.ru/articles/mongo-replica-set-docker-localhost арбитр и primary могут быть на одном узле. Или это ошибка?
Еще такой вопрос — как правильно общаться с кластером? Я могу писать только в primary и читать из любого, так?
DNS для записи это mongodb://localhost:27117/?replicaSet=TestMongoReplicaSet&connect=direct
DNS для чтения может быть такой mongodb://localhost:27117,localhost:27217,localhost:27317/?replicaSet=TestMongoReplicaSet&connect=direct
Добрый день. Начнем с того что приведённый вами туториал тоже написан каким то пользователем.
Опираться в данном случае необходимо на официальную документацию
Эта документация гласит что арбитр сам по себе не обязателен. Реплику можно построить и без него.
Далее про чтение/запись.
Запись производится только на Primary.
Чтение так же производится с Primary, но при определённых конфигурациях реплики читать можно напрямую с Secondary. Необходимо выполнить разрешение на мастере с указание ID того секондари, с которого хотите читать.
По поводу «общения» с кластером как указал выше всё проходит через Primary до тех пор пока не настроете иначе
Да, с этим разобрался. Арбитр не принимает трафик, только выбирает кому быть PRIMARY.
А как приложение, использующее кластер монго, работает со сменой PRIMARY сервера?
mongodb://localhost:27117,localhost:27217/?replicaSet=TestMongoReplicaSet&connect=direct&readPreference=secondary
используем DNS со всеми перечисленными репликами и драйвер сам подбирает что есть PRIMARY и пишет туда? Я проверил, вроде работает. Правда есть небольшой промежутой времени (5-10 секунд) с ошибкой «NotMaster» — наверно арбитр назначает primary не сразу.
Вопрос о смене Primary/Secondary немного не по адресу. Это к прогерам которые работают с драйверами
На практике смена Primary происходит меньше секунды в реплике из трёх инстансов Primary/Secondary/Arbiter
О каком DNS идёт речь если у вас везде используется localhost? Не понял вопроса, уточните
Опечатка, DSN (connesion string).
Спасибо за подсказки )) дальше буду разбираться с драйверами )
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Deploy a Replica Set¶
This tutorial describes how to create a three-member replica set from three existing mongod instances running with access control disabled.
To deploy a replica set with enabled access control, see Deploy Replica Set With Keyfile Authentication. If you wish to deploy a replica set from a single MongoDB instance, see Convert a Standalone to a Replica Set. For more information on replica set deployments, see the Replication and Replica Set Deployment Architectures documentation.
Overview¶
Three member replica sets provide enough redundancy to survive most network partitions and other system failures. These sets also have sufficient capacity for many distributed read operations. Replica sets should always have an odd number of members. This ensures that elections will proceed smoothly. For more about designing replica sets, see the Replication overview.
Requirements¶
For production deployments, you should maintain as much separation between members as possible by hosting the mongod instances on separate machines. When using virtual machines for production deployments, you should place each mongod instance on a separate host server serviced by redundant power circuits and redundant network paths.
Before you can deploy a replica set, you must install MongoDB on each system that will be part of your replica set. If you have not already installed MongoDB, see the installation tutorials.
Considerations When Deploying a Replica Set¶
Architecture¶
Hostnames¶
When possible, use a logical DNS hostname instead of an ip address, particularly when configuring replica set members or sharded cluster members. The use of logical DNS hostnames avoids configuration changes due to ip address changes.
IP Binding¶
Connectivity¶
Consider the following:
Ensure that each member of a replica set is accessible by way of resolvable DNS or hostnames. You should either configure your DNS names appropriately or set up your systems’ /etc/hosts file to reflect this configuration.
Each member must be able to connect to every other member. For instructions on how to check your connection, see Test Connections Between all Members.
Configuration¶
Create the directory where MongoDB stores data files before deploying MongoDB.
Specify the mongod configuration in a configuration file stored in /etc/mongod.conf or a related location.
For more information about configuration options, see Configuration File Options.
Procedure¶
The following procedure outlines the steps to deploy a replica set when access control is disabled.
Start each member of the replica set with the appropriate options.В¶
For each member, start a mongod instance with the following settings:
In this tutorial, the three mongod instances are associated with the following hosts:
Установка и настройка MongoDB на Debian, а также ReplicaSet и пара других мелочей
Это руководство описывает пошаговую установку и настройку реплики из 3 узлов mongoDB на базе движка WiredTiger. А также несколько полезных мелочей для людей, впервые столкнувшихся с MongoDB.
Важное уточнение:
Немного о движке WiredTiger
Engine WiredTiger — новый движок mongoDB, использующийся по умолчанию вместо MMAP, начиная с версии 3.4. Хорош тем, что работает с данными на уровне коллекций и отдельных документов, а не полностью базой. Также устраняет проблему Global lock по вышеуказанной причине, из-за чего и был выбран в продакшен.
Установка OS и компонентов
Ставим Debian любой удобной вам версии, у меня использовался 8.6.0.
Для упрощения масштабирования узлов и баз данных, рекомендую использовать lvm.
Из компонентов понадобится только ssh для более удобного доступа к серверу.
Установка MongoDB.
У меня используется бесплатная Community Edition, руководство будет на её основе.
По необходимости допишу Enterpise версию, т.к. она тоже крутилась и разбиралась.
Данное руководство описывается для варианта 3-х серверов (master, slave, arbiter).
Копируем репозиторий и сохраняем изменения.
Обновляем список доступных пакетов
Повторяем процедуру для 3(трех) серверов,
На этом первоначальная настройка завершена.
Теперь переходим к настройке mongoDB.
Настройка и добавление серверов в Replica Set
В начале было слово
Давайте для начала разберемся, что такое replica set.
Replica Set — это кластер серверов MongoDB, реализующий механизм репликации master-slave и автоматическое переключение между ними. Это рекомендуемый механизм репликации от разработчиков MongoDB. ссылка на офф. документацию.
Мы используем механизм репликации, приведенный на картинке:
мастер, два вторичных и арбитр.
Primary — основной сервер mongoDB.
Secondary — точные копии баз(ы) данных с real-time синхронизацией.
Arbiter — сервер выбора вторичной реплики с высшим приоритетом, которая станет главной в случае падения сервера.
ОЧЕНЬ ВАЖНО:
Arbiter отвечает только за выборы преемника, сам стать преемником он не может, поэтому рекомендуется отдавать под арбитра минимальные ресурсы.
ЕЩЁ БОЛЕЕ ВАЖНО:
Технически можно вообще жить без арбитра, однако с ним выборы будут происходить в разы быстрее, соответственно время простоя будет минимизировано. Плюс есть ненулевая вероятность потерять ReplicaSet целиком.
Primary
Настройки пишем в файл /etc/mongod.conf У меня файл выглядит следующим образом:
Указываемые значения переменных:
dbPath — путь к базе данных. При указании на пустое место, создаст там базы. При разворачивании бэкапа подцепит существующую.
journal — включает журналирование.
replSetName — название реплики. Должно быть идентичным у всех узлов внутри реплики.
bindIp — список адресов, с которых можно принимать соединения по порту 27017.
Далее для конфигурирования я использовал саму mongoDB:
попадаем внутрь и первым делом проверяем статус:
Начальный статус должен быть 0 — startup. Означает что узел не является членом ни одной реплики.
Инициализируем реплику.
Выполняем в MongoShell на первичном узле
Сразу после добавления в реплику узел будет в статусе 5 — Startup2, это означает что он присоединился к реплике и в данный момент синхронизируется. Может занять продолжительное время.
Добавляем следующие узлы:
Статусы в rs.status() будут:
1 — Primary
2 — Secondary
7 — Arbiter
Приоритеты
Первый:
Необходимо проставить приоритеты (цифры member id берем из статуса):
Чем выше цифра приоритета, тем ниже сам приоритет при выборе Primary узла.
Второй:
Добавляем узлы с заранее прописанным приоритетом:
Проверяем что все узлы доступны и выставлены с правильными приоритетами:
В моем случае конфиги и статусы приобрели следующий вид:
При добавлении узла в уже существующую реплику она какое-то время будет недоступна в связи с синхронизацией.
На этом установка и настройка MongoDB в режиме ReplicaSet завершена и можно с чистой совестью наполнять базу данными.
Другие полезные команды
Сбрасывание PRIMARY. Смена первичного узла и переназначение приоритетов
60 секунд — время, в течение которого сервер, с которого запущено выполнение команды, не может стать Primary; 40 секунд — время перевыборов нового Primary.
30 секунд — время отключения Primary и перевыборы. Выполнение команды допустимо с любого из серверов mongoDB.
Узел, с которого запущена команда, в течение 60 секунд не сможет стать Primary.
/var/lib/mongodb/ — Тут лежат файлы баз.
Восстановление из дампа:
Восстанавление базы в каталог по умолчанию. Если файл в с таким именем есть, то он перезаписывается:
Восстановление всех баз из указанного каталога:
Восстановление отдельной таблицы(коллекции):
Создание дампа
создание бэкапа всех баз в папку Backup:
создание бэкапа отдельной базы:
создание бэкапа отдельной таблицы:
Запуск от имени root, создание бэкапа указанной базы в указанный каталог + текущая дата:
Большой туториал MongoDB
Репликация
Jan 14, 2018 · 5 min read
Репликация — это синхронизация данных на разных серверах. Репликация помогает избежать сбоев и обесп е чивает высокую доступность. В MongoDB существуют replicaset сервера. К реплицированным кластерам мы можем подключаться и даже распределять нагрузку по чтению. Под репликацией понимается размещение и обслуживание серверов базы данных на нескольких машинах. В MongoDB реализовано две модели репликации: главный-подчиненный и наборы реплик. В обоих случаях единственный первичный узел выполняет все операции записи, после чего вторичные узлы считывают описания этих операций и асинхронно применяют их у себя. В основном используют паттерн наборы реплик, потому что он позволяет дополнительно к основным возможностям, еще и восстановить или развернуть новую базу из реплики. Единственный случай когда мы можем применять главный-подчиненный это случай если у нас больше 11 подчиненных, потому что в наборе реплик может быть только 12 членов.
Основное назначение репликации — обеспечить резервирование. Это означает, что должна поддерживаться связь между узлом и его репликами. Важно отметить, что хотя реплики и обеспечивают резервирование, они далеки от резервного копирование. Резервное копирование — это снимок базы на определенный момент времени, а реплика всегда актуальна.
Минимальная настройка реплик включает в себя 3 узла. 2 экземпляра mongod и третий играет роль арбитра. Начнем с создания каталогов для данных:
Запустим для каждой папки свой процесс mongod :
Нам нужно сконфигурировать набор реплик, для этого подключимся к одному из запущенных экземпляров, но не к арбитру.
После подключения выполним команду:
После чего также добавим арбитра.
Арбитр не реплицирует данные, а выполняет роль наблюдателя. Как следует из названия, этот узел занимается арбитражем, в случае отказа первичного узла, арбитр помогает выбрать новый первичный узел.
Чтобы получить краткую сводку информации о репликах можно воспользоваться командой:
Более подробную информацию можно получить с помощью команды:
Ну что же мы настроили репликацию, теперь можно проверить работает ли она. Подключимся к первичному узлу и попробуем вставить в базу какой нибудь документ:
Данные должно реплицироваться практически мгновенно, подключимся из другого окна терминала к вторичной базе:
Драйвера для базы принимают список реплик к которым они могут подключатся и если одна из реплик недоступна, то драйвер подключится к следующей.
Чтобы разрешить считывание из вторичных узлов, нужно сообщить об этом к подключенному вторичному узлу, с помощью команды:
После чего выберем базу и посмотрим, что в ней:
Проверить отказоустойчивость можно убив один из реплицируемых процессов. Драйвер сам начнет брать данных из рабочего процесса.
Как работает репликация
Набор реплик основан на двух механизмах: Журнал операций(oplog) и тактовый сигнал(heartbeat). Журнал операций делает репликацию возможной, а с помощью тактовых сигналов ведется мониторинг состояния и активируется процедура обработки отказа.
Журнал операций
Это сердце репликаций. Он представляет собой ограниченную коллекцию в базе local на каждом узле, в эту коллекцию записываются все изменения данных, достаточное количество для воспроизведения операции.
Тактовые сигналы
Механизм тактовых сигналов позволяет обеспечить отработку отказа и выбор нового первичного узла. По умолчанию каждый член набор реплик посылает тактовые сигналы всем остальным членам раз в две секунды. Это позволяет в целом отслеживать состояние системы. Если узел перестает отвечать и является первичным, то система автоматически выбирает новый первичный узел из вторичных с самым свежим состоянием.
Фиксация и откат
Мы можем писать в первичный узел весь день напролет, но данные не будут считаться зафиксированными пока они не будут реплицированы в большинство реплик. Представим такую ситуацию. Мы записали данные в первичный узел, но они не успели реплицироваться на вторичный, из за сбоев в сети например и неожиданно главный сервер выходит из строя, вторичный сервер становиться первичным и в него производятся операции записи, но рано или поздно бывший первичный сервер восстановиться и попытается реплицировать данные с нового первичного узла. Проблема в том, что на старом первичном узле имеются записи, которых нет в новом первичном. В такой ситуации инициируется откат. При откате все операции записи, которые не были реплицированы на большинство узлов, отменяются, то есть удаляются из журнала операций вторичного узла из коллекции, которой адресованы. Если мы удалили документ и его следует откатить, то база найдет данный документ в другой реплике и восстановит его.
Работа из драйвера
Все драйвера предлагают более менее единый интерфейс для работы с репликами. Мы всегда можем подключится к одному узлу из набора реплик. При подключении к первичному узлу или одному из набору обычно нет никакой разницы. В обоих случаях драйвер создает сокет соединения и выполняет команду isMaster данная команда возвращает документа такого вида:
Масштабирование чтения
Реплицированные базы данных, прекрасно подходят для масштабирования чтения. Если один сервер не справляется с количеством запросов на чтение, предъявляемых приложением, то эти запросы можно распределить по нескольким репликам. В большинстве драйверов встроена поддержка отправки запросов вторичным узлам. Обычно в драйверах для этого есть специальный флаг при подключении, который разрешает чтение из вторичных реплик. Что позволяет избежать долгого ответа от базы. Если вам все таки стоит выйти за пределы 12 реплик, то стоит посмотреть в сторону шардинга.