技术分享 | 利用GreatSQL部署MGR集群，并完成添加新节点、滚动升级、切主（超详细）...

川长思鸟来 2022-10-07 15:50 111阅读 0赞

本文来源：原创投稿

\* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。

## 0. 内容提纲 ##

*  1. 运行环境
 *  2、准备my.cnf配置文件
 *  3、初始化MySQL实例
 *  4、构建MGR集群
 *   *  4.1 构建MGR集群前的准备工作
     *  4.2 配置MGR集群PRIMARY节点
     *  4.3 查看MGR集群状态
     *  4.4 测试数据读写
 *  5、进一步，再增加一个新节点
 *  6、再进一步，切换主节点
 *   *  6.1 先升级SECONDARY节点
     *  6.2 再升级PRIMARY节点
     *  6.3 手动切换PRIMARY节点

‍‍‍‍‍‍

> 一文快速掌握MGR集群的部署和运维。

本文详细介绍如何在单机环境下，利用GreatSQL构建一个3节点的MGR集群，并用mysqld\_multi进行管理。

为了简单起见，这个MGR集群采用单主（single-primary）模式，不采用多主（multi-primary）模式。

构建完MGR集群后，再添加一个新节点，以及模拟进行滚动升级和切主等其他操作。

除了MySQL官方社区版本外，如果想体验更可靠、稳定、高效的MGR，推荐使用GreatSQL版本。本文采用GreatSQL 8.0.22版本，关于这个版本的说明详见 [GreatSQL，打造更好的MGR生态][GreatSQL_MGR]。

P.S，单机模式下，如果要部署多实例并构建MGR集群，要注意避免TCP self-connect的问题，详见 bug\#98151，如果采用GreatSQL版本就没这个问题了。

### 1. 运行环境 ###

GreatSQL二进制包放在 /usr/local/ 下，即 `basedir = /usr/local/GreatSQL-8.0.22`。

三个实例按下面规划分配：

<table> 
 <thead> 
  <tr> 
   <th>实例</th> 
   <th>端口</th> 
   <th>datadir</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>GreatSQL-01</td> 
   <td>3306</td> 
   <td>/data/GreatSQL/mgr01/</td> 
  </tr> 
  <tr> 
   <td>GreatSQL-02</td> 
   <td>3307</td> 
   <td>/data/GreatSQL/mgr02/</td> 
  </tr> 
  <tr> 
   <td>GreatSQL-03</td> 
   <td>3308</td> 
   <td>/data/GreatSQL/mgr03/</td> 
  </tr> 
 </tbody> 
</table>

![e8dc3c01b79395bff126ba6757c617a3.png][]

### 2、准备my.cnf配置文件 ###

[mysqld]
    basedir=/usr/local/GreatSQL-8.0.22
    log_timestamps=SYSTEM
    user = mysql
    log_error_verbosity = 3
    
    log-bin=binlog
    binlog-format=row
    log_slave_updates=ON
    binlog_checksum=CRC32
    
    master-info-repository=TABLE
    relay-log-info-repository=TABLE
    gtid-mode=on
    enforce-gtid-consistency=true
    binlog_transaction_dependency_tracking=writeset
    transaction_write_set_extraction=XXHASH64
    slave_parallel_type = LOGICAL_CLOCK
    slave_parallel_workers=128 #可以设置为逻辑CPU数量的2-4倍
    sql_require_primary_key=1
    slave_preserve_commit_order=1
    slave_checkpoint_period=2
    
    #mgr
    loose-plugin_load_add='mysql_clone.so'
    loose-plugin_load_add='group_replication.so'
    
    #所有节点的group_replication_group_name值必须相同
    #这是一个标准的UUID格式，可以手动指定，也可以用随机生成的UUID
    loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1"
    
    #指定MGR集群各节点的IP+端口，这个端口是专用于MGR的，不是平常所说的mysqld实例端口
    #如果是在多节点上部署MGR集群时，要注意这个端口是否会被防火墙拦截
    loose-group_replication_group_seeds= "127.0.0.1:33061,127.0.0.1:33071,127.0.0.1:33081"
    
    #不建议启动mysqld的同时也启动MGR服务
    loose-group_replication_start_on_boot=off
    
    #默认不要作为MGR集群引导节点，有需要时再手动执行并立即改回OFF状态
    loose-group_replication_bootstrap_group=off
    
    #当退出MGR后，把该实例设置为read_only，避免误操作写入数据
    loose-group_replication_exit_state_action=READ_ONLY
    
    #一般没什么必要开启流控机制
    loose-group_replication_flow_control_mode = "DISABLED"
    
    #【强烈】建议只用单主模式，如果是实验目的，可以尝试玩玩多主模式
    loose-group_replication_single_primary_mode=ON
    
    [mysqld_multi]
    mysqld = /usr/local/GreatSQL-8.0.22/bin/mysqld
    log = /data/GreatSQL/mysqld_multi.log
    mysqladmin = /usr/local/GreatSQL-8.0.22/bin/mysqladmin
    user=root
    
    [mysqld3306]
    datadir=/data/GreatSQL/mgr01
    socket=/data/GreatSQL/mgr01/mysql.sock
    port=3306
    server_id=3306
    log-error=/data/GreatSQL/mgr01/error.log
    #指定本节点的IP+端口
    loose-group_replication_local_address= "127.0.0.1:33061"
    
    [mysqld3307]
    datadir=/data/GreatSQL/mgr02
    socket=/data/GreatSQL/mgr02/mysql.sock
    port=3307
    server_id=3307
    log-error=/data/GreatSQL/mgr02/error.log
    loose-group_replication_local_address= "127.0.0.1:33071"
    
    [mysqld3308]
    datadir=/data/GreatSQL/mgr03
    socket=/data/GreatSQL/mgr03/mysql.sock
    port=3308
    server_id=3308
    log-error=/data/GreatSQL/mgr03/error.log
    loose-group_replication_local_address= "127.0.0.1:33081"

