Can I use mysql binlog from master as relay log on slave?

Question

I have following Mysql replication schema:

A(master)->B(slave/master)->C(slave)

• A writes binlog
• B reads A's binlog applies relaylog and writes it's own binlog
• C reads from B and applies.

If replication become broken by some reason (A->B) can I copy A's binlog, find which position is corresponded to B last executed statement and replay it. Is order of transactions/statements in bin/relay logs the same in all replication chain? (Replication uses one thread so it might be the same order.)

Update: I should have asked like: "Is the order of statements/transactions in binlogs the same across all replication chain? Can we replay any log on any host and repoint any slave(c) to master (A)" Seems that the answer is: "Yes". But official confirmation or documentation(source code) link hasn't been posted yet.

UPDATE2: from official docs to innodb_support_xa:

Enables InnoDB support for two-phase commit in XA transactions, causing an extra disk flush for transaction preparation. The XA mechanism is used internally and is essential for any server that has its binary log turned on and is accepting changes to its data from more than one thread. If you disable innodb_support_xa, transactions can be written to the binary log in a different order than the live database is committing them, which can produce different data when the binary log is replayed in disaster recovery or on a replication slave.

Answer 1

To directly answer your question, no.

Your Topology:

(a) master -> (b) replica -> (c) replica

• A = Master, bin-log must be enabled
• B = Replica of A, must have log_slave_updates enabled
• C = Replica of B

Each bin-log for each server will have its own bin-log file name and position, you cannot copy bin-logs between servers.

If you are wishing to manage your replication topology, moving slaves around and failover you should look at using one of the follow:

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

UPDATE:

Its worth nothing that you should root cause how mysql replication got out of sync and fix that problem to prevent this problem.