MySQL 8.0.23中复制架构从节点自动故障转移

红太狼 2023-01-12 04:27 117阅读 0赞

接触MGR有一段时间了，MySQL 8.0.23的到来，基于MySQL Group Replicaion（MGR）的高可用架构又提供了新的架构思路。

1.  灾备机房的slave，如何更好的支持主机房的MGR？
2.  MGR 到底可以坏几个节点？

这次我就以上2个问题，和大家简单聊下MGR的一些思想和功能。

# 一、MySQL Group Relication 成员数量的容错能力 #

![format_png][]

上面的表格相信大家不会陌生了，我经常在面试里会问：“4个节点的MGR，最多坏几个呢？” ，多数人回答：“最多坏1个，坏2个就脑裂不能工作了。”

![format_png 1][]

那我们来看看MGR的处理方式，是不是这个答案呢？

**1）我们具有一个4节点MGR**

![format_png 2][]

埋一个问题：这个图一看就是Single模式，但箭头不是单向，是不是画错了？

**2）此时，Second-04突然宕机了，那么MGR集群会成什么样子呢？**

![format_png 3][]

**集群此时状态会变成：**

![format_png 4][]

*  每个节点会固定时间交换各自信息。
 *  当没有收到Second-04节点信息后，其他成员会等待5秒。
 *  这个期间Second-04肯定没有发出来消息，于是健康成员认为Second-04是可疑状态，标记UNREACHABLE状态。
 *  然后健康成员按照参数：group\_replication\_member\_expel\_timeout，继续等待（此时Second-04依然是UNREACHABLE状态）。
 *  当超过了group\_replication\_member\_expel\_timeout时间，健康成员就把Second-04节点驱逐出集群了。

--------------------

###     ###

### 那么重点来了，敲黑板 ###

**在Second-04，没有被驱逐出去时：**

*  此时集群是（4节点-3健康-1坏）,这个期间如果继续坏1个节点，那么集群变成（4节点-2健康-2坏），集群没有满足多数原则，每个节点都无法写入了（除非人工干预，强制指定集群成员List）。

![format_png 5][]

**在Second-04，被驱逐出去后：**

*  此时集群是（3节点-3健康-0坏），4节点集群退化成3节点健康集群了，这个时候，集群依然可以继续坏一个节点，变成（3节点-2健康-1坏）
    
    ![format_png 6][]
    
    所以4节点集群是否可以坏1个还是2个，具体要看集群处理过程哪个阶段哦。

> PS：
> 
> 我们说说刚才埋的问题：这个图一看就是Single模式，但箭头不是单向，是不是画错了？
> 
> 首先Single模式，Second节点默认是不能写入的，但只是由于Second节点的super-read-only开启了。
> 
> 将Second节点super-read-only = 0，Second节点可以正常写入，并可以同步其他节点（Primary和其他Second），传输还是基于Paxos协议的。
> 
> 跑个火车：Second节点反向同步其他节点，是不会经过冲突检测阶段（理论效率要高于多写模式），没有验证，大家有兴趣可以研究下。

# 二、 Asynchronous Connection Failover #

MySQL 8.0.22,推出了异步复制连接故障转移，很多朋友都发文做了介绍，这里我只简单描述下：

1）同机房1主1从，异地机房单独放一个slave节点

![format_png 7][]

2）Master 故障，将Slave-01变成Master，Slave-02无法连接原Master

![format_png 8][]

3）如果对Slave-02配置了“异步连接故障转移配置”，那么Slave-02在识别原Master故障后，会自动尝试按照预先定义好的配置，与原Slave-01（新Master）建立复制关系：

![format_png 9][]

这个功能非常好，引用三方工具（例如MHA的修复主从关系）已经可以被MySQL原生功能代替了。

**但我测试完，又有了几点疑虑：**

*1. “异步”复制故障转移，难道不支持半同步架构？不能确保数据不丢失，还是无法完全代替MHA啊？*  
*答：其实是支持增强半同步的。*

*2. 要预先配置故障转移的Master List，那么A机房架构变更，还要去维护机房B的节点吗？*  
*答：是的。*

*3. 如果A机房是MGR，那么MGR的节点（master）异常，但服务没有关，可以访问，机房B节点岂不是一直连接着？*  
*答：是的*

## 然后,MySQL 8.0.23发布了，带来了此功能的增强： ##

Slave可以支持MGR集群，并且可以动态识别MGR成员，来建立Master-Slave关系了

![format_png 10][]

最后让我们跑一圈：

1）首先我们有3节点的MGR集群，版本8.0.22（异步连接故障转移，是作用在Slave的IO Thread上的，所以Slave是8.0.23版本就成）

+----------------------------+-------------+--------------+-------------+---------------------+
    | now(6)                     | member_host | member_state | member_role | VIEW_ID             |
    +----------------------------+-------------+--------------+-------------+---------------------+
    | 2021-01-22 13:41:27.902251 | mysql-01    | ONLINE       | SECONDARY  | 16112906030396799:9 |
    | 2021-01-22 13:41:27.902251 | mysql-02    | ONLINE       | PRIMARY     | 16112906030396799:9 |
    | 2021-01-22 13:41:27.902251 | mysql-03    | ONLINE       | SECONDARY   | 16112906030396799:9 |
    +----------------------------+-------------+--------------+-------------+---------------------+

