Это лучший способ двунаправленной синхронизации динамических данных в реальном времени с использованием 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 | |-----------| 

Solutions Collecting From Web of "Это лучший способ двунаправленной синхронизации динамических данных в реальном времени с использованием mysql"

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

Настройка 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, который не используется).

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

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

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

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

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

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

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

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

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

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

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

Чтобы быть понятным, вы можете «настроить» двухканальную репликацию, но MySQL AB отпугивает это .