I'm trying to understand how Innodb interacts with MySQL replication. It seems very, very complicated from the documentation, and it isn't clear at all how to set the various variables (sync_binlog, innodb_support_xa, innodb_flush_log_at_trx_commit).
Can someone help with me the following paragraph (from
http://dev.mysql.com/doc/refman/5.1/en/binary-log.html):
"The InnoDB logs are synchronized by default, and sync_binlog=1 can be used to synchronize the binary log. The effect of this option is that at restart after a crash, after doing a rollback of transactions, the MySQL server cuts rolled back InnoDB transactions from the binary log. This ensures that the binary log reflects the exact data of InnoDB tables, and so, that the slave remains in synchrony with the master (not receiving a statement which has been rolled back)."
As I understand things, this means that the process for the XA transaction between InnoDB and the binary log is something like this:
(1) Prepare the commit in InnoDB (flush it to the InnoDB log file)
(2) Flush the transaction to the binary log file
(3) Commit the transaction in InnoDB (make the changes to the table file)
In the event of a server failure between (2) and (3) I assumed that the transaction manager (for XA) would do (3) upon restart. The paragraph I quoted above contradicts this, however, and indicates that the binary log entries from (2) will be "cut" from that log.
What is actually happening here? If the statements are being "cut" from the binary log, what is being done about slaves that already replicated those statements? Is there a mutex that keeps replication from happening during the XA transaction? Are the answers to these questions in the documentation somewhere? Major thanks to anyone who can help out with this!
Charles Gordon