I've had an idea for using Amazon AWS S3 to distribute MySQL cluster replication data.
The existing architecture for MySQL clustering is as follows:
- The master has N slaves
- The master copies each binlog replication to each slave. If there are 7 slaves, then the master has to push the same data out it's network pipe 7 times
- The slave has a hot TCP connection to the master. The master has 7 hot TCP connections, one for each salve.
- The slave takes each replication chunk and applies it.
Here is my idea.
- For each replication chunk, the master creates a handle name for it, and also the handle name for the next chunk.
- The server copies each chuck into an S3 item, once. The item's name is it's handle, and it has a piece of S3 metadata that is the handle of the next chunk.
- Each client tails the bucket's item list, and grabs each chunk in turn. After it's applied that chunk, it writes a short item back to the bucket, stating that it's applied the chunk.
- A low priority reaper watches the bucket, and when every registered slave marks a given chunk as applied, the reaper deletes the chunk.
The advantages are
- The master only has to write the chunk out to the network once. There is no increased load when the number of slaves is increased.
- The slaves can be very geographically dispersed without additional pain.
- The master and the slave don't need hot TCP connections, VPN connections, or firewall configurations.
- If the network partitions for a while, the slave falls behind, but will resync without pain. Also, a network partition doesnt crash the master when it's binlog space is exhausted.