My service runs on single machine, and database (mysql 5.1.66) is replicated to 2 other identical slaves (with lesser system resources, mysql 5.1.66) via chained replication. Machines are located in different isps. There will always be a single entry point to service, and if master goes down, i'll switch to the next slave and continue.
simply the scenario is as master -> slave1 -> slave2.
But i don't want to deal with resyncing the master, when it comes up. I'm thinking of switching to circular replication model. which is:
master -> slave1 -> slave2 -> master …
I've never used circular model, and the latency between master and slaves do not bother much in current implementation. But with circular model, i guess master will also be waiting for a reply from slave2, even though no nodes other than the master will be writing the database. Is this latency -if exists- a show stopper? Is it sane to implement circular replication between different locations?
Best Answer
CIRCULAR REPLICATION
You should upgrade to MySQL 5.5 because it features Semisynchronous Replication
There are settings that can let you dictate how much delay a Master can tolerate before switching back to asynchronous replication until latency dies down. I have written posts on Semisynchronous Replication before:
Aug 05, 2011
: Is MySQL Replication Affected by a High-Latency Interconnect?Jul 25, 2012
: Mysql database replication on different vlan/subnet/another siteMar 12, 2013
: Breaking Semisynchronous Replication in MySQL 5.5Some have argued that it is not good over a geographic distance. This is debatable depending on several factors
DATA RESILIENCY
If you have Multiple Masters in Different Data Centers for the purpose of Disaster Recovery (or as the politically correct would say, "Business Continuity"), you should try to make the Data Center intrinsically resilient for the sake of MySQL. How would you do that?
Setup DRBD in each Data Center. Then, setup Circular Replication among the DRBD Primaries.
Here are my posts on setting this up
Mar 29, 2011
: MySQL high availability, failover and replication with LatencyDec 19, 2011
: Best way to setup master to multi master replicationDec 31, 2012
: Automatic MySQL Replication Fail-over Strategy