2）然后我们在独立Slave节点，指定Slave上“对Master连接故障转移列表”

SELECT asynchronous_connection_failover_add_managed('ch1', 'GroupReplication', 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1', 'mysql-02', 3306, '', 80, 60);
    
    
    简单解释下参数：
    ch1：chanel名称
    GroupReplication：强制写死的参数，目前支持MGR集群
    aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1：MGR组名（参数 group_replication_group_name）
    mysql-02：MGR成员之一
    80：Primary节点的优先级（0-100），多主相同优先级则随机选择节点充当master。
    60：Second节点的优先级（0-100），基本就是给Single模式准备的

3）为Slave指定复制通道信息

CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='123456', SOURCE_HOST='mysql-02',SOURCE_PORT=3306,SOURCE_RETRY_COUNT=2,SOURCE_CONNECTION_AUTO_FAILOVER=1,SOURCE_AUTO_POSITION=1 For CHANNEL 'ch1';

4）启动Slave，并查看“连接的可转移列表”

*  不开启io thread，是不会自动识别MGR成员的。并且复制用户
    
    rpl\_user需要在MGR节点对performance\_schema具有select权限

start slave;
    SELECT * FROM performance_schema.replication_asynchronous_connection_failover;
    +--------------+----------+------+-------------------+--------+--------------------------------------+
    | CHANNEL_NAME | HOST     | PORT | NETWORK_NAMESPACE | WEIGHT | MANAGED_NAME                         |
    +--------------+----------+------+-------------------+--------+--------------------------------------+
    | ch1          | mysql-01 | 3306 |                   |     60 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1 |
    | ch1          | mysql-02 | 3306 |                   |     80 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1 |
    | ch1          | mysql-03 | 3306 |                   |     60 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1 |
    +--------------+----------+------+-------------------+--------+--------------------------------------+

5）然后我们将mysql-02 stop group\_replication(不是关闭服务)，

Slave列表自动淘汰mysql-02，重新与其他节点建立连接-- mysql-02(Primary):

stop group_replication;
    
    
    -- Slave:
    SELECT * FROM performance_schema.replication_asynchronous_connection_failover;
    +--------------+----------+------+-------------------+--------+--------------------------------------+
    | CHANNEL_NAME | HOST     | PORT | NETWORK_NAMESPACE | WEIGHT | MANAGED_NAME                         |
    +--------------+----------+------+-------------------+--------+--------------------------------------+
    | ch1          | mysql-01 | 3306 |                   |     80 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1 |
    | ch1          | mysql-03 | 3306 |                   |     60 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1 |
    +--------------+----------+------+-------------------+--------+--------------------------------------+
    
    
    show slave status\G
    *************************** 1. row ***************************
                   Slave_IO_State: Waiting for master to send event
                      Master_Host: mysql-01
                      Master_User: rpl_user
                      Master_Port: 3306
                    Connect_Retry: 60
                  Master_Log_File: mybinlog.000003
              Read_Master_Log_Pos: 4904
                   Relay_Log_File: mysql-01-relay-bin-ch1.000065
                    Relay_Log_Pos: 439
            Relay_Master_Log_File: mybinlog.000003
                 Slave_IO_Running: Yes
                Slave_SQL_Running: Yes
                ...

至此，配置完成。后面MGR节点增、减，Slave都可以自动维护这个列表。不贴其他用例了。

PS:

*  如果想手工切换Slave已建立的Master节点（Primary）连接到其他节点（Second）上，只需要删除“复制连接的可转移列表”，重新调整Second优先级加回即可。

-- 删除配置
    SELECT asynchronous_connection_failover_delete_managed('ch1', 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1');
    
    
    -- 重新添加，调整Second优先级高于Primary
    SELECT asynchronous_connection_failover_add_managed('ch1', 'GroupReplication', 'aaaaaaaaaaaa-aaaa-aaaa-aaaaaaaaaaa1', 'mysql-03', 3306, '', 60, 80);

参考连接：

*  https://mysqlhighavailability.com/automatic-asynchronous-replication-connection-failover/
 *  https://my.oschina.net/u/4591256/blog/4813037
 *  https://dev.mysql.com/doc/refman/8.0/en/replication-functions-source-list.html

[format_png]: /images/20221119/d4425a9dcb514f078f6ad7a2c8343ff6.png
[format_png 1]: /images/20221119/ae7e99b7ade84cbcb3fd6ce086cc0def.png
[format_png 2]: /images/20221119/827fd3a97d8548e592d0f1a0c2057e38.png
[format_png 3]: /images/20221119/6d1c68cec6a94c788c66a8c3d7bf8600.png
[format_png 4]: /images/20221119/c41689b8a28d42fda1e216e292fd5459.png
[format_png 5]: /images/20221119/f64c79b628014999ab48cb210fab2f3c.png
[format_png 6]: /images/20221119/ef7fbab998924906a4530d167f13607c.png
[format_png 7]: /images/20221119/b5d8b56329bd4c8aa4bc2632bdd15f48.png
[format_png 8]: /images/20221119/cd787f4eb4a0446f930a431057ed8622.png
[format_png 9]: /images/20221119/d2c5440caece4cb0ac28d6251d7f9feb.png
[format_png 10]: /images/20221119/f6cfe2b8a9364903b5e1256c29e3504e.png