• Post author:
  • Post category:mysql
  • Post comments:0评论
Like
Like Love Haha Wow Sad Angry

一、简介

  MHA能够在较短的时间内实现自动故障检测和故障转移,通常在10-30秒以内。在主从框架中,MHA能够很好地解决主从复制过程中的数据一致性问题,由于不需要在现有的主从框架中添加额外的服务器,仅需要一个manager节点,而一个Manager能管理多套复制,所以能大大地节约服务器的数量。另外,安装简单,无性能损耗,以及不需要修改现有的复制部署也是它的优势之处。
  MHA可以监控主从复制环境中的主库,并在检测到主库故障时执行自动主库故障转移,当主库出现故障时,它可以自动将最新数据的从库提升为新的主库,然后将所有其它的从库重新指向新的主库。
  MHA还提供在线主库切换功能,能够将当前运行的主库安全的切换到一个新的主库(通过将从库提升为主库),能在0.5-2秒内完成,在切换过程中仅阻止写入。
  官方文档:https://github.com/yoshinorim/mha4mysql-manager/wiki/Overview
  下载地址:https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads

二、体系结构

  MHA由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点)。MHA Manager可以独立部署在一台独立的机器上管理多个Master-Slave集群,也可以部署在一台Slave上。
  Manager组件结构:

 •  masterha_manger                启动MHA 
 •  masterha_check_ssh             检查MHA的SSH配置状况 
 •  masterha_check_repl            检查MySQL复制状况 
 •  masterha_master_monitor        检测master是否宕机 
 •  masterha_check_status          检测当前MHA运行状态 
 •  masterha_master_switch         控制故障转移(自动或者手动)
 •  masterha_conf_host             添加或删除配置的server信息

  node 组件结构:

 •  save_binary_logs             保存和复制master的二进制日志 
 •  apply_diff_relay_logs        识别差异的中继日志事件并将其差异的事件应用于其它的从库
 •  purge_relay_logs             清除中继日志(不会阻塞SQL线程)

三、故障转移原理

  以一主多从为例,如果主库崩溃,MHA则会选择一个数据最新的从库,将其提升为新的主库,然后让其它从库从新的主库开始复制。实际上,这并本不是一件小事。即使可以识别出最新的从库,其他从库也有可能尚未收到所有二进制日志事件。要知道MySQL主从复制是异步的,某些(或没有一个)从库可以从崩溃的主库接收到所有二进制日志事件,也有可能只有一些从库收到了最新事件。
  如果就此重新依据新主库构建主从复制,则这些从库将会丢失事务,这将导致数据一致性问题。为了避免这些一致性问题,丢失的binlog事件(尚未到达所有从库)需要被识别,然后在依据新主库上启动复制之前,依次将其应用于每个从库,即从库互相识别差异互补。MHA会通过识别来自最新从库的差异中继日志事件,并将其应用于所有其它从库,包括那些尚未收到最新中继日志事件的从库,来保证所有从库的一致性。
  MHA的目标是在没有任何备用服务器的情况下,尽快使主库故障转移和恢复过程完全自动化。恢复包括确定新的主库、识别从库之间的差异中继日志事件、将差异的事件应用于新的主库、同步其它从库并使它们从新的主库开始复制。根据复制延迟,MHA通常可以在10到30秒的停机时间内完成故障转移。

具体流程如下:

1、监控
  通过masterha_master_monitor ,每隔 ping_interval 秒探测一次主库心跳。
  如果探测不到心跳,一共给4次机会,如果还探测不到就会认为主库宕机。

2、选主
(1)从判断各个从库的日志(position或者GTID)选,最接近主库的从库,成为备选主。
(2)在配置文件中,可以将特定从库指定为候选主库(通过设定权重 candidate_master=1 )如果有则优先按照权重指定为候选主库。注意仅仅只是候选主库而已。
    •  默认情况下如果一个从库落后主库 100M的relay logs的话,即使有权重,也没用。
    •  如果设定了"check_repl_delay=0"的话,即使落后很多日志,也会被选为候选主库。
(3)如果从库日志数据一致,则按照配置文件顺序选主。
(4)整体来说,选主策略优先级:最新日志+候选主库 > 最新日志 > 候选主库 > 配置文件顺序。

