Как подчинить данные в реальном времени из двух источников MySQL, сливающихся в одно место назначения MySQL?

По замыслу, один процесс mysqld не может одновременно слушать двух разных мастеров.

Команда CHANGE MASTER TO позволяет вам установить только один Master в качестве источника для чтения.

Чтобы подражать этому, вам придется программно переключаться между двумя Мастерами. Как ты это делаешь?

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

Вот основная идея

• Мастер М1
• Мастер М2
• Slave S1

Настройте репликацию M1 на S1 и затем M2 на S1 следующим образом

• 1) Пусть S1 запустит CHANGE MASTER TO с M1 в качестве источника
• 2) НАЧАТЬ РАБА;
• 3) Запустите репликацию на некоторое время
• 4) ОСТАНОВИТЬ РАБА;
• 5) Пусть S1 запустит CHANGE MASTER TO с M2 в качестве источника
• 6) НАЧАТЬ РАБА;
• 7) Запустите репликацию на некоторое время
• 8) ОСТАНОВИТЬ РАБА;
• 9) Вернитесь к шагу 1

Каждый раз, когда вы переключаетесь с одного мастера на другой, вы должны записать два значения из SHOW SLAVE STATUS\G

1. Relay_Master_Log_file
2. Exec_Master_Log_Pos

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

Есть одно важное предостережение: пока M1 и M2 обновляют взаимоисключающие базы данных, этот алгоритм должен быть в порядке.

Хотите верьте, хотите нет, но я обратился к такому вопросу в ServerFault еще в мае 2011 года. На самом деле я объяснил, как эмулировать настоящего мультимастера / одного подчиненного с помощью BLACKHOLE Storage Engine, основанного на книге "High Performance MySQL".

Для этого нет хорошего инструмента для чтения. pt-table-sync работает не совсем так, как вам сказали (я написал;), но это не правильное решение. Я видел его функцию двунаправленной синхронизации, используемую для согласования серверов с центральным источником после преднамеренного отключения и обновления, но это не то решение, которое вам нужно.

Обычно я не рассказываю о продажах по таким темам, но, честно говоря, это тот случай, когда я бы привлек Percona для разработки нового инструмента для вас. Некоторые люди написали небольшие сценарии, которые соответствуют их личным сценариям, но качественного решения для общего пользования еще не существует, и на самом деле это не так сложно. Главное, что вам нужно формальное тестирование, и компоненты Percona Toolkit уже на 90% соответствуют тому, что вам нужно - просто нужно немного склеить между ними. Конечно, вы могли бы сделать это самостоятельно, но зачем создавать квадратное колесо и в конечном итоге поддерживать его самостоятельно и обнаруживать все его ошибки, когда вы меньше всего этого хотите?

Это сказало (конец продаж, извините) - решение, которое я предложил бы, должно избежать таблиц черной дыры и пойти с более простыми, менее проблемными методами. (Да, я тоже написал High Performance MySQL. Я знаю. В то время я не видел столько проблем с таблицами чёрных дыр, сколько имею сегодня.) Это должно делать примерно то, что предлагает Роландо, но есть некоторые тонкости. Например, он не должен позволять потоку ввода-вывода передавать поток данных с главного устройства, значительно опережая поток SQL, а затем выбрасывать все это при циклическом переходе на следующий сервер. Это было бы очень расточительно и сильно повлияло бы на мастера. Есть много мелких деталей, о которых нужно позаботиться - еще одна, которая приходит на ум, - это не переключение мастеров, когда используется временная таблица, вызванная репликацией.