ホームページ >データベース >mysql チュートリアル >MySQL 8 Clone Plugin の新機能を見てみましょう
Cloneプラグイン MySQL 8.0.17 で導入された主要な機能ですが、なぜこの機能を実装する必要があるのでしょうか?個人的には、主にグループ レプリケーションに使用されていると感じています。グループレプリケーションでは、新たなノードを追加し、分散リカバリ(Distributed Recovery)により差分データを完成させます。
MySQL 8.0.17 より前では、Binlog という 1 つの回復方法のみがサポートされていました。ただし、新しいノードに必要な Binlog がパージされている場合、現時点ではバックアップ ツール (XtraBackup、mydumper、mysqldump) を使用して完全データを同期し、その後、分散リカバリを通じて増分データを同期することしかできません。
この方法でもノードを追加するという目的は達成できますが、やはり外部ツールの助けが必要であり、ある程度の作業量と使用量のしきい値が必要です。競合他社である PXC は、状態スナップショット転送 (完全同期と同様) のためにデフォルトで XtraBackup を統合していますが、MongoDB はさらに一歩進んで、完全なデータを同期するための初期同期をネイティブに実装していることを知っておく必要があります。使いやすさの観点から見ると、クラスタにノードを追加するという点では、MySQL は競合他社に比べて確かに劣っています。顧客エクスペリエンスに関しては、まだ改善の余地がたくさんあります。
幸いなことに、MySQL 関係者もこのギャップを認識し、最終的に MySQL 8.0.17 に Clone プラグインを実装しました。もちろん、当局にとってこの機能を実装するのは難しいことではなく、参照用の既製の物理バックアップ ツール (MySQL Enterprise Backup) があります。
この記事では、次の点について詳しく説明します:
- クローン プラグインのインストール
- クローン プラグインの使用方法
- 表示方法クローン 作業の進行状況
- クローンデータを元にスレーブライブラリを構築する方法
- クローンプラグインの実装詳細
- クローンプラグインの制限事項
- クローンプラグインの比較Clone Plugin と XtraBackup
- Clone Plugin のパラメータ分析
Clone Plugin は次の 2 つのインストール方法をサポートしています:
(1) 設定ファイルの指定
[mysqld] plugin-load-add=mysql_clone.so clone=FORCE_PLUS_PERMANENT复制代码
ここでのクローンとは、厳密に言えばパラメータ名ではなくプラグイン名であり、追加するかどうかは問いません。 FORCE_PLUS_PERMANENT はプラグインの動作を制御します。
には 4 つの値があります:
(2) 動的読み込み
[mysqld] plugin-load-add=mysql_clone.so clone=FORCE_PLUS_PERMANENT复制代码
プラグインが正常にインストールされたか確認
mysql> show plugins; ... | clone | ACTIVE | CLONE | mysql_clone.so | GPL | ...复制代码
クローンのステータスが「」と表示されます。 ACTIVE」、プラグインが正常にロードされたことを意味します。
クローン プラグインは、ローカル クローン作成とリモート クローン作成という 2 つのクローン作成方法をサポートします。
ローカル クローン作成はインスタンス上でローカルに開始され、その構文は次のとおりです。 、clone_dir はクローンの目次です。
具体的なデモを見てみましょう。
クローンユーザーの作成
CLONE LOCAL DATA DIRECTORY [=] 'clone_dir';复制代码
クローンディレクトリの作成
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复制代码
このうち、「/data/mysql/3307」がクローンですディレクトリは、次の要件を満たす必要があります:
クローン ディレクトリは絶対パスである必要があります。クローン ディレクトリの内容を表示します
- "/data/mysql" が存在し、MySQL が書き込み可能な権限を持っている必要があります。
- 3307 は存在できません。
# mysql -uclone_user -pclone_pass mysql> clone local data directory='/data/mysql/3307';复制代码
Xtrabackup と比べて準備が不要で、直接起動できます。
# 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复制代码
2. リモート クローン作成
#リモート クローン作成には 2 つのインスタンスが含まれます。そのうち、クローン作成されるインスタンスは Donor であり、インスタンスはクローンデータを受け入れるのが Recipient です。クローン作成コマンドは受信者で開始する必要があり、構文は次のとおりです。
# /usr/local/mysql/bin/mysqld --no-defaults --datadir=/data/mysql/3307 --user mysql --port 3307 &复制代码
このうち、ホストとポートはクローンを作成するインスタンス (ドナー) の IP とポート、ユーザーとパスワードは次のとおりです。 Donor のクローン ユーザーとパスワード。backup_admin には上記で作成した clone_user などの権限が必要です。
DATA DIRECTORY はバックアップ ディレクトリを指定します。指定しない場合、デフォルトで受信者のデータ ディレクトリにクローンが作成されます。
REQUIRE [NO] SSL、SSL 通信を有効にするかどうか。
以下、具体的なデモを見てみましょう。
まず、ドナー インスタンスでクローン ユーザーを作成し、クローン プラグインをロードします。
CLONE INSTANCE FROM 'user'@'host':port IDENTIFIED BY 'password' [DATA DIRECTORY [=] 'clone_dir'] [REQUIRE [NO] SSL];复制代码
backup_admin は、クローン作成操作に必要な権限です。
次に、受信者インスタンスでクローン ユーザーを作成し、クローン プラグインをロードします。
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复制和基于位置点的复制。
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)复制代码
这里,同样要区分两种场景。
场景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中的信息自动建立复制,很多时候,这未必是我们的预期行为。
克隆操作可细分为以下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()销毁克隆对象。
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端口。
除此之外,在进行远程克隆时,还会进行如下检查:
ERROR 3864 (HY000): Clone Donor MySQL version: 8.0.20 is different from Recipient MySQL version 8.0.19.复制代码
ERROR 3634 (HY000): Too many concurrent clone operations. Maximum allowed - 1.复制代码
ERROR 3707 (HY000): Restart server failed (mysqld is not managed by supervisor process).复制代码
1、在实现上,两者都有FILE COPY和REDO COPY阶段,但Clone Plugin比XtraBackup多了一个PAGE COPY,由此带来的好处是,Clone Plugin的恢复速度比XtraBackup更快。
2、XtraBackup没有Redo Archiving特性,有可能出现未拷贝的Redo日志被覆盖的情况。
3、GTID下建立复制,无需额外执行set global gtid_purged操作。
需要注意的是,如果在执行DDL时,有CLONE命令在执行,DDL同样会因获取不到备份锁被阻塞,只不过,DDL操作的等待时长由lock_wait_timeout参数决定,该参数的默认值为31536000s,即365天。
関連する無料学習の推奨事項: mysql ビデオ チュートリアル
以上がMySQL 8 Clone Plugin の新機能を見てみましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。