3、日志补偿
(1)如果主库SSH能连接,则从库会对比主库position或者GTID 号,save_binary_logs会立即将二进制日志保存至各个从节点并且应用。
(2)如果主库SSH不能连接,则通过apply_diff_relay_logs对比从库之间的relay log日志的差异。

4、故障转移
  取消所有节点的从库状态,构建新的主从关系。自动将故障节点,从配置文件剔除。

5、自动退出
  完成故障转移后,manager会自动退出,所以它是一次性的,只能完成一次切换。
  完成转移后,我们需要重新启动MHA和及时修复故障节点,因此,我们需要配置邮件通知。

四、MHA搭建

1、节点规划

节点名称 ip地址 角色
db01 10.0.0.51 主库
db02 10.0.0.52 从库
db03 10.0.0.53 从库

2、主从构建
主库db01操作:

(1)开启binlog日志
[root@db01 ~]# vim/etc/my.cnf       # 在mysqld下添加以下配置
server_id=1
log_bin=/service/data/binlog/mysql-bin

(2)主库创建专门用于复制的用户
mysql> grant replication slave on *.* to repl@'10.0.0.%' identified by '000000';

从库db02、db03操作:主从时间要同步

1、修改配置文件
[root@db02 ~]# vim/etc/my.cnf       # 在mysqld下添加以下配置
server_id=2 
log_bin=/service/data/binlog/mysql-bin

2、配置从库(因为没啥数据,也不关注太多,直接从头开始复制)
mysql> change master to
       master_host='10.0.0.51',
       master_user='repl',
       master_password='000000',
       master_port=3306,
       master_log_file='mysql-bin.000001',
       master_log_pos=1;

4、启动从库的复制功能
mysql> start slave;

5、检查从库复制功能状态
mysql> show slave status \G
......
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
......


3、安装软件
所有节点安装node

[root@db01 ~]# yum install perl-DBD-MySQL -y
[root@db01 ~]# rpm -vih mha4mysql-node-0.56-0.el6.noarch.rpm 

db03节点安装manger

[root@db03 ~]# yum install -y epel-release perl-Config-Tiny  perl-Time-HiRes
[root@db03 ~]# yum install -y perl-Log-Dispatch perl-Parallel-ForkManager
[root@db03 ~]# rpm -ivh mha4mysql-manager*.rpm


4、各节点准备工作

(1)各节点配置关键程序软链接(MHA会去使用以下链接的全路径去调用,代码写死的所以需要做软链接)
[root@db01 ~]# ln -s /service/app/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
[root@db01 ~]# ln -s /service/app/mysql/bin/mysql /usr/bin/mysql

(2)配置互信(免密ssh)
各节点:
[root@db01 ~]# sed -i '/StrictHostKeyChecking/c StrictHostKeyChecking no' /etc/ssh/ssh_config
db01节点:
[root@db01 ~]# rm -rf /root/.ssh 
[root@db01 ~]# ssh-keygen
[root@db01 ~]# cd /root/.ssh 
[root@db01 ~]# mv id_rsa.pub authorized_keys
[root@db01 ~]# scp -r /root/.ssh 10.0.0.52:/root 
[root@db01 ~]# scp -r /root/.ssh 10.0.0.53:/root 

(3)各节点验证
[root@db01 ~]# ssh 10.0.0.51 hostname
db01
[root@db01 ~]# ssh 10.0.0.52 hostname
db02
[root@db01 ~]# ssh 10.0.0.53 hostname
db03


5、在db01主库中创建mha管理用户

mysql> grant all privileges on *.* to mha@'10.0.0.%' identified by 'mha';

6、配置文件准备(db03)

(1)创建配置文件目录和日志目录
[root@db03 ~]# mkdir -p /etc/mha
[root@db03 ~]# mkdir -p /var/log/mha/app1

(2)编辑mha配置文件
[root@db03 ~]# vim /etc/mha/app1.cnf
[server default]
user=mha                                # MHA管理用户
password=mha                            # MHA管理用户密码
manager_workdir=/var/log/mha/app1       # 工作目录
manager_log=/var/log/mha/app1/app1.log  # 日志位置
master_binlog_dir=/service/data/binlog/ # 主库binlog目录
ping_interval=1                         # 探测主库存货的间隔时间
repl_user=repl                          # 主从复制管理用户
repl_password=000000                    # 主从复制管理用户密码
ssh_user=root                           # ssh连接用户

