MHA + keepalived

浅浅的花香味﹌ 2022-04-13 09:10 192阅读 0赞

# 1.keepalived #

## 通过VRRP协议来保证高可用性 ##

*  VRRP是一种容错协议，它通过把几台路由设备联合组成一台虚拟的路由设备，并通过一定的机制来保证当主机的下一跳设备出现故障时，可以及时将业务切换到其它设备，从而保持通讯的连续性和可靠性。
 *  VRRP是一种容错协议，它通过把几台路由设备联合组成一台虚拟的路由设备，并通过一定的机制来保证当主机的下一跳设备出现故障时，可以及时将业务切换到其它设备，从而保持通讯的连续性和可靠性。
 *  VRRP将局域网内的一组路由器划分在一起，称为一个备份组。备份组由一个Master路由器和多个Backup路由器组成，功能上相当于一台虚拟路由器。局域网内的主机只需要知道这个虚拟路由器的IP地址，并不需知道具体某台设备的IP地址，将网络内主机的缺省网关设置为该虚拟路由器的IP地址，主机就可以利用该虚拟网关与外部网络进行通信。
 *  VRRP将该虚拟路由器动态关联到承担传输业务的物理路由器上，当该物理路由器出现故障时，再次选择新路由器来接替业务传输工作，整个过程对用户完全透明，实现了内部网络和外部网络不间断通信。
 *  VRRP可以将两台或者多台物理路由器设备虚拟成一个虚拟路由，这个虚拟路由器通过虚拟IP（一个或者多个)对外提供服务，而在虚拟路由器内部十多个物理路由器协同工作，同一时间只有一台物理路由器对外提供服务，这台物理路由设备被成为：主路由器（Master角色)，一般情况下Master是由选举算法产生，它拥有对外服务的虚拟IP，提供各种网络功能，如：ARP请求，ICMP 数据转发等，而且其它的物理路由器不拥有对外的虚拟IP，也不提供对外网络功能，仅仅接收MASTER的VRRP状态通告信息，这些路由器被统称为“BACKUP的角色”，当主路由器失败时，处于BACKUP角色的备份路由器将重新进行选举，产生一个新的主路由器进入MASTER角色，继续提供对外服务，整个切换对用户来说是完全透明的。
 *  每个虚拟路由器都有一个唯一的标识号，称为VRID，一个VRID与一组IP地址构成一个虚拟路由器，在VRRP协议中，所有的报文都是通过IP多播方式发送的，而在一个虚拟路由器中，只有处于Master角色的路由器会一直发送VRRP数据包，处于BACKUP角色的路由器只会接受Master角色发送过来的报文信息，用来监控Master运行状态，一一般不会发生BACKUP抢占的情况，除非它的优先级更高，而当MASTER不可用时，BACKUP也就无法收到Master发过来的信息，于是就认定Master出现故障，接着多台BAKCUP就会进行选举，优先级最高的BACKUP将称为新的MASTER，这种选举角色切换非常之快，因而保证了服务的持续可用性。

### Master路由的选举 ###

*  备份组中路由器的优先级：VRRP根据优先级来确定备份组中每台路由器的角色（Master路由器或Backup路由器）。优先级越高，则越有可能成为Master路由器。当两台优先级相同的路由器同时竞争Master时，比较接口IP地址大小。接口地址大者当选为Master。IP地址所有者自动具有最高优先级：255。因此，当备份组内存在IP地址拥有者时，只要其工作正常，则为Master路由器。
 *  备份组中路由器的工作方式：抢占方式与非抢占方式

### VRRP的工作过程为： ###

