MySQL 8 新特性Clone Plugin是什么

63次阅读
没有评论

共计 11924 个字符,预计需要花费 30 分钟才能阅读完成。

自动写代码机器人,免费开通

这篇文章主要介绍了 MySQL 8 新特性 Clone Plugin 是什么,具有一定借鉴价值,需要的朋友可以参考下。希望大家阅读完这篇文章后大有收获。下面让丸趣 TV 小编带着大家一起了解一下。

Clone Plugin 是 MySQL 8.0.17 引入的一个重大特性,为什么要实现这个特性呢?个人感觉,主要还是为 Group Replication 服务。在 Group Replication 中,添加一个新的节点,差异数据的补齐是通过分布式恢复(Distributed Recovery)来实现的。

在 MySQL 8.0.17 之前,只支持一种恢复方式 -Binlog。但如果新节点需要的 Binlog 已经被 Purge 了,这个时候,只能先借助于备份工具(XtraBackup,mydumper,mysqldump)做个全量数据的同步,然后再通过分布式恢复同步增量数据。

这种方式,虽然也能实现添加节点的目的,但总归还是要借助于外部工具,需要一定的工作量和使用门槛。要知道,其竞争对手,PXC,默认集成了 XtraBackup 进行 State Snapshot Transfer(类似于全量同步),而 MongoDB 则更进一步,原生就实现了 Initial Sync 同步全量数据。从易用性来看,单就集群添加节点这一项而言,MySQL 确实不如其竞争对手。客户体验上,还有很大的提升空间。

好在 MySQL 官方也正视到这个差距,终于在 MySQL 8.0.17 实现了 Clone Plugin。当然,对于官方来说,实现这个特性并不算难,毕竟有现成的物理备份工具(MySQL Enterprise Backup)可供借鉴。

本文将从以下几个方面展开:

Clone Plugin 的安装 Clone Plugin 的使用如何查看克隆操作的进度如何基于克隆数据搭建从库 Clone Plugin 的实现细节 Clone Plugin 的限制 Clone Plugin 与 XtraBackup 的对比 Clone Plugin 的参数解析一、Clone Plugin 的安装

Clone Plugin 支持以下两种安装方式:

(1)配置文件指定

[mysqld]
plugin-load-add=mysql_clone.so
clone=FORCE_PLUS_PERMANENT 复制代码 

这里的 clone,严格来说,不是参数名,而是插件名,可加可不加,FORCE_PLUS_PERMANENT 控制插件的行为。

有四个取值:

ON**(** 开启插件)OFF(禁用插件)FORCE(强制开启。如果插件初始化失败,MySQL 将不会启动)FORCE_PLUS_PERMANENT(在 FORCE 的基础上,不允许通过 UNINSTALL PLUGIN 命令卸载插件)。

(2)动态加载

[mysqld]
plugin-load-add=mysql_clone.so
clone=FORCE_PLUS_PERMANENT 复制代码 

查看插件是否安装成功

mysql show plugins;
| clone | ACTIVE | CLONE | mysql_clone.so | GPL |
... 复制代码 

clone 状态显示为”ACTIVE“代表插件加载成功。

二、Clone Plugin 的使用

Clone Plugin 支持两种克隆方式:本地克隆和远程克隆。

1、本地克隆

MySQL 8 新特性 Clone Plugin 是什么

本地克隆是在实例本地发起的,其语法如下:

CLONE LOCAL DATA DIRECTORY [=] clone_dir 复制代码 

其中,clone_dir 是克隆目录。

下面看个具体的 Demo。

创建克隆用户

mysql create user clone_user @ % identified by clone_pass 
mysql grant backup_admin on *.* to clone_user @ % 复制代码 

创建克隆目录

# mkdir /data/mysql
# chown -R mysql.mysql /data/mysql 复制代码 

创建本地克隆

# mysql -uclone_user -pclone_pass
mysql clone local data directory= /data/mysql/3307 复制代码 

其中,“/data/mysql/3307”是克隆目录,其需满足以下几点要求:

