Введение в репликацию

Одна из сильных сторон CouchDB — возможность синхронизировать две копии одной базы данных. Это позволяет пользователям распределять данные между несколькими узлами или центрами обработки данных, а также размещать данные ближе к клиентам.

Репликация выполняется между исходной и целевой базами данных, которые могут находиться как на одном, так и на разных экземплярах CouchDB. Цель репликации — чтобы по её завершении все активные документы из исходной базы данных присутствовали в целевой, а все документы, удалённые в исходной базе, были удалены и в целевой (если они там вообще существовали).

Временная и постоянная репликация

Существует два разных способа настроить репликацию. Первый способ, появившийся в CouchDB, создаёт репликацию, которую можно назвать временной. Временная означает, что репликация не сохраняется в документах. Поэтому после перезапуска сервера CouchDB репликация исчезнет. Позже появилась база данных _replicator, в которой хранятся документы с параметрами репликации. Такую репликацию можно назвать постоянной. Временные репликации сохранены для обратной совместимости. Обе репликации могут находиться в разных состояниях репликации.

Запуск, остановка и мониторинг репликации

Постоянная репликация управляется с помощью документа в базе данных _replicator, где каждый документ описывает один процесс репликации (см. Настройки репликации). Для настройки временной репликации можно использовать конечную точку API /_replicate. Репликация запускается отправкой объекта JSON либо на конечную точку _replicate, либо сохранением его в виде документа в базе данных _replicator.

Если репликация выполняется в данный момент, её состояние можно проверить с помощью API активных задач (см. /_active_tasks, Состояние репликации и /_scheduler/jobs).

Для репликации на основе документов можно использовать /_scheduler/docs, чтобы получить полную сводку состояния. Этот API предпочтительнее, поскольку он показывает состояние документа репликации до того, как тот станет заданием репликации.

Для временных репликаций невозможно узнать их состояние после завершения задания.

Репликацию можно остановить, удалив документ или обновив его, установив свойство cancel в значение true.

Процедура репликации

Во время репликации CouchDB сравнивает исходную и целевую базы данных, чтобы определить, какие документы в них различаются. Для этого CouchDB отслеживает ленты изменений исходной базы данных и сравнивает документы с целевой базой. Изменения отправляются в целевую базу пакетами, что может приводить к конфликтам. Документы, уже существующие в целевой базе с той же ревизией, не передаются. Поскольку удаление документа представлено новой ревизией, документ, удалённый в исходной базе, будет также удалён в целевой.

Задание репликации завершается, когда достигает конца ленты изменений. Если для его свойства continuous установлено значение true, оно будет ожидать появления новых изменений, пока задача не будет отменена. Задания репликации также создают контрольные документы в целевой базе, чтобы перезапущенное задание могло продолжить работу с места остановки, например после сбоя.

Если задание репликации запускается на отправляющем узле, это называется репликацией push; если на принимающем узле — репликацией pull.

Репликация «ведущий — ведущий»

Одно задание репликации передаёт изменения только в одном направлении. Для реализации репликации «ведущий — ведущий» можно настроить два задания репликации в противоположных направлениях. Когда первое задание реплицирует изменение из базы данных A в базу B, второе задание, направленное из B в A, обнаружит, что новое изменение в B уже есть в A, и будет ожидать дальнейших изменений.

Управление выбором документов для репликации

Есть три способа управлять тем, какие документы реплицируются, а какие пропускаются:

Определить документы как локальные.
Использовать объекты-селекторы.
Использовать функции-фильтры.

Локальные документы никогда не реплицируются (см. Локальные (не реплицируемые) документы).

Объекты-селекторы можно включить в документ репликации (см. Настройки репликации). Объект-селектор содержит выражение запроса, которое используется для проверки того, следует ли реплицировать документ.

В репликации можно использовать функции-фильтры (см. Настройки репликации). Задание репликации применяет функцию-фильтр к каждому документу в ленте изменений. Документ реплицируется, только если фильтр возвращает true.

Примечание

Использование селектора повышает производительность по сравнению с использованием функций-фильтров. По возможности следует использовать объекты-селекторы.

Примечание

При использовании фильтров репликации, зависящих от содержимого документа, удалённые документы могут вызывать проблемы, поскольку документ, передаваемый фильтру, не будет содержать никаких данных документа. Эту проблему можно решить, добавив в документ поле _deleted:true вместо использования метода DELETE HTTP, а также применив обработчик проверки обновления документа, чтобы необходимые для фильтров репликации поля всегда присутствовали. Однако учтите, что удалённый документ по-прежнему будет содержать все свои данные (включая вложения)!

Передача данных клиентам

Репликация может быть особенно полезна для размещения данных ближе к клиентам. PouchDB реализует алгоритм репликации CouchDB на JavaScript, позволяя сделать данные из базы CouchDB доступными в офлайн-приложении браузера и синхронизировать изменения обратно с CouchDB.