Введение

Метод репликации базы данных

Многомастерная репликация – это метод репликации базы данных, позволяющий хранить данные на группе компьютеров и обновлять их любым участником группы. Все участники отвечают на запросы данных от клиентов. Система многомастерной репликации отвечает за распространение изменений данных, внесенных каждым участником, на остальные узлы группы, и разрешение любых конфликтов, которые могут возникнуть при одновременном изменении данных разными участниками. Многомастерную репликацию можно противопоставить репликации "главный-подчиненный", в которой один участник группы назначается "главным" для определенного элемента данных и является единственным узлом, которому разрешено его изменять. Другие участники, желающие изменить элемент данных, должны сначала обратиться к главному узлу. Ограничение одним главным узлом упрощает обеспечение согласованности между участниками группы, но снижает гибкость по сравнению с многомастерной репликацией. Многомастерную репликацию также можно противопоставить отказоустойчивой кластеризации, где пассивные серверы реплицируют данные главного сервера для подготовки к переключению в случае его отказа. Главный сервер – единственный, активный для взаимодействия с клиентами. Часто коммуникация и репликация в многомастерных системах реализуются с помощью алгоритма консенсуса, но также могут быть реализованы с использованием пользовательских или проприетарных алгоритмов, специфичных для программного обеспечения. Основными задачами многомастерной репликации являются повышение доступности и сокращение времени отклика сервера.

Преимущества

Доступность: в случае отказа одного мастера, другие мастера продолжают обновлять базу данных. Распределенный доступ: мастера могут располагаться в нескольких физических локациях, то есть быть распределенными по сети.

Недостатки

Последовательность: Большинство систем репликации с несколькими ведущими узлами обеспечивают лишь слабую согласованность, то есть являются ленивыми и асинхронными, нарушая свойства ACID. Производительность: Системы немедленной репликации сложны и увеличивают задержку связи. Целостность: Проблемы, такие как разрешение конфликтов, могут стать неразрешимыми по мере увеличения числа участвующих узлов и роста задержки.

Услуги по каталогу

Многие серверы каталогов основаны на протоколе легковесного доступа к каталогам (LDAP) и реализуют многомастерную репликацию.

Активный каталог

Одной из наиболее распространенных реализаций многомастерной репликации в серверах каталогов является Active Directory от Microsoft. В Active Directory объекты, измененные на одном контроллере домена, затем реплицируются на другие контроллеры домена посредством многомастерной репликации. Не обязательно, чтобы все контроллеры домена реплицировались друг с другом, поскольку это привело бы к избыточному сетевому трафику в крупных развертываниях Active Directory. Вместо этого контроллеры домена используют сложный алгоритм обновления, который обеспечивает своевременное обновление всех серверов без чрезмерного трафика репликации. Однако некоторые задачи Active Directory лучше решаются с помощью гибкой схемы работы с одним мастером.

Справочник КА

CA Directory поддерживает репликацию с несколькими ведущими узлами.

OpenDS/OpenDJ

OpenDS (и его преемник OpenDJ) поддерживали мультимастерную репликацию, начиная с версии 1.0. Мультимастерная репликация OpenDS/OpenDJ является асинхронной и использует журнал с механизмом публикации-подписки, что обеспечивает масштабируемость до большого числа узлов. Репликация OpenDS/OpenDJ выполняет разрешение конфликтов на уровне записей и атрибутов. Репликация OpenDS/OpenDJ может использоваться в глобальных сетях.

OpenLDAP (открыть)

OpenLDAP, широко используемый сервер LDAP с открытым исходным кодом, реализует многомастерную репликацию, начиная с версии 2.4 (октябрь 2007 года).

Амазонская Аврора

Amazon Aurora состоит из узлов-писателей, которые реплицируют записи повторного применения, и 6 узлов хранения. Узел-писатель отправляет изменения каждому узлу хранения, каждый из которых проверяет наличие конфликтов и затем сообщает о подтверждении или отклонении этого изменения.

Apache CouchDB (англ.) (недоступная ссылка)

Apache CouchDB использует простую систему многомастерской репликации на основе HTTP, построенную на использовании хранилища данных, допускающего только добавление, и механизма Multiversion Concurrency Control (MVCC). Каждый документ содержит идентификатор ревизии, поэтому каждая запись хранит эволюционную историю всех предыдущих идентификаторов ревизий, ведущих к текущей – это обеспечивает основу системы MVCC в CouchDB. Кроме того, поддерживается индекс по последовательности для всей базы данных. "Процесс репликации копирует только последнюю ревизию документа, поэтому все предыдущие ревизии, которые были только в исходной базе данных, не копируются в целевую базу данных". Репликатор CouchDB выступает в роли простого HTTP-клиента, работающего как с одной, так и с другой базой данных. Он сравнивает текущие идентификаторы последовательности для баз данных, вычисляет различия в ревизиях и вносит необходимые изменения в целевую базу данных на основе истории исходной базы данных. Двунаправленная репликация достигается путем повторного выполнения репликации с обратной заменой исходной и целевой базы данных.

