AI 助理
备案控制台
开发者社区 数据库 文章 正文

MHA高可用主从复制实现

2017-06-11 1194
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云数据库 RDS MySQL，集群系列 2核4GB
推荐场景：
搭建个人博客
RDS MySQL Serverless 基础系列，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
RDS MySQL Serverless 高可用系列，价值2615元额度，1个月
简介： 一 MHA1.1 关于MHAMHA（master HA）是一款开源的MySQL的高可用程序，它为MySQL的主从复制架构提供了automating master failover功能。MHA在监控到的master节点故障时，会提升其中拥有最新数据的slave节点成为新的master节点，在此期间，MHA会通过熊其它节点获取额外信息来源避免一致性方面的问题。

一 MHA

1.1 关于MHA

MHA（master HA）是一款开源的MySQL的高可用程序，它为MySQL的主从复制架构提供了automating master failover功能。MHA在监控到的master节点故障时，会提升其中拥有最新数据的slave节点成为新的master节点，在此期间，MHA会通过熊其它节点获取额外信息来源避免一致性方面的问题。MHA还提供了master节点的在线切换功能，即按需切换master/slave节点。

MHA服务有两种角色，MHA Manager（管理节点）和MHA Node（数据节点）：
 MHA Manager：通常单独部署在一台独立机器上管理多个master/slave集群，每个master/slave集群称作一个application；
 MHA node：运行在每台MySQL服务器上（master/slave/manager），它通过监控具备解析和清理logs功能的脚本来加快故障转义。

Manager package:Can manager multiple {master,slaves} pairs
 masterha_manager:Automated master monitoring and failover command
 Other helper scripts:Manual master failover,online master switch,con checking,etc
Node package :Deplpying on all MySQLservers
 save_binary_logs:Copying master's binary logs if accessible
 apply_diff relay_logs:Generating differential relay logs from the latest slave,and applying all differential binlog events
 purge_relay_logs:Deleting relay logs withotu stopong SQL thread

拓扑图

 

1.2 Architecture of MHA

MySQL复制集群中的master故障时，MHA按如下步骤进行故障转移：

1.3 MHA组件

MHA会提供诸多工具程序。其常见如下所示：

Manager角色拥有的工具
 masterha_check_ssh:MHA 依赖的 SSH 环境检测工具
 masterha_check_repl:MySQL 复制环境检测工具
 masterha_manager:MHA 服务主程序
 masterha_check_status:MHA 运行状态探测工具
 masterha_master_monitor:MySQL master 节点可用性监测工具; – masterha_master_switch:master 节点切换工具
 masterha_conf_host:添加或删除配置的节点
 masterha_stop:关闭 MHA 服务的工具
Node节点的拥有的工具
 save_binary_logs:保存和复制 master 的二进制日志
 apply_diff_relay_logs:识别差异的中继日志事件并应用于其它 slave
 filter_mysqlbinlog:去除不必要的 ROLLBACK 事件(MHA 已不再使用这个工具): – purge_relay_logs:清除中继日志(不会阻塞 SQL 线程)
自定义扩展工具
 secondary_check_script:通过多条网络路由检测 master 的可用性
 master_ip_failover_script:更新 application 使用的 masterip; – shutdown_script:强制关闭 master 节点
 report_script:发送报告
 init_conf_load_script:加载初始配置参数
 master_ip_online_change_script:更新 master 节点 ip 地址


二 准备MySQL Replication环境

2.1 配置主从复制文件

MAH对MySQL复制环境有特殊要求，例如各节点都要开启二进制日志和中继日志，各从节点必须显式启用其read-only属性，并关闭relay-log-purge功能等，这里先对其配置做实现说明。

本实验环境共有四个节点，其角色分配如下：
node1:MariaDB master
node2:MariaDB slave
node3:MariaDB slave
node4:MHA Manager

#各节点的etc/hosts文件配置内容如下：
172.18.67.11 node1 node1
172.18.67.12 node2 node2
172.18.67.13 node3 node3
172.18.67.14 node4 node4

 

#初始节点master的配置：
server_id=1
relay_log=relay-log
log_bin=master-log

#所有slave节点的配置如下：
server_id=2,3      #两个slave节点id号不同
relay_log=relay-log
log_bin=master-log
relay_log_purge=0
read_only=1

 

