У меня есть два разных экземпляра MySQL, которые я хотел бы «подчинить» третьему экземпляру. (так что я могу легко присоединиться к третьему экземпляру)
например.
mysql1> show databases
db1
db2
mysql2> show databases
db3
db4
mysql3> show databases
db1
db2
db3
db4
Я посмотрел мааткит (набор инструментов percona) pt-table-sync, но люди говорят, что это может повредить данные. (Очевидно, удаляет и повторно добавляет данные для создания вставок)
pt-archiver вроде работает для «моментальных снимков», но db1 занимает примерно 6 ГБ, и копирование всего этого требует гораздо большего объема данных, чем действительно необходимо. Обновления в реальном времени составляют всего около 100 МБ в день.
Для меня естественной концепцией было бы позволить mysql3 работать в качестве подчиненного реплики ОБЕИХ mysql1 и mysql2, но, похоже, это не вариант в MySQL.
Вольфрамовый репликатор похоже, позволяет использовать этот тип синхронизации данных, но это кажется немного громоздким в настройке, и я беспокоюсь о надежности.
У кого-нибудь есть другие решения, которые они использовали для этой проблемы?
По задумке один процесс mysqld не может одновременно прослушивать два разных мастера.
Команда CHANGE MASTER TO позволяет вам установить только один мастер в качестве источника для чтения.
Чтобы имитировать это, вам придется программно переключаться между двумя мастерами. Как ты это делаешь ?
Вот основная идея
Настройте репликацию M1 на S1, а затем M2 на S1, как это
Каждый раз, когда вы переключаетесь с одного Мастера на другой, вы должны записывать два значения из SHOW SLAVE STATUS\G
Эти два значения представляют собой последний оператор SQL, поступивший от ведущего устройства и выполняемый на ведомом.
Есть одно серьезное предупреждение: пока M1 и M2 обновляют взаимоисключающие базы данных, этот алгоритм должен работать нормально.
Для этого нет хорошего готового инструмента. pt-table-sync работает не так, как вам сказали (я написал ее;), но это неправильное решение. Я видел, как его функция двунаправленной синхронизации используется для согласования серверов с центральным источником после намеренного отключения и обновления, но это не то решение, которое вам нужно.
Обычно я не говорю о продажах по таким темам, но, честно говоря, это тот случай, когда я бы попросил Percona разработать для вас новый инструмент. Некоторые люди написали небольшие скрипты, соответствующие их личным сценариям, но высококачественного решения для общего использования еще не существует, и на самом деле это не так сложно. Главное, что вам нужно формальное тестирование, а компоненты Percona Toolkit уже на 90% добрались до того, что вам нужно - просто нужно немного клея между ними. Конечно, вы могли бы сделать это сами, но зачем делать квадратное колесо и в конечном итоге самому его обслуживать и обнаруживать все его ошибки, когда вы меньше всего этого хотите?
Тем не менее (конец предложения, извините) - решение, которое я предлагаю, должно избегать таблиц черных дыр и использовать более простые и менее проблемные методы. (Да, я тоже написал высокопроизводительный MySQL. Я знаю. Тогда я не видел столько проблем с таблицами черных дыр, сколько сегодня.) Он должен делать примерно то, что предлагает Роландо, но есть некоторые тонкости. Например, он не должен позволять потоку ввода-вывода передавать поток данных от ведущего устройства, далеко опережая поток SQL, а затем отбрасывать все это при циклическом пересылке на следующий сервер. Это было бы действительно расточительно и сильно повлияло бы на мастера. Есть много таких мелких деталей, о которых нужно позаботиться - другая, которая приходит на ум, - это не переключение мастеров, когда используется временная таблица, вызванная репликацией.