Это лучший способ двунаправленной синхронизации динамических данных в реальном времени с помощью mysql
Вот сценарий. 2 веб-сервера в двух разных местах с двумя базами данных mysql с идентичными таблицами. Ожидается, что данные в таблицах будут идентичными в реальном времени.
Вот в чем проблема. если пользователь в любом месте одновременно вводит новую запись в идентичные таблицы, как показано в двух первых таблицах ниже, где третья запись в каждой таблице была введена одновременно разными людьми. Данные в таблицах больше не идентичны. Как лучше всего поддерживать идентичность данных в реальном времени, как показано в третьей таблице ниже, независимо от того, где происходят обновления? Таким образом, на приведенных ниже иллюстрациях вместо трех строк в каждой таблице новые записи реплицируются в двух направлениях и вставляются в обе таблицы, чтобы на этот раз снова создать 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
Единственный способ обеспечить синхронизацию таблиц - это настроить двустороннюю репликацию между базами данных.
Но MySQL разрешает только одностороннюю репликацию, поэтому вы не можете просто решить вашу проблему в этой конфигурации.
Для ясности, вы можете "настроить" двухстороннюю репликацию, но MySQL AB препятствует этому.
Важно ли, чтобы UID были одинаковыми? Или вы могли бы подумать о том, чтобы иметь таблицу или столбец, отображающую удаленный UID с локальным UID, и писать собственный код синхронизации для объектов, которые вы хотите реплицировать, чтобы выполнить любое необходимое сопоставление UID для столбцов внешнего ключа и т. д.?
MySQL не поддерживает синхронную репликацию, однако, даже если бы она и поддерживалась, вы, вероятно, не захотели бы ее использовать (не можете выдержать снижение производительности, ожидая, пока другой сервер синхронизируется при каждой фиксации транзакции).
Вам нужно будет рассмотреть более подходящие архитектурные решения для этого - есть сторонние продукты, которые будут выполнять слияние и разрешать конфликты заранее определенным способом - это единственный способ.
Ожидать, что ваша архитектура будет функционировать таким образом, наивно - не существует «простого решения» для любой базы данных, не только для MySQL.
он не ждет, как вы описываете - как указано выше, это действительно два экземпляра master-slave
Я имел в виду гипотетическую ситуацию, когда MySQL поддерживает синхронную репликацию.
Репликация базы данных на двух мастерах не дает большой производительности. Тем не менее, если вы правильно запрограммируете свое приложение, есть изящный способ аварийного переключения.
Настройка Master-Master, по сути, такая же, как настройка 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 вставляет четвертую, ему будет присвоен ключ 6 (а не 2, который остался неиспользованным).
После того, как вы это настроите, запустите их обоих как рабов.
Затем, чтобы убедиться, что оба работают нормально, подключитесь к обоим машинам и выполните команду SHOW SLAVE STATUS, и вы должны отметить, что и Slave_IO_Running, и Slave_SQL_Running должны сказать «ДА» на каждом поле.
Затем, конечно, создайте несколько записей в таблице и убедитесь, что в одно поле вставляются только нечетные первичные ключи, а в другом - только увеличиваются четные.
Затем выполните все тесты, чтобы убедиться, что вы можете выполнять все стандартные приложения на каждом компьютере, копируя его на другой.
Это относительно просто. Но, как уже упоминалось, MySQL не одобряет этого и советует вам помнить об этой функциональности при написании кода приложения.
Редактировать: Я полагаю, что теоретически возможно добавить больше мастеров, если вы убедитесь, что смещения правильные, и так далее. Тем не менее, вы могли бы более реалистично добавить несколько дополнительных ведомых устройств.
Для резервирования должно быть достаточно двух мастеров. Для балансировки нагрузки можно использовать индивидуальные настройки главный-подчиненный в обоих местах. Но другой вариант - использование ведущего устройства с внешним ведомым устройством, на которое можно вручную переключиться в случае сбоя.
Кроме того, убедитесь, что серверы имеют разные значения для server-id и что для параметра replicate-same-server-id установлено значение по умолчанию 0. Это может уже быть, но в противном случае он будет зацикливаться и обнаруживать ошибки.
Мне нравится идея, что серверы будут автоматически увеличиваться на 2, а затем написать собственный плагин для отслеживания вставок / редактирования, а плагин сделает все остальное. поэтому, если сервер 1 вставляет (1,3,5), плагин может выбрать его и экспортировать на сервер 2, используя тот же идентификатор, и наоборот, поэтому никаких конфликтов.
Я сомневаюсь, что вам нужно писать плагин для этого, репликация должна это делать. Ваш код подключения должен просто попытаться сбалансировать нагрузку / подключиться к рабочему блоку, все остальное сделает репликация (и, поскольку нет конфликтов ключей, он не должен бороться).
Да, важно, чтобы UID были одинаковыми на обоих серверах. им не обязательно следовать последовательности, они просто должны быть похожими и уникальными на обоих серверах. Спасибо, в любом случае. У меня довольно хорошее представление о том, что я буду делать.