As a final (possibly stupid question). Master-master doesn’t help you scale beyond the capabilities of a single server, but only provides a fallback if the primary server fails, correct?

Master-slave at least increases the read performance by every slave you add, but the write performance it still limited to the slowest machine on the cluster, as all writes need to propagate to each of the slaves too, right?

Please excuse my stupidity, I’m new to MySQL scaling, even though I’ve been tasked to handle it… lol

The data doesn’t have different primary keys on each server, both masters are also slaves of each other, and at any given point only one master is the active master. A write happens once on the active master, and then replicates to the passive master.

What master-master means in this context, is actually a master-slave topology that can switch roles instantly, without having a complex slave to master promotion.

And yes, you are right about the fact that you still don’t have control over the IP of the load balancer, but at least the load balancer software is a lot less likely to fail as it’s not doing any heavy work compared to MySQL.

I’m not sure if Haproxy is capable of proxying MySQL requests. I believe its intended for HTTP traffic only. But I’ve read briefly about a load balancer for MySQL called ldirector that might work.

And regarding system load for a software load balancer, I have Haproxy running on a m1.small instance on EC2 at the moment, serving around 130k users per day. Haproxy rarely goes above 1% CPU usage, even during the heaviest traffic times.

And in theory, there should be a lot less traffic going through a MySQL specific load balancer, as the http load balancer I’m running at the moment is stupidly handling both dynamic and static content.

You are correct regarding auto increment values. You should keep them separate on each master. For example, if you have 2 masters, you should do the following:

on one of them in my.cnf:
auto_increment_increment=2
auto_increment_offset=1

and on the other:
auto_increment_increment=2
auto_increment_offset=0

This way auto increment values will not collide, one master will use even values, while the other will use odd values.

Regarding IP switching, I am not aware of any way to implement it on EC2. I tried once with OpenVPN but got stuck and never pushed to implement it. You might try some other balancing combinations for MySQL (maybe with HAProxy, LVS, etc.), but the pitfall is always this – you can’t control Virtual IP addresses in the network layer on EC2. You must always fall back to name resolving, with an underlying layer that can make sure switching propagation delay is minimal (and therefore Elastic IPs are out of the question).

However, from what I understand, you can’t keep the same auto-increment values on both masters right? Won’t that cause issues when looking up rows based on an auto-incremented id column?

Also, regarding the IP switching, have you considered using a software load balancer? As in you connect to a load balancer machine that proxies all queries to the currently healthy MySQL machine. Switching should be as easy as changing the config file (doable via a script even), and then relaunching the load balancer.