Abstracting Binlog Servers and MySQL Master Promotion without Reconfiguring all Slaves

http://blog.booking.com/abstracting_binlog_servers_and_mysql_master_promotion_wo_reconfiguring_slaves.html

Follow the link above to read my latest article on the Booking.com Developer Blog.  It is about Binlog Servers and how to promote a slave as the new master without reconfiguring all slaves.

This is also a good opportunity to remind you of my next talks:

• I’ll be giving a talk about Binlog Servers and another talk about Binary Logs in general at Percona Live Amsterdam. Feel free to grab me after the talk, catch me at Booking.com booth (# 205) or share a drink with me at the Community Dinner to exchange thoughts about Binlog Servers of other MySQL subjects. 
• I'll also be giving a talk about Binlog Servers at Oracle Open World in San Francisco at the end of October.
• Finally, I'll also be animating a  Birds-of-a-Feather (BoF) session at Oracle Open World: Riding the Binary Logs: Forthcoming Evolution in the Replication Stream.

Looking forward to seeing you in Amsterdam and/or in San Francisco.

Self-Critic and Slides of my PLMCE Talks

The link to the slides of my talks can be found at the end of this post but first, let me share some thoughts about PLMCE.

Talking with people, I was surprised to be criticized of presenting only the good sides of my solution without giving credit to the good side of the alternative solutions.  More than surprised, I was also a little shocked as I want to be perceived as objective as possible.  Let me try to fix that:

MaxScale Binlog Server HOWTO: POC for Master Promotion without Touching any Slave

Note: DO NOT use this procedure in production, this is a proof of concept (POC).  MaxScale 1.1.0 does not yet fully support that procedure and things could go wrong in some situations (see at the end of the post for the details).

In my talk at PLMCE 2015, I presented an architecture to promote a slave as a new master without touching any other slave and I claimed that I tested it.  This HOWTO will show you how I did my test so you are able to reproduce my results.

Even Easier Master Promotion (and High Availability) for MySQL (no need to touch any slave)

Dealing with the failure of a MySQL master is not simple.  The most common solution is to promote a slave as the new master but in an environment where you have many slaves, the asynchronous implementation of replication gets in your way.  The problem is that each slave might be in a different state:

• some could be very close to the dead master,
• some could be missing the latest transactions,
• and some could be far behind (lagging, delayed slaves, or slaves in maintenance).

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).