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

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

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

(а) мастер -> (б) реплика -> (в) реплика

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

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

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

1. MySQL 5.6 с GTID
2. MHA
3. Orchestrator

ОБНОВЛЕНИЕ:

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

Чтобы прояснить ваш вопрос. Если репликация останавливается между 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, чтобы проверить бинлоги на хосте 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, которые вы можете воспроизвести локально. Это очень полезно в сценариях аварийного восстановления.

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

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

Если проблема в другом, просьба уточнить.