mysql-master-ha：mysql master高可用性管理工具

最新推荐文章于 2021-08-16 14:11:52 发布

weixin_33828101

最新推荐文章于 2021-08-16 14:11:52 发布

阅读量417

点赞数

文章标签：数据库运维开发工具

原文链接：https://my.oschina.net/766/blog/211292

版权

为什么80%的码农都做不了架构师？>>>

mysql-master-ha ： mysql master 高可用性管理工具一． MHA 介绍 MHA 自动化主服务器故障转移，快速将从服务器晋级为主服务器 ( 通常在 10-30s) ，而不影响复制的一致性，不需要花钱买更多的新服务器，不会有性能损耗，容易安装，不必更改现有的部署环境，适用于任何存储引擎。 MHA 提供在线主服务器切换，改变先正运行的主服务器到另外一台上，这个过程只需 0.5-2s 的时间，这个时间内数据无法写入。 MHA Manager 通过 ssh 连接 mysql slave 服务器。虽然 MHA 试图从挡掉的主服务器上保存二进制日志，并不是总是可行的。例如，如果主服务器硬件故障或无法通过 ssh 访问， MHA 没法保存二进制日志，只进行故障转移而丢失最新数据。使用半同步复制，可以大大降低数据丢失的风险。 MHA 可以与半同步复制结合起来。如果只有一个 slave 已经收到了最新的二进制日志， MHA 可以将最新的二进制日志应用于其他所有的 slave 服务器上，因此他们彼此保持一致性。 MHA 有如下特性： 1.主服务器的自动监控和故障转移 MHA 监控复制架构的主服务器，一旦检测到主服务器故障，就会自动进行故障转移。即使有些从服务器没有收到最新的 relay log ， MHA 自动从最新的从服务器上识别差异的 relay log 并把这些日志应用到其他从服务器上，因此所有的从服务器保持一致性了。 MHA 通常在几秒内完成故障转移， 9-12 秒可以检测出主服务器故障， 7-10 秒内关闭故障的主服务器以避免脑裂，几秒中内应用差异的 relay log 到新的主服务器上，整个过程可以在 10-30s 内完成。还可以设置优先级指定其中的一台 slave 作为 master 的候选人。由于 MHA 在 slaves 之间修复一致性，因此可以将任何 slave 变成新的 master ，而不会发生一致性的问题，从而导致复制失败。 2.交互式主服务器故障转移可以只使用 MHA 的故障转移，而不用于监控主服务器，当主服务器故障时，人工调用 MHA 来进行故障故障。 3.非交互式的主故障转移不监控主服务器，但自动实现故障转移。这种特征适用于已经使用其他软件来监控主服务器状态，比如 heartbeat 来检测主服务器故障和虚拟 IP 地址接管，可以使用 MHA 来实现故障转移和 slave 服务器晋级为 master 服务器。 4.在线切换主服务器在许多情况下，需要将现有的主服务器迁移到另外一台服务器上。比如主服务器硬件故障， RAID 控制卡需要重建，将主服务器移到性能更好的服务器上等等。维护主服务器引起性能下降，导致停机时间至少无法写入数据。另外，阻塞或杀掉当前运行的会话会导致主主之间数据不一致的问题发生。 MHA 提供快速切换和优雅的阻塞写入，这个切换过程只需要 0.5-2s 的时间，这段时间内数据是无法写入的。在很多情况下， 0.5-2s 的阻塞写入是可以接受的。因此切换主服务器不需要计划分配维护时间窗口 ( 呵呵，不需要你在夜黑风高时通宵达旦完成切换主服务器的任务 ) 。注： MHA 可以应用于任何复制结构二． MHA 所需条件 1.SSH 公钥验证 MHA 管理节点通过 ssh 连接 mysql 服务器， MHA 节点通过 scp 发送最新的 relay log 到其他 slaves 服务器上。为了使这些过程自动化，使用 SSH 公钥验证密码。 2.操作系统 MHA 目前只支持 Linux 系统 3.单台可写主服务器和多台从服务器或只读主服务器当主服务器当掉时， MHA 修复从服务器之间数据一致性。 MHA 试图从当掉的主服务器上保存尚未发送的二进制日志文件并应用于所有从服务器。如果只有一个从服务器，就不需在意从服务器之间一致性问题。即使只有一个从服务器， MHA 也会从当掉的主服务器上保存尚未发送的二进制日志事件只要能通过 ssh 访问到主服务器。使用半同步复制可以解决当主服务器当掉后，无法 ssh 到主服务器上保存尚未发送的二进制日志事件。从 MHA Manager0.52 版本开始，支持多主复制结构。只允许其中一台主服务器可写，其他主服务器必须设置 read-only=1 。默认情况下，被管理服务器应该是两层复制结构。 4.在三层或三层以上复制情况下默认情况下， MHA 不支持三层或三层以上的复制结构。如 master1---master2----slave3 。 MHA 故障转移和恢复是直接从从服务器中选择一台作为当前的主主服务器。 MHA 可以管理 master1 和 master2 ，当 master1 当掉后，将 master2 作为主， MHA 不会监控和恢复 slave3 因为 slave3 是从不同的主服务器上 (master2) 复制的。为了使 MHA 工作在这种架构下，需要做如下设置：只在 MHA 配置文件中配置 master1 和 master2 在 MHA 配置文件中所有主机上设置 multi_tier_slave=1 在这种情况下， MHA 只管理主主服务器和二层的从服务器，在故障转移过程中，三层从服务器仍然可以正常工作的。 5.mysql 版本 5.0 或更高 MHA 支持 mysql5.0 或以上版本。因为从 mysql5.0 版本起二进制日志格式 (binlog v4 格式 ) 改变了。当 MHA 解析二进制日志来确定目标中继日志位置，是使用 v4 格式的。 MySQL 版本不得低于 5.0.60 。 6.mysqlbinlog 版本 3.3 或更高 MHA 在目标从服务器上应用二进制事件使用 mysqlbinlog 。如果主服务器使用基于行格式复制，基于行格式的事件写入到二进制文件中，这种二进制日志格式的文件只能被 MySQL5.1 或更高版本的 mysqlbinlog 解析。 MySQL5.0.60 以下版本中的 mysqlbinlog 不支持基于行格式的。 7.候选主服务器 log-bin 必须开启如果当前的从服务器没有开启 log-bin ，那么将不可能成为主服务器。 MHA 管理节点会检测是否有配置 log-bin 。如果当前所有从服务器都没有设置 log-bin ，那么 MHA 不进行故障转移。 8.所有服务器上的二进制日志和中继日志过滤规则必须相同 binlog-do-db 和 replicate-ignore-db 设置必须相同。 MHA 在启动时候会检测过滤规则，如果过滤规则不同， MHA 不启动监控和故障转移。 9.候选主服务器上的复制用户必须存在当故障转移后，所有从服务器上将执行 change master to 命令。 10.保留中继日志和定期清理默认情况下，从服务器上的中继日志在 SQL 线程执行完后会被自动删除的。但是这些中继日志在恢复其他从服务器时候可能会被用到，因此需要禁用中继日志的自动清除和定期清除旧的中继日志。定期清除中继日志需要考虑到复制延时的问题。在 ext3 文件系统下，删除大的文件需要一定的时间，会导致严重的复制延时。为了避免复制延时，暂时为中继日志创建硬链接。 MHA 节点包含 pure_relay_logs 命令工具，它可以为中继日志创建硬链接，执行SET GLOBAL relay_log_purge=1，等待几秒中以便 SQL 线程切换到新的中继日志，再执行SET GLOBAL relay_log_purge=0 。 pure_relay_logs 参数如下所示： --user mysql 用户名 --password mysql 密码 --host mysql 服务器地址 --port 端口号 --workdir 创建和删除中继日志硬链接目录。成功执行脚本后，硬链接的中继日志文件将被删除。默认目录是 /var/tmp 。 --disable_relay_log_purge 如果 relay_log_purge=1 ， purge_relay_logs 脚本将退出不做任何事情。设置 --disable_relay_log_purge 参数， purge_relay_logs 脚本不会退去，且自动设置 relay_log_purge=0 。定期执行 purge_relay_logs 脚本： Purge_relay_logs 脚本删除中继日志不会阻塞 SQL 线程。因此在每台从服务器上设置计划任务定期清除中继日志。 00 00 * * * /usr/bin/purge_relay_logs --user=root --password=passwd --disable_relay_log_purge >> /data/masterha/log/purge_relay_logs.log 2>&1 最好在每台从服务器上不同时间点执行计划任务。 11. LOAD DATA INFILE 不要使用基于语句型的二进制日志如果使用非事务性存储引擎，在执行完LOAD DATA INFILE 基于语句型二进制日志时，主服务器当掉， MHA 可能不会产生差异的中继日志事件。使用 LOAD DATA INFILE 基于语句型二进制日志有一些已知问题，在 mysql5.1 版本中不建议使用，同时还会引起严重的复制延时，因此没有理由使用它。三． MHA 过程 1. 监控和故障转移过程检测复制设置和确定当前主服务器监控主服务器检测主服务器当掉再次检测从服务器配置关闭当掉的主服务器 ( 可选 ) 恢复一个新的主服务器激活新的主服务器恢复其余的从服务器告警 ( 可选 ) 2. 在线切换过程检测复制设置和确定当前主服务器确定新的主服务器阻塞写入到当前主服务器等待所有从服务器赶上复制授予写入到新的主服务器重新设置从服务器四． MHA 安装 MHA 节点包含三个脚本，依赖 perl 模块。 save_binary_logs: 保存和复制当掉的主服务器二进制日志 apply_diff_relay_logs: 识别差异的 relay log 事件，并应用于其他 salve 服务器 purge_relay_logs: 清除 relay log 文件需要在所有 mysql 服务器上安装 MHA 节点， MHA 管理服务器也需要安装。 MHA 管理节点模块内部依赖 MHA 节点模块。 MHA 管理节点通过 ssh 连接管理 mysql 服务器和执行 MHA 节点脚本。 MHA 节点依赖 perl 的 DBD::mysql 模块。 1.安装 MHA Node 在所有的 mysql 服务器上安装 # apt-get install libdbd-mysql-perl # wget http://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.52.tar.gz # perl Makefile.PL # make # make install 2.安装 MHA Manager # apt-get install libdbd-mysql-perl # wget http://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.52.tar.gz # perl Makefile.PL # make # make install # apt-get install libconfig-tiny-perl # apt-get install liblog-dispatch-perl # apt-get install libparallel-forkmanager-perl # apt-get install libnet-telnet-perl # wget http://mysql-master-ha.googlecode.com/files/mha4mysql-manager-0.52.tar.gz # tar zxvf mha4mysql-manager-0.52.tar.gz -C ../software/ # perl Makefile.PL # make # make install 五．配置 1.配置主从结构【 node2 】 server-id = 101 log-bin=mysql-bin-101 mysql> grant replication slave on *.* to 'repl'@'192.168.1.%' identified by 'replpasswd'; mysql> grant all privileges on *.* to 'root'@'192.168.1.101' identified by '123456'; mysql> grant all privileges on *.* to 'root'@'192.168.1.189' identified by '123456'; 【 node3 】 server-id = 103 log-bin=mysql-bin-103 read_only=1 relay_log_purge=0 mysql> grant replication slave on *.* to 'repl'@'192.168.1.%' identified by 'replpasswd'; mysql> grant all privileges on *.* to 'root'@'192.168.1.103' identified by '123456'; mysql> grant all privileges on *.* to 'root'@'192.168.1.189' identified by '123456'; mysql> change master to -> master_host='192.168.1.101', -> master_user='repl', -> master_password='replpasswd', -> master_log_file='mysql-bin-101.000003', -> master_log_pos=660; 【 node4 】 server-id = 114 log-bin=mysql-bin-114 read_only=1 relay_log_purge=0 mysql> grant replication slave on *.* to 'repl'@'192.168.1.%' identified by 'replpasswd'; mysql> grant all privileges on *.* to 'root'@'192.168.1.114' identified by '123456'; mysql> grant all privileges on *.* to 'root'@'192.168.1.189' identified by '123456'; mysql> change master to -> master_host='192.168.1.101', -> master_user='repl', -> master_password='replpasswd', -> master_log_file='mysql-bin-101.000003', -> master_log_pos=660; 2.配置 mha # mkdir /etc/masterha # mkdir -p /masterha/app1 # cp ./mha4mysql-manager-0.52/samples/conf/* /etc/masterha/ # vim app1.cnf [server default] manager_workdir=/masterha/app1 manager_log=/masterha/app1/manager.log user=root password=123456 ssh_user=root repl_user=repl repl_password=replpasswd ping_interval=1 shutdown_script="" master_ip_failover_script="/usr/local/bin/master_ip_failover" master_ip_online_change_script="" report_script="" [server1] hostname=192.168.1.101 master_binlog_dir=/data/mydata candidate_master=1 [server2] hostname=192.168.1.103 master_binlog_dir=/data/mydata candidate_master=1 [server3] hostname=192.168.1.114 master_binlog_dir=/data/mydata mysql> grant all privileges on *.* to 'root'@'192.168.1.189' identified by '123456'; root@node1:~# ssh-keygen -t rsa root@node1:~# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.1.101 root@node1:~# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.1.103 root@node1:~# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.1.114 root@node2:~# ssh-keygen -t rsa root@node2:~# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.1.103 root@node2:~# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.1.114 root@node3:~# ssh-keygen -t rsa root@node3:~# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.1.101 root@node3:~# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.1.114 root@node4:~# ssh-keygen -t rsa root@node4:~# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.1.101 root@node4:~# ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.1.103 root@node1:~# masterha_check_ssh --conf=/etc/masterha/app1.cnf Tue Oct 25 20:51:04 2011 - [info] Reading default configuratoins from /etc/masterha_default.cnf.. Tue Oct 25 20:51:04 2011 - [info] Reading application default configurations from /etc/masterha/app1.cnf.. Tue Oct 25 20:51:04 2011 - [info] Reading server configurations from /etc/masterha/app1.cnf.. Tue Oct 25 20:51:04 2011 - [info] Starting SSH connection tests.. Tue Oct 25 20:51:05 2011 - [debug] Tue Oct 25 20:51:04 2011 - [debug] Connecting via SSH from root@192.168.1.101(192.168.1.101) to root@192.168.1.103(192.168.1.103).. Tue Oct 25 20:51:05 2011 - [debug] ok. Tue Oct 25 20:51:05 2011 - [debug] Connecting via SSH from root@192.168.1.101(192.168.1.101) to root@192.168.1.114(192.168.1.114).. Tue Oct 25 20:51:05 2011 - [debug] ok. Tue Oct 25 20:51:05 2011 - [debug] Tue Oct 25 20:51:05 2011 - [debug] Connecting via SSH from root@192.168.1.103(192.168.1.103) to root@192.168.1.101(192.168.1.101).. Tue Oct 25 20:51:05 2011 - [debug] ok. Tue Oct 25 20:51:05 2011 - [debug] Connecting via SSH from root@192.168.1.103(192.168.1.103) to root@192.168.1.114(192.168.1.114).. Tue Oct 25 20:51:05 2011 - [debug] ok. Tue Oct 25 20:51:06 2011 - [debug] Tue Oct 25 20:51:05 2011 - [debug] Connecting via SSH from root@192.168.1.114(192.168.1.114) to root@192.168.1.101(192.168.1.101).. Tue Oct 25 20:51:06 2011 - [debug] ok. Tue Oct 25 20:51:06 2011 - [debug] Connecting via SSH from root@192.168.1.114(192.168.1.114) to root@192.168.1.103(192.168.1.103).. Tue Oct 25 20:51:06 2011 - [debug] ok. Tue Oct 25 20:51:06 2011 - [info] All SSH connection tests passed successfully. root@node1:~# masterha_check_repl --conf=/etc/masterha/app1.cnf Wed Oct 26 20:47:34 2011 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping. Wed Oct 26 20:47:34 2011 - [info] Reading application default configurations from /etc/masterha/app1.cnf.. Wed Oct 26 20:47:34 2011 - [info] Reading server configurations from /etc/masterha/app1.cnf.. Wed Oct 26 20:47:34 2011 - [info] MHA::MasterMonitor version 0.52. Wed Oct 26 20:47:35 2011 - [info] Dead Servers: Wed Oct 26 20:47:35 2011 - [info] Alive Servers: Wed Oct 26 20:47:35 2011 - [info] 192.168.1.101(192.168.1.101:3306) Wed Oct 26 20:47:35 2011 - [info] 192.168.1.103(192.168.1.103:3306) Wed Oct 26 20:47:35 2011 - [info] 192.168.1.114(192.168.1.114:3306) Wed Oct 26 20:47:35 2011 - [info] Alive Slaves: Wed Oct 26 20:47:35 2011 - [info] 192.168.1.103(192.168.1.103:3306) Version=5.5.14-log (oldest major version between slaves) log-bin:enabled Wed Oct 26 20:47:35 2011 - [info] Replicating from 192.168.1.101(192.168.1.101:3306) Wed Oct 26 20:47:35 2011 - [info] Primary candidate for the new Master (candidate_master is set) Wed Oct 26 20:47:35 2011 - [info] 192.168.1.114(192.168.1.114:3306) Version=5.5.14-log (oldest major version between slaves) log-bin:enabled Wed Oct 26 20:47:35 2011 - [info] Replicating from 192.168.1.101(192.168.1.101:3306) Wed Oct 26 20:47:35 2011 - [info] Current Alive Master: 192.168.1.101(192.168.1.101:3306) Wed Oct 26 20:47:35 2011 - [info] Checking slave configurations.. Wed Oct 26 20:47:35 2011 - [info] Checking replication filtering settings.. Wed Oct 26 20:47:35 2011 - [info] binlog_do_db= , binlog_ignore_db= Wed Oct 26 20:47:35 2011 - [info] Replication filtering check ok. Wed Oct 26 20:47:35 2011 - [info] Starting SSH connection tests.. Wed Oct 26 20:47:37 2011 - [info] All SSH connection tests passed successfully. Wed Oct 26 20:47:37 2011 - [info] Checking MHA Node version.. Wed Oct 26 20:47:37 2011 - [info] Version check ok. Wed Oct 26 20:47:37 2011 - [info] Checking SSH publickey authentication and checking recovery script configurations on the current master.. Wed Oct 26 20:47:38 2011 - [info] Executing command: save_binary_logs --command=test --start_file=mysql-bin-101.000003 --start_pos=4 --binlog_dir=/data/mydata --output_file=/var/tmp/save_binary_logs_test --manager_version=0.52 Wed Oct 26 20:47:38 2011 - [info] Connecting to root@192.168.1.101(192.168.1.101).. Creating /var/tmp if not exists.. ok. Checking output directory is accessible or not.. ok. Binlog found at /data/mydata, up to mysql-bin-101.000003 Wed Oct 26 20:47:38 2011 - [info] Master setting check done. Wed Oct 26 20:47:38 2011 - [info] Checking SSH publickey authentication and checking recovery script configurations on all alive slave servers.. Wed Oct 26 20:47:38 2011 - [info] Executing command : apply_diff_relay_logs --command=test --slave_user=root --slave_host=192.168.1.103 --slave_ip=192.168.1.103 --slave_port=3306 --workdir=/var/tmp --target_version=5.5.14-log --manager_version=0.52 --relay_log_info=/data/mydata/relay-log.info --slave_pass=xxx Wed Oct 26 20:47:38 2011 - [info] Connecting to root@192.168.1.103(192.168.1.103).. Checking slave recovery environment settings.. Opening /data/mydata/relay-log.info ... ok. Relay log found at /data/mydata, up to node3-relay-bin.000004 Temporary relay log file is /data/mydata/node3-relay-bin.000004 Testing mysql connection and privileges.. done. Testing mysqlbinlog output.. done. Cleaning up test file(s).. done. Wed Oct 26 20:47:38 2011 - [info] Executing command : apply_diff_relay_logs --command=test --slave_user=root --slave_host=192.168.1.114 --slave_ip=192.168.1.114 --slave_port=3306 --workdir=/var/tmp --target_version=5.5.14-log --manager_version=0.52 --relay_log_info=/data/mydata/relay-log.info --slave_pass=xxx Wed Oct 26 20:47:38 2011 - [info] Connecting to root@192.168.1.114(192.168.1.114).. Checking slave recovery environment settings.. Opening /data/mydata/relay-log.info ... ok. Relay log found at /data/mydata, up to node4-relay-bin.000002 Temporary relay log file is /data/mydata/node4-relay-bin.000002 Testing mysql connection and privileges.. done. Testing mysqlbinlog output.. done. Cleaning up test file(s).. done. Wed Oct 26 20:47:39 2011 - [info] Slaves settings check done. Wed Oct 26 20:47:39 2011 - [info] 192.168.1.101 (current master) +--192.168.1.103 +--192.168.1.114 Wed Oct 26 20:47:39 2011 - [info] Checking replication health on 192.168.1.103.. Wed Oct 26 20:47:39 2011 - [info] ok. Wed Oct 26 20:47:39 2011 - [info] Checking replication health on 192.168.1.114.. Wed Oct 26 20:47:39 2011 - [info] ok. Wed Oct 26 20:47:39 2011 - [info] Checking master_ip_failvoer_script status: Wed Oct 26 20:47:39 2011 - [info] /usr/local/bin/master_ip_failover --command=status --ssh_user=root --orig_master_host=192.168.1.101 --orig_master_ip=192.168.1.101 --orig_master_port=3306 Wed Oct 26 20:47:39 2011 - [info] OK. Wed Oct 26 20:47:39 2011 - [warning] shutdown_script is not defined. Wed Oct 26 20:47:39 2011 - [info] Got exit code 0 (Not master dead). MySQL Replication Health is OK. root@node1:~# masterha_check_status --conf=/etc/masterha/app1.cnf app1 (pid:16179) is running(0:PING_OK), master:192.168.1.101 root@node3:~# crontab -l 00 00 * * * /usr/local/bin/purge_relay_logs --user=root --password=123456 --disable_relay_log_purge >> /masterha/purge_relay_logs.log 2>&1 root@node4:~# crontab -l 00 01 * * * /usr/local/bin/purge_relay_logs --user=root --password=123456 --disable_relay_log_purge >> /masterha/purge_relay_logs.log 2>&1 3.启动 MHA root@node1:~# nohup masterha_manager --conf=/etc/masterha/app1.cnf < /dev/null > /masterha/app1/manager.log 2>&1 & 六．测试 root@node2:~# pkill mysql* root@node1:~# tail -f manager.log 将看到整个过程 ----- Failover Report ----- app1: MySQL Master failover 192.168.1.101 to 192.168.1.103 succeeded Master 192.168.1.101 is down! Check MHA Manager logs at ubuntu:/masterha/app1/manager.log for details. Started automated(non-interactive) failover. Invalidated master IP address on 192.168.1.101. The latest slave 192.168.1.103(192.168.1.103:3306) has all relay logs for recovery. Selected 192.168.1.103 as a new master. 192.168.1.103: OK: Applying all logs succeeded. Failed to activate master IP address for 192.168.1.103 with return code 10:0 192.168.1.114: This host has the latest relay log events. Generating relay diff files from the latest slave succeeded. 192.168.1.114: OK: Applying all logs succeeded. Slave started, replicating from 192.168.1.103. 192.168.1.103: Resetting slave info succeeded. Master failover to 192.168.1.103(192.168.1.103:3306) completed successfully. node3> show slave hosts; +-----------+------+------+-----------+ | Server_id | Host | Port | Master_id | +-----------+------+------+-----------+ | 114 | | 3306 | 103 | +-----------+------+------+-----------+ node4> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.1.103 成功将主服务器切换到 192.168.1.103 ，同时将从服务器的主切换到 192.168.1.103 。

转载于:https://my.oschina.net/766/blog/211292