I just publish a post on the Booking.com blog: http://blog.booking.com/better_crash_safe_replication_for_mysql.html Spoiler: it uses Binlog Servers.
This is also the opportunity to tell you that I will be at Percona Live London at the beginning of November, and that I will give a talk about Binlog Servers: High Availability, Disaster Recovery and Extreme Read Scaling using Binlog Servers. I will not talk too much about Binlog Server for crash-safe replication, but I will present a new use-case for Binlog Servers that I did not blog about yet. I am looking forward to meet you there.
Wednesday, October 22, 2014
Wednesday, August 13, 2014
SBR vs RBR when using On Duplicate Key Update for High Availability
The other day, I was discussing high availability (HA) with other people. The discussion was going in the direction of, as the application was only using INSERT ... ON DUPLICATE KEY UPDATE (IODKU) and traffic could be replayed, promoting a slave in case of the failure of the master was easy: replaying traffic would make& all the slaves converge back to a common state. It looks as this could work but it might not be as simple. Before going into the details, let's take a step back and look into HA in general.
tl;dr: be careful when using row-based replication when replicating IODKU as slaves will stop replicating if a row is present on the master and missing on slave (or vice-versa).
tl;dr: be careful when using row-based replication when replicating IODKU as slaves will stop replicating if a row is present on the master and missing on slave (or vice-versa).