Mysql – Binlog – ‘Race-like’ Condition on Replication

MySQLreplication

I have a typical master-slave MySQL setup. Slave is in test mode currently. Master is heavily used.

I am noticing something that looks like a potential race-like condition on the slave. On occasion, because of heavy use on the master, I will get 2 entries in the Master binlog with the same timestamp on a very heavily used table.

On the slave, the relay log is identical to the binlog on the Master so I know that part is working properly. However, when these statements are replayed I end up with a 1062 Duplicate error condition.

When I check the slave tables I get the first statement replayed properly but only part of the second. The binlog format is currently mixed.

I am considering testing the setup with row-based instead of mixed mode replication as I have read that it is suppose to help with such a condition – I have not used RBR myself before.

  • Has anyone else had similar experiences?
  • Do you have a resolution to this condition?
  • Since RBR can have an impact on performance, is that significant from your experience?

Here were my settings:

  • MySQL ver is 5.5.13
  • Sync_binlog=1
  • innodb_flush_log_at_trx_commit=1

Thanks

Best Answer

Replication is always serialized to prevent the race-conditions you are speaking about. See this stackoverflow post for my explanation of InnoDB locking. Some important notes:

  • RBR with row-based replication and read-committed isolation level sets fewer locks than InnoDB would have previously.

  • We should be moving to a world with RBR anyway, because this will open more doors for parallel replication threads (by working out dependencies between transactions).

To answer your last question, I use RBR in production, and I haven't seen any major performance hit. We do generate a lot more binary log data however, since the events logged contain whole rows.