2.2 配置主从架构

#启动MariaDB服务
[root@node1 ~]# systemctl start mariadb
[root@node2 ~]# systemctl start mariadb
[root@node3 ~]# systemctl start mariadb

#登入主节点
[root@node1 ~]# mysql
MariaDB [(none)]> SHOW MASTER STATUS;
+-------------------+----------+--------------+------------------+
| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+----------+--------------+------------------+
| master-log.000003 |      245 |              |                  |
+-------------------+----------+--------------+------------------+

#为一个用户授权
MariaDB [(none)]> GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO 'repluser'@'172.18.67.%' IDENTIFIED BY 'replpass';
MariaDB [(none)]> FLUSH PRIVILEGES;

#从节点node2配置
MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='172.18.67.11',MASTER_USER='repluser',MASTER_PASSWORD='replpass',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 event
                  Master_Host: 172.18.67.11
                  Master_User: repluser
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: master-log.000003
          Read_Master_Log_Pos: 497
               Relay_Log_File: relay-log.000002
                Relay_Log_Pos: 782
        Relay_Master_Log_File: master-log.000003
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 497
              Relay_Log_Space: 1070
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_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: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1

#从节点node3配置
MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='172.18.67.11',MASTER_USER='repluser',MASTER_PASSWORD='replpass',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 event
                  Master_Host: 172.18.67.11
                  Master_User: repluser
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: master-log.000003
          Read_Master_Log_Pos: 497
               Relay_Log_File: relay-log.000002
                Relay_Log_Pos: 782
        Relay_Master_Log_File: master-log.000003
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 497
              Relay_Log_Space: 1070
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_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: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1
MariaDB [(none)]> SELECT User,Host FROM mysql.user;
+----------+-------------+
| User     | Host        |
+----------+-------------+
| root     | 127.0.0.1   |
| repluser | 172.18.67.% |
| root     | ::1         |
|          | localhost   |
| root     | localhost   |
|          | node3       |
| root     | node3       |
+----------+-------------+

#在主节点授权一个HA管理的账号
MariaDB [(none)]> GRANT ALL ON *.* TO 'haadmin'@'172.18.67.%' IDENTIFIED BY 'hapass';
MariaDB [(none)]> FLUSH PRIVILEGES;


三 安装MHA及配置

3.1 准备基于ssh互信通信环境

MHA集群中的各节点彼此之间均需要基于ssh互信互通，以实现远程控制及数据管理功能。简单起见，可在Manager节点生成密钥对儿，并设置其可远程连接本地主机后，将私钥文件及authorized_keys文件复制给余下的所有节点即可。

#下面的操作在manager节点操作即可
[root@node4 ~]# ssh-keygen -t rsa
[root@node4 ~]# cat .ssh/id_rsa.pub > .ssh/authorized_keys
[root@node4 ~]# chmod 600 .ssh/authorized_keys

[root@node4 ~]# scp -p .{id_rsa,authorized_keys} root@node1:/root/.ssh/
[root@node4 ~]# scp -p .{id_rsa,authorized_keys} root@node2:/root/.ssh/
[root@node4 ~]# scp -p .{id_rsa,authorized_keys} root@node3:/root/.ssh

 

3.2 安装MHA

下载：
mha4mysql-manager-0.56-0.el6.noarch.rpm
mha4mysql-node-0.56-0.el6.noarch.rpm

#在MHA节点安装两个包
[root@node4 ~]# yum install ./mha4mysql-*

#将mha4mysql-node-0.56-0.el6.noarch.rpm复制到其它三个节点
[root@node4 ~]# for i in {1..3};do scp mha4mysql-node-0.56-0.el6.noarch.rpm node${i}:/root/; done

#安装mha4mysql-node-0.56-0.el6.noarch.rpm
[root@node4 ~]# for i in {1..3};do ssh node$i 'yum install -y /root/mha4mysql-node-0.56-0.el6.noarch.rpm'; done


3.3 初始化MHA

Manager节点需要为每个监控的master/slave集群提供一个专用的配置文件，而所有的master/slave集群也可共享全局配置。全局配置文件默认为/etc/masterha_default.cnf，其为可选配置。如果监控一组master/slave集群，也可直接通过application的配置来提供各服务器的默认配置信息。而每个application的配置文件路径为自定义，例如本示例中将使用/etc/masterha/app1.cnf，其内容如下所示：