克隆目录必须是绝对路径。“/data/mysql”必须存在,且 MySQL 对其有可写权限。3307 不能存在。

查看克隆目录的内容

# ll /data/mysql/3307
total 172996
drwxr-x--- 2 mysql mysql 89 May 24 22:37 #clone
-rw-r----- 1 mysql mysql 3646 May 24 22:37 ib_buffer_pool
-rw-r----- 1 mysql mysql 12582912 May 24 22:37 ibdata1
-rw-r----- 1 mysql mysql 50331648 May 24 22:37 ib_logfile0
-rw-r----- 1 mysql mysql 50331648 May 24 22:37 ib_logfile1
drwxr-x--- 2 mysql mysql 6 May 24 22:37 mysql
-rw-r----- 1 mysql mysql 25165824 May 24 22:37 mysql.ibd
drwxr-x--- 2 mysql mysql 20 May 24 22:37 slowtech
drwxr-x--- 2 mysql mysql 28 May 24 22:37 sys
-rw-r----- 1 mysql mysql 10485760 May 24 22:37 undo_001
-rw-r----- 1 mysql mysql 11534336 May 24 22:37 undo_002 复制代码 

相对于 Xtrabackup,无需 Prepare,直接即可启动使用。

# /usr/local/mysql/bin/mysqld --no-defaults --datadir=/data/mysql/3307 --user mysql --port 3307 复制代码 

2、远程克隆

MySQL 8 新特性 Clone Plugin 是什么MySQL 8 新特性 Clone Plugin 是什么

远程克隆涉及两个实例,其中,待克隆的实例是 Donor,接受克隆数据的实例是 Recipient。克隆命令需在 Recipient 上发起,语法如下:

CLONE INSTANCE FROM user @ host :port
IDENTIFIED BY password 
[DATA DIRECTORY [=] clone_dir ]
[REQUIRE [NO] SSL]; 复制代码 

其中,host,port 是待克隆实例的(Donor)的 IP 和端口,user,password 是 Donor 上的克隆用户和密码,需要 backup_admin 权限,如上面创建的 clone_user。

DATA DIRECTORY 指定备份目录,不指定的话,则默认克隆到 Recipient 的数据目录下。

REQUIRE [NO] SSL,是否开启 SSL 通信。

下面,看个具体 Demo。

首先,在 Donor 实例上创建克隆用户,加载 Clone Plugin。

mysql create user donor_user @ % identified by donor_pass 
mysql grant backup_admin on *.* to donor_user @ % 
mysql install plugin clone soname mysql_clone.so 复制代码 

backup_admin 是克隆操作必需权限。

接着,在 Recipient 实例上创建克隆用户,加载 Clone Plugin。

mysql create user recipient_user @ % identified by recipient_pass 
mysql grant clone_admin on *.* to recipient_user @ % 
mysql install plugin clone soname mysql_clone.so 复制代码 

这里的 clone_admin,隐式含有 backup_admin(阻塞 DDL)和 shutdown(重启实例)权限。

设置 Donor 白名单。Recipient 只能克隆白名单中的实例。

mysql set global clone_valid_donor_list = 192.168.244.10:3306 复制代码 

设置该参数需要 SYSTEM_VARIABLES_ADMIN 权限。

在 Recipient 上发起克隆命令

# mysql -urecipient_user -precipient_pass
mysql clone instance from donor_user @ 192.168.244.10 :3306 identified by donor_pass 
Query OK, 0 rows affected (36.97 sec) 复制代码 

远程克隆会依次进行以下操作:

**(1)**** 获取备份锁。** 备份锁和 DDL 互斥。注意,不仅仅是 Recipient,Donor 上的备份锁同样会获取。

**(2)****DROP 用户表空间。** 注意,DROP 的只是用户数据,不是数据目录,也不包括 mysql,ibdata 等系统表空间。

**(3)从 Donor 实例拷贝数据。** 对于用户表空间,会直接拷贝,如果是系统表空间,则会重命名为 xxx.#clone,不会直接替代原文件。

