Можно ли использовать mysql binlog из master в качестве журнала реестров на ведомом?

У меня есть следующая схема репликации Mysql:

А (ведущий) → В (ведомый/ведущий) → С (ведомый)

  • A пишет binlog
  • B читает Бункер применяет ретранслятор и записывает его собственный binlog
  • C читается из B и применяется.

Если по какой-то причине репликация повреждена (A- > B), я могу скопировать B binlog, найти, какая позиция соответствует последней выполненной инструкции B и воспроизвести ее. Является ли порядок транзакций/операторов в журналах bin/relay одинаковым во всей цепочке репликации? (Репликация использует один поток, поэтому он может быть одного и того же порядка.)

Обновить: мне следовало бы спросить: "Является ли порядок операторов/транзакций в binlogs одинаковым во всей цепочке репликации? Можем ли мы воспроизвести любой журнал на любом хосте и переназначить любой подчиненный (c) для овладения (A)" Кажется, что ответ: "Да". Однако официальное подтверждение или документация (исходный код) еще не опубликованы.

UPDATE2: от официальных документов до innodb_support_xa:

Включает поддержку InnoDB для двухфазной фиксации транзакций XA, в результате чего дополнительный флеш-диск для подготовки транзакции. Механизм XA используется внутренне и необходим для любого сервера, на котором включен его двоичный журнал, и принимает изменения в своих данных из более чем одного потока. Если вы отключите innodb_support_xa, транзакции могут быть записаны в двоичный журнал в другом порядке, чем их передает в реальном времени база данных, которая может создавать разные данные, когда бинарный журнал воспроизводится при аварийном восстановлении или в ведомом репликации.

Ответы

Ответ 1

Чтобы ответить на ваш вопрос, нет.

Ваша топология:

(a) master → (b) replica → (c) replica

  • A = Мастер, bin-журнал должен быть включен
  • B = Реплика A должна содержать log_slave_updates
  • C = копия B

В каждом бин-журнале для каждого сервера будет свое собственное имя и позиция файла журнала bin, вы не можете копировать лог-журналы между серверами.

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

UPDATE:

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

Ответ 2

Чтобы прояснить ваш вопрос. Если репликация останавливается между A → B и, возможно, невоспроизводима. Возможно ли репликация с A → C. Ответ - да.

В вашем примере оба A и B записывают в binlog. Порядок инструкций в этих журналах будет таким же, хотя я не могу найти документацию, чтобы доказать это, это основной принцип репликации. Если бы порядок был другим, тогда было бы легко получить данные из синхронизации. И вы правы, поток подчиненных репликаций является однопоточным, так что хост B будет считывать и записывать операторы в порядке.

Однако, если некоторые данные были записаны на хост "B" напрямую, то, конечно, B и C будут иметь разные данные в "A" в зависимости от того, что было написано.

Перед внесением изменений убедитесь, что вы создали резервные копии своих серверов. Запустите "SHOW SLAVE STATUS" на B и C и скопируйте/вставьте вывод где-нибудь в качестве ссылки.

Чтобы сделать репликацию 'C' с 'A', вам нужно найти позицию в бинлогах из "A" , которые соответствуют тому, где C в настоящее время смотрит на "B". Существует несколько способов сделать это, в том числе с помощью инструмента mysqlbinlog для поиска запросов вручную и начала с этой точки.

Более быстрый способ - довести "C" до 100% с "B". Предполагая, что репликация уже остановлена ​​на "B". Используйте "SHOW SLAVE STATUS" на B, чтобы получить параметры для следующего запроса для запуска на "C".

 CHANGE MASTER TO MASTER_HOST = '[Master_Host]',  MASTER_LOG_FILE='[Master_Log_File]',  '[Exec_Master_Log_Pos]';

Возможно, вам придется добавить другие параметры:

 MASTER_USER='__USER__', MASTER_PASS='__PASS__',

Это сообщит хосту 'C', чтобы продолжить его репликацию, начиная с того места, где 'B' получил. Если вы параноик, как хороший dbadmin, тогда вы будете использовать mysqlbinlog для проверки binlogs на хосте "A" и подтверждения запросов/временных меток на новых позициях для "C" и сравнения запросов вокруг этой точки с данными на "C", чтобы подтвердить, что это точка перезапуска репликации. Что-то вроде:

mysqlbinlog  --read-from-remote-server --host=HostA --user.. --password=.. --start-position=[Exec_Master_Log_Pos - 100] --stop-position=[Exec_Master_Log_Pos + 100] Master_Log_File

Хорошая новость о mysqlbinlog заключается в том, что она также позволит вам прочитать копию binlog с другого сервера и преобразовать ее в SQL-заявления, которые вы можете воспроизводить локально. Это очень полезно в сценариях аварийного восстановления.

Ответ 3

В нормальном сценарии, если у вашего статуса slave-шоу отображается указатель, в котором была нарушена ваша репликация (A > B), вы должны исправить ее, таким образом ваш ведомый B будет в порядке, и теперь данные будут реплицированы в Slave C также успешно.

Если по какой-либо конкретной причине вы не хотите использовать Slave B, и вы уверены, что до репликации Slave B все данные из B были реплицированы на C, и вы знаете указатель, в котором была нарушена репликация, вы можете выполните binlogs непосредственно на ведомом C, и теперь вы можете сделать ведомое ведомое С подчиненного мастера A вместо B.

Если проблема в чем-то отличается, пожалуйста, уточните.