I have dealt with Circular Replication with three nodes before. Here are my posts:

• May 07, 2012 : Setting Circular Replication in mysql (From Scratch)
• Sep 24, 2012 : Setting up MySQL circular replication in existing replication topology? (Takes a Master with Two Slaves and converts the topology to Three-Node Circular Replication)

I remember a client I used to have who had 800 client databases (about 2TB) in three-node Circular Replication. The client did the writes for 267 databases at one DB server, 267 databases at the second DB server, and the last 266 at the third database. There were heavy writes. There were long intervals of Replication Lag between node. When the peak business time was past, all nodes were back to normal with Seconds_Behind_Master at 0. They did not need auto_increment_increment and auto_increment_offset since all writes to a specific database was restricted to a specific DB Server.

In your case, if you have a small-to-moderate sized database that is not write-intensive, Circular Replication is OK. I just would restrict all DB writes to one box and load balance your SELECTs.

#CAVEAT

Please keep in mind that both @jynus and @AaronBrown are right in saying you have multiple points of failure. You also have to exercise great care in taking backups, restricting writes of specific databases to a fixed DB server, making sure your app is Cluster aware. You must also design strict methods for doing failovers, taking nodes out of the ring, inserting nodes back in the ring, and restoring a single database without increasing server load.

I have dealt with Circular Replication with three nodes before. Here are my posts:

• May 07, 2012 : Setting Circular Replication in mysql (From Scratch)
• Sep 24, 2012 : Setting up MySQL circular replication in existing replication topology? (Takes a Master with Two Slaves and converts the topology to Three-Node Circular Replication)

I remember a client I used to have who had 800 client databases (about 2TB) in three-node Circular Replication. The client did the writes for 267 databases at one DB server, 267 databases at the second DB server, and the last 266 at the third database. There were heavy writes. There were long intervals of Replication Lag between node. When the peak business time was past, all nodes were back to normal with Seconds_Behind_Master at 0. They did not need auto_increment_increment and auto_increment_offset since all writes to a specific database was restricted to a specific DB Server.

In your case, if you have a small-to-moderate sized database that is not write-intensive, Circular Replication is OK. I just would restrict all DB writes to one box and load balance your SELECTs.

CAVEAT

Please keep in mind that both @jynus and @AaronBrown are right in saying you have multiple points of failure. You also have to exercise great care in taking backups, restricting writes of specific databases to a fixed DB server, making sure your app is Cluster aware. You must also design strict methods for doing failovers, taking nodes out of the ring, inserting nodes back in the ring, and restoring a single database without increasing server load.

I have dealt with Circular Replication with three nodes before. Here are my posts:

• May 07, 2012 : Setting Circular Replication in mysql (From Scratch)
• Sep 24, 2012 : Setting up MySQL circular replication in existing replication topology? (Takes a Master with Two Slaves and converts the topology to Three-Node Circular Replication)

I remember a client I used to have who had 800 client databases (about 2TB) in three-node Circular Replication. The client did the writes for 267 databases at one DB server, 267 databases at the second DB server, and the last 266 at the third database. There were heavy writes. There were long intervals of Replication Lag between node. When the peak business time was past, all nodes were back to normal with Seconds_Behind_Master at 0. They did not need auto_increment_increment and auto_increment_offset since all writes to a specific database was restricted to a specific DB Server.

In your case, if you have a small-to-moderate sized database that is not write-intensive, Circular Replication is OK. I just would restrict all DB writes to one box and load balance your SELECTs.

#CAVEAT

Please keep in mind that both @jynus and @AaronBrown are right in saying you have multiple points of failure. You also have to exercise great in taking backups, restricting writes of specific databases to a fixed DB server, making sure your app is Cluster aware. You must also design strict methods for doing failovers, taking nodes out of the ring, inserting nodes back in the ring, and restoring a single database without increase server load.

I have dealt with Circular Replication with three nodes before. Here are my posts:

• May 07, 2012 : Setting Circular Replication in mysql (From Scratch)
• Sep 24, 2012 : Setting up MySQL circular replication in existing replication topology? (Takes a Master with Two Slaves and converts the topology to Three-Node Circular Replication)

I remember a client I used to have who had 800 client databases (about 2TB) in three-node Circular Replication. The client did the writes for 267 databases at one DB server, 267 databases at the second DB server, and the last 266 at the third database. There were heavy writes. There were long intervals of Replication Lag between node. When the peak business time was past, all nodes were back to normal with Seconds_Behind_Master at 0. They did not need auto_increment_increment and auto_increment_offset since all writes to a specific database was restricted to a specific DB Server.

In your case, if you have a small-to-moderate sized database that is not write-intensive, Circular Replication is OK. I just would restrict all DB writes to one box and load balance your SELECTs.

#CAVEAT

Please keep in mind that both @jynus and @AaronBrown are right in saying you have multiple points of failure. You also have to exercise great care in taking backups, restricting writes of specific databases to a fixed DB server, making sure your app is Cluster aware. You must also design strict methods for doing failovers, taking nodes out of the ring, inserting nodes back in the ring, and restoring a single database without increasing server load.

I have dealt with Circular Replication with three nodes before. Here are my posts:

• May 07, 2012 : Setting Circular Replication in mysql (From Scratch)
• Sep 24, 2012 : Setting up MySQL circular replication in existing replication topology? (Takes a Master with Two Slaves and converts the topology to Three-Node Circular Replication)

I remember a client I used to have who had 800 client databases (about 2TB) in three-node Circular Replication. The client did the writes for 267 databases at one DB server, 267 databases at the second DB server, and the last 266 at the third database. There were heavy writes. There were long intervals of Replication Lag between node. When the peak business time was past, all nodes were back to normal with Seconds_Behind_Master at 0. They did not need auto_increment_increment and auto_increment_offset since all writes to a specific database was restricted to a specific DB Server.

In your case, if you have a small-to-moderate sized database that is not write-intensive, Circular Replication is OK. I just would restrict all DB writes to one box and load balance your SELECTs.

#CAVEAT

Please keep in mind that both @jynus and @AaronBrown are right in saying you have multiple points of failure. You also have to exercise great in taking backups, restricting writes of specific databases to a fixed DB server, making sure your app is Cluster aware. You must also design strict methods for doing failovers, taking nodes out of the ring, inserting nodes back in the ring, and restoring a single database without increase server load.

I have dealt with Circular Replication with three nodes before. Here are my posts:

• May 07, 2012 : Setting Circular Replication in mysql (From Scratch)
• Sep 24, 2012 : Setting up MySQL circular replication in existing replication topology? (Takes a Master with Two Slaves and converts the topology to Three-Node Circular Replication)

I remember a client I used to have who had 800 client databases (about 2TB) in three-node Circular Replication. The client did the writes for 267 databases at one DB server, 267 databases at the second DB server, and the last 266 at the third database. There were heavy writes. There were long intervals of Replication Lag between node. When the peak business time was past, all nodes were back to normal with Seconds_Behind_Master at 0. They did not need auto_increment_increment and auto_increment_offset since all writes to a specific database was restricted to a specific DB Server.

In your case, if you have a small-to-moderate sized database that is not write-intensive, Circular Replication is OK. I just would restrict all DB writes to one box and load balance your SELECTs.

#CAVEAT

Please keep in mind that both @jynus and @AaronBrown are right in saying you have multiple points of failure. You also have to exercise great in taking backups, restricting writes of specific databases to a fixed DB server, making sure your app is Cluster aware. You must also design strict methods for doing failovers, taking nodes out of the ring, inserting nodes back in the ring, and restoring a single database without increase server load.