ll /data/mysql/3306/data/
-rw-r----- 1 mysql mysql 3646 May 25 07:20 ib_buffer_pool
-rw-r----- 1 mysql mysql 3646 May 27 07:31 ib_buffer_pool.#clone
-rw-r----- 1 mysql mysql 12582912 May 27 07:31 ibdata1
-rw-r----- 1 mysql mysql 12582912 May 27 07:31 ibdata1.#clone
-rw-r----- 1 mysql mysql 50331648 May 27 07:32 ib_logfile0
-rw-r----- 1 mysql mysql 50331648 May 27 07:31 ib_logfile0.#clone
-rw-r----- 1 mysql mysql 25165824 May 27 07:31 mysql.ibd
-rw-r----- 1 mysql mysql 25165824 May 27 07:31 mysql.ibd.#clone
... 复制代码 

**(4)重启实例。** 在启动的过程中,会用 xxx.#clone 替换掉原来的系统表空间文件。

三、如何查看克隆操作的进度

查看克隆操作的进度主要依托于 performance_schema.clone_status 和 performance_schema.clone_progress 这两张表。

首先看看 performance_schema.clone_status 表。

mysql select * from performance_schema.clone_status\G
*************************** 1\. row ***************************
 ID: 1
 PID: 0
 STATE: Completed
 BEGIN_TIME: 2020-05-27 07:31:24.220
 END_TIME: 2020-05-27 07:33:08.185
 SOURCE: 192.168.244.10:3306
 DESTINATION: LOCAL INSTANCE
 ERROR_NO: 0
 ERROR_MESSAGE:
 BINLOG_FILE: mysql-bin.000009
BINLOG_POSITION: 665197555
 GTID_EXECUTED: 59cd4f8f-8fa1-11ea-a0fe-000c29f66609:1-560
1 row in set (0.06 sec) 复制代码 

顾名思义,该表记录了克隆操作的当前状态。

其中,

**PID:**Processlist ID。对应 show processlist 中的 Id,如果要终止当前的克隆操作,执行 kill processlist_id 命令即可。

**STATE:** 克隆操作的状态,Not Started(克隆尚未开始),In Progress(克隆中),Completed(克隆成功),Failed(克隆失败)。如果是 Failed 状态,ERROR_NO,ERROR_MESSAGE 会给出具体的错误编码和错误信息。

**BEGIN_TIME,END_TIME:** 克隆操作开始,结束时间。

**SOURCE:**Donor 实例的地址。

**DESTINATION:** 克隆目录。“LOCAL INSTANCE”代表当前实例的数据目录。

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

接下来看看 performance_schema.clone_progress 表。

mysql 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 | 2020-05-27 07:31:28.581661 | 2020-05-27 07:31:35.855706 | 1 | 0 | 0 | 0 | 0 | 0 |
| 1 | FILE COPY | Completed | 2020-05-27 07:31:35.855952 | 2020-05-27 07:31:58.270881 | 2 | 482463294 | 482463294 | 482497011 | 0 | 0 |
| 1 | PAGE COPY | Completed | 2020-05-27 07:31:58.271250 | 2020-05-27 07:31:58.719085 | 2 | 10977280 | 10977280 | 11014997 | 0 | 0 |
| 1 | REDO COPY | Completed | 2020-05-27 07:31:58.720128 | 2020-05-27 07:31:58.930804 | 2 | 465408 | 465408 | 465903 | 0 | 0 |
| 1 | FILE SYNC | Completed | 2020-05-27 07:31:58.931094 | 2020-05-27 07:32:01.063325 | 2 | 0 | 0 | 0 | 0 | 0 |
| 1 | RESTART | Completed | 2020-05-27 07:32:01.063325 | 2020-05-27 07:32:59.844119 | 0 | 0 | 0 | 0 | 0 | 0 |
| 1 | RECOVERY | Completed | 2020-05-27 07:32:59.844119 | 2020-05-27 07:33:08.185367 | 0 | 0 | 0 | 0 | 0 | 0 |
+------+-----------+-----------+----------------------------+----------------------------+---------+-----------+-----------+-----------+------------+---------------+
7 rows in set (0.00 sec) 复制代码 

