[MongoDB, Администрирование баз данных] Виды репликации в MongoDB
Автор
Сообщение
news_bot ®
Стаж: 6 лет 7 месяцев
Сообщений: 27286
Привет, хабровчане! Расшифровали для вас часть урока по 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”} ] )
Проблемы чтения с реплики
- Так как запись асинхронная, она может быть уже сделана на 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 сентября, но в течение первого месяца можно присоединиться к группе. Изучайте программу, проходите вступительный тест и присоединяйтесь!
===========
Источник:
habr.com
===========
Похожие новости:
- [Анализ и проектирование систем, Программирование, Промышленное программирование, Системы управления версиями] О системах контроля версий
- [Open source, PostgreSQL, Администрирование баз данных] Знакомство с pg_probackup. Вторая часть
- [Big Data, SQL, Администрирование баз данных, Системное администрирование] Переезжаем на ClickHouse: 3 года спустя
- [Управление продуктом] No-code: продакты против больших трат денег
- [MySQL, Администрирование баз данных, Программирование, Хранение данных] История о физическом удалении 300 миллионов записей в MySQL (перевод)
- [Искусственный интеллект, Машинное обучение] Инструмент AI распознает изображения жестокого обращения с детьми с точностью в 99% (перевод)
- [Алгоритмы, Программирование] Удаление узлов из красно-чёрного дерева
- [Flutter, Разработка мобильных приложений] InheritedWidget во Flutter (перевод)
- [MongoDB, Node.JS, Python] Top 10 Full Stack Development Companies to Check Out in 2020
- [Высокая производительность, Анализ и проектирование систем, Промышленное программирование, Распределённые системы] Выбор архитектурного стиля (часть 3)
Теги для поиска: #_mongodb, #_administrirovanie_baz_dannyh (Администрирование баз данных), #_mongodb, #_nosql, #_blog_kompanii_otus._onlajnobrazovanie (
Блог компании OTUS. Онлайн-образование
), #_mongodb, #_administrirovanie_baz_dannyh (
Администрирование баз данных
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 06-Окт 00:53
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 7 месяцев |
|
|
Привет, хабровчане! Расшифровали для вас часть урока по MongoDB от Евгения Аристова, разработчика с 20-летним стажем и автора онлайн-курса «Нереляционные базы данных». Материал, как и сам курс, будет полезен специалистам, сталкивающимся в работе с NoSQL, желающим научиться оптимизировать свои базы данных и работу с ними. Зачем нужна репликация? 1. Высокая доступность. Бэкап это хорошо, но нужно время на его развертывание. 2. Горизонтальное масштабирование. В случае, когда закончились физические ядра и память у сервера. 3. Бэкап лучше делать с реплики, а не с мастера. 4. Геораспределение нагрузки. В MongoDB видов репликации из коробки немного: самый актуальный на данный момент Replicaset, а второй — Master-slave, который ограничен версией 3.6 и подробно рассматриваться в этой статье не будет. №1. Запись и чтение с основного сервера У нас есть драйвер клиентского приложения, который читает и пишет на Primary-ноду. Дальше по протоколу репликации информация, которая записывается на Primary-ноду, отправляется на Secondary-ноды.  №2. Чтение с реплики Альтернативой чтению и записи с Primary является вариант, когда драйвер может читать информацию с Secondary. При этом настройки могут быть разными, например, «читать информацию предпочтительнее с Secondary, а потом с Primary» или «читать информацию с ближайшего по карте сети нода» и т.д. Такие варианты настроек используются чаще, чем первый вариант репликации, где все идет через Primary.  3 способа сделать реплику доступной для чтения:
Проблемы чтения с реплики
Настроен процесс репликации может быть двумя способами: А) Ноды «слушают» друг друга, эта связь называется Heartbeat. То есть каждая нода постоянно проверяется другими на предмет «живая/ неживая», для того, чтобы предпринимать какие-то действия, если что-то случилось.  Б) Одна Secondary-нода меняется на Arbiter. Это очень легковесное приложение, запускается как Mongo, практически не ест ресурсов и отвечает за то, что определяет, какую ноду в момент голосования признать главной. И это в целом рекомендуемая конфигурация.  Основные особенности этой конфигурации:
Если вам интересно узнать больше о кластерных возможностях MongoDB, посмотреть запись всего демо-урока можно тут. На занятии Евгений Аристов демонстрирует отличия Replicaset от Master-slave, объясняет процесс кворума, масштабирование, шардирование и правильный подбор ключа к шардированию. Изучение возможностей MongoDB входит в программу онлайн-курса «Нереляционные базы данных». Курс предназначен для разработчиков, администраторов и других специалистов, которые сталкиваются в работе с NoSQL. На занятиях студенты на практике осваивают наиболее актуальные сегодня инструменты: Cassandra, MongoDB, Redis, ClickHouse, Tarantool, Kafka, Neo4j, RabbitMQ. Старт уже 30 сентября, но в течение первого месяца можно присоединиться к группе. Изучайте программу, проходите вступительный тест и присоединяйтесь! =========== Источник: habr.com =========== Похожие новости:
Блог компании OTUS. Онлайн-образование ), #_mongodb, #_administrirovanie_baz_dannyh ( Администрирование баз данных ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 06-Окт 00:53
Часовой пояс: UTC + 5