[server1]                                   
hostname=10.0.0.51
port=3306                                  

[server2]            
hostname=10.0.0.52
port=3306

[server3]
hostname=10.0.0.53
port=3306


7、状态检查

(1)互信检查
[root@db03 ~]# masterha_check_ssh --conf=/etc/mha/app1.cnf  

(2)主从状态检查
[root@db03 ~]# masterha_check_repl --conf=/etc/mha/app1.cnf 


8、开启MHA

[root@db03 ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

命令参数说明:
nohup                           后台启动
masterha_manager                MHA启动程序
--conf=/service/mha/app1.cnf    指定配置文件
--remove_dead_master_conf       移除崩溃的主库节点配置
--ignore_last_failover          忽略最后一次切换

安全机制说明:
    1.完成一次切换后,会生成一个锁文件。
    2.再次进行切换时,会检查锁文件。
    3.如果锁文件存在,则不能进行切换,8小时后才能进行再次切换。
    4.所以配置--ignore_last_failover进行跳过。


9、查看MHA状态

[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:11077) is running(0:PING_OK), master:10.0.0.51


10、建议添加配置
以上MHA环境已经构建完成,以下是建议配置的mysql配置:

(1)关闭自动删除relay log的功能
    relay_log_purge=0

(2)从库配置只读
    read_only=1

(3)从库开启保存binlog
    log_slave_updates

五、故障转移演示

1、关闭db01数据库模拟故障
[root@db01 ~]# systemctl stop mysqld

2、db03查看manager日志
[root@db03 ~]# vim /var/log/mha/app1/app1.log
......
Started automated(non-interactive) failover.
The latest slave 10.0.0.52(10.0.0.52:3306) has all relay logs for recovery.
Selected 10.0.0.52(10.0.0.52:3306) as a new master.
10.0.0.52(10.0.0.52:3306): OK: Applying all logs succeeded.
10.0.0.53(10.0.0.53:3306): This host has the latest relay log events.
Generating relay diff files from the latest slave succeeded.
10.0.0.53(10.0.0.53:3306): OK: Applying all logs succeeded. Slave started, replicating from 10.0.0.52(10.0.0.52:3306)
10.0.0.52(10.0.0.52:3306): Resetting slave info succeeded.
Master failover to 10.0.0.52(10.0.0.52:3306) completed successfully.

通过日志发现主库已经切换到了db02

3、db03查看从库状态
mysql> show slave status \G
......
                  Master_Host: 10.0.0.52
                  Master_User: repl
                  Master_Port: 3306
......

节点修复重新构建主从

[root@db01 ~]# systemctl start mysqld

mysql> change master to
       master_host='10.0.0.52',
       master_user='repl',
       master_password='000000',
       master_port=3306,
       master_log_file='mysql-bin.000001',
       master_log_pos=1;

mysql> start slave;
mysql> show slave status \G
......
                  Master_Host: 10.0.0.52
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
......

重新部署MHA

1、将db01节点重新加入MHA环境
[root@db01 ~]# vim /etc/mha/app1.cnf    # 添加
[server1]
hostname=10.0.0.51
port=3306

2、重新检查状态
[root@db03 ~]# masterha_check_ssh --conf=/etc/mha/app1.cnf  
[root@db03 ~]# masterha_check_repl --conf=/etc/mha/app1.cnf 

3、重新启动MHA
[root@db03 ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

4、检查
[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf 
app1 (pid:11089) is running(0:PING_OK), master:10.0.0.52

六、VIP

  前面我们进行主库故障转移演示,主库成功由10.0.0.51切换到了10.0.0.52。那么大家想到没,对于连接数据库的应用来而言该怎么办呢?因为主库ip地址的变化,为了能让应用正常服务,需要修改代码重新上线。那么这显然不是我们所期望,因此MHA也给我们提供了VIP地址漂移的功能。应用绑定VIP,VIP处于主库,当主库宕机了,主库切换到新库,VIP跟着漂移到新库,对于应用而言还是连接着主库。
  对于VIP,MHA是通过调用脚本实现的,官方给我们提供了脚本。下载地址:https://github.com/yoshinorim/mha4mysql-manager/archive/master.zip,脚本位于下载文件中的samples/scripts中,注意官方提供的脚本只是个模板,是不能直接用的,需要进行修改。
  以下提供修改后的几个脚本下载地址:https://www.cpweb.top/wp-content/uploads/2020/11/scripts.zip

1、下载脚本
[root@db03 ~]# https://www.cpweb.top/wp-content/uploads/2020/11/scripts.zip
[root@db03 ~]# unzip scripts.zip -d /usr/local/bin/
[root@db03 ~]# chmod +x /usr/local/bin/*

2、根据服务器自身情况修改脚本
[root@db03 bin]# cd /usr/local/bin/
[root@db03 bin]# vim master_ip_failover     # 修改以下配置

my $vip = '10.0.0.50/24';       # VIP地址
my $key = '1';                  # 网卡后面数字
my $if  = 'ens33';              # 指定VIP绑定网卡
my $ssh_start_vip = "/sbin/ifconfig $if:$key $vip";     # 生成VIP
my $ssh_stop_vip = "/sbin/ifconfig  $if:$key down";     # 关闭VIP
my $ssh_Bcast_arp= "/sbin/arping -I $if -c 3 -A 10.0.0.50";     # arp广播

3、修改manager配置文件
[root@db03 ~]# vim /etc/mha/app1.cnf    # 在[server default]下添加以下配置
master_ip_failover_script=/usr/local/bin/master_ip_failover

4、重启MHA
[root@db03 ~]# masterha_stop  --conf=/etc/mha/app1.cnf 
[root@db03 ~]# masterha_check_repl --conf=/etc/mha/app1.cnf 
[root@db03 ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

5、主库手工添加VIP 
[root@db02 ~]# ifconfig ens33:1 10.0.0.50/24

模拟故障,测试VIP地址漂移

1、主库模拟故障
[root@db02 ~]# systemctl stop mysqld

2、db03查看manager日志
Started automated(non-interactive) failover.
Invalidated master IP address on 10.0.0.52(10.0.0.52:3306)
The latest slave 10.0.0.51(10.0.0.51:3306) has all relay logs for recovery.
Selected 10.0.0.51(10.0.0.51:3306) as a new master.
10.0.0.51(10.0.0.51:3306): OK: Applying all logs succeeded.
10.0.0.51(10.0.0.51:3306): OK: Activated master IP address.
10.0.0.53(10.0.0.53:3306): This host has the latest relay log events.
Generating relay diff files from the latest slave succeeded.
10.0.0.53(10.0.0.53:3306): OK: Applying all logs succeeded. Slave started, replicating from 10.0.0.51(10.0.0.51:3306)
10.0.0.51(10.0.0.51:3306): Resetting slave info succeeded.
Master failover to 10.0.0.51(10.0.0.51:3306) completed successfully.

3、db01查看VIP
[root@db01 bin]# ip a show ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:67:84:79 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.51/24 brd 10.0.0.255 scope global noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet 10.0.0.50/24 brd 10.0.0.255 scope global secondary ens33:1
       valid_lft forever preferred_lft forever
    inet6 fe80::3b3e:c579:6d22:26ef/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

4、db03查看从库状态
mysql> show slave status \G
......
                  Master_Host: 10.0.0.51
......

七、邮件通知故障转移

  因为MHA在完成故障转移后,manager会自动退出,为了重新去启动MHA和及时修复故障节点,我们需要去配置邮件通知。同样MHA通过调用脚本实现,脚本在上面下载的scripts包中。

1、修改脚本
[root@db03 bin]# vim send_report        # 根据情况修改以下配置

my $smtp='smtp.qq.com';       # smtp服务器
my $mail_from='xx@qq.com';    # 发件箱
my $mail_user='xx';           # 用户名
my $mail_pass='xx';           # 授权码
my $mail_to=['xx@qq.com'];    # 收件箱

2、修改manager配置文件
[root@db03 ~]# vim /etc/mha/app1.cnf   # 在[server default]下添加以下配置
report_script=/usr/local/bin/send_report

3、重启MHA
[root@db03 ~]# masterha_stop  --conf=/etc/mha/app1.cnf 
[root@db03 ~]# masterha_check_repl --conf=/etc/mha/app1.cnf 
[root@db03 ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

模拟故障,收到邮件提醒:


八、binlog_server

  前面我们说到MySQL主从复制是异步的,当主库崩溃后,某些(或没有一个)从库可以从崩溃的主库接收到所有二进制日志事件,也有可能只有一些从库收到了最新事件。如果再这这种情况下,SSH不能连接到主库,那么从库只会通过apply_diff_relay_logs对比从库之间的relay log日志的差异进行互补。那么肯定会缺少部分数据,binlog_server 就是为了防止这样情况发生的,
  顾名思义binlog_server,即一台专门储存主库binlog日志文件的节点。当主库故障,从库SSH不能连接到主库时,从库会去这个节点去请求最新数据。为了方便下面我们将它部署在db03。

1、创建目录
[root@db03 ~]# mkdir -p /binlog_server
[root@db03 ~]# chown -R mysql.mysql /binlog_server
[root@db03 ~]# cd /binlog_server/

2、使用mysqlbinlog远程实时备份主库binlog
[root@db03 binlog_server]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:9097) is running(0:PING_OK), master:10.0.0.51

[root@db03 binlog_server]# mysqlbinlog -R --host=10.0.0.51 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &

3、修改manager配置文件
[root@db03 ~]# vim /etc/mha/app1.cnf    # 添加

[binlog1]
no_master=1
hostname=10.0.0.53
master_binlog_dir=/binlog_server/

4、重启MHA 
[root@db03 ~]# masterha_stop  --conf=/etc/mha/app1.cnf
[root@db03 ~]# masterha_check_repl --conf=/etc/mha/app1.cnf
[root@db03 ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

九、主库在线切换

  MHA给我们提供了在线切换主库的方法,通过masterha_master_switch 手动切换实现。主要有以下两种方式:

1、不调用脚本进行在线切换(不推荐)

[root@db03 ~]# masterha_stop --conf=/etc/mha/app1.cnf
[root@db03 ~]# masterha_check_repl --conf=/etc/mha/app1.cnf 
[root@db03 ~]# masterha_master_switch  --conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=10.0.0.52 --orig_master_is_new_slave --running_updates_limit=10000

 参数说明:
  --master_state=alive:  在主库存活情况下切换
  --new_master_host=xx:  指定新主库
  --orig_master_is_new_slave:  原来主库作为新主库
  --running_updates_limit=xx:  如果延迟超过xx毫秒,切换失败

注意:执行会收到以下问询和提示,意思是没有定义脚本,如果不手动在当前主库禁止写入,应用程序会继续写入数据。当然还有其它问询,自行填写。
master_ip_online_change_script is not defined. If you do not disable writes on the current master manually, applications keep writing on the current master. Is it ok to proceed? (yes/NO): yes

此种方法切换注意事项:
(1)原主库加FTWRL,否则会造成主从不一致。
(2)需要手工切换vip,脚本可以随着主库切换自动切换。
(3)发邮件功能无效


2、调用脚本进行在线切换(推荐)

(1)根据情况对脚本进行修改
[root@db03 ~]# vim /usr/local/bin/master_ip_online_change   

my $vip = "10.0.0.50/24";
my $key = "1";
my $ssh_start_vip = "/sbin/ifconfig ens33:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig ens33:$key $vip down";
my $ssh_Bcast_arp= "/sbin/arping -I ens33 -c 3 -A 10.0.0.50";

2、修改配置文件 
[root@db03 ~]# vim /etc/mha/app1.cnf    # 在[server default]下添加以下配置
master_ip_online_change_script=/usr/local/bin/master_ip_online_change

3、停止MHA
[root@db03 ~]# masterha_stop --conf=/etc/mha/app1.cnf 
[root@db03 ~]# masterha_check_repl --conf=/etc/mha/app1.cnf 

4、在线切换
[root@db03 ~]# masterha_master_switch  --conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=10.0.0.51 --orig_master_is_new_slave --running_updates_limit=10000

参考文章:
  https://www.jianshu.com/p/0f7b5a962ba7
  https://github.com/yoshinorim/mha4mysql-manager/wiki/Overview

Like
Like Love Haha Wow Sad Angry

发表评论