Кластеризация mongoDb

MongoDb поддерживает репликацию баз данных в том числе в режиме реального времени.

Цели репликации в mongoDb

• Failover.  Пережить падение железа
• Улучшение перфоманса. Можно добиться улучшения производительности для приложений, где количество чтений значительно превосходит количество записей. Распределив нагрузку на чтение по разным серверам.

• Уменьшение отклика. Позволить разным нодам общаться с теми репликами, которые находятся наиболее близко географически.
• Есть дубликат базы, который обновляется раз в 30 минут.  Например, мы можем захотеть увидеть какие-то тенденции, каким образом обновляются данные, сравнивая их между собой (сравнивая данные в реплике и основной базе)
• Например, нам надо делать бекапы с данными, которые меняются очень часто и данных много. Если использовать обычные инструменты для бекапа, то это может занимать много времени.
• Строить какие-то сложные отчеты по данным. Запросы могут оказаться довольно тяжелыми для основной базы, поэтому лучше делать их на реплике.
• Имеется стаджинг, который требует реальных данных для тестирования. Тестирование кода с использованием базы продакшена может привести к потере данных. Имея репликациюв виде стеджинга этого не произойдет

Oplog

Что-то вроде транзакционного лога (журнала), который использует mongoDb. Oplog имеет фиксированный размер (настраиваемый), новые записи со времнем перетирают старые. Slave переодически просматривает Oplog в поисках изменных данных, и синхронизируется с мастером. Размер лога должен быть выбран таким образом, чтобы Slave “успевал” понять, насколько далеко он находится от мастера до того, как новые изменения в Oplog перетрут старые.


Типы репликаций

• Single master/ Single slave. Простейший вид репликации, не предусматривает автоматического failover. Если мастер упадет, приложение должно само определить, что пора идти к Slave

• Single master/ Multiple slave. Трудно представить зачем это может быть нужно

• Multiple master/ Single slave Например, есть 2 разных базы, 2 разных приложения, расположенных на разных серверах. Все данные можно реплицировать в один Slave, например для построения тяжелых отчетов. Важно то, что нельзя реплицировать одну и ту же базу с разных мастеров. (имена баз должны быть уникальны)

• Cascade replication. Master - > Slave/Master - > Slave. Данные пишутся на основной мастер, сразу же на Slave/Master, а потом через какое-то время на Slave. 
• Master/Master replication. Кластер всегда будет оставаться в синхронизированном состоянии, клиенты могут писать и читать с обоих инстантов.
• Intervealed replication. Может быть использовано для экономии места, когда есть несколько приложений, работающих на разных серверах. Один может быть мастером для одной базы и слейвом для другой и наоборот. Master app A / Slave app B ⇔ Master app B / Slave app A
• Repilca pairs. Deprecated since mongoDb 1.4 in favoe to Replica Set (другой механизм) Отличается от Single master/Single slave тем, что в случае падения мастера, слейв возьмет на себя его роль. При чем когда мастер неожиданно проснется после своего падения, он поймет, что пора ему становится slave-ом. Понятно, что в таком случае приложение должно знать об обоих серверах. Драйвера для всех языков mongoDb поддерживают эту возможность.
• Replica set. Replica set поддерживают намного более гибкую конфигурацию чем replica pairs.  Если в кратце, серверов может быть много в реплике каждый из них - это secondary/primary и active/passive. (я пользуюсь терминологией mongoDb)  Master - один, это и есть primary. Secondary - это slave-ы, их может быть много. В случае падения master, все слейвы, у которых статус active будут участвовать в “голосовании”, кто же из них станет master. Passive слейвы мастером никогда не станут, т.к возможно используются для отчетности.