У меня есть производственная система, которая использует репликацию на основе операторов MySQL для «горячего» переключения на случай отказа главной базы данных. Работает версия 5.5 Percona. Я должен использовать репликацию на основе инструкций по причинам, которые являются неизменными для целей этого вопроса.
Теперь я хотел бы увидеть поток построчной репликации тех же данных, чтобы попытаться адаптировать его к хранилищу данных на основе HBase.
Можно ли настроить сервер MySQL для подчинения (чтения) с использованием репликации на основе операторов, но в то же время быть ведущим устройством репликации (записывать в другие подчиненные устройства) с использованием репликации на основе строк? Если да, то как мне это настроить? Я искал в документации, но не нашел.
Я должен использовать репликацию на основе инструкций по причинам, которые неизменны для целей этого вопроса.
Я предполагаю, для целей этого вопроса, что действительно могут быть веские причины для использования журналирования на основе операторов, но обычно это не рекомендуется, поскольку ведение журнала на основе операторов относительно хрупко. В любой системе, где у вас есть гибкость не чтобы использовать ведение журнала на основе операторов, не используйте его - используйте MIXED или ROW.²
Сервер MySQL (и совместимые системы, такие как Percona Server, MariaDB и Aurora для MySQL) автоматически «переводят» из одного формата в другой в зависимости от конфигурации каждого отдельного сервера.
«Каждый сервер MySQL может установить свой собственный и только свой собственный двоичный формат ведения журнала (правда, независимо от того,
binlog_formatустанавливается с глобальной или сеансовой областью). Это означает, что изменение формата ведения журнала на ведущем устройстве репликации не приводит к тому, что ведомое устройство изменяет свой формат ведения журнала для соответствия.”- https://dev.mysql.com/doc/refman/5.6/en/binary-log-setting.html
Чтобы повторить это с некоторыми дополнительными выводами, то, что вы хотите сделать, «просто работает», потому что настройка binlog_format на рабе делает не укажите какой раб надеется. Он только устанавливает то, что раб генерировать.
Настройте ведомое устройство с помощью binlog_format=ROW и включить log_slave_updates в my.cnf на ведомом (что приводит к перезаписи входящих событий в журнал ведомого устройства).
...и вы сделали.
Подчиненное устройство будет регистрировать весь свой DML как построчные события, несмотря на формат binlog ведущего. На самом деле вам не нужно ничего делать, чтобы подчиненное устройство также было мастером, поскольку каждый сервер MySQL с включенной двоичной регистрацией, по сути, уже является мастером - он просто может оказаться мастером без каких-либо фактических подчиненных устройств.
Любая комбинация ведущего и ведомого binlog_format действует Кроме для мастера, настроенного как ROW и ведомый, настроенный как STATEMENT (противоположность тому, что вы здесь делаете), потому что операторы while могут быть преобразованы в события строк (в конце концов, они влияют на строки на ведомом устройстве), обратное неверно - вы не всегда можете определить конкретный оператор изменившие строки, если вы знаете только фактические измененные данные. Но для приложения, о котором вы спрашиваете, приведенное выше должно делать именно то, что вы намереваетесь.
Я также обсудил взаимодействие возможных комбинаций главного и подчиненного формата binlog. здесь, на dba.stackexchange.com в некоторых дополнительных деталях.
¹протоколирование здесь используется, а не «репликация», потому что это более точное описание того, что на самом деле настраивается, хотя, возможно, значение не изменилось.
² STATEMENT регистрирует фактические запросы, которые внесли изменение; ROW регистрирует "изображения строк" строк, вставленных / обновленных / удаленных по запросу. Для обновлений регистрируются как старые, так и новые значения. MIXED режим позволяет серверу выбирать формат для каждого запроса, всегда используя ROW когда в запросе есть что-то, что может повлиять на базу данных, потенциально небезопасно для репликации на основе операторов, потому что реплика потенциально может интерпретировать его таким образом, что данные реплики могут отличаться от данных мастера, потому что запрос не детерминированный. Примеры могут включать неупорядоченный UPDATE ... LIMIT где реплика может обновлять другой набор строк в зависимости от выбора индекса, и операторы, использующие недетерминированные функции, такие как UUID(). Другие, казалось бы, недетерминированные функции, такие как NOW() и RAND() совместимы с репликацией на основе операторов, поскольку в журнал операторов записываются подсказки, указывающие системное время ведущего устройства и случайное начальное значение ведущего во время выполнения запроса.