keepalived+MHA实现mysql主从高可用集群
本节索引
原理分析
实验环境准备
主从复制集群
安装MHA包
初始化MHA
配置Keepalived
故障出现
故障恢复
总结
一 原理分析
1 MHA简介:
MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用。
2 MHA组成:
该软件由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点)。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群,也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上,MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自动将最新数据的slave提升为新的master,然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。
Manager工具包主要包括以下几个工具:
masterha_check_ssh 检查MHA的SSH配置状况 masterha_check_repl 检查MySQL复制状况 masterha_manger 启动MHA masterha_check_status 检测当前MHA运行状态 masterha_master_monitor 检测master是否宕机 masterha_master_switch 控制故障转移(自动或者手动) masterha_conf_host 添加或删除配置的server信息
Node工具包(这些工具通常由MHA Manager的脚本触发,无需人为操作)主要包括以下几个工具:
save_binary_logs 保存和复制master的二进制日志 apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的slave filter_mysqlbinlog 去除不必要的ROLLBACK事件(MHA已不再使用这个工具) purge_relay_logs 清除中继日志(不会阻塞SQL线程)
3 MHA工作原理:
在MHA自动故障切换过程中,MHA试图从宕机的主服务器上保存二进制日志,最大程度的保证数据的不丢失,但这并不总是可行的。例如,如果主服务器硬件故障或无法通过ssh访问,MHA没法保存二进制日志,只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制,可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志,MHA可以将最新的二进制日志应用于其他所有的slave服务器上,因此可以保证所有节点的数据一致性。
目前MHA主要支持一主多从的架构,要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器,一主二从,即一台充当master,一台充当备用master,另外一台充当从库,因为至少需要三台服务器,出于机器成本的考虑,淘宝也在该基础上进行了改造,目前淘宝TMHA已经支持一主一从。我们自己使用其实也可以使用1主1从,但是master主机宕机后无法切换,以及无法补全binlog。master的mysqld进程crash后,还是可以切换成功,以及补全binlog的。其结构如下:
官方地址:https://code.google.com/p/mysql-master-ha/
二 实验环境准备
1 系统版本
统一版本,统一规范,这是将来能够自动户运维的前提。
[root@vin ~]# cat /etc/redhat-release CentOS Linux release 7.3.1611 (Core)
2 内核参数
[root@vin ~]# uname -r 3.10.0-514.el7.x86_64
3 主机配置参数:准备4台干净的主机node{1,2,3,4}
互相能够解析主机名,由于节点上配置文件,很多都是大体相同的,只需要修改一份让后使用for循环复制给其他节点即可,简单方便,所以这里实现主机名的认证。
角色 ip地址 主机名 server_id 类型 MHA-Manager 172.18.253.73 node1 - 监控复制组 Master 172.18.250.27 node2 1 写入 Candicate master 172.18.253.160 node3 2 读 Slave 172.18.254.15 node4 3 读
4 实现互相能够解析主机名
[root@vin ~]# cat /etc/hosts 172.18.253.73 node1 172.18.250.27 node2 172.18.253.160 node3 172.18.254.15 node4
5 实现主机间的互相无密钥通信
由于使用MHA时,Manager需要验证各个节点之间的ssh连通性,所以我们在这里需要实现给节点之间的无密钥通信,这里采用了一个简单的方法,那就是在某个节点上生成ssh密钥对,实现本主机的认证,然后将认证文件以及公私钥都复制到其他节点,这样就不需要,每个节点都去创建密钥对,在实现认证了。
[root@vin ~]# ssh-keygen -t rsa -P '' [root@vin ~]# ssh-copy-id -i ./id_rsa.pub node1: [root@vin ~]# for i in {2..4};do scp id_rsa{,.pub} authorized_keys root@node$i:/root/.ssh/;done
三 实现主从复制集群
1 Master配置:
修改配置文件
[root@vin ~]# cat /etc/my.cnf.d/server.cnf [server] server_id = 1 # 提供给主节点一个server号码,可以是任意的整数 log_bin = master-log # 启用二进制日志 relay_log = relay-log # 启用中继日志,因为主将来也会成为从innodb_file_per_table = ON # 每个数据表存储为单个文件 skip_name_resolve = ON # 关闭主机名解析,有助于提升性能 max_connections = 5000 # 最大并发连接数
创建具有复制功能的用户与用于Manager节点管理的用户;
[root@vin ~]# mysql MariaDB [(none)]> show master status\G; *************************** 1. row ***************************File: master-log.000003Position: 245Binlog_Do_DB: Binlog_Ignore_DB: MariaDB [(none)]> grant replication slave,replication client on *.* to -> 'vinsent'@'172.18.%.%' identified by 'vinsent'; # 这是一个语句 MariaDB [(none)]> grant ALL on *.* to 'MhaAdmin'@'172.18.%.%' identified by 'MhaPass'; MariaDB [(none)]> flush privileges;
说明:我们应该先查看主节点正在使用的日志文件及对应的POSITION,再创建用户,以便于从节点能够同步拥有这些用户;创建Manager节点用于管理的用户时需要注意的是,用户名中的主机范围必须能够囊括其他节点的地址。
2 Slave{1,2}配置:
两个从节点的配置相同;修改配置文件,以支持主从复制功能;
[root@vin ~]# cat /etc/my.cnf.d/server.cnf [server] server_id = 2 log_bin = master-log relay_log = relay-logrelay_log_purge = OFF # 关闭中继日志裁剪功能 read_only = ON # 由于是从节点,故设置为只读模式innodb_file_per_table = ON skip_name_resolve = ON max_connections = 5000
连接至主节点,实现同步;
[root@vin ~]# mysql MariaDB [(none)]> change master to master_host='172.18.250.27',master_user='vinsent',master_password='vinsent',master_log_file='master-log.000003',master_log_pos=245; MariaDB [(none)]> start slave; MariaDB [(none)]> show slave status\G; *************************** 1. row ***************************Slave_IO_State: Waiting for master to send eventMaster_Host: 172.18.250.27Master_User: vinsentMaster_Port: 3306Connect_Retry: 60Master_Log_File: master-log.000003Read_Master_Log_Pos: 637Relay_Log_File: relay-log.000002Relay_Log_Pos: 922Relay_Master_Log_File: master-log.000003Slave_IO_Running: YesSlave_SQL_Running: YesReplicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0Last_Error: Skip_Counter: 0Exec_Master_Log_Pos: 637Relay_Log_Space: 1210Until_Condition: NoneUntil_Log_File: Until_Log_Pos: 0Master_SSL_Allowed: NoMaster_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: NoLast_IO_Errno: 0Last_IO_Error: Last_SQL_Errno: 0Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 1
说明:查看从节点状态,确保"Slave_IO_Running","Slave_SQL_Running"的值为"YES",即从节点正常工作,并且"Last_IO_Errno","Last_SQL_Errno"中没有错误信息提示,出现错误,一般就是连接性错误,这说明要么用户创建的有问题,要么主从节点的数据不同步,请确保两者数据一致。
测试一下从节点是否将主节点的数据同步至本地:
MariaDB [(none)]> select user from mysql.user; +----------+ | user | +----------+ | root | | MhaAdmin | | vinsent | | root | | | | root | | | | root | +----------+
四 安装MHA包
除了源码包,MHA官方也提供了rpm格式的程序包,其下载地址为http://code.google.com/p/mysql-master/wiki/Downloads?tm=2。CentOS 7 系统可直接使用适用于el6的程序包,另外,MHA Manager和MHA NODe程序包的版本并不强制要求一致。
1 Manager节点
[root@vin ~]# lsmha4mysql-manager-0.56-0.el6.noarch.rpm mha4mysql-node-0.56-0.el6.noarch.rpm
主节点需要安装mha4mysql-manager管理包,以及node几点包,
2 Master && SLave{1,2}节点
从节点只需要安装mode包即可
[root@vin ~]# ls mha4mysql-node-0.56-0.el6.noarch.rpm [root@vin ~]# yum install /root/*.rpm
3 检测各节点之间ssh可用性
出现下面的结果则说明ssh联通性无误
[root@vin ~]# masterha_check_ssh --conf=/etc/masterha/app1.cnf ... - [info] All SSH connection tests passed successfully.
4 检测管理的mysql主从复制集群的连接配置参数是否满足
[root@vin ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf ... Mon Nov 13 22:11:30 2017 - [info] Slaves settings check done. Mon Nov 13 22:11:30 2017 - [info] 172.18.250.27(172.18.250.27:3306) (current master)+--172.18.253.160(172.18.253.160:3306)+--172.18.254.15(172.18.254.15:3306) ... MySQL Replication Health is OK.
如果配置参数满足要求,那么你将看到这个集群的主从节点,如上实例。
5 启动MHA
Manager节点:
[root@vin ~]# masterha_manager --conf=/etc/masterha/app1.cnf Mon Nov 13 22:16:17 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping. # 没有默认配置文件 Mon Nov 13 22:16:17 2017 - [info] Reading application default configuration from /etc/masterha/app1.cnf.. Mon Nov 13 22:16:17 2017 - [info] Reading server configuration from /etc/masterha/app1.cnf..
说明:MHA默认是工作在前台的,要想将它防止至后台运行,可使用下面的命令:
[root@vin ~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf > \ /data/masterha/app1/managerha/manager.log 2&>1 &
成功启动之后,查看一下Master节点的状态;
[root@vin ~]# masterha_check_status --conf=/etc/masterha/app1.cnf app1 (pid:4090) is running(0:PING_OK), master:172.18.250.27
说明:如果未成功启动,这里的命令将不能够正确执行;提示:"app1 is stopped(2:NOT_RUNNING)."
六 配置keepalived
设置为用户提供服务的地址为"172.18.14.55/16",通过keepalived实现VIP在Mysql复制集群中浮动。
1 安装keepalived
使用默认yum安装即可;在Mysql复制集群的所有主机上都安装配置keepalived;
[root@vin ~]# yum install keepalived -y
2修改keepalived配置文件实现keepalived集群
Master:
[root@vin ~]# vim /etc/keepalived/keepalived.conf ! Configuration File for keepalivedglobal_defs {notification_email {root@localhost}notification_email_from kadmin@localhostsmtp_server 127.0.0.1smtp_connect_timeout 30router_id LVS_DEVELroute_mcast_group4 224.14.0.14 # 广播地址 }vrrp_script chk_mysql {script "killall -0 mysql" # 监控mysql健康性脚本insterval 1weight -10 } vrrp_instance VI_1 { # keepalived实例state BACKUPinterface ens33virtual_router_id 66priority 98 # keepalived节点优先级advert_int 1authentication {auth_type PASSauth_pass 1111}virtual_ipaddress {172.18.14.55/16 # 面向客户端的地址}track_script {chk_mysql}}
Slave{1,2}:复主节点的配置文件至Slave节点:
[root@vin ~]# for i in {3,4};do scp /etc/keepalived/keepalived.conf \ root@node$i:/etc/keepalived/ ;done
说明:复制过去并不能直接使用,由于keepalived通过优先级机制来决定VIP工作在哪台主机,所以将两个从节点的优先级调节至比主节点上keepalived的优先级低,且互相不同。
有心人可能发现问题了,怎么没有修改VRRP实例的状态"state BACKUP";上面服务器的keepalived都设置为了BACKUP模式,在keepalived中2种模式,分别是master->backup模式和backup->backup模式。这两种模式有很大区别。在master->backup模式下,一旦主节点宕机,虚拟ip会自动漂移到从节点,当主节点修复后,keepalived启动后,还会把虚拟ip抢占过来,即使设置了非抢占模式(nopreempt)抢占ip的动作也会发生。在backup->backup模式下,当主节点故障后虚拟ip会自动漂移到从节点上,当原主节点恢复后,并不会抢占新主的虚拟ip,即使是优先级高于从库的优先级别,也不会发生抢占。为了减少ip漂移次数,通常是把修复好的主库当做新的备库。
七 故障出现
模拟故障发生,我们手动"down"掉了主节点,生产中可能有各种原因导致故障的出现,这里为了最好的模拟办法,当然是关停服务了。
1 Master
[root@vin ~]# systemctl stop mariadb
2 在MHA节点上查看MHA的状态
[root@vin ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf .... Mon Nov 13 22:36:37 2017 - [info] MHA::MasterMonitor version 0.56. Mon Nov 13 22:36:37 2017 - [info] GTID failover mode = 0 Mon Nov 13 22:36:37 2017 - [info] Dead Servers: # 指明故障的节点 Mon Nov 13 22:36:37 2017 - [info] 172.18.250.27(172.18.250.27:3306) Mon Nov 13 22:36:37 2017 - [info] Alive Servers: Mon Nov 13 22:36:37 2017 - [info] 172.18.253.160(172.18.253.160:3306) Mon Nov 13 22:36:37 2017 - [info] 172.18.254.15(172.18.254.15:3306) Mon Nov 13 22:36:37 2017 - [info] Alive Slaves: Mon Nov 13 22:36:37 2017 - [info] 172.18.254.15(172.18.254.15:3306) # 从节点由两个转为了一个,另为一个升级为主节点 ....
3 在从节点进行测试看主节点是否正确切换
Slave1:
MariaDB [(none)]> show slave status; # 查看从节点状态为空,说明已非从节点 Empty set (0.00 sec)MariaDB [(none)]> show master status; # 再查看master状态,已正确切换 +-------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +-------------------+----------+--------------+------------------+ | master-log.000003 | 245 | | | +-------------------+----------+--------------+------------------+
Slave2:
MariaDB [(none)]> show slave status\G; *************************** 1. row ***************************Slave_IO_State: Waiting for master to send eventMaster_Host: 172.18.253.160 # 从节点"Slave2"已经将主节点指向了新的主节点Master_User: vinsentMaster_Port: 3306Connect_Retry: 60Master_Log_File: master-log.000003 ...
4 查看keepalived地址绑定情况:
Master:
[root@vin ~]# ip a | grep ens33 2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000inet 172.18.250.27/16 brd 172.18.255.255 scope global dynamic ens33
Slave1:
[root@vin ~]# ip a | grep ens33 2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000inet 172.18.250.160/16 brd 172.18.255.255 scope global dynamic ens33inet 172.18.14.55/16 scope global secondary ens33 # 地址正确漂移至从节点Slave1
Slave2:
[root@vin ~]# ip a | grep ens33 2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000inet 172.18.254.15/16 brd 172.18.255.255 scope global dynamic ens33
八 故障恢复
为了满足集群要求,应当立即将故障的主节点修复上线。由于Mysql复制集群的主节点已然切换,那么故障的原主节点上线之后只能为从节点,所以应当修改其配置文件满足从节点的要求。
1 Master节点
[root@vin ~]# vim /etc/my.cnf.d/server.cnf # 添加如下两项 [server] relay_log_purge = OFF read_only = ON
启动服务,并连接Mysql;并连接至新的主节点做主从同步;这里值得注意的是:如果你的主节点是在运行过程中故障宕机来了,那么你要做的就不仅仅是修改配置,启动服务了。修改配置文件之后,应当对新主做一个完全备份,将新主节点的数据恢复至本机,然后在连接至新的主节点做复制同步(本实验没有太多的数据,故直接上线)。
[root@vin ~]# systemctl start mariadb [root@vin ~]# mysql MariaDB [(none)]> change master to master_host='172.18.253.160',master_user='vinsent',master_password='vinsent',master_log_file='master-log.000003',master_log_pos=245; MariaDB [(none)]> start slave; MariaDB [(none)]> show slave status\G *************************** 1. row ***************************Slave_IO_State: Waiting for master to send eventMaster_Host: 172.18.253.160Master_User: vinsentMaster_Port: 3306 ...
2 Manager:
切换至MHA上并查看集群状态;
[root@vin ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf ... Mon Nov 13 22:54:53 2017 - [info] GTID failover mode = 0 Mon Nov 13 22:54:53 2017 - [info] Dead Servers: Mon Nov 13 22:54:53 2017 - [info] Alive Servers: Mon Nov 13 22:54:53 2017 - [info] 172.18.250.27(172.18.250.27:3306) # 由于没有在配置文件中指明谁是主,故这里只能看到所有工作的主机 Mon Nov 13 22:54:53 2017 - [info] 172.18.253.160(172.18.253.160:3306) Mon Nov 13 22:54:53 2017 - [info] 172.18.254.15(172.18.254.15:3306) Mon Nov 13 22:54:53 2017 - [info] Alive Slaves: Mon Nov 13 22:54:53 2017 - [info] 172.18.250.27(172.18.250.27:3306) ... MySQL Replication Health is OK.
启动MHA Manger监控,查看集群里面现在谁是master;
[root@vin ~]# masterha_check_status --conf=/etc/masterha/app1.cnf app1 is stopped(2:NOT_RUNNING).
??怎么回事,明明已经正确启动,为何此处显示为“stopped”;赶紧去官网一查发现:"Currently MHA Manager process does not run as a daemon. If failover completed successfully or the master process was killed by accident, the manager stops working. To run as a daemon, daemontool. or any external daemon program can be used. Here is an example to run from daemontools.",原来如此。
九 总结
通过查日志观察切换过程分析MHA切换过程:
[root@vin masterha]# cat manager.log Mon Nov 13 22:36:03 2017 - [info] MHA::MasterMonitor version 0.56. Mon Nov 13 22:36:04 2017 - [info] GTID failover mode = 0 Mon Nov 13 22:36:04 2017 - [info] Dead Servers: Mon Nov 13 22:36:04 2017 - [info] 172.18.250.27(172.18.250.27:3306) Mon Nov 13 22:36:04 2017 - [info] Alive Servers: Mon Nov 13 22:36:04 2017 - [info] 172.18.253.160(172.18.253.160:3306) Mon Nov 13 22:36:04 2017 - [info] 172.18.254.15(172.18.254.15:3306) Mon Nov 13 22:36:04 2017 - [info] Alive Slaves: Mon Nov 13 22:36:04 2017 - [info] 172.18.254.15(172.18.254.15:3306) Version=5.5.52-MariaDB (oldest major version between slaves) log-bin:enabled Mon Nov 13 22:36:04 2017 - [info] Replicating from 172.18.253.160(172.18.253.160:3306) Mon Nov 13 22:36:04 2017 - [info] Primary candidate for the new Master (candidate_master is set) Mon Nov 13 22:36:04 2017 - [info] Current Alive Master: 172.18.253.160(172.18.253.160:3306) Mon Nov 13 22:36:04 2017 - [info] Checking slave configurations.. Mon Nov 13 22:36:04 2017 - [warning] relay_log_purge=0 is not set on slave 172.18.254.15(172.18.254.15:3306). Mon Nov 13 22:36:04 2017 - [info] Checking replication filtering settings.. Mon Nov 13 22:36:04 2017 - [info] binlog_do_db= , binlog_ignore_db= Mon Nov 13 22:36:04 2017 - [info] Replication filtering check ok. Mon Nov 13 22:36:04 2017 - [info] GTID (with auto-pos) is not supported Mon Nov 13 22:36:04 2017 - [info] Starting SSH connection tests.. Mon Nov 13 22:36:05 2017 - [info] All SSH connection tests passed successfully. Mon Nov 13 22:36:05 2017 - [info] Checking MHA Node version.. Mon Nov 13 22:36:06 2017 - [info] Version check ok. Mon Nov 13 22:36:06 2017 - [error][/usr/share/perl5/vendor_perl/MHA/ServerManager.pm, ln492] Server 172.18.250.27(172.18.250.27:3306) is dead, but must be alive! Check server settings. Mon Nov 13 22:36:06 2017 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln424] Error happened on checking configurations. at /usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm line 399. Mon Nov 13 22:36:06 2017 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln523] Error happened on monitoring servers. Mon Nov 13 22:36:06 2017 - [info] Got exit code 1 (Not master dead). Mon Nov 13 22:36:13 2017 - [info] MHA::MasterMonitor version 0.56. Mon Nov 13 22:36:13 2017 - [info] GTID failover mode = 0 Mon Nov 13 22:36:13 2017 - [info] Dead Servers: Mon Nov 13 22:36:13 2017 - [info] 172.18.250.27(172.18.250.27:3306) Mon Nov 13 22:36:13 2017 - [info] Alive Servers: Mon Nov 13 22:36:13 2017 - [info] 172.18.253.160(172.18.253.160:3306) Mon Nov 13 22:36:13 2017 - [info] 172.18.254.15(172.18.254.15:3306) Mon Nov 13 22:36:13 2017 - [info] Alive Slaves: Mon Nov 13 22:36:13 2017 - [info] 172.18.254.15(172.18.254.15:3306) Version=5.5.52-MariaDB (oldest major version between slaves) log-bin:enabled Mon Nov 13 22:36:13 2017 - [info] Replicating from 172.18.253.160(172.18.253.160:3306) Mon Nov 13 22:36:13 2017 - [info] Primary candidate for the new Master (candidate_master is set) Mon Nov 13 22:36:13 2017 - [info] Current Alive Master: 172.18.253.160(172.18.253.160:3306) Mon Nov 13 22:36:13 2017 - [info] Checking slave configurations.. Mon Nov 13 22:36:13 2017 - [warning] relay_log_purge=0 is not set on slave 172.18.254.15(172.18.254.15:3306). Mon Nov 13 22:36:13 2017 - [info] Checking replication filtering settings.. Mon Nov 13 22:36:13 2017 - [info] binlog_do_db= , binlog_ignore_db= Mon Nov 13 22:36:13 2017 - [info] Replication filtering check ok. Mon Nov 13 22:36:13 2017 - [info] GTID (with auto-pos) is not supported Mon Nov 13 22:36:13 2017 - [info] Starting SSH connection tests.. Mon Nov 13 22:36:15 2017 - [info] All SSH connection tests passed successfully. Mon Nov 13 22:36:15 2017 - [info] Checking MHA Node version.. Mon Nov 13 22:36:15 2017 - [info] Version check ok. Mon Nov 13 22:36:15 2017 - [error][/usr/share/perl5/vendor_perl/MHA/ServerManager.pm, ln492] Server 172.18.250.27(172.18.250.27:3306) is dead, but must be alive! Check server settings. Mon Nov 13 22:36:15 2017 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln424] Error happened on checking configurations. at /usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm line 399. Mon Nov 13 22:36:15 2017 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln523] Error happened on monitoring servers. Mon Nov 13 22:36:15 2017 - [info] Got exit code 1 (Not master dead).
从上面的输出可以看出整个MHA的切换过程,共包括以下的步骤:
配置文件检查阶段,这个阶段会检查整个集群配置文件配置
宕机的master处理,这个阶段包括虚拟ip摘除操作,主机关机操作,这是MHA管理keepalived的时候,我们这里是通过keepalived的脚本实现mysql状态监控的。MHA也有管理keepalived的脚本,有需要的可以自行研究。
复制dead maste和最新slave相差的relay log,并保存到MHA Manger具体的目录下
识别含有最新更新的slave
应用从master保存的二进制日志事件(binlog events)
提升一个slave为新的master进行复制
使其他的slave连接新的master进行复制
目前高可用方案可以一定程度上实现数据库的高可用,比如MMM,heartbeat+drbd,Cluster等。还有percona的Galera Cluster等。这些高可用软件各有优劣。在进行高可用方案选择时,主要是看业务还有对数据一致性方面的要求。最后出于对数据库的高可用和数据一致性的要求,推荐使用MHA架构。
转载于:https://blog.51cto.com/vinsent/1981733
keepalived+MHA实现mysql主从高可用集群相关推荐
- mysql vip_MySQL高可用集群的VIP切换
一.目的 实现在mysql高可用集群的VIP切换,不涉及数据补偿 二.基础环境 python3.0+ 三.具体三大部分 1.启动条件检测检测集群是否down机 方式 select 1 检测主库是否有V ...
- MySQL数据库高可用集群搭建-PXC集群部署
Percona XtraDB Cluster(下文简称PXC集群)提供了MySQL高可用的一种实现方法.集群是有节点组成的,推荐配置至少3个节点,但是也可以运行在2个节点上. PXC原理描述: 分布式 ...
- 基于corosync+pacemaker实现主从高可用集群
本实验由两个节点组成高可用主从集群,在实际中不常用,目的是通过实验来加深对corosync的认识和理解. 环境设置: node1:node1.magedu.com ip 172.16.14.10 no ...
- activitimq集群搭建_activitmq+keepalived+nfs 非zk的高可用集群构建
nfs 192.168.10.32 maast 192.168.10.4 savel 192.168.10.31 应对这个需求既要高可用又要消息延迟,只能使用变态方式实现 nfs部署 #yum ins ...
- 18.1 集群介绍 18.2 keepalived介绍 18.3/18.4/18.5 用keepalived配置高可用集群
2019独角兽企业重金招聘Python工程师标准>>> 第十八章 Linux集群 18.1 集群介绍 Linux集群根据功能划分为两大类:高可用和负载均衡. 高可用集群 高可用集群通 ...
- 18.3/18.4/18.5 用keepalived配置高可用集群
2019独角兽企业重金招聘Python工程师标准>>> 用keepalived配置高可用集群 准备两台机器130和132,130作为master,132作为backup 两台机器都执 ...
- nfs mysql_heatbeat-gui实现基于nfs的mysql高可用集群
一.简述HA高可用集群 高可用集群就是当集群中的一个节点发生各种软硬件及人为故障时,集群中的其他节点能够自动接管故障节点的资源并向外提供服务.以实现减少业务中断时间,为用户提供更可靠,更高效的服务. ...
- LVS+Keepalived-DR模式负载均衡高可用集群
LVS+Keepalived DR模式负载均衡+高可用集群架构图 工作原理: Keepalived采用VRRP热备份协议实现Linux服务器的多机热备功能. VRRP,虚拟路由冗余协议,是针对路由器的 ...
- 企业中MySQL高可用集群架构三部曲之MM+keepalived
各位老铁们,老张与大家又见面了.看到各位在博客里面给我的留言和访问量的情况,我很是欣慰,也谢谢大家对我的认可.我写这些博客,就是想把自己对于MySQL数据库的一些看法和自己平时的实战经验分享出来,我们 ...
最新文章
- Note:一些优化建议
- 回调函数在replace方法中的应用
- cuda安装和caffe
- 上海交大计算机网络课件 翁惠玉 ppt,上海交通大学 计算机网络PPT3 翁惠玉.ppt
- 文献记录(part7)--An Improved Biclustering Algorithm and Its Application to Gene Expression ...
- 公差基本偏差代号_螺纹基础知识学习,螺纹公差标准的结构,螺纹公差带与旋合长度...
- 高精度测量让交会对接更“温柔”
- 3-AIV--使用ContentProvider获得所有图片路径
- Q96:PT(1):方格纹理(Checker)(1)——3D Checker
- View绘制详解(四),谝一谝layout过程
- 预应力钢筒混凝土管(PCCP)行业发展现状及竞争格局分析报告2022-2027年版
- 计算当前时间到午夜零点的时间差——Java(JDK1.8)
- HTML5个人学习笔记(一)
- C#绘制中国象棋棋盘
- linux运行ardupilot,ardupilot在Linux上的启动过程
- 软件工程(三)——敏捷开发和理解需求
- 很久以前看到的很经典的小说
- 动态网页和静态网页之间的区别?
- STC 89C52 单片机引脚对应的功能以及实例讲解
- 如何真正发挥CRM的价值?