(转)http://blog.csdn.net/starxu85/archive/2008/07/27/2717833.aspx
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, whichprovides monitoring node with simple set of remote services to makeservers 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
downpour: 讨论一下基于Master-Slave数据库模式的J2EE开发的框架选择
http://www.javaeye.com/topic/143714
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
主机名
|
IP
|
Port
|
App
|
目录
|
备注
|
Node1
|
192.168.1.2
|
3306
|
mysql
|
/var/lib/mysql
|
数据库服务器1
|
Node2
|
192.168.1.3
|
3306
|
mysql
|
/var/lib/mysql
|
数据库服务器2
|
Mon
|
192.168.1.4
|
3306
|
Mysql
|
/var/lib/mysql
|
数据库管理服务器
|
Proxy
|
192.168.1.5
|
4040
|
Proxy
|
|
数据库代理(NLB)
|
![](https://i-blog.csdnimg.cn/blog_migrate/cc85d9825f09b4b7b4976e412a233d62.png)
<!--[if !vml]-->
<!--[endif]-->
server-id =
|
1
|
log_bin =
|
mysql-bin
|
master_host
|
192.168.1.2
|
master_port
|
3306
|
master_user
|
replication
|
master_password
|
slave
|
server-id =
|
2
|
log_bin =
|
mysql-bin
|
master_host
|
192.168.1.3
|
master_port
|
3306
|
master_user
|
replication
|
master_password
|
slave
|
Node1
|
192.168.1.2
|
Node2
|
192.168.1.3
|
Mon
|
192.168.1.4
|
--
|
Algorithm-Diff-1.1902.tar.gz
|
--
|
Proc-Daemon-0.03.tar.gz
|
RPM
|
mysql-server-5.0.22-2.1
|
RPM
|
mysql-5.0.22-2.1
|
RPM
|
perl-DBD-MySQL-3.0007-1.fc6
|
--
|
mmm-1.0.tar.bz2
|
--
|
Algorithm-Diff-1.1902.tar.gz
|
--
|
Proc-Daemon-0.03.tar.gz
|
host db1
|
数据库名
|
ip 192.168.1.2
|
node1 ip
|
port 3306
|
node1 port
|
user rep_monitor
|
node1
用户(供mon监控使用,该用户需要在db上添加)
|
password RepMonitor
|
对应密码
|
mode master
|
模式
|
peer db2
|
slave
指定
|
host db2
|
意义同上
|
ip 192.168.1.3
|
|
port 3306
|
|
user rep_monitor
|
|
password RepMonitor
|
|
mode master
|
|
peer db1
|
|
# Mysql Reader role
|
读规则
|
mode balanced
|
模式为均摊
|
servers db1,db2
|
规则覆盖db1 db2(如有更多slave 继续填写,别忘了ip )
|
ip 192.168.1.7
, 192.168.1.8
|
对应ip 虚拟的IP
|
role writer
|
写规则
|
mode exclusive
|
模式为独占
|
servers db1,db2
|
规则负载db1 db2
|
ip 192.168.1.9
|
两台数据库公用一个ip为写,采用HA模式,默认db1使用,db1下线db2接管此ip
|
连接接管
|
Proxy 192.168.1.5
|
4040
|
读操作
|
Db1 192.168.1.7:3306
Db2 192.168.1.8:3306
|
|
写操作
|
Db1/db2 192.168.1.9
默认db1先用,db1当机,db2接管
|
|