MySQL clone plugin 进阶知识

用户1278550

发布于 2023-09-04 12:30:02

2390

发布于 2023-09-04 12:30:02

文章被收录于专栏：idbaidba

一简介

前面一篇文章介绍了 MySQL clone plugin 实践操作。本文继续深入学习 clone 插件的相关技术知识。

二克隆相关的表

表 performance_schema.clone_status 记录克隆操作的当前状态。

 select * from performance_schema.clone_status \G
*************************** 1. row ***************************
             ID: 1
            PID: 11431
          STATE: Completed
     BEGIN_TIME: 2023-05-22 10:08:33.573
       END_TIME: 2023-05-22 10:08:54.044
         SOURCE: 172.17.28.117:3306
    DESTINATION: /data/mysql/20230522/
       ERROR_NO: 0
  ERROR_MESSAGE:
    BINLOG_FILE:
BINLOG_POSITION: 0
  GTID_EXECUTED:
1 row in set (0.00 sec)

目前测试下来该表只是记录最近一条克隆记录。

其中要注意的字段:

STATE：克隆操作的状态，Not Started，In Progress，Completed，Failed。如果是Failed状态，ERROR_NO，ERROR_MESSAGE会给出具体的错误编码和错误信息。

SOURCE 包含捐赠者的地址格式为 : IP:PORT

GTID_EXECUTED，BINLOG_FILE/BINLOG_POSITION: 克隆操作结束时，主库已经执行的GTID集合，及一致性位置点,可利用这些信息来搭建从库。

select * from performance_schema.clone_progress;
+------+-----------+-------------+----------------------------+----------------------------+---------+------------+------------+------------+------------+---------------+
| ID   | STAGE     | STATE       | BEGIN_TIME                 | END_TIME                   | THREADS | ESTIMATE   | DATA       | NETWORK    | DATA_SPEED | NETWORK_SPEED |
+------+-----------+-------------+----------------------------+----------------------------+---------+------------+------------+------------+------------+---------------+
|    1 | DROP DATA | Completed   | 2023-05-22 10:08:33.596902 | 2023-05-22 10:08:33.598484 |       1 |          0 |          0 |          0 |          0 |             0 |
|    1 | FILE COPY | Completed   | 2023-05-22 10:08:33.598549 | 2023-05-22 10:08:50.623072 |       8 | 4781624686 | 4781624686 | 4781890105 |          0 |             0 |
|    1 | PAGE COPY | Completed   | 2023-05-22 10:08:50.623252 | 2023-05-22 10:08:50.853804 |       8 |          0 |          0 |        785 |          0 |             0 |
|    1 | REDO COPY | Completed   | 2023-05-22 10:08:50.853871 | 2023-05-22 10:08:51.081509 |       8 |       3584 |       3584 |       4667 |          0 |             0 |
|    1 | FILE SYNC | Completed   | 2023-05-22 10:08:51.081578 | 2023-05-22 10:08:54.043953 |       8 |          0 |          0 |          0 |          0 |             0 |
|    1 | RESTART   | Not Started | NULL                       | NULL                       |       0 |          0 |          0 |          0 |          0 |             0 |
|    1 | RECOVERY  | Not Started | NULL                       | NULL                       |       0 |          0 |          0 |          0 |          0 |             0 |
+------+-----------+-------------+----------------------------+----------------------------+---------+------------+------------+------------+------------+---------------+
7 rows in set (0.00 sec)

其中需要关注的字段:

STAGE：克隆操作包括如下 7个步骤 : DROP DATA，FILE COPY，PAGE COPY，REDO COPY，FILE SYNC，RESTART，RECOVERY。

NETWORK：通过网络传输的数据量。如果是本地克隆，该列的值为0。DATA_SPEED，NETWORK_SPEED：当前数据拷贝的速率和网络传输的速率。

三克隆的基本原理

MySQL 克隆插件在克隆数据库时主要有以下 4个步骤:

[INIT] ---> [FILE COPY] ---> [PAGE COPY] ---> [REDO COPY] -> [Done]

1、INIT：初始化一个克隆对象。

2、FILE COPY

拷贝所有数据文件。在拷贝之前，会记录一个LSN，作为 "CLONE START LSN"，这个 LSN 其实是当前CHECKPOINT的LSN，同时启动 "Page Tracking" 特性。

"Page Tracking"会跟踪 "CLONE START LSN"之后被修改的页，具体来说，会记录该页的Tablespace ID和page ID。数据文件拷贝结束后，会将当前CHECKPOINT的LSN记为 "CLONE FILE END LSN"。

3、PAGE COPY

拷贝“CLONE START LSN”和“CLONE FILE END LSN”之间的页，在拷贝之前，会对这些页进行排序-基于Tablespace ID和page ID，尽量避免拷贝过程中出现随机读写。同时，开启“Redo Archiving”特性。