该表记录了克隆操作的进度信息。

**STAGE:** 一个克隆操作可依次细分为 DROP DATA,FILE COPY,PAGE COPY,REDO COPY,FILE SYNC,RESTART,RECOVERY 等 7 个阶段。当前阶段结束了才会开始下一个阶段。

**STATE:** 当前阶段的状态。有三种状态:Not Started,In Progress,Completed。

**BEGIN_TIME,END_TIME:** 当前阶段的开始时间和结束时间。

**THREADS:** 当前阶段使用的并发线程数。

**ESTIMATE:** 预估的数据量。

**DATA:** 已经拷贝的数据量。

**NETWORK:** 通过网络传输的数据量。如果是本地克隆,该列的值为 0。

**DATA_SPEED,NETWORK_SPEED:** 当前数据拷贝的速率和网络传输的速率。

注意,是当前值。

四、如何基于克隆数据搭建从库

在前面,我们介绍过 performance_schema.clone_status 表,该表会记录 Donor 实例的一致性位置点信息。我们可以利用这些信息来搭建从库。

mysql select * from performance_schema.clone_status\G
*************************** 1\. row ***************************
 BINLOG_FILE: mysql-bin.000009
BINLOG_POSITION: 665197555
 GTID_EXECUTED: 59cd4f8f-8fa1-11ea-a0fe-000c29f66609:1-560
1 row in set (0.06 sec) 复制代码 

这里,区分两种场景,GTID 复制和基于位置点的复制。

1、GTID 复制

mysql CHANGE MASTER TO MASTER_HOST = master_host_name , MASTER_PORT = master_port_num,
 MASTER_AUTO_POSITION = 1;
mysql START SLAVE; 复制代码 

需要注意的是,无需额外执行 set global gtid_purged 操作。通过克隆数据启动的实例,gtid_purged 已经初始化完毕。

mysql show global variables like gtid_purged 
+---------------+--------------------------------------------+
| Variable_name | Value |
+---------------+--------------------------------------------+
| gtid_purged | 59cd4f8f-8fa1-11ea-a0fe-000c29f66609:1-560 |
+---------------+--------------------------------------------+
1 row in set (0.00 sec) 复制代码 

2、基于位置点的复制

这里,同样要区分两种场景。

场景 1,Recipient 要作为 Donor 的从库。

mysql SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status; 
mysql CHANGE MASTER TO MASTER_HOST = master_host_name , MASTER_PORT = master_port_num,
 MASTER_LOG_FILE = master_log_name ,
 MASTER_LOG_POS = master_log_pos;
mysql START SLAVE; 复制代码 

其中,

master_host_name,master_port_num:Donor 实例的 IP 和端口。

master_log_name,master_log_pos:performance_schema.clone_status 中的 BINLOG_FILE, BINLOG_POSITION。

场景 2,Donor 本身就是一个从库,Recipient 要作为 Donor 主库的从库。

mysql SELECT MASTER_LOG_NAME, MASTER_LOG_POS FROM mysql.slave_relay_log_info;
mysql CHANGE MASTER TO MASTER_HOST = master_host_name , MASTER_PORT = master_port_num,
 MASTER_LOG_FILE = master_log_name ,
 MASTER_LOG_POS = master_log_pos;
mysql START SLAVE; 复制代码 

其中,

master_host_name,master_port_num:Donor 主库的 IP 和端口。

master_log_name,master_log_pos:mysql.slave_relay_log_info 中的 Master_log_name,Master_log_pos(分别对应 SHOW SLAVE STATUS 中的 Relay_Master_Log_File,Exec_Master_Log_Pos)。

在搭建从库时,建议设置 –skip-slave-start。该参数默认为 OFF,实例启动后,会自动执行 START SLAVE 操作。

