MYSQL高级运用-MHA(提供主从复制高可用,主节点故障时，进行故障转移）

shenjialong • • Linux干货

MHA的介绍、重用工具；
MHA的安装；
搭建MYSQL主从复制架构，运用MHA实现其高可用，主节点故障时，进行故障转移；并恢复整个架构；

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功能的脚本来加快故障转移。

MHA组件：

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

              Manager节点：

                  masterha_check_ssh :MHA依赖的ssh环境监测工具
                  masterha_check_repl: MYSQL复制环境检测工具；
                  masterga_manager: MHA 服务主程序
                  masterha_check_status: MHA 运行状态探测工具；
                  masterha_master_monitor:MYSQL master节点可用性监测工具；
                  masterha_master_swith: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；
                 report_script:发送报告
                 init_conf_load_script:加载初始配置参数；
                 master_ip_online_change_script:更新master节点ip地址；

实验：实现主从复制的高可用，主节点故障时，进行故障转移；以及回复整个复制集群。

 1、准备实验MYSQL Replication环境：

MHA对MYSQL复制环境有特殊要求，例如各节点都要开启二进制日志及中继日志，各从节点必须显示启用其read-only属性，并关闭relay_log_purge功能等，这里对配置做事先说明。
                    本实验环境共有四个节点，其角色分配如下：
                             node1:MariaDB master
                             node2: MariaDB slave
                             node3: MariaDB slave
                             node4: MHA Manager
                 
                   各节点的/etc/hosts文件配置内容中添加：
                           172.16.252.18 node1.magedu.com node1
                           172.16.252.17 node2.magedu.com node2
                           172.16.252.20 node3.magedu.com node3
                           172.16.252.21 node4.magedu.com node4
                 
                    初始主节点master配置：
                                 [mysqld]
                                 server-id = 1
                                 log-bin = master-log
                                 relay-log = relay-log
                                 skip_name_resolve = ON
                                 innodb_file_per_table = ON
                    所有slave节点依赖的配置：
                                [mysqld]
                                server-id = 2     #复制集群中的各节点的id均必须唯一；
                                relay-log = relay-log
                                log-bin = master-log
                                read_only = ON
                                relay_log_purge = 0
                                skip_name_resolve = ON
                                innodb_file_per_table = ON
按上述要求分别配置好主从节点之后，按MYSQL复制配置架构的配置方式将其配置完成并启动master节点和各slave节点，以及为各slave节点启动其IO和SQL线程，确保主从复制运行无误。操作如下：
master节点上：
MariaDB [(none)]>GRANT REPLICATION SLAVE,REPLICATION CLIENT ON
*.* TO ‘repluser’@172.16.252.%’ IDENTIFIED BY ‘replpass’;
MariaDB [(none)]> FLUSH PRIVILEGES;
MariaDB [(none)]> SHOW MASTER STATUS;
+——————-+———-+————–+——————+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————-+———-+————–+——————+
| master-log.000003 | 498 | | |
+——————-+———-+————–+——————+
各slave节点上：
[root@node3 ~]# mysql
MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST=’172.16.252.18′,MASTER_USER=’repluser’,MASTER_PASSWORD=’replpass’,MASTER_LOG_FILE=’master-log.000003′,MASTER_LOG_POS=498;
MariaDB [(none)]> START SLAVE;
MariaDB [(none)]> SHOW SLAVE STATUS\G
而后，在所有MYSQL节点授权拥有管理权限的用户可在本地网络中有其他节点上远程访问。当然，此时仅需要且只能在master节点运行类似如下SQL语句即可。
mysql> GRANT ALL ON *.*  TO    ‘mhaadmin’@’172.16.252.%’   IDENTIFIED    BY ‘mhapass’;
各slave节点可以查看：
                 SHOW GRANTS FOR ‘proxysql’@’172.16.252.%’;1

2、安装配置MHA

       a、准备基于SSH互信通信环境：
MHA集群中的各节点彼此之间均需要基于ssh互信通信，以实现远程控制及数据管理功能。简单起见，可在Manager节点生成密钥对儿，并设置其可远程连接本地主机后，将私钥文件及authorized_keys文件复制给余下的所有节点即可。
          下面操作在node4：Manager 节点上操作：
                      [root@node4 ~]# ssh-keygen -t rsa -P ”
                      [root@node4 ~]#ssh-copy-id -i .ssh/id_rsa.pub root@node4
                       自己连接自己进行验证
2
[root@node4 ~]# for i in {1..3}; do scp -p .ssh/id_rsa .ssh/authorized_keys root@node$i:/root/.ssh/; done
编写一个小循环把.ssh/id_rsa (私钥）、shh/authorized_keys（记录进行公钥认证的信息）复制到三个节点上。复制完成后，各节点可以互信通信连接测试，进行验证。
               
              验证发现各节点之间进行ssh连接时，老是要回答yes:
                   可以修改/etc/ssh/ssh_config 配置文件：
                                            StrictHostKeyChecking no
                  或者可以用ssh -o 选项进行参数的传递：
                                 ssh -o StrictHostKetchecking=no node1
          b、安装MHA
                 除了源码包，MHA官方也提供了rpm格式的程序包，其下载地址为：
           Centos7系统可直接使用适用于el6的程序包。另外，MHA Manage和MHA Node 程序包的版本并不强制要求一致。
              这里我直接在FTP共享里面下载的rpm包：
                  lftp 172.16.0.1/pub
                      >cd Sources/6.x86_64/mha
                     >mget mha4mysql-node-0.56-0.el6.norch.rpm     mha4mysql-manager-0.560.el6.noarch.rpm
             Manager 节点：
                       #yum install mha4mysql-manager-0.56-0.el6.noarch.rpm
              所有节点，包括Manager:
                       #yum install mha4mysql-node-0.56-0.el6.norch.rpm

          c、初始化MHA，进行配置

Manager 节点需要为每个监控的master/slave集群提供一个专用的配置文件，而所有的master/slave集群也可共享全局配置。全局配置文件默认为/etc/masterha_default.cnf，其为可选配置。如果仅监控一组master/slave集群，也可直接通过application的配置来提供各服务器的默认配置信息。而每个application的配置文件路径为自定义。
               例如，本示例中将使用/etc/masterha/app1.cnf,其操作如下：
                             [root@node4 ~]# mkdir /etc/masterha
                             [root@node4 ~]# vim /etc/masterha/app1.cnf
                                       [server default]
                                      user=mhaadmin
                                      password=mhaadminpass
                                      manager_workdir=/data/masterha/app1
                                      manager_log=/data/masterha/app1/manager.log
                                      remote_wordir=/data/masterha/app1
                                      ssh_user=root
                                      repl_user=repluser
                                      repl_password=replpass
                                      ping_interval=1
                                     [server1]
                                     hostname=172.16.252.18
                                     candidate_master=1
                                    [server2]
                                    hostname=172.16.252.17
                                    candidate_master=1
                                    [server3]
                                     hostname=172.16.252.20
                                     candidate_master=1
                  检测各节点间ssh互信通信配置是否Ok:
                        [root@node4 ~]# master_check_ssh –conf=/etc/masterha/app1.cnf
                              输出信息最后一行类似如下信息，表示其通过检测。
                            [info]All SSH connection tests passed successfully.
                 检查管理的MySQL复制集群的连接配置参数是否OK：
                           [root@node4 ~]#master_check_repl –conf=/etc/masterha/app1.cnf
                     测试时会报错：从节点上没有账号，因为这个架构，任何一个从节点，将有可能成为主节点，                      所以也需要创建账号。
                 因此，这里只要在mater节点上再次执行以下操作即可：
                 MariaDB [(none)]>GRANT REPLICATION SLAVE,REPLICATION CLIENT ON    *.* TO                                    ‘repluser’@172.16.252.%’ IDENTIFIED BY ‘replpass’;
                 MariaDB [(none)]> FLUSH PRIVILEGES;
                 Manager节点上再次运行，就显示Ok了。

     d、启动MHA

 [root@node4 ~]#nohup masterha_manager –conf=/etc/master/aap1.cnf   &> /data/masterha/manager.log  &
               启动成功后，可用过如下命令来查看master节点的状态:
                     [root@node4 ~]#masterha_check_status –conf=/etc/master/aap1.cnf
                      app1 (pid:4978)is running(0:PING_OK),master:172.16.252.18
                   上面的信息中“app1 (pid:4978)is running(0:PING_OK)”表示MHA服务运行OK，否则，则会显                      示为类似“app1 is stopped(1:NOT_RUNNINg).”
              如果要停止MHA，需要使用master_stop命令。
              [root@node4 ~]#masterha_stop –conf=/etc/masterha/app1.cnf

       e 、测试故障转移

              (1)在master节点关闭mariadb服务,模拟主节点数据崩溃
                        #killall -9 mysqld mysqld_safe
                        #rm -rf /var/lib/mysql/*
             (2)在manager节点查看日志：
/data/masterha/app1/manager.log 日志文件中出现如下信息，表示manager检测到172.16.252.18节点故障，而后自动执行故障转移，将172.16.252.17提升为主节点。
注意，故障转移完成后，manager将会自动停止，此时使用masterha_check_status命令检测将会遇到错误提示，如下所示：
                           #masterha_check_status –conf=/etc/masterha/app1.cnf
                            app1 is stopped(2:NOT_RINNING).
            (3)提供新的从节点以修复复制集群
原有master节点故障后，需要重新准备好一个新的MySQL节点。基于来自于master节点的备份恢复数据后，将其配置为新的master的从节点即可。注意，新加入的节点如果为新增节点，其Ip地址要配置为原来master节点的IP，否则，还需要修改app1.cnf中相应的ip地址。随后再次启动manager，并再次检测其状态。
                 此时node2为主节点，进行一次完全数据备份：
                    #mysqldump -x -R –triggers –events –master-data=2 –flush-logs –all-databases >                                         /tmp/alldatabases.sql
                    #scp /tmp/databases.sql node1:/root/
               note1:
                      #sysytemctl start mariadb.service
                     #mysql < /root/databases.sql 进行数据重放，还原。
                     连入mysql发现数据已回复了。
                    #head -30 alldatabases.sql
CHANGE MASTER to MASTER_LOG_FILE=’master-log.000002′, MASTER_LOG_POS=245； 备份那一刻，日志文件，处于哪个位置.
                   #mysql
                   >CHANGE MASTER TO MASTER_HOST=’172.16.0.17′,MASTER_USER=’repluser’,MASTER_PASSWORD=’replpass’,MASTER_LOG_FILE=’master-log.000002′,MASTER_LOG_POS=245;
                   >START SLAVE;
                 # vim /etc/my.cnf.d/server.cnf
                               [mysql]
                              server-id = 1
                               log-bin = master-log
                               relay-log = relay-log
                               skip_name_resolve = ON
                               innodb_file_per_table = ON
                               read_only = ON
                         #systemctl restart mariadb.service
                         note4:Manager节点上在次启动，并检测MYSQL复制集群；

本文来自投稿，不代表Linux运维部落立场，如若转载，请注明出处：http://www.178linux.com/87554

赞 (1)
shenjialongshenjialong
0
上一篇 2017-09-24 19:20
下一篇 2017-09-24 23:34

相关推荐

  • Linux网络

    网络概念 OSI模型网络设备TCP/IPIP地址   什么是网络 资源共享的功能和优点数据和应用程序资源网络存储备份设备 常见的网络物理组件 网络应用程序Web 浏览器（Chrome、IE、Firefox等）即时消息（QQ、微信、钉钉等）电子邮件（Outlook、foxmail 等）协作（视频会议、VNC、Netmeeting、WebEx 等）we…

    Linux干货 2017-08-19

  • N25_第二周作业

    前言 我们这次使用HAProxy作为负载均衡调度器来实现后端httpd服务的负载均衡和动静分离，实现将来自用户的80端口的http请求转发只后端8080端口的server服务 HAProxy介绍 HAProxy的是一个免费的，非常快速和可靠的解决方案，提供高可用性，负载均衡和代理对TCP和HTTP的应用程序。它特别适用于非常高流量网站。多年来，它已成为标准的…

    Linux干货 2016-12-12

  • 你会用Python写洗脑神曲吗？

    Python实战班-学员学习成果展示 同样是周末，有些人是闲聊着度过，有些人是学习充电度过。 人与人最大的区别，是下班后的时间。看你怎么去利用。 周末时，马哥Python实战班的学员正在认真上课，他们中的不少人，月薪在10k以上，甚至月薪20k以上。 但他们没有虚度周末时光。 #最浪费时间的就是：思而不学+犹豫不决。# 马哥Python实战班二期的小伙伴们才…

    Linux干货 2016-07-05

  • Linux系统的软硬连接的区别

    Linux系统的软硬连接的区别 M21-陆东贵 CentOS 7.2 Linux链接分两种，一种被称为硬链接（Hard Link），另一种被称为符号链接（Symbolic Link）。默认情况下，ln命令产生硬链接。 一、  硬链接： 硬连接是指通过索引节点来进行连接Linux链接分两种，一种被称为硬链接（Hard Link），另一种被称为符号链接…

    Linux干货 2016-10-19

  • Linux基础-用户管理相关操作-week 4

    1.复制/etc/skel 目录为/home/tuser1,要求/home/tuser1及其内部文件的属组和其他用户均没有任何访问权限  cp /etc/skel /home/tuser1 -rf chmod og=  /home/tuser1 -R 2.编辑/etc/group文件添加组hadoop echo hadoop:x:503 …

    Linux干货 2016-11-21

  • nginx反向代理负载均衡集群配置详解

    反向代理负载均衡集群配置详解 反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时站在服务器角度来看，代理服务器对外就表现为一个反向代理服务器。 对反向代理服务器的攻击并不会使得后端内网Web服务器上网页信息遭到…

    Linux干货 2016-11-07
电话咨询
在线咨询