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.wikipe
dia.org/wiki/High_availability "]High availability[/url])在重要的系统(critical System)是
需要架构师事先考虑的。存在[url="http://en.wikipedia.org/wiki/Single_point_of_failur
e "]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 操作