如果 Donor 是个从库,Recipient 会基于 mysql.slave_master_info,mysql.slave_relay_log_info 中的信息自动建立复制,很多时候,这未必是我们的预期行为。

五、Clone Plugin 的实现细节

克隆操作可细分为以下 5 个阶段。

[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() 销毁克隆对象。

六、Clone Plugin 的限制

1、克隆期间,不允许执行 DDL 命令。同样,DDL 会阻塞克隆命令的执行

2、Clone Plugin 不会拷贝 Donor 的配置参数。

3、Clone Plugin 不会拷贝 Donor 的二进制日志文件。

4、Clone Plugin 只会拷贝 InnoDB 表的数据,对于其它存储引擎的表,只会拷贝表结构。

5、Donor 实例中如果有表通过 DATA DIRECTORY 指定了绝对路径,在进行本地克隆时,会提示文件已存在。在进行远程克隆时,绝对路径必须存在且有可写权限。

6、不允许通过 MySQL Router 连接 Donor 实例。

7、执行 CLONE INSTANCE 操作时,指定的 Donor 端口不能为 X Protocol 端口。

除此之外,在进行远程克隆时,还会进行如下检查:

MySQL 版本(包括小版本)必须一致,且支持 Clone Plugin。

ERROR 3864 (HY000): Clone Donor MySQL version: 8.0.20 is different from Recipient MySQL version 8.0.19. 复制代码 

主机的操作系统和位数(32 位,64 位)必须一致。两者可根据 version_compile_os,version_compile_machine 参数获取。Recipient 必须有足够的磁盘空间存储克隆数据。字符集(character_set_server),校验集(collation_server),character_set_filesystem 必须一致。innodb_page_size 必须一致。会检查 innodb_data_file_path 中 ibdata 的数量和大小。目前 Clone Plugin(8.0.20)的实现,无论是 Donor,还是 Recipient,同一时间,只能执行一个克隆操作。后续会支持多个克隆操作并发执行。

ERROR 3634 (HY000): Too many concurrent clone operations. Maximum allowed - 1. 复制代码 

Recipient 需要重启,所以其必须通过 mysqld_safe 或 systemd 等进行管理。如果是通过 mysqld 进行启动,实例关闭后,需要手动启动。

ERROR 3707 (HY000): Restart server failed (mysqld is not managed by supervisor process). 复制代码 

ACTIVE 状态的 Plugin 必须一致。七、Clone Plugin 与 XtraBackup 的对比

1、在实现上,两者都有 FILE COPY 和 REDO COPY 阶段,但 Clone Plugin 比 XtraBackup 多了一个 PAGE COPY,由此带来的好处是,Clone Plugin 的恢复速度比 XtraBackup 更快。

2、XtraBackup 没有 Redo Archiving 特性,有可能出现未拷贝的 Redo 日志被覆盖的情况。

3、GTID 下建立复制,无需额外执行 set global gtid_purged 操作。

八、Clone Plugin 的参数解析 clone_autotune_concurrency 是否自动调节克隆过程中并发线程数的数量,默认为 ON,此时,最大线程数受 clone_max_concurrency 参数控制。若设置为 OFF,则并发线程数的数量将是固定的,同 clone_max_concurrency 参数一致。该参数的默认值为 16。clone_buffer_size 本地克隆时,中转缓冲区的大小,默认 4M。缓冲区越大,备份速度越快,相应的,对磁盘 IO 的压力越大。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 白名单,只能克隆白名单中指定的实例。clone_ssl_ca,clone_ssl_cert,clone_ssl_key SSL 相关。

感谢你能够认真阅读完这篇文章,希望丸趣 TV 小编分享 MySQL 8 新特性 Clone Plugin 是什么内容对大家有帮助,同时也希望大家多多支持丸趣 TV,关注丸趣 TV 行业资讯频道,遇到问题就找丸趣 TV,详细的解决方法等着你来学习!

向 AI 问一下细节

丸趣 TV 网 – 提供最优质的资源集合!

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-12-18发表,共计11924字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)