*  路由器使能VRRP功能后，会根据优先级确定自己在备份组中的角色。优先级高的路由器成为Master路由器，优先级低的成为Backup路由器。Master路由器定期发送VRRP通告报文，通知备份组内的其他路由器自己工作正常；Backup路由器则启动定时器等待通告报文的到来。
 *  在抢占方式下，当Backup路由器收到VRRP通告报文后，会将自己的优先级与通告报文中的优先级进行比较。如果大于通告报文中的优先级，则成为Master路由器；否则将保持Backup状态。  
    在非抢占方式下，只要Master路由器没有出现故障，备份组中的路由器始终保持Master或Backup状态，Backup路由器即使随后被配置了更高的优先级也不会成为Master路由器。
 *  如果Backup路由器的定时器超时后仍未收到Master路由器发送来的VRRP通告报文，则认为Master路由器已经无法正常工作，此时Backup路由器会认为自己是Master路由器，并对外发送VRRP通告报文。备份组内的路由器根据优先级选举出Master路由器，承担报文的转发功能。

## keepalived原理: ##

*  keepalived安装在两台物理服务器上 并互相监控对方是否正常运行
 *  当A工作正常的时候 会将VIP对应的MAC地址为节点A网卡的MAC地址
 *  当A发生故障的时候 节点B上的keepalived会检测到 并将VIP的MAC等于B的MAC地址
 *  Keepalived的部署比较容易,直接可以yum 安装,主要的就是他的参数文件,参数文件是如何控制主备的。

vrrp_script chk_port_3306 { 
    script"/opt/dtstack/dtagent/agent/mysqlha_check_alive.py 3306" 
    interval 11# check every 2 seconds 
    fall 3# require 2 failures for KO 
    rise 3# require 2 successes for OK 
    timeout 11 
    }

*  第一部分,检测系统上3306端口,监控的途径是通过/opt/dtstack/dtagent/agent/mysqlha\_check\_alive.py 3306这条命令来判断的,就是判断系统3306端口是否存在,如果你的MySQL是别的端口,那么就需要作下更改,脚本是一大神写的,就不贴出来了。

