MySQL 8 新特性Clone Plugin是什么

這篇文章主要介紹了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）可供借鑒。

本文將從以下幾個方面展開：

1. Clone Plugin的安裝
2. Clone Plugin的使用
3. 如何查看克隆操作的進度
4. 如何基于克隆數據搭建從庫
5. Clone Plugin的實現細節
6. Clone Plugin的限制
7. Clone Plugin與XtraBackup的對比
8. 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” 是克隆目錄，其需滿足以下幾點要求：

1. 克隆目錄必須是絕對路徑。
2. “/data/mysql”必須存在，且MySQL對其有可寫權限。
3. 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相關。

感謝你能夠認真閱讀完這篇文章，希望小編分享MySQL 8 新特性Clone Plugin是什么內容對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，遇到問題就找億速云，詳細的解決方法等著你來學習!