Репликация с несколькими мастерами - Multi-master replication
 | Эта статья включает в себя список общих Рекомендации, но он остается в основном непроверенным, потому что ему не хватает соответствующих встроенные цитаты. (Май 2012 г.) (Узнайте, как и когда удалить этот шаблон сообщения) |
Репликация с несколькими мастерами это метод базы данных репликация что позволяет хранить данные группой компьютеров и обновлять их любым членом группы. Все участники реагируют на запросы данных клиентов. Система репликации с несколькими мастерами отвечает за распространение изменений данных, внесенных каждым участником, на остальную часть группы и разрешение любых конфликтов, которые могут возникнуть между одновременными изменениями, внесенными разными участниками.
Репликацию с несколькими мастерами можно противопоставить первичная реплика репликация, при которой один член группы назначается "главным" для данного фрагмента данных и является единственным узлом, которому разрешено изменять этот элемент данных. Другие участники, желающие изменить элемент данных, должны сначала связаться с главным узлом. Разрешение только одного мастера упрощает достижение согласованности среди членов группы, но менее гибко, чем репликация с несколькими мастерами.
Репликацию с несколькими мастерами также можно противопоставить отказоустойчивая кластеризация где пассивные серверы-реплики реплицируют основные данные, чтобы подготовиться к передаче управления в случае, если мастер перестанет работать. Мастер - единственный сервер, активный для взаимодействия с клиентом.
Часто обмен данными и репликация в системах с несколькими ведущими осуществляется через тип Алгоритм консенсуса, но также могут быть реализованы с помощью специальных или проприетарных алгоритмов, специфичных для программного обеспечения.
Основными целями репликации с несколькими главными серверами являются повышение доступности и сокращение времени отклика сервера.[1]
Преимущества
- Доступность: Если один мастер выходит из строя, другие мастера продолжают обновлять база данных.
- Распределенный доступ: Мастера могут быть расположены на нескольких физических площадках, т.е. распределены по сети.
Недостатки
- Последовательность: Большинство систем репликации с несколькими мастерами являются непостоянными, то есть ленивыми и асинхронными, нарушая КИСЛОТА характеристики.
- Спектакль: Системы активной репликации сложны и улучшают взаимодействие задержка.
- Честность: Такие проблемы, как разрешение конфликтов, могут стать неразрешимыми по мере увеличения количества задействованных узлов и увеличения задержки.
Реализации
Справочные службы
Много серверы каталогов основаны на LDAP и реализовать репликацию с несколькими мастерами.
Active Directory
Одна из наиболее распространенных реализаций репликации с несколькими мастерами на серверах каталогов - это Microsoft с Active Directory. В Active Directory объекты, которые обновляются на одном Контроллер домена затем реплицируются на другие контроллеры домена посредством репликации с несколькими хозяевами. Необязательно, чтобы все контроллеры домена реплицировали друг друга, поскольку это может вызвать чрезмерный сетевой трафик в крупных развертываниях Active Directory. Вместо этого у контроллеров домена есть сложный шаблон обновления, который гарантирует своевременное обновление всех серверов без чрезмерного трафика репликации. Однако некоторые потребности Active Directory лучше обслуживаются Гибкая работа с одним мастером.
Каталог CA
Каталог CA поддерживает репликацию с несколькими мастерами.
OpenDS / OpenDJ
OpenDS (и его преемник OpenDJ ) реализован с несколькими мастерами, начиная с версии 1.0. Репликация с несколькими мастерами OpenDS / OpenDJ является асинхронной, в ней используется журнал с механизмом публикации-подписки, который позволяет масштабировать до большого количества узлов. Репликация OpenDS / OpenDJ выполняет разрешение конфликтов на уровне записи и атрибута. Репликация OpenDS / OpenDJ может использоваться через Глобальная сеть.
OpenLDAP
Широко используемый сервер LDAP с открытым исходным кодом реализует репликацию с несколькими мастерами, начиная с версии 2.4 (октябрь 2007 г.). [1].
Системы управления базами данных
Apache CouchDB
Apache CouchDB использует простую систему репликации с несколькими главными серверами на основе HTTP, построенную на использовании хранилища данных только для добавления и использования Многоверсионный контроль параллелизма (MVCC).
Каждый документ содержит идентификатор ревизии, поэтому каждая запись хранит хронологию эволюции всех предыдущих идентификаторов ревизий, ведущих к самой себе, что обеспечивает основу для CouchDB. MVCC система. Кроме того, он хранит индекс по последовательности для всей базы данных. «В процессе репликации копируется только последняя версия документа, поэтому все предыдущие версии, которые были только в исходной базе данных, не копируются в целевую базу данных».[2]
Репликатор CouchDB действует как простой HTTP-клиент, действующий как на источник и цель база данных. Он сравнивает текущие идентификаторы последовательностей для базы данных, вычисляет различия ревизий и вносит необходимые изменения в цель основываясь на том, что он нашел в истории источник база данных. Двунаправленная репликация - это результат простого выполнения другой репликации с источник и цель значения поменялись местами.
ArangoDB
ArangoDB - это собственная система многомодельных баз данных, использующая репликацию с несколькими мастерами. Кластеры в ArangoDB используют модель CP master / master без единой точки отказа. Когда кластер встречает сетевой раздел, ArangoDB предпочитает поддерживать свою внутреннюю согласованность, а не доступность. Клиенты видят базу данных одинаково независимо от того, к какому узлу они подключаются. И кластер продолжает обслуживать запросы даже при выходе из строя одной машины.[3]
Cloudant
Cloudant, распределенная система баз данных, в основном использует тот же HTTP API, что и Apache CouchDB, и предоставляет такую же возможность репликации с помощью Многоверсионный контроль параллелизма (MVCC). Базы данных Cloudant могут реплицироваться между собой, но внутренне узлы в кластерах Cloudant используют репликацию с несколькими мастерами, чтобы оставаться в синхронизации друг с другом и обеспечивать высокую доступность для потребителей API.
Кластер eXtremeDB
eXtremeDB Cluster - это подсистема кластеризации для McObject's eXtremeDB семейство продуктов встроенных баз данных. Он поддерживает согласованность базы данных на нескольких аппаратных узлах путем синхронной репликации транзакций (двухфазная фиксация). Важной характеристикой eXtremeDB Cluster является сделка репликация, в отличие от схем репликации на основе файлов журнала, операторов SQL или других схем репликации, которые могут гарантировать, а могут и не гарантировать успех или неудачу всех транзакций. Соответственно, eXtremeDB Cluster является КИСЛОТА совместимая система (не BASE или возможная последовательность ); запрос, выполненный на любом узле кластера, вернет тот же результат, что и при выполнении на любом другом узле кластера.
Oracle
База данных кластеры реализовать репликацию с несколькими мастерами одним из двух методов. Асинхронный репликация с несколькими мастерами фиксирует изменения данных в очередь отложенных транзакций который периодически обрабатывается во всех базах данных кластера. Синхронный репликация с несколькими хозяевами использует функцию двухфазной фиксации Oracle, чтобы гарантировать, что все базы данных в кластере имеют согласованный набор данных.
Microsoft SQL
Microsoft SQL обеспечивает репликацию с несколькими мастерами посредством одноранговой репликации. Он обеспечивает горизонтальное масштабирование и решение высокой доступности за счет поддержки копий данных на нескольких узлах. Одноранговая репликация, построенная на основе репликации транзакций, распространяет согласованные с транзакциями изменения почти в реальном времени.[4]
MySQL / MariaDB
На базовом уровне можно реализовать схему репликации с несколькими мастерами, начиная с MySQL версии 3.23, с круговой репликацией. Исходя из этого, MariaDB и MySQL поставляется с некоторой поддержкой репликации, каждая из которых имеет свои нюансы.
Что касается прямой поддержки, у нас есть:
MariaDB: изначально поддерживает репликацию с несколькими мастерами, начиная с версии 10.0, но разрешение конфликтов не поддерживается, поэтому каждый мастер должен содержать разные базы данных. В MySQL это называется multi-source, доступным с версии 5.7.6.
MySQL: MySQL Group Replication, плагин для виртуального синхронного мульти-мастера с обработкой конфликтов и распределенным восстановлением, был выпущен с 5.7.17.
Кластерные проекты:
Кластер MySQL поддерживает обнаружение и разрешение конфликтов между несколькими мастерами, начиная с версии 6.3 для истинной возможности нескольких мастеров для MySQL Server.
Также есть внешний проект, Galera Cluster сделано кодерство, который обеспечивает настоящую возможность работы с несколькими мастерами на основе ответвления механизма хранения InnoDB и настраиваемых подключаемых модулей репликации. Репликация синхронная, поэтому конфликт невозможен.
Percona XtraDB Cluster также представляет собой комбинацию библиотеки репликации Galera и MySQL, поддерживающей несколько мастеров.
PostgreSQL
Существуют различные варианты синхронной репликации с несколькими мастерами. Postgres-XL который доступен по общественной лицензии Mozilla, и PostgresXC (теперь известный как Postgres-X2 ), который доступен по той же лицензии, что и сам PostgreSQL, являются примерами. Обратите внимание, что PgCluster (В архиве 2017-07-05 в Wayback Machine ) проект был заброшен в 2007 году.
Документация по репликации для PostgreSQL[5] классифицирует различные доступные типы репликации. Существуют различные варианты распределенного мультимастера, включая Bucardo, рубинреп и BDR Двунаправленная репликация.
PostgreSQL BDR
BDR нацелен на возможное включение в ядро PostgreSQL и был протестирован как демонстрирующий значительно улучшенную производительность.[6] по сравнению с предыдущими вариантами. BDR включает репликацию записи данных (DML), а также изменения в определении данных (DDL) и глобальных последовательностях. Узлы BDR могут быть обновлены онлайн, начиная с версии 0.9. 2ndQuadrant непрерывно разрабатывает BDR с 2012 года, а система используется в производстве с 2014 года. Последняя версия BDR 3.6 обеспечивает обнаружение конфликтов на уровне столбцов, CRDT, активную репликацию, согласованность многоузловых запросов и многие другие функции.
Ingres
В Ingres Replicator, объекты, которые обновляются на одном сервере Ingres, затем могут быть реплицированы на другие серверы, локальные или удаленные, посредством репликации с несколькими мастерами. Если один сервер выходит из строя, клиентские соединения могут быть перенаправлены на другой сервер. Не требуется, чтобы все серверы Ingres в среде реплицировались друг с другом, поскольку это может вызвать чрезмерный сетевой трафик в больших реализациях. Вместо этого Ingres Replicator позволяет реплицировать соответствующие данные на соответствующие серверы без чрезмерного трафика репликации. Это означает, что некоторые серверы в среде могут служить кандидатами для отработки отказа, в то время как другие серверы могут соответствовать другим требованиям, таким как управление подмножеством столбцов или таблиц для решения отдела, подмножеством строк для географического региона или односторонней репликацией для отчетности. сервер. В случае отказа источника, цели или сети целостность данных обеспечивается посредством этого протокол двухфазной фиксации гарантируя, что либо вся транзакция реплицируется, либо ничего не реплицируется. Кроме того, Ingres Replicator может работать через СУБД от нескольких поставщиков.[который? ] соединить их.
Смотрите также
- Гибкая работа с одним мастером
- Active Directory
- Система управления распределенной базой данных
- Перенос зоны DNS
- Оптимистичная репликация
Рекомендации
- ^ Postgres-XC В архиве 2012-07-01 в Wayback Machine под Что такое Postgres-XC?:
Масштабируемость записи означает, что Postgres-XC может быть сконфигурирован с любым количеством серверов баз данных и обрабатывать гораздо больше операций записи (обновляя операторы SQL) по сравнению с тем, что не может делать один сервер базы данных.
- ^ "Репликация Apache CouchDB". Фонд Apache - проект Apache CouchDB.
- ^ «Кластерная архитектура ArangoDB». ArangoDB - Архитектура ArangoDB.
- ^ Одноранговая репликация транзакций
- ^ Сравнение различных решений репликации для PostgreSQL Как указано в документации PostgreSQL 9. Проверено 8 мая 2012 г.
- ^ Производительность BDR Петр Елинек, второй квадрант. Дата обращения 10 июля 2014
внешняя ссылка
- Модель репликации Active Directory
- Термины и определения для репликации базы данных
- SymmetricDS не зависит от базы данных, синхронизация данных программного обеспечения. Он использует веб-технологии и технологии баз данных для репликации таблиц между реляционными базами данных почти в реальном времени. Программное обеспечение было разработано для масштабирования для большого количества баз данных, работы с подключениями с низкой пропускной способностью и выдерживания периодов сбоев в сети. Он поддерживает MySQL, Oracle, SQL Server, PostgreSQL, DB2, Жар-птица, Interbase, HSQLDB, H2, Apache Derby, Informix, Greenplum, SQLite, Sybase ASE, и Sybase ASA. Под лицензией как с открытым исходным кодом (GPL ) и коммерческие лицензии.
- Репликатор нарциссов это Ява инструмент для синхронизация данных, перенос данных, и резервное копирование данных между различными серверами баз данных. Daffodil Replicator работает сверх стандартного JDBC драйвер и поддерживает репликацию в разнородных базах данных. В настоящее время он поддерживает следующие базы данных: Microsoft SQL Server, Oracle, База данных нарциссов, DB2, Apache Derby, MySQL, и PostgreSQL. Daffodil Replicator доступен как для предприятий (коммерческих), так и для предприятий. Открытый исходный код (GPL -лицензионные) версии.
- DMOZ Open Directory Project - страница репликации базы данных