vrrp_instance mysql_3306 { 
    state MASTER 
    interface eth0 #检测eth0 
    garp_master_delay 5 
    virtual_router_id 231 #路由组 
    priority 251 #权重 
    advert_int 1

*  第二部分,这一部分主要决定的你这台机器上的3306端口是否是主库,而且这台机器的外网是不是eth0网卡上。virtual\_router\_id这个参数主库跟备库必须要一样,这样告知Keepalived他需要看到是那一个路由组的机器。priority权重约大,那么主库的方向就越往哪台机器上偏。

authentication { 
    auth_type PASS 
    auth_pass PASS3306 
    } 
    virtual_ipaddress { 
    192.168.40.231/24 dev eth0 # vip是192.168.40.231/24 起在eth0上 
    } 
    track_script { 
    chk_port_3306 # 检测3306端口 
    }

*  第三部分,这一部分就是实现2变1的地方,起一个vip到eth0网卡上,当某台数据库为主库的时候,那么这个vip就会票到这个台机器的eth0网卡上。

## Keepalived体系结构 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NTUzMjk0_size_16_color_FFFFFF_t_70]

## 脑裂问题出现原因 ##

*  两个服务器端的keepalived之间的心跳获得另一个服务器的信息。当slave无法获取master的信息时，slave会对外提供服务，此时就会出现脑裂的问题（两个服务器使用同一ip对外提供服务）。

## 脑裂问题处理 ##

1.  设置仲裁机制。例如设置参考IP（如网关IP），当心跳线完全断开时，2个节点都各自ping一下参考IP，不通则表明断点就出在本端。不仅“心跳”、还兼对外“服务”的本端网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通参考IP的一端去起服务。更保险一些，ping不通参考IP的一方干脆就自我重启，以彻底释放有可能还占用着的那些共享资源。
2.  可以通过在slave库增加检测脚本，若检测到VIP漂移到了当前服务器上，则kill掉原master库的mysql进程。

## keepalived安装与配置 ##

<table> 
 <thead> 
  <tr> 
   <th>IP</th> 
   <th>主机名</th> 
   <th>角色</th> 
   <th>mha角色</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>192.168.2.61</td> 
   <td>node1</td> 
   <td>主库</td> 
   <td>node</td> 
  </tr> 
  <tr> 
   <td>192.168.2.62</td> 
   <td>node2</td> 
   <td>从库1</td> 
   <td>node</td> 
  </tr> 
  <tr> 
   <td>192.168.2.63</td> 
   <td>node3</td> 
   <td>从库2</td> 
   <td>node , mha-master</td> 
  </tr> 
 </tbody> 
</table>

### 1.安装keepalived ###

yum -y install keepalived

### 2.配置keepalived ###

#### node1修改keepalived配置文件 ####

[root@node1 ~]# cat /etc/keepalived/keepalived.conf
    global_defs {
         notification_email {
         saltstack@163.com
       }
       notification_email_from dba@dbserver.com
       smtp_server 127.0.0.1
       smtp_connect_timeout 30
       router_id MySQL-HA
    }
    
    vrrp_instance VI_1 {
        state BACKUP
        interface eth0
        virtual_router_id 51
        priority 150
        advert_int 1
        nopreempt
    
        authentication {
        auth_type PASS
        auth_pass 1111
        }
    
        virtual_ipaddress {
            192.168.6.66/24
        }
    }

#### node2修改keepalived配置文件 ####

[root@node2 ~]#  cat /etc/keepalived/keepalived.conf
    global_defs {
         notification_email {
         saltstack@163.com
       }
       notification_email_from dba@dbserver.com
       smtp_server 127.0.0.1
       smtp_connect_timeout 30
       router_id MySQL-HA
    }
    
    vrrp_instance VI_1 {
        state BACKUP
        interface eth0
        virtual_router_id 51
        priority 150
        advert_int 1
        nopreempt
    
        authentication {
        auth_type PASS
        auth_pass 1111
        }
    
        virtual_ipaddress {
            192.168.6.66/24
        }
    }

# 2.MHA #

## 原理 ##

*  1.一主两从架构，主库挂了，但主库能被从库ssh上去的情况下，MHA从三个从库中选择同步最接近的作为新主，然后新主和s2都ssh到原主上通过binlog补上还没有同步的数据，io\_thread读取到binlog位置，传到save\_binary\_logs，然后回放，达到s1,s2和原主一致。
 *  2.主库无法ssh上去的情况下，即主库的系统无法连接，假设有binlog server ，利用binlog补数据，和前面情况一样；如果没有binlog server，假设s1靠前，s2会通过relay-log和s1同步（所以从库的relay不能自动清除参数relay\_log\_purge = 0） ，提升s1为主，把s2作为s1的从；
 *  5.6之后，如果有一主两从的架构，使用GTID复制，keepalived+一主两从，并且其中一个从库使用半同步复制，这样完全可以取代MHA，这就是为什么MHA代码为什么不更新，out的原因。

## MHA切换步骤 ##

1.  从宕机的master中保存二进制文件
2.  检测含有最新日至更新的slave
3.  应用差异的中继日至（relay log）到其他的slave
4.  应用从master中保存的二进制日至事件到其他的slave中
5.  提升一个slave为master
6.  使其他的slave指向最新的master进行复制。

### manager的工具 ###

*  masterha\_check\_ssh 检查MHA的SSH配置状况
 *  masterha\_check\_repl 检查MySQL复制状况
 *  masterha\_manger 启动MHA
 *  masterha\_check\_status 检测当前MHA运行状态
 *  masterha\_master\_monitor 检测master是否宕机
 *  masterha\_master\_switch 控制故障转移（自动或者手动）
 *  masterha\_conf\_host 添加或删除配置的server信息、

### node的工具 ###

*  save\_binary\_logs 保存和复制master的二进制日志
 *  apply\_diff\_relay\_logs 识别差异的中继日志事件并将其差异的事件应用于其他的slave
 *  filter\_mysqlbinlog 去除不必要的ROLLBACK事件（MHA已不再使用这个工具）
 *  purge\_relay\_logs 清除中继日志（不会阻塞SQL线程）

## MHA自动切换流程 ##

1.  检测master的状态，方法是一秒一次“ SELECT 1 As Value”，发现没有响应后会重复3次检查，如果还没有响应，shutdown并再重复一次SELECT 1 As Value确认master关闭
2.  确认SSH到master所在的机器是否可达
3.  给出消息：Connecting to a master server failed，并开始读取配置文件masterha\_default.conf和app1.conf，确认复制切换模式: \[info\] GTID failover mode = 1
4.  报告整个架构中的机器存活情况

Fri Jul  1 13:35:33 2016 - [info] Dead Servers:
    Fri Jul  1 13:35:33 2016 - [info]   192.168.118.63(192.168.118.63:3306)
    Fri Jul  1 13:35:33 2016 - [info] Alive Servers:
    Fri Jul  1 13:35:33 2016 - [info]   192.168.118.62(192.168.118.62:3306)
    Fri Jul  1 13:35:33 2016 - [info]   192.168.118.64(192.168.118.64:3306)

1.  检查存活的实例版本、GTID开启情况、是否开启read\_only以及复制过滤情况

Fri Jul  1 13:35:33 2016 - [info] Alive Slaves:
    Fri Jul  1 13:35:33 2016 - [info]   192.168.118.62(192.168.118.62:3306)  Version=5.6.28-log (oldest major version between slaves) log-bin:enabled
    Fri Jul  1 13:35:33 2016 - [info]     GTID ON
    Fri Jul  1 13:35:33 2016 - [info]     Replicating from 192.168.118.63(192.168.118.63:3306)
    Fri Jul  1 13:35:33 2016 - [info]     Primary candidate for the new Master (candidate_master is set)
    Fri Jul  1 13:35:33 2016 - [info]   192.168.118.64(192.168.118.64:3306)  Version=5.6.28-log (oldest major version between slaves) log-bin:enabled
    Fri Jul  1 13:35:33 2016 - [info]     GTID ON
    Fri Jul  1 13:35:33 2016 - [info]     Replicating from 192.168.118.63(192.168.118.63:3306)
    Fri Jul  1 13:35:33 2016 - [info]     Primary candidate for the new Master (candidate_master is set)
    Fri Jul  1 13:35:33 2016 - [info] Checking slave configurations..
    Fri Jul  1 13:35:33 2016 - [info]  read_only=1 is not set on slave 192.168.118.62(192.168.118.62:3306).
    Fri Jul  1 13:35:33 2016 - [info]  read_only=1 is not set on slave 192.168.118.64(192.168.118.64:3306).
    Fri Jul  1 13:35:33 2016 - [info] Checking replication filtering settings..
    Fri Jul  1 13:35:33 2016 - [info]  Replication filtering check ok.

1.  在GTID复制基础上的切换过程

*  (1) 配置检查阶段，具体检查如下

[info] ** Phase 1: Configuration Check Phase completed.

检查项目如下:

Query     SELECT @@global.server_id As Value     
    Query     SELECT VERSION() AS Value                              #如果是GTID模式，版本不得小于5.6，如果是普通模式，版本不得小于5.0.45
    Query     SELECT @@global.gtid_mode As Value                     #MHA0.56版本开始支持GTID，之前的版本不支持
     Query     SHOW GLOBAL VARIABLES LIKE 'log_bin'                   #binlog必须开启
    Query     SHOW MASTER STATUS                    
    Query     SELECT @@global.datadir AS Value
    Query     SELECT @@global.slave_parallel_workers AS Value        #确定slave是不是多线程并行复制，这个参数的影响还没整明白，再研究下
    Query     SHOW SLAVE STATUS                     
    Query     SELECT @@global.read_only As Value                     #确定read_only的设置，如果要转为新的master，这个值要设为0
    Query     SELECT @@global.relay_log_purge As Value               #确定relay_log是否可自动删除，默认是可以
    Query     SELECT @@global.relay_log_info_repository AS Value     #确定relay_log是以file还是table格式存放的，默认是file
    Query     SELECT @@global.datadir AS Value                       #确定数据存放位置
    Query      SELECT @@global.relay_log_info_file AS Value                                                   #确定relay_log的文件名，为后面slave之间的relay_log应用做准备

备注：1. 默认情况下，从服务器上的中继日志在SQL线程执行完后会被自动删除的。但是这些中继日志在恢复其他从服务器时候可能会被用到，因此需要禁用中继日志的自动清除和定期清除旧的中继日志  
2. binlog-do-db和replicate-ignore-db设置必须相同。MHA在启动时候会检测过滤规则，如果过滤规则不同，MHA不启动监控和故障转移

*  (2)彻底关闭master连接的阶段，避免master未关闭导致的脑裂

[info] * Phase 2: Dead Master Shutdown Phase..

具体关闭命令是：

/etc/masterha/master_ip_failover --orig_master_host=192.168.118.3 --orig_master_ip=192.168.118.3 --orig_master_port=3306 --command=stopssh --ssh_user=root

关闭完成后给出报告

[info] * Phase 2: Dead Master Shutdown Phase completed.

*  (3)master恢复阶段：

[info] * Phase 3: Master Recovery Phase..

*  确认新的master后，会选取含有最新relay log 的slave，在该slave上设置sql\_log\_bin=0并在其余slaves上应用该最新relay log，最终获得这个层次的数据一致性，之后再set sql\_log\_bin=1使恢复日志写入。可以通过半同步复制来解决无法ssh到master所在机器所造成的事务丢失问题,待全部数据一致后，通过show master status确定新master的日志位置并在其他slave上执行change master语句创建新的主从连接：

Fri Jul 1 13:35:33 2016 - [info] Getting new master's binlog name and position..
    Fri Jul 1 13:35:33 2016 - [info] mysql-bin.000004:191
    Fri Jul 1 13:35:33 2016 - [info] All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='192.168.118.2', MASTER_PORT=3306, MAST
    ER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='xxx';

*  执行该切换的具体语句是

/etc/masterha/master_ip_failover --command=start --ssh_user=root --orig_master_host=192.168.118.3 --orig_master_ip=192.168.118.3 --orig_master_port=3306 --new_master_host=192.168.118.2 --new_master_ip=192.168.118.2 --new_master_port=3306 --new_master_user='user' --new_master_password='password'

*  该阶段成果后给出报告

Fri Jul  1 13:35:33 2016 - [info] ** Finished master recovery successfully.
    Fri Jul  1 13:35:33 2016 - [info] * Phase 3: Master Recovery Phase completed.

*  (4)slaves恢复阶段

[info] * Phase 4: Slaves Recovery Phase..

*  先停止IO线程，等待SQL线程执行完成后，stop slave，清除原slave信息，重新change master指向新的master，start slave ，over

Query     SHOW SLAVE STATUS
    Query     STOP SLAVE IO_THREAD
    Query     SHOW SLAVE STATUS
    Query     SHOW SLAVE STATUS
    Query     STOP SLAVE
    Query     SHOW SLAVE STATUS
    Query     RESET SLAVE
    Query     CHANGE MASTER TO MASTER_HOST = '192.168.118.62' MASTER_USER = 'repl' MASTER_PASSWORD = <secret> MASTER_PORT = 3306
    Query     START SLAVE
    Connect Out       repl@192.168.118.62:3306
    Query     SHOW SLAVE STATUS

*  (5)清除新选出的master上的slave信息

reset slave all;

## 安装过程参考网页 ##

[https://blog.csdn.net/Mryiyi/article/details/73822952][https_blog.csdn.net_Mryiyi_article_details_73822952]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0NTUzMjk0_size_16_color_FFFFFF_t_70]: /images/20220413/b08648fbb84a43088acc8b3422510615.png
[https_blog.csdn.net_Mryiyi_article_details_73822952]: https://blog.csdn.net/Mryiyi/article/details/73822952