Войти
Репликация с несколькими мастерами - это метод репликации базы данных, который позволяет хранить данные на группе компьютеров и обновлять их любым членом группы. Все участники реагируют на запросы данных клиентов. Система репликации с несколькими мастерами отвечает за распространение изменений данных, внесенных каждым участником, на остальную часть группы и разрешение любых конфликтов, которые могут возникнуть между одновременными изменениями, внесенными разными участниками.
Репликацию с несколькими главными серверами можно противопоставить репликации с первичной репликой, при которой один член группы назначается «главным» для данного фрагмента данных и является единственным узлом, которому разрешено изменять этот элемент данных. Другие участники, желающие изменить элемент данных, должны сначала связаться с главным узлом. Разрешение только одного мастера упрощает достижение согласованности между членами группы, но менее гибко, чем репликация с несколькими мастерами.
Репликацию с несколькими мастерами можно также противопоставить отказоустойчивой кластеризации, когда пассивные серверы реплик реплицируют основные данные, чтобы подготовиться к передаче управления в случае, если мастер перестанет работать. Мастер - единственный сервер, активный для взаимодействия с клиентом.
Часто связь и репликация в системах с несколькими ведущими осуществляются с помощью определенного типа алгоритма консенсуса, но также могут быть реализованы с помощью пользовательских или проприетарных алгоритмов, специфичных для программного обеспечения.
Основными целями репликации с несколькими мастерами являются повышение доступности и сокращение времени отклика сервера.
Многие серверы каталогов основаны на протоколе облегченного доступа к каталогам (LDAP) и реализуют репликацию с несколькими мастерами.
Одним из наиболее распространенных реализаций репликации с несколькими ведущими в серверах каталогов является Microsoft «s Active Directory. В Active Directory объекты, которые обновляются на одном контроллере домена, затем реплицируются на другие контроллеры домена посредством репликации с несколькими главными серверами. Не требуется, чтобы все контроллеры домена реплицировались друг с другом, поскольку это может вызвать чрезмерный сетевой трафик в крупных развертываниях Active Directory. Вместо этого контроллеры домена имеют сложный шаблон обновления, который гарантирует своевременное обновление всех серверов без чрезмерного трафика репликации. Однако некоторые потребности Active Directory лучше удовлетворяются с помощью гибкой операции с одним главным мастером.
CA Directory поддерживает репликацию с несколькими мастерами.
OpenDS (и его последовательный продукт OpenDJ ) реализовал мульти-мастер, начиная с версии 1.0. Репликация OpenDS / OpenDJ с несколькими мастерами является асинхронной, она использует журнал с механизмом публикации-подписки, который позволяет масштабировать до большого количества узлов. Репликация OpenDS / OpenDJ выполняет разрешение конфликтов на уровне записи и атрибута. Репликация OpenDS / OpenDJ может использоваться в глобальной сети.
OpenLDAP, широко используемый сервер LDAP с открытым исходным кодом, реализует репликацию с несколькими мастерами, начиная с версии 2.4 (октябрь 2007 г.) [1].
Amazon Aurora состоит из узлов записи, которые реплицируют записи повторения, и 6 узлов хранения. Узел записи отправляет изменение на каждый узел хранения, каждый из которых проверяет наличие конфликтов, а затем сообщает о подтверждении или отклонении изменения.
Apache CouchDB использует простую систему репликации с несколькими главными серверами на основе HTTP, основанную на использовании хранилища данных только с добавлением и использовании управления параллелизмом нескольких версий (MVCC).
Каждый документ содержит идентификатор ревизии, поэтому каждая запись хранит хронологию эволюции всех предыдущих идентификаторов ревизий, ведущих к самой себе, что составляет основу системы MVCC CouchDB. Кроме того, он поддерживает индекс по последовательности для всей базы данных. «Процесс репликации копирует только последнюю ревизию документа, поэтому все предыдущие ревизии, которые были только в исходной базе данных, не копируются в целевую базу данных».
Репликатор CouchDB действует как простой HTTP-клиент, действующий как для исходной, так и для целевой базы данных. Он сравнивает текущие идентификаторы последовательностей для базы данных, вычисляет различия ревизий и вносит необходимые изменения в целевой объект на основе того, что он нашел в истории исходной базы данных. Двунаправленная репликация - это результат простого выполнения другой репликации с заменой исходного и целевого значений.
ArangoDB - это собственная многомодельная система баз данных, использующая репликацию с несколькими мастерами. Кластеры в ArangoDB используют модель CP master / master без единой точки отказа. Когда кластер встречает сетевой раздел, ArangoDB предпочитает поддерживать внутреннюю согласованность, а не доступность. Клиенты видят базу данных одинаково независимо от того, к какому узлу они подключаются. И кластер продолжает обслуживать запросы, даже если одна машина выходит из строя.
Cloudant, система распределенных баз данных, в основном использует тот же HTTP API, что и Apache CouchDB, и предоставляет ту же возможность репликации с использованием Multiversion Concurrency Control (MVCC). Базы данных Cloudant могут реплицироваться между собой, но внутренне узлы в кластерах Cloudant используют репликацию с несколькими мастерами, чтобы оставаться в синхронизации друг с другом и обеспечивать высокую доступность для потребителей API.
eXtremeDB Cluster - это подсистема кластеризации для семейства продуктов McObject eXtremeDB для встроенных баз данных. Он поддерживает согласованность базы данных на нескольких аппаратных узлах за счет синхронной репликации транзакций (двухфазная фиксация). Важной характеристикой кластера eXtremeDB является репликация транзакций, в отличие от схем репликации на основе файлов журнала, операторов SQL или других схем репликации, которые могут гарантировать, а могут и не гарантировать успех или неудачу всех транзакций. Соответственно, eXtremeDB Cluster является системой, совместимой с ACID (не BASE или возможной согласованности ); запрос, выполненный на любом узле кластера, вернет тот же результат, что и при выполнении на любом другом узле кластера.
Кластеры баз данных реализуют репликацию с несколькими мастерами одним из двух методов. Асинхронная репликация с несколькими мастерами фиксирует изменения данных в очереди отложенных транзакций, которая периодически обрабатывается во всех базах данных в кластере. Синхронная репликация с несколькими главными серверами использует функцию двухфазной фиксации Oracle, чтобы гарантировать, что все базы данных в кластере имеют согласованный набор данных.
Microsoft SQL обеспечивает репликацию с несколькими мастерами посредством одноранговой репликации. Это решение обеспечивает горизонтальное масштабирование и высокую доступность за счет поддержки копий данных на нескольких узлах. Одноранговая репликация, построенная на основе репликации транзакций, распространяет согласованные с транзакциями изменения почти в реальном времени.
На базовом уровне можно реализовать схему репликации с несколькими мастерами, начиная с MySQL версии 3.23, с циклической репликацией. Исходя из этого, MariaDB и MySQL поставляются с некоторой поддержкой репликации, каждая из которых имеет разные нюансы.
Что касается прямой поддержки, у нас есть:
MariaDB: изначально поддерживает репликацию с несколькими мастерами, начиная с версии 10.0, но разрешение конфликтов не поддерживается, поэтому каждый мастер должен содержать разные базы данных. В MySQL это называется multi-source, доступным с версии 5.7.6.
MySQL: MySQL Group Replication, плагин для виртуального синхронного мульти-мастера с обработкой конфликтов и распределенным восстановлением, был выпущен с 5.7.17.
Кластерные проекты:
MySQL Cluster поддерживает обнаружение и разрешение конфликтов между несколькими мастерами, начиная с версии 6.3, для истинной возможности нескольких мастеров для MySQL Server.
Существует также внешний проект Galera Cluster, созданный кодерством, который обеспечивает настоящую возможность работы с несколькими мастерами, основанную на ответвлении механизма хранения InnoDB и настраиваемых подключаемых модулях репликации. Репликация синхронная, поэтому конфликт невозможен.
Percona XtraDB Cluster также представляет собой комбинацию библиотеки репликации Galera и MySQL с поддержкой нескольких мастеров.
Существуют различные варианты синхронной репликации с несколькими мастерами. Postgres-XL, доступный по общественной лицензии Mozilla, и PostgresXC (теперь известный как Postgres-X2 ), который доступен под той же лицензией, что и сам PostgreSQL, являются примерами. Обратите внимание, что проект PgCluster ( Архивировано 05 июля 2017 г. на Wayback Machine ) был заброшен в 2007 году.
В документации по репликации для PostgreSQL классифицируются различные доступные типы репликации. Существуют различные варианты распределенного мультимастера, включая Bucardo, rubyrep и двунаправленную репликацию 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 может работать через СУБД от нескольких поставщиков для их подключения.
