MySQL MHA 典型使用场景(二)

2015-02-13 23:46:33 · 作者: · 浏览: 75
can also set priorities) to the new master, and recover the rest second-tier slaves. The third tier slave(Sr2) is not managed by MHA, but as long as Sr (Sr2's master) is alive, Sr2 can continue replication without changing anything.


If Sr crashes, Sr2 can't continue replication because Sr2's master is Sr. MHA can NOT be used to recover Sr2. This is where support for global transaction id is desired. Hopefully this is less serious than master crash.


?
2.6? ? ? ? Three tier replication, multi-master(三层复制架构,多主)
? M1(host1,RW) <-----------------> M2(host2,read-only)? ? ? ? |? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |? +-----+--------+? ? ? ? ? ? ? ? ? ? ? + S1(host3,R)? ? S2(host4,R)? ? ? ? ? ? S3(host5,R)=> After failover


?


? ? ? ? ? M2(host2,RW)


? ? ? ? ? ? ? ? |


? +--------------+--------------------------+


?S1(host3,R)? ? S2(host4,R)? ? ? ? ? ? S3(host5,R)


?


This structure is also supported. In this case, host5 is a third-tier slave, so MHA does not manage host5(MHA does not execute CHANGE MASTER on host5 when the primary master host1 fails). When current master host1 is down, host2 will be new master, so host5 can keep replication from host2 without doing anything. Here are configuration file example.


[server default]
multi_tier_slave=1


[server1]
hostname=host1
candidate_master=1


[server2]
hostname=host2
candidate_master=1


[server3]
hostname=host3


[server4]
hostname=host4


[server5]
hostname=host5