MySQL 8 新特性之Clone Plugin-有解無憂

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、本地克隆

本地克隆是在實體本地發起的，其語法如下：

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、遠程克隆

遠程克隆涉及兩個實體，其中，待克隆的實體是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相關，

九、參考資料

1. InnoDB: Clone local replica：https://dev.mysql.com/worklog/task/?id=9209

2. InnoDB: Clone remote replica：https://dev.mysql.com/worklog/task/?id=9210=

3. InnoDB: Clone Replication Coordinates：https://dev.mysql.com/worklog/task/?id=9211

4. InnoDB: Clone Remote provisioning：https://dev.mysql.com/worklog/task/?id=11636

5. MySQL/InnoDB資料克隆插件(clone plugin)實作剖析：https://zhuanlan.zhihu.com/p/79328512

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/172681.html

標籤：其他

上一篇：Oracle學習筆記十二：EM管理工具

下一篇：Mysql事務四個特征(ACID)