第一部分:MYSQL MHA架构介绍说明
一、MHA简述
本次简述来官方
MHA通常在10-30秒内以最小的停机时间自动执行master故障转移和slave升级为new master。
MHA可以防止复制一致性问题,并节省购买其他服务器的开销。所有这些都没有性能下降,没有复杂性(易于安装),不需要更改现有部署
MHA还提供了预定的在线master切换,可以在停机(仅阻塞写操作)后几秒内(0.5-2秒)安全地将当前正在运行的master更改为new master。
MHA具有如下功能:
1.Automated master monitoring and failover
MHA可以已建好的复制环境中监视MySQL主机,在检测到master故障时执行自动主故障转移。
MHA通过获取日志最新的slave服务器中继日志事件,并将其应用于所有其他slave(包括那些仍然没有接收到最新中继日志事件的slave)来保证所有slave的一致性。
MHA通常可以在几秒钟内执行故障转移:9-12秒检测主设备故障,7-10秒关闭主设备电源以避免大脑分裂,几秒向新主设备应用差异继电器日志。总的停机时间通常为10-30秒。
可以在配置文件中将特定的slave节点点指定为候选主节点(设置优先级)。
由于MHA保持了slave之间的一致性,所以任何slave都可以被提升为new master。
通常下,复制突然失败的一致性问题不会发生。
2.Interactive (manually initiated) Master Failover
MHA可以配置为手动启动(非自动)、交互式故障转移,而无需监视主服务器。
3.Non-interactive master failover
还支持非交互式的自动主故障转移,无需监视主服务器。当MySQL主软件监控已经在使用时,这个特性特别有用。例如,您可以使用Pacemaker(Heartbeat)检测主故障和虚拟IP地址接管,同时使用MHA进行主故障转移和从服务器升级。
4.Online switching master to a different host
通常有必要将现有的主服务器迁移到另一台机器上,比如当前主服务器有H/W RAID控制器或RAM问题,或者希望用更快的机器替换它,等等。这不是主崩溃,但是需要定期的主维护。
计划的主程序维护应该尽快完成,因为它需要部分停机(主程序写被禁用)。另一方面,您应该非常小心地阻塞/终止当前正在运行的会话,因为不同的主机之间可能会出现一致性问题(如“更新master1,更新master 2,提交master1,提交master 2出错”将导致数据不一致)。快速主开关和优雅的阻塞写都是必需的。
MHA在写入器阻塞后0.5-2秒内提供优雅的主开关。0.5-2秒的写程序停机时间通常是可以接受的,因此即使不分配计划维护窗口,也可以切换主程序。诸如升级到更高版本、更快的机器等操作变得容易得多。
5.选主时面对的困难
主故障转移并不像看上去那么简单。以最典型的MYSQL部署为例,一个master有多个slave。
如果主服务器崩溃,您需要选择一个最新的slave,将其提升到new master,并让其他slave从new master开始复制,这并不是小事。
即使可以识别出当前的slave,其他slave也可能还没有收到所有的二进制日志事件。如果在复制开始时连接到new master,这些slave将丢失事务。这会导致一致性问题。为了避免这些一致性问题,需要在提升slave为new master的复制之前,依次标识丢失的binlog事件(还没有到达所有从属服务器),并将其应用于每个从属服务器。这种操作非常复杂,很难手工执行。
MHA的目标是尽可能快地实现主故障转移和恢复过程的完全自动化。恢复包括确定new master、确定所有slave的差异中继日志事件、向new master应用必要的事件、同步其他slave并让它们从新主服务器开始复制。
MHA通常可以在10-30秒的停机时间内进行故障转移(10秒检测主机故障,可选7-10秒关闭主机电源以避免大脑分裂,几秒或更长时间进行恢复),具体取决于复制延迟。
MHA提供自动和手动故障转移命令。自动故障转移命令“masterha_manager (MHA Manager)”由主监视和主故障转移组成。masterha_manager永久地监视主服务器的可用性。如果MHA Manager无法到达主服务器,它将自动启动非交互式故障转移过程。
手动故障转移命令“masterha_master_switch”最初会检查master是否已经死亡。如果主服务器确实已死,masterha_master_switch将从服务器中选择一个作为新主服务器(您可以选择首选的主服务器),并启动恢复和故障转移。
在内部,它可以执行更多的操作,但是只执行一个命令,而不需要自己执行复杂的主恢复和故障转移操作。
二、MHA架构
1.When a master crashes, MHA recovers rest slaves as below.
在从服务器上的中继日志文件中,主服务器的二进制日志位置写在“end_log_pos”部分(示例)。通过比较从服务器之间最新的end_log_pos,我们可以确定哪些中继日志事件没有发送到每个从服务器。MHA通过使用此机制在内部恢复从服务器(修复一致性问题)。MHA做了一些优化和增强,比如非常快速地生成差分中继日志(独立于中继日志文件大小),binlog基于row格式等等。
2.MHA consists of MHA Manager and MHA Node
MHA Manager具有监控MySQL主机、控制主机故障转移等管理程序。
MHA Node有故障转移帮助脚本,例如解析MySQL二进制/中继日志、确定中继日志的位置(中继日志应该从哪个位置应用到其他从节点)、将事件应用到目标从节点等等。MHA节点在每个MySQL服务器上运行。
当MHA Manager执行故障转移时,MHA Manager通过SSH连接MHA节点,并在需要时执行MHA节点命令。
3.MHA Manager里可以扩展的脚本。
secondary_check_script:用于检查来自多个网络路由的主可用性
master_ip_failover_script:用于更新应用程序中使用的主ip地址
shutdown_script:用于强制关闭主服务器
report_script:用于发送报告
init_con_load_script:用于加载初始配置参数
master_ip_online_change_script:用于更新主ip地址。这不是用于主故障转移,而是用于在线master切换
三、MHA优点
1.Master failover and slave promotion can be done very quickly
MHA通常可以在几秒钟内故障转移(9 – 12秒检测主失败,选择7 – 10秒关机主机避免分裂的大脑,几秒钟应用差异中继日志到new master上,所以总停机时间通常是10 – 30秒),只要slave不延迟复制严重。
在选举出一个new master后,MHA并行地恢复其他slave。即使您有数十个slave,它也不会影响master恢复时间,而且您可以非常快速地恢复slave。
2.Master crash does not result in data inconsistency
当前主服务器崩溃时,MHA自动标识从服务器之间的差异中继日志事件,并应用于每个从服务器。因此,只要所有从服务器都是活动的,所有从服务器就可以保持同步。通过与增强半同步复制一起使用,(几乎)没有数据丢失也可以得到保证。
3.No need to modify current MySQL settings
MHA最重要的设计原则之一是使MHA尽可能长时间地易于使用。MHA与现有的传统MySQL 5.0+主从复制环境兼容。尽管许多其他HA解决方案需要更改MySQL部署设置,但MHA并不强制dba执行此类任务。MHA使用最常见的两层单主机和多个从机环境。MHA同时支持异步和半同步MySQL复制。启动/停止/升级/降级/安装/卸载MHA无需更改(包括启动/停止)MySQL复制。当您需要将MHA升级到新版本时,不需要停止MySQL。只需替换为较新的MHA版本并重新启动MHA管理器即可。
MHA可以从MySQL 5.0开始使用普通MySQL版本。一些HA解决方案需要特殊的MySQL版本(例如MySQL集群、带有全局事务ID的MySQL等),但是您可能不喜欢只为主HA迁移应用程序。在很多情况下,人们已经部署了许多遗留的MySQL应用程序,他们不想花太多时间迁移到不同的存储引擎或更新的主流发行版上,而仅仅是为了主HA。MHA支持包括5.0/5.1/5.5在内的普通MySQL版本,因此不需要迁移。
4.No need to increase lots of servers
MHA由MHA管理器和MHA节点组成。当发生故障转移/恢复时,MHA节点在MySQL服务器上运行,因此它不需要额外的服务器。MHA Manager通常运行在专用服务器上,所以您需要为HA服务器添加一个(或两个)主机,但是MHA Manager可以从单个服务器监视很多(甚至100多个)主机,所以服务器的总数不会增加太多。注意,甚至可以在一个从服务器上运行MHA Manager。在这种情况下,服务器的总数根本没有增加。
5.No performance penalty
MHA支持常规的异步或半同步MySQL复制。在监视主服务器时,MHA只是每N秒向主服务器发送ping包(默认值为3),并不发送繁重的查询。您可以期望与常规MySQL复制一样快的性能。
6.Works with any storage engine
只要MySQL复制能够工作,MHA就可以与任何存储引擎一起工作,而不限于InnoDB(安全的事务存储引擎)。即使使用不易迁移的遗留MyISAM环境,也可以使用MHA。
7.Using together with Semi-Synchronous Replication
尽管MHA试图从崩溃的主服务器中保存二进制日志,但这并不总是可能的。例如,如果崩溃的主机死于H/W故障或无法通过SSH访问,MHA不能保存二进制日志,并且必须在不应用仅存在于崩溃的主机上的二进制日志事件的情况下进行故障转移。这将导致丢失最新的数据。
使用半同步复制大大降低了此类数据丢失的风险。MHA使用半同步复制,因为它基于MySQL复制机制。值得注意的是,如果只有一个从服务器收到了最新的二进制日志事件,那么MHA可以将这些事件应用于所有其他从服务器,这样它们就可以彼此保持一致。
四、MHA限制条件或缺点
1.SSH public key authentication(配置对等性,安全性需要注意)
MHA Manager通过SSH在内部连接MySQL服务器。因为通过SSH(scp)向其他从服务器内部发送中继日志文件。为了使这些过程自动化,通常建议启用SSH公钥身份验证而不使用密码短语。可以使用MHA Manager中包含的masterha_check_ssh命令检查SSH连接是否正常工作。
2.MHA只运行在linux系统下
3.如果master机器掉电导致,slave提升为new master,可能会导致数据丢失(增强半同步解决)
4.如果因为网络波动导致监听master故障误判,导致slave提升为new master,可能会导致数据丢失
5.MHA默认不支持三层或多层复制结构(即Master1 -> Master2 -> Slave3),当master1崩溃时,MHA可以管理master1和master2并提升new master,但是MHA不能监控和恢复slave3,因为slave3从不同的master2复制。要使MHA能够使用这些结构,可以配置如下:
需在MHA配置文件中设置主主机和第二层主机(master1和master2),使用“multi_tier_slave=1”参数并在MHA配置文件中设置所有主机
6.MHA支持5.1之后的版本并且binlog格式时候v4,
7.MHA要求mysqlbinlog版本需要在5.1以上,否
8.如果当前的slave没开启binlog,显然他们不能成为new master。MHA Manager在内部检查binlog设置,并且不将它们提升到new master。如果当前从服务器中都没有设置binlog, MHA Manager将不进行故障转移。
9.复制过滤规则(binlog-do-db、replicate-ignore-db等)在所有MySQL服务器上必须是相同的。MHA在启动时检查过滤规则,如果过滤规则彼此不相同,则不启动监视或故障转移(建议不要配置任何过滤规则)
10.主故障转移完成后,所有其他从服务器执行CHANGE master TO语句。要启动复制,new master上必须存在一个拥有REPLICATION SLAVE权限用户。
11.默认情况下,如果SQL线程已经执行完从服务器上的中继日志,则会自动删除它们。但中继日志可能仍然需要用于恢复其他的slave。因此,您需要禁用自动中继日志清除,并定期清除旧的中继日志。但是在手动清除中继日志时,需要注意复制延迟问题。在ext3文件系统上,删除大型文件需要大量的时间,这将导致严重的复制延迟。
12.如果要使用LOAD数据,请设置sql_log_bin=0;加载数据…;设置sql_log_bin = 1;是比较推荐的方法。
五.使用时总结
1.使用MHA时,可能需要自己编写一些脚本取弥补MHA的不足,例如:加强主从之间的延迟监控,进行vip自动故障切换功能
2.MHA后台守护进程,每次进行切换完之后,会自动关闭管理进程,需要再启动
3.建议使用GTID+ROW+semi-sync-replication加强数据不丢失
4.主库和slave的用户权限一样,集群里禁止使用过滤规则
5.进行选主后,其他slave如果落后很大,会导致恢复slave时很慢
6.基于gtid模式下,截止0.58版本,mysql master crash之后,不会做补偿机制(普通的binlogserver(利用mysqlbinlog工具搭建的)解决不了这个问题,通过增强半同步或者sync的binlogserver解决这个问题)
7.传统复制注意relay_log_purge需要关闭,每天需要手工清理relay_log_purge,防止在利用relay进行日志补偿时日志已经被删除了
8.super_read_only mha不支持这个参数开关,需要自己改动源码
第二部分:构建生产MHA架构
一、安装包选择
MHA有现在比较常见的版本0.56 0.57.0.58
0.56 最佳操作系统:centos6 支持GTID
0.57 最佳操作系统:centos7 支持0.56
0.58 最佳操作系统:centos7 支持ipv6+支持0.57特性(本次选择)
note:l利用源码编译安装0.58在centos6上
mysql:5.7.24版本
二、资源规划
1.本次MHA整个架构 mysql拓扑结构
主机名 ip地址 作用
trsen191 172.18.0.191 master
trsen192 172.18.0.192 slave
trsen193 172.18.0.193 slave
zabbix24 172.18.0.11 mha manager
vip资源 172.18.0.200 节点间浮动
2.拓扑结构如下:
三、mha软件包安装
github下载安装软件
先安装node,再安装manager,实际上针对数据库节点只需要安装node即可(线上建议)
1.node包及依赖包安装
yum -y install perl-DBD-MySQL ncftp perl-DBI
[root@trsen191 dfile]# rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm
Preparing... ################################# [100%]
Updating / installing...
1:mha4mysql-node-0.58-0.el7.centos ################################# [100%]
会在/usr/bin目录生成如下四个命令
apply_diff_relay_logs
filter_mysqlbinlog
purge_relay_logs
save_binary_logs
2.manager包及依赖包安装
yum install -y perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager
[root@trsen191 dfile]# rpm -ivh mha4mysql-manager-0.58-0.el7.centos.noarch.rpm
Preparing... ################################# [100%]
Updating / installing...
1:mha4mysql-manager-0.58-0.el7.cent################################# [100%]
会在/usr/bin目录生成如下就个命令
masterha_check_repl
masterha_check_ssh
masterha_check_status
masterha_conf_host
masterha_manager
masterha_master_monitor
masterha_master_switch
masterha_secondary_check
masterha_stop
四、服务间之间对等配置
1.生成key,一路回车即可
[root@trsen191 .ssh]# cd ~/.ssh/ & ssh-keygen
2.创建ssh需要的秘钥文件
[root@trsen191 .ssh]# cat id_rsa.pub >> authorized_keys
3.copy key文件
[root@trsen191 ~]# scp -r .ssh/ 172.18.0.192:~/
[root@trsen191 ~]# scp -r .ssh/ 172.18.0.193:~/
[root@trsen191 ~]# scp -r .ssh/ 172.18.0.11:~/
4..ssh目录权限为700,id_rsa,authorized_keys权限为600
5.测试
五、安装mysql,这里不多介绍说明,见文章mysql5.7.24二进制快速安装,里面参数要根据生产上的信息进行相关配置
需要指出创建管理用户和一个复制用户
mysql> create user 'trsen'@'172.18.0.%' identified by 'trsen';
Query OK, 0 rows affected (1.02 sec)
mysql> grant all privileges on *.* to 'trsen'@'172.18.0.%';
Query OK, 0 rows affected (0.04 sec)
mysql> create user 'repl'@'172.18.0.%' identified by 'repl';
Query OK, 0 rows affected (0.03 sec)
mysql> grant replication slave on *.* to 'repl'@'172.18.0.%';
Query OK, 0 rows affected (0.01 sec)
六、MHA配置
1.在manager节点和node节点创建目录
mkir -p /usr/local/masterha/mha1
2.管理节点touch一个空的masterha_default.cnf文件
touch /etc/masterha_default.cnf
3.创建配置文件
vi /usr/local/masterha/masterha_mha1.cnf
###################global###############
[server default]
#log_level=debug
#MySQL的用户和密码
user=trsen
password=trsen
#系统ssh用户
ssh_user=root
ssh_port=22
#复制用户
repl_user=repl
repl_password=repl
#监控
ping_interval=3
#shutdown_script=""
#切换调用的脚本
master_ip_failover_script= /usr/local/masterha/master_ip_failover
master_ip_online_change_script= /usr/local/masterha/master_ip_online_change
#################################cluster1#############################################
#mha manager工作目录
manager_workdir = /usr/local/masterha/mha1
manager_log = /usr/local/masterha/mha1/mha1.log
remote_workdir = /usr/local/masterha/mha1
port = 3309
[server1]
hostname=172.18.0.191
master_binlog_dir = /data/mysql/mha/logs
candidate_master = 1
check_repl_delay = 0 #用防止master故障时,切换时slave有延迟,卡在那里切不过来。
[server2]
hostname=172.18.0.192
master_binlog_dir=/data/mysql/mha/logs
candidate_master=1
check_repl_delay=0
[server3]
hostname=172.18.0.193
master_binlog_dir=/data/mysql/mha/logs
candidate_master=1
check_repl_delay=0
4.将master_ip_failover和master_ip_online_change放进配置文件里指定目录位置,但是需要进行手工的修改,样例代码去tar包文件中的sample目录获取或者
5.检查ssh对等性
[root@zabbix24 masterha]# masterha_check_ssh --conf=/usr/local/masterha/masterha_mha1.cnf
Wed Jul 24 16:29:41 2019 - [info] Reading default configuration from /etc/masterha_default.cnf..
Wed Jul 24 16:29:41 2019 - [info] Reading application default configuration from /usr/local/masterha/masterha_mha1.cnf..
Wed Jul 24 16:29:41 2019 - [info] Reading server configuration from /usr/local/masterha/masterha_mha1.cnf..
Wed Jul 24 16:29:41 2019 - [info] Starting SSH connection tests..
Wed Jul 24 16:29:42 2019 - [debug]
Wed Jul 24 16:29:41 2019 - [debug] Connecting via SSH from root@172.18.0.191(172.18.0.191:22) to root@172.18.0.192(172.18.0.192:22)..
Wed Jul 24 16:29:42 2019 - [debug] ok.
Wed Jul 24 16:29:42 2019 - [debug] Connecting via SSH from root@172.18.0.191(172.18.0.191:22) to root@172.18.0.193(172.18.0.193:22)..
Wed Jul 24 16:29:42 2019 - [debug] ok.
Wed Jul 24 16:29:43 2019 - [debug]
Wed Jul 24 16:29:42 2019 - [debug] Connecting via SSH from root@172.18.0.192(172.18.0.192:22) to root@172.18.0.191(172.18.0.191:22)..
Wed Jul 24 16:29:42 2019 - [debug] ok.
Wed Jul 24 16:29:42 2019 - [debug] Connecting via SSH from root@172.18.0.192(172.18.0.192:22) to root@172.18.0.193(172.18.0.193:22)..
Wed Jul 24 16:29:43 2019 - [debug] ok.
Wed Jul 24 16:29:44 2019 - [debug]
Wed Jul 24 16:29:42 2019 - [debug] Connecting via SSH from root@172.18.0.193(172.18.0.193:22) to root@172.18.0.191(172.18.0.191:22)..
Wed Jul 24 16:29:43 2019 - [debug] ok.
Wed Jul 24 16:29:43 2019 - [debug] Connecting via SSH from root@172.18.0.193(172.18.0.193:22) to root@172.18.0.192(172.18.0.192:22)..
Wed Jul 24 16:29:43 2019 - [debug] ok.
Wed Jul 24 16:29:44 2019 - [info] All SSH connection tests passed successfully.
6.检查复制是不是正常
[root@zabbix24 masterha]# masterha_check_repl --conf=/usr/local/masterha/masterha_mha1.cnf
Wed Jul 24 16:38:12 2019 - [info] Reading default configuration from /etc/masterha_default.cnf..
Wed Jul 24 16:38:12 2019 - [info] Reading application default configuration from /usr/local/masterha/masterha_mha1.cnf..
Wed Jul 24 16:38:12 2019 - [info] Reading server configuration from /usr/local/masterha/masterha_mha1.cnf..
Wed Jul 24 16:38:12 2019 - [info] MHA::MasterMonitor version 0.58.
Wed Jul 24 16:38:13 2019 - [info] GTID failover mode = 1
Wed Jul 24 16:38:13 2019 - [info] Dead Servers:
Wed Jul 24 16:38:13 2019 - [info] Alive Servers:
Wed Jul 24 16:38:13 2019 - [info] 172.18.0.191(172.18.0.191:3309)
Wed Jul 24 16:38:13 2019 - [info] 172.18.0.192(172.18.0.192:3309)
Wed Jul 24 16:38:13 2019 - [info] 172.18.0.193(172.18.0.193:3309)
Wed Jul 24 16:38:13 2019 - [info] Alive Slaves:
Wed Jul 24 16:38:13 2019 - [info] 172.18.0.192(172.18.0.192:3309) Version=5.7.24-log (oldest major version between slaves) log-bin:enabled
Wed Jul 24 16:38:13 2019 - [info] GTID ON
Wed Jul 24 16:38:13 2019 - [info] Replicating from 172.18.0.191(172.18.0.191:3309)
Wed Jul 24 16:38:13 2019 - [info] Primary candidate for the new Master (candidate_master is set)
Wed Jul 24 16:38:13 2019 - [info] 172.18.0.193(172.18.0.193:3309) Version=5.7.24-log (oldest major version between slaves) log-bin:enabled
Wed Jul 24 16:38:13 2019 - [info] GTID ON
Wed Jul 24 16:38:13 2019 - [info] Replicating from 172.18.0.191(172.18.0.191:3309)
Wed Jul 24 16:38:13 2019 - [info] Primary candidate for the new Master (candidate_master is set)
Wed Jul 24 16:38:13 2019 - [info] Current Alive Master: 172.18.0.191(172.18.0.191:3309)
Wed Jul 24 16:38:13 2019 - [info] Checking slave configurations..
Wed Jul 24 16:38:13 2019 - [info] Checking replication filtering settings..
Wed Jul 24 16:38:13 2019 - [info] binlog_do_db= , binlog_ignore_db=
Wed Jul 24 16:38:13 2019 - [info] Replication filtering check ok.
Wed Jul 24 16:38:13 2019 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking.
Wed Jul 24 16:38:13 2019 - [info] Checking SSH publickey authentication settings on the current master..
Wed Jul 24 16:38:13 2019 - [info] HealthCheck: SSH to 172.18.0.191 is reachable.
Wed Jul 24 16:38:13 2019 - [info]
172.18.0.191(172.18.0.191:3309) (current master)
+--172.18.0.192(172.18.0.192:3309)
+--172.18.0.193(172.18.0.193:3309)
Wed Jul 24 16:38:13 2019 - [info] Checking replication health on 172.18.0.192..
Wed Jul 24 16:38:13 2019 - [info] ok.
Wed Jul 24 16:38:13 2019 - [info] Checking replication health on 172.18.0.193..
Wed Jul 24 16:38:13 2019 - [info] ok.
Wed Jul 24 16:38:13 2019 - [info] Checking master_ip_failover_script status:
Wed Jul 24 16:38:13 2019 - [info] /usr/local/masterha/master_ip_failover --command=status --ssh_user=root --orig_master_host=172.18.0.191 --orig_master_ip=172.18.0.191 --orig_master_port=3309
Wed Jul 24 16:38:13 2019 - [info] OK.
Wed Jul 24 16:38:13 2019 - [warning] shutdown_script is not defined.
Wed Jul 24 16:38:13 2019 - [info] Got exit code 0 (Not master dead).
MySQL Replication Health is OK.