MySQL Master Slave Replication

MySQL本身没有提供replication failover的解决方案(见How can I use replication to provide redundancy or high availability?)
如何使Replication方案具有HA？
答案是MMM(MySQL Master-Master Replication Manager)
MMM对MySQL Master-Slave Replication绝对是一个很有益的补充!
引言
Master-Slave的数据库机构解决了很多问题，特别是read/write比较高的web2.0应用：
1、写操作全部在Master结点执行，并由Slave数据库结点定时(默认60s)读取Master的bin-log
2、将众多的用户读请求分散到更多的数据库节点，从而减轻了单点的压力
这是对Replication的最基本陈述，这种模式的在系统Scale-out方案中很有引力(如有必要，数据可以先进行Sharding，再使用replication)。
它的缺点是：
1、Slave实时性的保障，对于实时性很高的场合可能需要做一些处理
2、高可用性问题，Master就是那个致命点([url="http://en.wikipedia.org/wiki/Single_point_of_failure "]SPOF:Single point of failure[/url])
本文主要讨论的是如何解决第2个缺点。
DB的设计对大规模、高负载的系统是极其重要的。高可用性([url="http://en.wikipedia.org/wiki/High_availability "]High availability[/url])在重要的系统(critical System)是需要架构师事先考虑的。存在[url="http://en.wikipedia.org/wiki/Single_point_of_failure "]SPOF:Single point of failure[/url]的设计在重要系统中是危险的。
Master-Master Replication
1、使用两个MySQL数据库db01,db02，互为Master和Slave，即：
一边db01作为db02的master，一旦有数据写向db01时，db02定时从db01更新
另一边db02也作为db01的master，一旦有数据写向db02时，db01也定时从db02获得更新
(这不会导致循环，MySQL Slave默认不会记录Master同步过来的变化)
2、但从AppServer的角度来说，同时只有一个结点db01扮演Master，另外一个结点db02扮演Slave，不能同时两个结点扮演Master。即AppSever总是把write操作分配某个数据库(db01)，除非db01 failed，被切换。
3、如果扮演Slave的数据库结点db02 Failed了：
a)此时appServer要能够把所有的read,write分配给db01，read操作不再指向db02
b)一旦db02恢复过来后，继续充当Slave角色，并告诉AppServer可以将read分配给它了
4、如果扮演Master的数据库结点db01 Failed了
a)此时appServer要能够把所有的写操作从db01切换分配给db02，也就是