“Redo Archiving”会在后台开启一个归档线程将Redo文件中的内容按Chunk拷贝到归档文件中。通常来说，归档线程的拷贝速度会快于Redo日志的生成速度。即使慢于，在写入新的Redo日志时，也会等待归档线程完成拷贝，不会出现还未拷贝的Redo日志被覆盖的情况。当所有修改的页拷贝完毕后，会获取实例的一致性位置点信息，此时的LSN记为“CLONE LSN”。

4、REDO COPY

拷贝归档文件中“CLONE FILE END LSN”与“CLONE LSN”之间的Redo日志。

5、Done

调用 snapshot_end()销毁克隆对象。

四克隆的相关参数

总共14个参数，这里抽几个常用的参数进行介绍，更详细的信息请参考官方文档 https://dev.mysql.com/doc/refman/8.1/en/clone-plugin-options-variables.html

clone_autotune_concurrency 是否自动调节克隆过程中并发线程数的数量，默认为ON，此时，最大线程数受 clone_max_concurrency 参数控制。若设置为OFF，则并发线程数的数量将是固定的，同clone_max_concurrency参数一致。该参数的默认值为16。
clone_buffer_size 本地克隆时，中转缓冲区的大小，默认4M。缓冲区越大，备份速度越快，相应的，对磁盘IO的压力越大。
clone_block_ddl 如果设置为ON ，开启一个备份锁排它锁，再克隆数据期间阻止 DDL 动作。
clone_ddl_timeout 克隆操作需要获取备份锁（Backup Lock）。如果在执行CLONE命令时，有DDL在执行，则CLONE命令会被阻塞，等待获取备份锁（Waiting for backup lock）。等待的最大时长由clone_ddl_timeout参数决定，默认300（单位秒）。如果在这个时间内还没获取到锁，CLONE命令会失败，且提示“ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction”。需要注意的是，如果在执行DDL时，有CLONE命令在执行，DDL同样会因获取不到备份锁被阻塞，只不过，DDL操作的等待时长由 lock_wait_timeout 参数决定，该参数的默认值为31536000s，即365天。
clone_enable_compression 远程克隆，在传输数据时，是否开启压缩。开启压缩能节省网络带宽，但相应的，会增加CPU消耗。
clone_max_data_bandwidth 远程克隆时，可允许的最大数据拷贝速率（单位MiB/s）。默认为0，不限制。注意，这里限制的只是单个线程的拷贝速率，如果存在多个线程并行拷贝，实际最大拷贝速率=clone_max_data_bandwidth*线程数。
clone_max_network_bandwidth 远程克隆时，可允许的最大网络传输速率（单位MiB/s）。默认为0，不限制。如果网络带宽存在瓶颈，可通过该参数进行限速。
clone_valid_donor_list 设置Donor白名单，只能克隆白名单中指定的实例。比如:“HOST1:PORT1,HOST2:PORT2,HOST3:PORT3”. 不允许有空格。

五克隆的相关限制

MySQL 8.0.27 之前的版本中，克隆期间，不允许执行DDL命令。同样，DDL会阻塞克隆命令的执行，但是不会阻塞 DML 。

MySQL 8.0.27 之后的版本默认可以执行 DDL , 参考参数 clone_block_ddl

MySQL版本包括小版本必须一致，且支持开启 Clone Plugin 才能进行实例之间的克隆。比如不能从 5.7 克隆到 8.0 ，因为 8.0.17 版本之后才支持 Clone Plugin。
Clone 操作只会拷贝捐赠者的 InnoDB 表的表结构和数据，对于非 InnoDB 存储引擎的表，只会拷贝表结构。
同一时刻只能允许克隆一个实例，不能同时进行多个实例拷贝。
Clone Plugin 不会拷贝 Donor 捐赠者的配置参数, Recipient 接收者保留自己的参数文件和系统参数。标准化的配置，两边应该保持部分参数的差异，比如server_id 或者端口。
Donor 实例中如果有表通过 DATA DIRECTORY 指定了绝对路径，在进行本地克隆时，会提示文件已存在。在进行远程克隆时，绝对路径必须存在且有可写权限。
Clone Plugin 不会拷贝Donor的 binlog。
不支持通过 MySQL Router 连接 Donor 实例。
执行 CLONE INSTANCE 操作时，不能指定的 Donor 端口为 X Protocol 端口。

其他注意事项:

Recipient 必须有足够的磁盘空间存储克隆数据。
字符集（character_set_server），校验集（collation_server），character_set_filesystem 必须一致。
innodb_page_size 必须一致，clone 操作会检查 innodb_data_file_path中ibdata的数量和大小，否则新的实例无法启动。
Recipient 接收者在执行完克隆命令之后需要重启，建议使用 mysqld_safe 启动mysqld 服务进程。如果是通过 mysqld 进行启动，实例关闭后，需要手动启动。