Mysql+mmm+Proxy实现Mysql读写分离及HA.pdf

誉天 Cisco / RHCE 认证社区 Mysql+mmm+Proxy 实现 Mysql 读写分离及 HA Master-Slave 的数据库机构解决了很多问题，特别是read/write 比较高的web2.0 应用： 1、写操作全部在Master 结点执行，并由 Slave 数据库结点定时(默认 60s)读取 Master 的bin-log 2 、将众多的用户读请求分散到更多的数据库节点，从而减轻了单点的压力 这是对 Replication 的最基本陈述，这种模式的在系统 Scale-out 方案中很有引力(如有必要，数据可 以先进行 Sharding，再使用replication) 。 它的缺点是： 1、Slave 实时性的保障，对于实时性很高的场合可能需要做一些处理 2 、高可用性问题，Master就是那个致命点(SPOF:Single point of failure) 本文主要讨论的是如何解决第 2 个缺点。 DB 的设计对大规模、高负载的系统是极其重要的。高可用性(High availability)在重要的系统(critical System)是需要架构师事先考虑的。存在SPOF:Single point of failure的设计在重要系统中是危险的。 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，也就是切换Master 由db02 充当 b)db01 恢复过来后，充当 Slave 的角色，Master 由db02 继续扮演 难点： 3、4 要如何自动进行？ Master-Master with n Slaves Replication !--[if !vml]-- !--[endif]-- 这比上一个还要复杂，即： 武汉誉天.独家授权Cisco / RHCE培训 誉天 Cisco / RHCE 认证社区 当一个Master Fail 时，所有的 Slave 不再从原来失败的那个 Master(db01)获取更新日志，而应该“ 自 动”切换到必威体育精装版充当 Master 角色的数据库 db02 。 MMM，a greate project! MMM 的基本信息请参考它的网站(见后参考资料) MMM 有 3 个重要的器件: 1、mmmd_mon - monitoring script which does all monitoring work and makes all decisions about roles moving and so on. 2 、mmmd_agent - remote servers management agent script, whichprovides monitoring node with simple set of remote services to makeservers management easier, more flexible abd high