Какой лучший способ двунаправленной синхронизации динамических данных в режиме реального времени с использованием MySQL

Question

Вот сценарий. 2 веб-сервера в двух разных местах, имеющие две базы данных mysql с одинаковыми таблицами. Ожидается, что данные в таблицах будут идентичны в режиме реального времени.

Вот проблема. если пользователь в любом месте одновременно вводит новую запись в идентичные таблицы, как показано в двух первых таблицах ниже, где третья запись в каждой таблице была введена разными людьми одновременно. Данные в таблицах больше не идентичны. Каков наилучший способ сохранить данные в режиме реального времени идентичными, как показано в третьей таблице ниже, независимо от того, где происходят обновления? Таким образом, на рисунках ниже вместо 3 строк в каждой таблице новые записи дублируются в двух направлениях и вставляются в обе таблицы, чтобы на этот раз снова создать 2 идентичные таблицы с 4 столбцами?

Server A in Location A
==============

Table Names
| ID| NAME  |
|-----------|
| 1 | Tom   |
| 2 | Scott |
|-----------|
| 3 | John  |
|-----------|

Server B in Location B
==============
Table Names
| ID| NAME  |
|-----------|
| 1 | Tom   |
| 2 | Scott |
|-----------|
| 3 | Peter |
|-----------|


Expected Scenario
===========
Table Names
| ID| NAME  |
|-----------|
| 1 | Tom   |
| 2 | Scott |
| 3 | Peter |
| 4 | John  |
|-----------|

Answer 1

Производительность репликации базы данных на двух основных устройствах невелика. Однако, если вы правильно закодируете свое приложение, вы получите отличную отработку отказа.

Настройка Master-Master, по сути, такая же, как и настройка Slave-Master, но при этом запущены как Slave, так и важные изменения в ваших конфигурационных файлах на каждой коробке.

Мастер MySQL 1:

auto_increment_increment = 2
auto_increment_offset = 1 

Мастер MySQL 2:

auto_increment_increment = 2
auto_increment_offset = 2

Эти два параметра гарантируют, что, когда два сервера по какой-то причине борются за первичный ключ, они не дублируют и не уничтожают репликацию. Вместо увеличения на 1 любое поле автоинкремента будет по умолчанию увеличиваться на 2. В одном блоке начнется смещение от 1 и будет выполняться последовательность 1 3 5 7 9 11 13 и т. Д. Во втором блоке начнется смещение в 2 и бегите вдоль 2 4 6 8 10 12 и т. д. В результате текущего тестирования автоинкремент, по-видимому, берет следующий свободный номер, а не тот, который был ранее.
Например. Если сервер 1 вставляет первые 3 записи (1, 3 и 5), а сервер 2 вставляет четвертую, ему будет присвоен ключ 6 (а не 2, который не используется).

Как только вы это настроите, запустите их обоих как Рабов.
Затем, чтобы проверить, что оба работают нормально, подключитесь к обеим машинам и выполните команду SHOW SLAVE STATUS, и вы должны заметить, что оба значения: Slave_IO_Running и Slave_SQL_Running должны сказать «ДА» на каждом поле.

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

Затем выполните все тесты, чтобы убедиться, что вы можете выполнять все стандартные приложения на каждом боксе с его репликацией на другой.

Это относительно просто, как только это произойдет.
Но, как уже упоминалось, MySQL не одобряет это и советует вам убедиться, что вы помните об этой функциональности при написании кода приложения.

Редактировать: Я полагаю, теоретически возможно добавить больше мастеров, если вы убедитесь, что смещения правильны и так далее. Вы могли бы более реалистично, хотя, добавить несколько дополнительных рабов.

Answer 2

MySQL не поддерживает синхронную репликацию, однако, даже если бы она это сделала, вы, вероятно, не захотите ее использовать (не может не сказаться на производительности, ожидая синхронизации другого сервера при каждой фиксации транзакции).

Вам придется рассмотреть более подходящие архитектурные решения для этого - есть продукты сторонних производителей, которые будут выполнять слияние и разрешать конфликты заранее определенным образом - это действительно единственный способ.

Ожидать, что ваша архитектура будет функционировать таким образом, наивно - нет «легкого решения» для любой базы данных, не только для MySQL.

Answer 3

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

Answer 4

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

Но MySQL разрешает только одностороннюю репликацию, поэтому вы не можете просто решить вашу проблему в этой конфигурации.

Для ясности, вы можете "настроить" двустороннюю репликацию, но MySQL AB препятствует этому .