[root@node4 ~]# vim /etc/mha4mysql/mha4.cnf
[server default]
user=mhaadmin 
password=mhapass
manager_workdir=/data/masterha/app1
manager_log=/data/masterha/app1/manager.log 
remote_workdir=/data/masterha/app1
ssh_user=root
repl_user=repluser
repl_password=replpass
ping_interval=1
master_ip_failover_script=/tmp/master_ip_failover
 
[server1] 
hostname=172.18.67.11
ssh_port=22
candidate_master=1
 
[server2] 
hostname=172.18.67.12 
ssh_port=22 
candidate_master=1
 
[server3] 
hostname=172.18.67.13 
ssh_port=22
candidate_master=1

#检测各节点间ssh互信互通配置对否成功
[root@node4 ~]# masterha_check_ssh --conf=/etc/masterha/app1.cnf
[root@node4 ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf

#最后一行输出如下类似信心表示成功
MySQL Replication Health is OK.

#启动MHA
[root@node4 ~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf  > /data/masterha/
app1/manager.log 2>&1 &

#查看MHA状态
[root@node4 ~]# masterha_check_status  --conf=/etc/mha/app1.cnf


3.4 测试故障转移 

#停止master节点的mariadb服务。此操作在master节点执行
[root@node1 ~]# systemctl stop mariadb
 
#查看MHA状态。此操作在manager节点执行
[root@node4 ~]# masterha_check_status  --conf=/etc/mha/app1.cnf
app1 is stopped(2:NOT_RUNNING)
 
#验证master节点是否切换。此操作在slave节点上执行。
#可以看到slave2节点的Master_Host已经从172.18.67.11切换到172.18.67.12
[root@node2 ~]# mysql -e 'SHOW SLAVE STATUS\G' | grep "Master_Host"
                  Master_Host: 172.18.67.12

 

文章标签：
云数据库 RDS MySQL 版
日志服务
关系型数据库
MySQL
网络安全
监控
相关实践学习
如何在云端创建MySQL数据库
开始实验后，系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心，利用清洁计算为万物互联的新世界提供源源不断的能源动力，目前开服的区域包括中国（华北、华东、华南、香港）、新加坡、美国（美东、美西）、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程，来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品：云服务器ECS 云服务器 ECS（Elastic Compute Service）是一种弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率，使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
iuskye
目录
相关文章
憧憬blog
|
6月前
|
SQL 存储 运维
MySQL高可用性：主从复制和集群
MySQL高可用性：主从复制和集群
憧憬blog
111 0
玉米侠爱吃玉米
|
6月前
|
关系型数据库 MySQL 网络安全
MHA 高可用配置 及故障切换
MHA 高可用配置 及故障切换
玉米侠爱吃玉米
120 0
m0_58076958
|
安全 关系型数据库 MySQL
MHA高可用配置及故障切换
MHA高可用配置及故障切换
m0_58076958
147 0
Cisyam
|
SQL 缓存 NoSQL
第18章_主从复制（上）
第18章_主从复制
Cisyam
196 0
Cisyam
|
SQL cobar 算法
第18章_主从复制（下）
第18章_主从复制
Cisyam
154 0
aly109u0
|
负载均衡 数据库
主从复制
主从复制
aly109u0
110 0
我是廖志伟
|
SQL 存储 网络协议
【主从复制】
【主从复制】
我是廖志伟
147 0
【主从复制】
rqbarzitsudte
|
存储 SQL 运维
使用 MHA 实现 MySQL 主从复制高可用
MHA（Master High Availability）是由日本一家公司开发的一套 MySQL 高可用性环境下故障切换和主从提升的高可用软件，目前在 MySQL 高可用方面是一个相对成熟的的解决方案。在 MySQL 故障切换过程中，MHA 能做到在 0~30 秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA 能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
rqbarzitsudte
238 0
使用 MHA 实现 MySQL 主从复制高可用
隐姓埋名4869
|
监控 安全 关系型数据库
MySQL MHA 高可用集群部署及故障切换
1、概念 2、搭建MySQL + MHA
隐姓埋名4869
1391 0
MySQL MHA 高可用集群部署及故障切换
javaedge
主主、主从和主备区别
主主、主从和主备区别
javaedge
392 0
主主、主从和主备区别