Что такое replica set mongodb
Виды репликации в MongoDB
Привет, хабровчане! Расшифровали для вас часть урока по MongoDB от Евгения Аристова, разработчика с 20-летним стажем и автора онлайн-курса «Нереляционные базы данных». Материал, как и сам курс, будет полезен специалистам, сталкивающимся в работе с NoSQL, желающим научиться оптимизировать свои базы данных и работу с ними.
Зачем нужна репликация?
№1. Запись и чтение с основного сервера
У нас есть драйвер клиентского приложения, который читает и пишет на Primary-ноду. Дальше по протоколу репликации информация, которая записывается на Primary-ноду, отправляется на Secondary-ноды.
№2. Чтение с реплики
Альтернативой чтению и записи с Primary является вариант, когда драйвер может читать информацию с Secondary. При этом настройки могут быть разными, например, «читать информацию предпочтительнее с Secondary, а потом с Primary» или «читать информацию с ближайшего по карте сети нода» и т.д. Такие варианты настроек используются чаще, чем первый вариант репликации, где все идет через Primary.
3 способа сделать реплику доступной для чтения:
Проблемы чтения с реплики
Настроен процесс репликации может быть двумя способами
А) Ноды «слушают» друг друга, эта связь называется Heartbeat. То есть каждая нода постоянно проверяется другими на предмет «живая/ неживая», для того, чтобы предпринимать какие-то действия, если что-то случилось.
Б) Одна Secondary-нода меняется на Arbiter. Это очень легковесное приложение, запускается как Mongo, практически не ест ресурсов и отвечает за то, что определяет, какую ноду в момент голосования признать главной. И это в целом рекомендуемая конфигурация.
Основные особенности этой конфигурации
Изучение возможностей MongoDB входит в программу онлайн-курса «Нереляционные базы данных». Курс предназначен для разработчиков, администраторов и других специалистов, которые сталкиваются в работе с NoSQL. На занятиях студенты на практике осваивают наиболее актуальные сегодня инструменты: Cassandra, MongoDB, Redis, ClickHouse, Tarantool, Kafka, Neo4j, RabbitMQ.
Старт уже 30 сентября, но в течение первого месяца можно присоединиться к группе. Изучайте программу, проходите вступительный тест и присоединяйтесь!
Установка и настройка 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 Replication
Overview
How does replication work in MongoDB?
Replication exists primarily to offer data redundancy and high availability. We maintain the durability of data by keeping multiple copies or replicas of that data on physically isolated servers. That’s replication: the process of creating redundant data to streamline and safeguard data availability and durability.
Replication allows you to increase data availability by creating multiple copies of your data across servers. This is especially useful if a server crashes or if you experience service interruptions or hardware failure.
If your data only resides in a single database, any of these events would make accessing the data impossible. But thanks to replication, your applications can stay online in case of database server failure, while also providing disaster recovery and backup options.
With MongoDB, replication is achieved through a replica set. Writer operations are sent to the primary server (node), which applies the operations across secondary servers, replicating the data.
If the primary server fails (through a crash or system failure), one of the secondary servers takes over and becomes the new primary node via election. If that server comes back online, it becomes a secondary once it fully recovers, aiding the new primary node.
How do I enable replication in MongoDB?
To start, you’ll need MongoDB installed on three or more nodes. Each of the nodes in the cluster will need to be able to communicate with the others over a standard port (27017 by default). Additionally, each replica set member needs to have a hostname that is resolvable from the others.
Overview: Network Connectivity
Establish a virtual private network. Ensure that your network topology routes all traffic between members within a single site over the local area network.
Configure access control to prevent connections from unknown clients to the replica set.
Configure networking and firewall rules so that incoming and outgoing packets are permitted only on the default MongoDB port and only from within your deployment. See the IP Binding considerations.
Ensure that each member of a replica set is accessible by way of resolvable DNS or hostnames.
1: Start each member of the replica set with the appropriate options.
2: Connect a mongo shell to one of the mongod instances.
From the same machine where one of the mongod is running, start the mongo shell. To connect to the mongod listening to localhost on the default port of 27017, simply issue:
Depending on how you installed MongoDB and set up your environment, you may need to specify the path to the mongo binary.
3: Initiate the replica set.
MongoDB initiates a replica set, using the default replica set configuration.
4: View the replica set configuration.
Use rs.conf() to display the replica set configuration object:
The replica set configuration object resembles the following:
5: Ensure that the replica set has a primary.
Use rs.status() to identify the primary in the replica set.
How does MongoDB detect replication lag?
Replication lag is a delay in data being copied to a secondary server after an update on the primary server. Short windows of replication lag are normal, and should be considered in systems that choose to read the eventually-consistent secondary data. Replication lag can also prevent secondary servers from assuming the primary role if the primary goes down.
If you want to check your current replication lag:
In a Mongo shell connected to the primary, call the rs.printSlaveReplicationInfo() method.
This returns the syncedTo value for each member, which shows the time when the last oplog entry was written to the secondary server.
Replication lag can be due to several things, including:
Network Latency: Check your ping and traceroute to see if there is a network routing issue or packet loss. See: ping diagonistic documentation, troubleshooting replica sets.
Disk Throughput: Sometimes the secondary server is unable to flush data to disk as rapidly as the primary. This is common on multi-tenant systems, especially if the system accesses disk devices over an IP network. System-level tools, like vmstat or iostat can help you find out more. See: production notes, mongostat.
Concurrency: Long-running operations on the primary can block replications. Set up your write concern so that write operations don’t return if replication can’t keep up with the load. Alternatively, check slow queries and long-running operations via the database profiler. See: Write Concern.
Appropriate Write Concern: If the primary requires a large amount of writes (due to a bulk load operation or a sizable data ingestion), the secondaries may not be able to keep up with the changes on the oplog. Consider setting your write concern to “majority” in order to ensure that large operations are properly replicated.
What is the difference between replication and sharding?
Replication: The primary server node copies data onto secondary server nodes. This can help increase data availability and act as a backup, in case if the primary server fails.
Sharding: Handles horizontal scaling across servers using a shard key. This means that rather than copying data holistically, sharding copies pieces of the data (or “shards”) across multiple replica sets. These replica sets work together to utilize all of the data.
Think of it like a pizza. With replication, you are making a copy of a complete pizza pie on every server. With sharding, you’re sending pizza slices to several different replica sets. Combined together, you have access to the entire pizza pie.
Replication and sharding can work together to form something called a sharded cluster, where each shard is replicated in turn to preserve the same high availability.
What is the benefit of replication?
Replication has several benefits. It increases data availability and reliability thanks to there being multiple live copies of your data.
Replication is also helpful in case of an event like hardware failure or a server crash. Rather than suffer downtime (or, even worse, losing your data entirely), replication ensures your data is safely protected across multiple servers. If you have distributed analytics teams, you can effectively collaborate on business intelligence projects.
Does replication affect latency?
Replication does not meaningfully affect read or write latency to primary servers. Application latency can be improved in cases where it makes sense to read data from replica set secondary nodes, provided you’re okay showing customers eventually-consistent data.
Conclusion
Rather than having to configure and manage everything yourself, you can always use MongoDB Atlas. It streamlines and automates your replica sets, making the process effortless for you. MongoDB Atlas can also deploy globally sharded replica sets with few clicks, enabling data locality, disaster recovery, and multi-region deployments.
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 от теории к настройке 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.
Поэтому нужно понимать сколько вы закладываете серверов и какая отказоустойчивость будет. Надеюсь наш пример и небольшие эксперименты будут для вас полезны!
Ну и на последок, если решите удалить: