MySQL 8.0 复制搭建与可观测监控

前言

2020 年美国科技界纷纷响应 Black Lives Matter，BLM 维权运动，将带有种族色彩的词汇替换，MySQL 也将 master、slave 等关键字进行替换，但是没有彻底删除，留给用户过渡的空间。在 2024 年 4 月 30 日 MySQL 发布的 8.4 LTS 版本中带有种族色彩的关键字已经彻底删除。本篇文章将介绍在新版本中搭建备库的语法，还有一些基于新特性搭建和监控复制的有趣的方法。

1. 环境准备

MySQL 8.0 复制中比较大的突破就是 clone 特性，让搭建一个备份非常简单。在主库有数据的情况下，搭建备库需要先做一个全量备份，因为主库的 Binlog 很难全部都保留。然后基于全备的位点建立复制关系，建立复制关系的位点也无需记录，可以使用 GTID 特性。

以下是环境信息，source 就是主库，replica 就是备节点。

服务器	角色	版本	Server_id
172.16.104.55	source	MySQL 8.0.36	553306
172.16.104.57	replica	MySQL 8.0.36	573306

以下是复制相关的参数要求，需开启 GTID 另外 binlog_format 为 row 模式。

# 集群中 server_id 要唯一
server_id = 553306
gtid_mode = on
enforce_gtid_consistency = on
binlog_format = ROW

2. 克隆数据

默认主节点和备节点的参数都一致，除了了一些标记本节点的参数。

安装克隆插件，主备节点 都要安装：

install plugin clone soname 'mysql_clone.so';

确认 clone 插件的状态：

-- SQL：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone';

-- 输出：
+-------------+---------------+
| PLUGIN_NAME | PLUGIN_STATUS |
+-------------+---------------+
| clone       | ACTIVE        |
+-------------+---------------+

在 主节点 创建 clone 专用的账号：

CREATE USER 'donor_user'@'%' IDENTIFIED BY 'password';
GRANT BACKUP_ADMIN on *.* to 'donor_user'@'%';

在 备节点 添加主节点的白名单：

SET GLOBAL clone_valid_donor_list = '172.16.104.55:3306';

在 备节点 发起克隆，结束后数据库会重启：

CLONE INSTANCE FROM 'donor_user'@'172.16.104.57':3306 IDENTIFIED BY 'password';

在 备节点 查看 clone 结果，可以看到主节点 Binlog 位点和 GTID 信息：

select * from performance_schema.clone_status\G

至此，已经获取到主节点的全量数据，接下来需要建立复制关系。

3. 建立复制关系

备节点 创建专用的复制账号：

create user repl@'%' identified by 'password';
grant replication slave on *.* to repl@'%';

备节点 创建复制通道，CHANNEL 为复制通道的名称：

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='172.16.104.55',
  SOURCE_USER='repl',
  SOURCE_PASSWORD='password',
  GET_SOURCE_PUBLIC_KEY = 1,
  SOURCE_AUTO_POSITION = 1
  FOR CHANNEL 'mysql_rplica';

执行完成后，启动复制

start replica；

查看复制状态：

show replica status\G

4. 可观测监控

针对主备复制，比较习惯使用 show slave status 语句来监控主备复制的状态和延迟，在 8.0 版本 MySQL 提供了更精细粒度的监控，延迟可以精确到毫秒。

在 performance_schema 中，提供了 12 张复制相关的表，但是这些表的含义比较难理解，而且官方对这些表的介绍也很简单，一位 Oracle 工程师，提供一些视图，降低了 performance_schema 的使用成本，从而获得更精细粒度的监控。

视图下载地址：mysql_8_replication_observability.sql

安装非常简单，执行 SQL 文本即可。

4.1 监控延迟

select * from sys.replication_lag;

[performance_schema]>select * from sys.replication_lag;
+--------------+-----------------------+------------------------+
| channel_name | max_lag_from_original | max_lag_from_immediate |
+--------------+-----------------------+------------------------+
| mysql_rplica | 00:00:08.768837       | 00:00:08.768837        |
+--------------+-----------------------+------------------------+

4.2 复制状态

查看每个复制线程的状态，如下面的结果所示，使用的是 4 个 worker 的多线程复制：

select * from replication_status;

+------------------+----------+----------+---------+-------------------+--------------------+
| channel          | io_state | co_state | w_state | lag_from_original | lag_from_immediate |
+------------------+----------+----------+---------+-------------------+--------------------+
| mysql_rplica (1) | ON       | ON       | ON      | 00:00:30.070091   | 00:00:30.070091    |
| mysql_rplica (2) | ON       | ON       | ON      | none              | none               |
| mysql_rplica (3) | ON       | ON       | ON      | none              | none               |
| mysql_rplica (4) | ON       | ON       | ON      | none              | none               |
+------------------+----------+----------+---------+-------------------+--------------------+

4.3 更细粒度的监控

select * from sys.replication_status_full\G

*************************** 1. row ***************************
                 channel: mysql_rplica (1)
                    host: 172.16.104.55
                    port: 3306
                    user: repl
             source_uuid: bc880563-004e-11ef-b91c-fa7581637800
              group_name: 
last_heartbeat_timestamp: 2024-07-30 11:36:24.601625
      heartbeat_interval: 30.000
                io_state: ON
         io_thread_state: Waiting for source to send event
                io_errno: 0
               io_errmsg: 
              io_errtime: 0000-00-00 00:00:00.000000
                co_state: ON
         co_thread_state: Replica has read all relay log; waiting for more updates
                co_errno: 0
               co_errmsg: 
              co_errtime: 0000-00-00 00:00:00.000000
                 w_state: ON
          w_thread_state: Waiting for an event from Coordinator
                 w_errno: 0
                w_errmsg: 
               w_errtime: 0000-00-00 00:00:00.000000
 time_since_last_message: 00:00:29.666315
      applier_busy_state: IDLE
       lag_from_original: none
      lag_from_immediate: none
          transport_time: 108.85 ms
       time_to_relay_log: 2.09 s
              apply_time: 34.50 s
last_applied_transaction: bc880563-004e-11ef-b91c-fa7581637800:2058
 last_queued_transaction: bc880563-004e-11ef-b91c-fa7581637800:2058
queued_gtid_set_to_apply: 

参考

https://dev.mysql.com/blog-archive/mysql-8-and-replication-observability/