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

вот сценарий. 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  |
|-----------|

4 ответов


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

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

Мастер 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 вставляет 4-й, ему будет дан ключ 6 (Не 2, который остается неиспользованным).

как только вы это настроите, запустите их обоих в качестве рабов. Затем, чтобы проверить, что оба работают нормально, подключитесь к обеим машинам и выполните команду SHOW SLAVE STATUS и вы должны отметить, что оба Slave_IO_Running и Slave_SQL_Running должны сказать "да" на каждой коробке.

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

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

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

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


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

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

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


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


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

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

чтобы быть ясным, вы можете "настроить" репликацию 2-ways, но MySQL AB отбивает этот.