АрангоДБ

ArangoDB — это нативная многомодельная система управления базами данных, использующая многомастерную репликацию. Кластеры в ArangoDB используют модель CP "мастер-мастер" без единой точки отказа. При возникновении сетевого разделения в кластере, ArangoDB приоритезирует внутреннюю согласованность данных над доступностью. Клиенты получают согласованное представление базы данных, независимо от того, к какому узлу они подключены. И кластер продолжает обрабатывать запросы даже при выходе из строя одного из серверов.

Облакатель

Cloudant, распределенная система баз данных, использует преимущественно тот же HTTP API, что и Apache CouchDB, и предоставляет аналогичные возможности репликации с применением многоверсионного управления конкурентным доступом (MVCC). Базы данных Cloudant могут реплицироваться между собой, однако внутри кластеров Cloudant узлы используют репликацию "много мастеров" для поддержания синхронизации и обеспечения высокой доступности для пользователей API.

Кластер eXtremeDB

eXtremeDB Cluster — это подсистема кластеризации для семейства продуктов встроенных баз данных eXtremeDB от McObject. Она обеспечивает согласованность данных между несколькими аппаратными узлами посредством синхронной репликации транзакций (с использованием двухфазной фиксации). Важной особенностью eXtremeDB Cluster является репликация именно транзакций, в отличие от схем репликации, основанных на файлах журналов, SQL-запросах или других подходах, которые не всегда гарантируют успешное завершение или откат всей транзакции. Таким образом, eXtremeDB Cluster соответствует требованиям ACID (а не BASE или принципу "в конечном итоге согласованности"); любой запрос, выполненный на любом узле кластера, вернет тот же результат, что и при выполнении на любом другом узле кластера.

Оракул

Кластеры баз данных реализуют репликацию с несколькими ведущими узлами одним из двух способов. Асинхронная репликация с несколькими ведущими узлами фиксирует изменения данных в отложенную очередь транзакций, которая периодически обрабатывается на всех базах данных в кластере. Синхронная репликация с несколькими ведущими узлами использует двухфазную фиксацию Oracle для обеспечения согласованности наборов данных во всех базах данных кластера.

Microsoft SQL (англ.) (англ.)

Microsoft SQL обеспечивает репликацию с несколькими мастерами посредством репликации типа "одноранговый узел к одноранговому узлу". Она предоставляет решение для масштабирования и высокой доступности, поддерживая копии данных на нескольких узлах. Основываясь на транзакционной репликации, репликация "одноранговый узел к одноранговому узлу" распространяет транзакционно согласованные изменения практически в реальном времени.

PostgreSQL (после гресклюля)

Существуют различные варианты синхронной репликации с несколькими мастерами. Postgres XL, распространяемый под Mozilla Public License, и PostgresXC (теперь известный как Postgres X2), распространяемый под той же лицензией, что и PostgreSQL, являются примерами. Обратите внимание, что проект PgCluster был прекращен в 2007 году. Документация PostgreSQL по репликации классифицирует различные типы доступной репликации. Существуют различные варианты распределенной репликации с несколькими мастерами, включая Bucardo, rubyrep и BDR (двунаправленная репликация).

PostgreSQL BDR (послесле гресклюлюля)

BDR разрабатывается с целью последующего включения в ядро PostgreSQL и, согласно результатам тестирования, демонстрирует значительно более высокую производительность по сравнению с предыдущими решениями. BDR обеспечивает репликацию операций записи данных (DML), а также изменений в определении данных (DDL) и глобальных последовательностей. Узлы BDR могут быть обновлены в режиме онлайн, начиная с версии 0.9. Компания 2ndQuadrant непрерывно разрабатывает BDR с 2012 года, а данная система используется в производственной среде с 2014 года. Последняя версия BDR 3.6 предоставляет обнаружение конфликтов на уровне столбцов, CRDT, нетерпеливую репликацию, согласованность запросов на нескольких узлах и множество других функций.

Ингрес

В рамках Ingres Replicator объекты, обновленные на одном сервере Ingres, могут быть реплицированы на другие серверы – локальные или удаленные – с использованием многомастерной репликации. В случае отказа одного сервера клиентские подключения могут быть перенаправлены на другой сервер. Не обязательно, чтобы все серверы Ingres в среде реплицировались друг с другом, поскольку это может привести к избыточному сетевому трафику в крупных установках. Вместо этого, Ingres Replicator позволяет реплицировать соответствующие данные на нужные серверы, избегая избыточного трафика репликации. Это означает, что некоторые серверы в среде могут выступать в качестве резервных, а другие – выполнять другие задачи, такие как управление подмножеством столбцов или таблиц для решения задач конкретного отдела, подмножеством строк для географического региона или односторонняя репликация для сервера отчетов. В случае сбоя источника, целевого сервера или сети целостность данных обеспечивается посредством двухфазного протокола фиксации, гарантируя, что либо вся транзакция будет реплицирована, либо ни одна ее часть. Кроме того, Ingres Replicator может взаимодействовать с СУБД от различных поставщиков, обеспечивая их соединение.