泛世纪首页　空间首页　  　　　　 mysql的空间 　　　　　　 欢迎进入mysql的空间

介绍MySQL Master-Slave架构下使用MMM的必要性 　2008-04-27 17:05 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就是那个致命点(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 这比上一个还要复杂，即： 当一个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, which provides monitoring node with simple set of remote services to make servers management easier, more flexible abd highly portable. 3、mmm_control - simple script dedicated to management of the mmmd_mon processes by commands. 每一个MySQL服务器器结点需要运行mmmd_agent，同时在另外的一个机器上(可以是独立的一台机器，也可以是和AppServer共享同一个服务器)运行mmmd_mon。形成1 * mmmd_mon + n * mmmd_agent的部署架构。 MMM利用了虚拟IP的技术：1个网卡可以同时使用多个IP。 (所以使用MMM时，需要2*n+1个IP，n为mysql数据库结点个数，包括master,slave) 当有数据库结点fail时，mmmd_mon检测不到mmmd_agent的心跳或者对应的MySQL服务器的状态，mmmd_mon将进行决定，并下指令给某个正常的数据库结点的mmmd_agent，使得该mmmd_agent“篡位”使用(注)刚才fail的那个结点的虚拟IP，使得虚拟IP实际从指向fail的那个机器自动转为此时的这个正常机器。 注：据Qieqie猜测是将获得的虚拟IP设置给网卡，也只能这样了，改天测试验证一下。 repeat: MMM对MySQL Master-Slave Replication绝对是一个很有益的补充! 参考资料 Switching Masters During Failover http://dev.mysql.com/doc/refman/5.1/en/replication-solutions-switch.html MMM http://blog.kovyrin.net/mysql-master-master-replication-manager/ Project page on Google Code: http://code.google.com/p/mysql-master-master mmm-devel users group: http://groups.google.com/group/mmm-devel 　类别：默认分类  |  评论(0)  |  浏览(112)   　　　　　　　　　　　　　　　　暂无文章评论！ 　　　　　　　 您尚未登录，只有登录后才能留言！ [ 登录 ] 　  [ 注册 ]