在这份配置文件中，`[mysqld]` 这部分内容是所有实例都会读取应用的，而在 `[mysqld3306]` 这部分配置，才是 3306 端口这个实例所独有的。

在构建MGR集群中，要保证集群各节点的 `group_replication_group_name` 选项值一样才行，否则就是不同的集群了。

另外，如果有防火墙的话，注意要开放各端口间的访问规则，否则无法启动MGR。

### 3、初始化MySQL实例 ###

先手动创建相应的datadir，并修改目录属主为mysql用户：

[root@greatsql]# mkdir -p /data/GreatSQL/{mgr01,mgr02,mgr03}
    [root@greatsql]# chown -R mysql.mysql /data/GreatSQL

执行下面的命令进行MySQL实例初始化，会自动创建InnoDB系统表空间、redo log、undo log的文件：

[root@greatsql]# /usr/local/GreatSQL-8.0.22/bin/mysqld --no-defaults --datadir=/data/GreatSQL/mgr01 --initialize --user=mysql
    
    [System] [MY-013169] [Server] /usr/local/GreatSQL-8.0.22/bin/mysqld (mysqld 8.0.22-13) initializing of server in progress as process 18688
    [System] [MY-013576] [InnoDB] InnoDB initialization has started.
    [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
    [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: h<GL%Lr:v66W

可以看到，在输出的日志中打印了root账号的临时密码（最后一行），启动mysqld实例后，首次用这个密码登入，就要立即进行修改，否则其他什么也做不了：

用同样的方法，也分别完成mgr02、mgr03的初始化。

接下来，分别启动三个mysqld实例：

[root@greatsql]# /usr/local/GreatSQL-8.0.22/bin/mysqld_multi start 3306
    [root@greatsql]# /usr/local/GreatSQL-8.0.22/bin/mysqld_multi start 3307
    [root@greatsql]# /usr/local/GreatSQL-8.0.22/bin/mysqld_multi start 3308

能看到datadir下的文件目录大概像这样的：

-rw-r----- 1 mysql mysql       56 Jun  4 10:44 auto.cnf
    -rw-r----- 1 mysql mysql      401 Jun  4 10:46 binlog.000001
    -rw-r----- 1 mysql mysql       16 Jun  4 10:46 binlog.index
    -rw------- 1 mysql mysql     1676 Jun  4 10:44 ca-key.pem
    -rw-r--r-- 1 mysql mysql     1120 Jun  4 10:44 ca.pem
    -rw-r--r-- 1 mysql mysql     1120 Jun  4 10:44 client-cert.pem
    -rw------- 1 mysql mysql     1680 Jun  4 10:44 client-key.pem
    -rw-r----- 1 mysql mysql     8800 Jun  4 10:46 error.log
    -rw-r----- 1 mysql mysql   196608 Jun  4 10:48 #ib_16384_0.dblwr
    -rw-r----- 1 mysql mysql  8585216 Jun  4 10:44 #ib_16384_1.dblwr
    -rw-r----- 1 mysql mysql     6274 Jun  4 10:44 ib_buffer_pool
    -rw-r----- 1 mysql mysql 12582912 Jun  4 10:46 ibdata1
    -rw-r----- 1 mysql mysql 50331648 Jun  4 10:48 ib_logfile0
    -rw-r----- 1 mysql mysql 50331648 Jun  4 10:44 ib_logfile1
    -rw-r----- 1 mysql mysql 12582912 Jun  4 10:46 ibtmp1
    drwxr-x--- 2 mysql mysql      168 Jun  4 10:46 #innodb_temp
    drwxr-x--- 2 mysql mysql      143 Jun  4 10:44 mysql
    -rw-r----- 1 mysql mysql 25165824 Jun  4 10:46 mysql.ibd
    srwxrwxrwx 1 mysql mysql        0 Jun  4 10:46 mysql.sock
    -rw------- 1 mysql mysql        6 Jun  4 10:46 mysql.sock.lock
    drwxr-x--- 2 mysql mysql     8192 Jun  4 10:46 performance_schema
    -rw------- 1 mysql mysql     1680 Jun  4 10:44 private_key.pem
    -rw-r--r-- 1 mysql mysql      452 Jun  4 10:44 public_key.pem
    -rw-r--r-- 1 mysql mysql     1120 Jun  4 10:44 server-cert.pem
    -rw------- 1 mysql mysql     1676 Jun  4 10:44 server-key.pem
    drwxr-x--- 2 mysql mysql       28 Jun  4 10:44 sys
    -rw-r----- 1 mysql mysql 10485760 Jun  4 10:48 undo_001
    -rw-r----- 1 mysql mysql 10485760 Jun  4 10:46 undo_002
    -rw-r----- 1 mysql mysql        6 Jun  4 10:46 greatsql.pid

### 4、构建MGR集群 ###

#### 4.1 构建MGR集群前的准备工作 ####

因为在配置文件中已经指定了要加载 `group_replication` 和 `mysql_clone` 两个 plugin，如无意外，应该都已经加载成功：

看到确实已经加载了。

如果没有被正确加载，就需要查看日志文件确认什么原因无法加载。

也可以尝试手动加载这两个plugin：

[root@GreatSQL][(3306)]> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
    [root@GreatSQL][(3306)]> INSTALL PLUGIN clone SONAME 'mysql_clone.so';

`clone plugin` 的作用后面再介绍。

#### 4.2 配置MGR集群PRIMARY节点 ####

接下来创建MGR所需要的账户，并授权：

[root@GreatSQL][(3306)]> CREATE USER repl@'%' IDENTIFIED WITH MYSQL_NATIVE_PASSWORD BY 'repl';
    [root@GreatSQL][(3306)]> GRANT REPLICATION SLAVE, BACKUP_ADMIN ON *.* TO `repl`@`%`;

因为是一个刚初始化的干净系统，也为了简单起见，执行下面的命令再重置一下：

[root@GreatSQL][(3306)]> reset master; reset slave all;

【提醒】**生产环境中请勿这么做**。后面会有其他文章介绍如何对已上线的MGR集群再加入新的节点。

创建MGR复制通道：

[root@GreatSQL][(3306)]> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='repl' FOR CHANNEL 'group_replication_recovery';

上述所有操作，在其他几个节点上都重复执行一遍。

接着，【重要的一步】来了，登入被选中作为 **PRIMARY** 节点的mgr01实例，执行下面的命令：

[root@GreatSQL][(3306)]> set global group_replication_bootstrap_group=ON;

这个命令的作用是在MGR集群的PRIMARY节点第一次被启动时，用于引导MGR集群的。集群启动后，记得立即将该选项重置为 OFF。

[root@GreatSQL][(3306)]> set global group_replication_bootstrap_group=OFF;

在其他节点启动时，记住【不要】将选项 `group_replication_bootstrap_group` 设置为ON，否则会独立拉起一个新的MGR集群。

之后就可以在MGR集群的 **PRIMARY** 节点上启动组复制线程了：

[root@GreatSQL][(3306)]> start group_replication;
    Query OK, 0 rows affected (2.14 sec)
    
    [root@GreatSQL][(3306)]> select * from performance_schema.replication_group_members;
    +---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
    | CHANNEL_NAME              | MEMBER_ID                            |  MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
    +---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
    | group_replication_applier | 0fbb2cfd-c4d9-11eb-8747-525400e2078a | greatsql-mgr |        3306 | ONLINE       | PRIMARY     | 8.0.22         |
    +---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+

此时可以看到MGR集群已启动，且只有PRIMARY节点。

接下来在mgr02、mgr03节点上也执行 `start group_replication` 启动MGR服务，【记得要设置 】`group_replication_bootstrap_group=OFF`。

#### 4.3 查看MGR集群状态 ####

所有实例都启动MGR服务后，再次查看集群状态：

因为是在同一个主机上启动多实例构建的MGR，所以 **MEMBER\_HOST** 的值是一样的。

一个在单机上由三个实例组成的MGR集群构建完毕。

#### 4.4 测试数据读写 ####

在MGR集群运行过程中，**只有PRIMARY节点上允许同时读写数据，其他节点只能只读数据，不能写入**。

在PRIMARY节点上，创建新的库表并写入几行数据：

[root@GreatSQL][(3306)]> create database greatsql;
    [root@GreatSQL][(3306)]> use greatsql;
    [root@GreatSQL][(3306)][greatsql]> create table t1(id int primary key);
    [root@GreatSQL][(3306)][greatsql]> insert into t1 values (rand()*1024), (rand()*1024), (rand()*1024);
    Query OK, 3 rows affected (0.01 sec)
    Records: 3  Duplicates: 0  Warnings: 0
    
    [root@GreatSQL][(3306)][greatsql]> select * from t1;
    +-----+
    | id  |
    +-----+
    | 105 |
    | 423 |
    | 557 |
    +-----+
    3 rows in set (0.00 sec)

在另外两个节点上查看数据：

[root@GreatSQL][(3308)]> select * from greatsql.t1;
    +-----+
    | id  |
    +-----+
    | 105 |
    | 423 |
    | 557 |
    +-----+
    3 rows in set (0.00 sec)

可以读取到刚新写入的数据。

再次查看MGR的applier线程工作状态：

[root@GreatSQL][(3306)]> select * from performance_schema.replication_connection_status where channel_name = 'group_replication_applier'\G
    *************************** 1. row ***************************
                                          CHANNEL_NAME: group_replication_applier
                                            GROUP_NAME: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1
                                           SOURCE_UUID: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1
                                             THREAD_ID: NULL
                                         SERVICE_STATE: ON   <---状态为ON，正常
                             COUNT_RECEIVED_HEARTBEATS: 0
                              LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00.000000
                              RECEIVED_TRANSACTION_SET: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:1-19  <--- GTID在持续变化
                                     LAST_ERROR_NUMBER: 0
                                    LAST_ERROR_MESSAGE:
                                  LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
                               LAST_QUEUED_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:19
     LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
    LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
         LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP: 2021-06-04 15:53:55.395605
           LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP: 2021-06-04 15:53:55.395630
                                  QUEUEING_TRANSACTION:
        QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
       QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
            QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000

以及查看复制组各成员的状态：

[root@GreatSQL][(3306)]> select * from performance_schema.replication_group_member_stats\G
    *************************** 1. row ***************************
                                  CHANNEL_NAME: group_replication_applier
                                       VIEW_ID: 16227931944218245:4
                                     MEMBER_ID: 0fbb2cfd-c4d9-11eb-8747-525400e2078a
                   COUNT_TRANSACTIONS_IN_QUEUE: 0   <--- 等待冲突检测的事务队列大小
                    COUNT_TRANSACTIONS_CHECKED: 0
                      COUNT_CONFLICTS_DETECTED: 0
            COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
            TRANSACTIONS_COMMITTED_ALL_MEMBERS: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:1-19
                LAST_CONFLICT_FREE_TRANSACTION:
    COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0   <--- 本地等待apply的事务队列大小
             COUNT_TRANSACTIONS_REMOTE_APPLIED: 3
             COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
             COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
             ...

### 5、进一步，再增加一个新节点 ###

如果想对MGR集群扩展读性能，可以增加新的SECONDARY节点。

按照前面的方法，先初始化一个新的实例 mgr04，它运行的端口是 3309。然后利用 **clone plugin**（主从节点都必须要启用clone plugin） 从现有其他节点复制数据过来，再加入MGR集群。

运行clone复制数据需要 `BACKUP_ADMIN` 权限（复制源、目标两个节点都需要），前面已经授予了。

首先，设置clone donor节点：

# 尽量从SECONDARY节点复制数据，不从PRIMARY节点复制
    [root@GreatSQL][(3309)]> set global clone_valid_donor_list='127.0.0.1:3307';

开始复制数据：

[root@GreatSQL][(3309)]> clone instance from repl@127.0.0.1:3307 identified by 'repl';
    
    #clone结束后，会自动重启mysqld实例
    #但因为该实例没有用systemd服务管理起来，所以需要手动启动进程
    ERROR 3707 (HY000): Restart server failed (mysqld is not managed by supervisor process).

再次启动3309端口实例，登入查询，就能看到从其他节点复制过来的数据了：

[root@GreatSQL][(3309)]> select * from greatsql.t1;
    +-----+
    | id  |
    +-----+
    | 105 |
    | 423 |
    | 557 |
    +-----+
    3 rows in set (0.00 sec)

在mgr04实例上启动MGR服务：

可以看到，新节点加入成功了。

![dc8d2496fdc80e95f096ef9233aa5381.png][]

### 6、再进一步，切换主节点 ###

如果需要升级MGR集群中各节点的MySQL版本，则可以进行**滚动升级**。

即**先升级完全部SECONDARY节点，再将PRIMARY节点停掉下线，最后升级**，MGR集群会自动选择其他已升级完的节点作为新的PRIMARY节点，等到原来的PRIMARY节点也升级完后再加入 回来即可，这就完成整个集群所有节点的升级工作了。

#### 6.1 先升级SECONDARY节点 ####

现在要升级mgr4节点的MySQL版本，需要先停掉MGR服务：

[root@GreatSQL][(3309)]> stop group_replication;

再停掉mysqld进程后，在my.cnf中增加一行配置：

upgrade=AUTO

替换/指定新的MySQL二进制程序文件（相同大版本，只有相近几个小版本的差异时可以这么做），再次启动mysqld进程，即可实现自动升级。

这是MySQL 8.0.16之后的升级新方法，在8.0.16之前，需要手动执行 `mysql_upgrade` 二进制程序进行升级。

启动过程中，能看到类似下面的日志：

[System] [MY-013381] [Server] Server upgrade from '80022' to '80025' started.
    [Note] [MY-013386] [Server] Running queries to upgrade MySQL server.
    [Note] [MY-013387] [Server] Upgrading system table data.
    [Note] [MY-013385] [Server] Upgrading the sys schema.

之后再启动MGR服务，就能看到各节点的MySQL版本不同了。

如上图所示，只剩下mgr01节点还没升级。

从MySQL 8.0.16开始，新增MGR协议要求，比如使用相同的通信协议版本才能组成MGR集群，而8.0.22和8.0.25是相同的，所以可以在同一个集群里。

#在mgr01上执行
    [root@GreatSQL][(3306)]> select version(), group_replication_get_communication_protocol();
    +-----------+------------------------------------------------+
    | version() | group_replication_get_communication_protocol() |
    +-----------+------------------------------------------------+
    | 8.0.22-13 | 8.0.16                                         |
    +-----------+------------------------------------------------+
    
    #在mgr04上执行
    [root@GreatSQL][(3309)]> select version(), group_replication_get_communication_protocol();
    +-----------+------------------------------------------------+
    | version() | group_replication_get_communication_protocol() |
    +-----------+------------------------------------------------+
    | 8.0.25    | 8.0.16                                         |
    +-----------+------------------------------------------------+

#### 6.2 再升级PRIMARY节点 ####

现在关闭mgr01节点后，剩下的三个节点会完成自动选主：

自动选择了 mgr02 节点作为新的PRIMARY节点（未设定各节点权重值时，则按照 `MEMBER_ID` 的顺序依次选主）。

待到mgr01节点也完成升级，重新加回集群后：

![63e8ac05878f6a666f91115540e92200.png][]

#### 6.3 手动切换PRIMARY节点 ####

此时，还是选择mgr02作为PRIMARY节点，不会发生变化，除非手动执行切主操作：

这就完成滚动升级以及再次切主的全部操作了。

至此，MGR集群的构建、添加新节点、滚动升级、切主等操作都已完成。

在单机多节点构建MGR集群，和在多机上的构建过程并无本质区别，大家可以自行操作一遍。

Enjoy GreatSQL :)

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

**文章推荐：**

*  [《叶问》34期，延迟从库加上MASTER\_DELAY，主库宕机后如何快速恢复服务][34_MASTER_DELAY]  
    
 *  [《叶问》33期，MGR最佳配置参考，PFS里的监测指标要全开吗，mysqld进程占用内存过高怎么排查][33_MGR_PFS_mysqld]
 *  [binlog server伪装master恢复增量数据][binlog server_master]
 *  [从库Seconds\_Behind\_Master延迟总结][Seconds_Behind_Master]
 *  [MySQL 复制延迟 Seconds\_Behind\_Master 究竟是如何计算的][MySQL _ Seconds_Behind_Master]  
    
 *  [MySQL MGR看着很美，却又为什么不敢用？][MySQL MGR]
 *  [GreatSQL MGR优化参考][GreatSQL MGR]
 *  [GreatSQL，打造更好的MGR生态][GreatSQL_MGR 1]

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

点击文末“**阅读原文**”直达「叶问」专栏

[GreatSQL_MGR]: https://mp.weixin.qq.com/s?__biz=MzkzMTIzMDgwMg%3D%3D&idx=1&mid=2247483656&scene=21&sn=ca60b3875450cd3dfaad3519b12c9dcb#wechat_redirect
[e8dc3c01b79395bff126ba6757c617a3.png]: /images/20221005/481a54238bca4925beab1bc6dcd0e6a7.png
[dc8d2496fdc80e95f096ef9233aa5381.png]: /images/20221005/0ac950ae61d5441da60989875cf6d404.png
[63e8ac05878f6a666f91115540e92200.png]: /images/20221005/2f888b0674fa4ce7b2927b007edf7636.png
[34_MASTER_DELAY]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b43268a4cca301fa05c3dc7afd2bb5420763848af3c4e50e58b0f232e29caba77c2f93f4b&idx=1&mid=2653935948&scene=21&sn=3355e702d41109e375297b0bb6c77f84#wechat_redirect
[33_MGR_PFS_mysqld]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b436b8a4cca7ddf138db1d2342aa19f0452bff97beb2f5015cf0eb377a7d2a6899d1c3c05&idx=1&mid=2653935873&scene=21&sn=7511853d63145b7d72ae533586b6ad81#wechat_redirect
[binlog server_master]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b4eb08a4cc7a6f46de41fe64e8eadbb55f93c514361c611c469adad369fac3a5b2b53f35f&idx=1&mid=2653934810&scene=21&sn=581f4562a5e5bc661946cfab2dda98c5#wechat_redirect
[Seconds_Behind_Master]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b57588a4cde4e53742bc8160cd1602e73951bcd13f0c2d33c157a76db834ec2575ada690b&idx=1&mid=2653932850&scene=21&sn=722402793ebba0e7e8790bc9bd48813e#wechat_redirect
[MySQL _ Seconds_Behind_Master]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b518d8a4cd89b8b5a4e5a97b8d55cc3cf179b767665ee2661991207baa5e74be4ef88fa2e&idx=1&mid=2653932519&scene=21&sn=e018ea5f3bc86f8a6862a35c4b805652#wechat_redirect
[MySQL MGR]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b42b28a4ccba4699c1557d0f3ad0eeeb59cb9b0464fa4f008b46a80c66440e31353ccccd6&idx=1&mid=2653935832&scene=21&sn=87057f4f6837b70cd9a778d7b10381d1#wechat_redirect
[GreatSQL MGR]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b42c78a4ccbd1d08d39f6869bfd01dca3645e5096e419ab35474c261317c71d55876a6543&idx=1&mid=2653935789&scene=21&sn=936dfa64b0e2e957bd23086c0212d8e9#wechat_redirect
[GreatSQL_MGR 1]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b42fd8a4ccbebac385c47daf7bca40415b09b1298b6b1b7fc0c7822d147ab157ba35e7d03&idx=1&mid=2653935767&scene=21&sn=3f396b10f61629f6a09f29e364dc260b#wechat_redirect