MySQL8 中文参考(二十二)(2)https://developer.aliyun.com/article/1566118
克隆远程数据
以下示例演示了克隆远程数据的过程。默认情况下,远程克隆操作会在接收方上删除用户创建的数据(模式、表、表空间)和二进制日志,将新数据克隆到接收方数据目录,并在之后重新启动 MySQL 服务器。
本示例假定远程克隆的先决条件已满足。请参阅远程克隆先决条件。
- 使用管理员用户帐户登录到捐赠方 MySQL 服务器实例。
- 创建一个具有
BACKUP_ADMIN
权限的克隆用户。
mysql> CREATE USER 'donor_clone_user'@'example.donor.host.com' IDENTIFIED BY '*password*'; mysql> GRANT BACKUP_ADMIN on *.* to 'donor_clone_user'@'example.donor.host.com';
- 安装克隆插件:
mysql> INSTALL PLUGIN clone SONAME 'mysql_clone.so';
- 使用管理员用户帐户登录到接收方 MySQL 服务器实例。
- 创建一个具有
CLONE_ADMIN
权限的克隆用户。
mysql> CREATE USER 'recipient_clone_user'@'example.recipient.host.com' IDENTIFIED BY '*password*'; mysql> GRANT CLONE_ADMIN on *.* to 'recipient_clone_user'@'example.recipient.host.com';
- 安装克隆插件:
mysql> INSTALL PLUGIN clone SONAME 'mysql_clone.so';
- 将捐赠方 MySQL 服务器实例的主机地址添加到
clone_valid_donor_list
变量设置中。
mysql> SET GLOBAL clone_valid_donor_list = '*example.donor.host.com*:*3306*';
- 以前创建的克隆用户(
recipient_clone_user'@'example.recipient.host.com
)登录到接收方 MySQL 服务器实例,并执行CLONE INSTANCE
语句。
mysql> CLONE INSTANCE FROM 'donor_clone_user'@'example.donor.host.com':3306 IDENTIFIED BY '*password*';
- 数据克隆完成后,接收方 MySQL 服务器实例将自动重新启动。
有关监视克隆操作状态和进度的信息,请参见 Section 7.6.7.10, “监视克隆操作”。
克隆到指定目录
默认情况下,远程克隆操作会在克隆数据之前从接收方数据目录中删除用户创建的数据(模式、表、表空间)和二进制日志。通过克隆到指定目录,您可以避免从当前接收方数据目录中删除数据。
克隆到指定目录的过程与克隆远程数据中描述的过程相同,唯一的例外是:CLONE INSTANCE
语句必须包含DATA DIRECTORY
子句。例如:
mysql> CLONE INSTANCE FROM '*user*'@'*example.donor.host.com*':*3306* IDENTIFIED BY '*password*' DATA DIRECTORY = '*/path/to/clone_dir*';
需要绝对路径,并且目录不能存在。MySQL 服务器必须具有必要的写访问权限以创建目录。
在克隆到命名目录时,接收方 MySQL 服务器实例在克隆数据后不会自动重新启动。如果要在命名目录上重新启动 MySQL 服务器,则必须手动执行:
$> mysqld_safe --datadir=*/path/to/clone_dir*
其中*/path/to/clone_dir
*是接收方命名目录的路径。
为克隆配置加密连接
您可以配置远程克隆操作的加密连接,以保护在网络上传输时克隆的数据。默认情况下,当克隆加密数据时需要加密连接。(参见第 7.6.7.5 节,“克隆加密数据”。)
接下来的说明描述了如何配置接收方 MySQL 服务器实例以使用加密连接。假定捐赠方 MySQL 服务器实例已配置为使用加密连接。如果没有,请参考第 8.3.1 节,“配置 MySQL 使用加密连接”进行服务器端配置说明。
要配置接收方 MySQL 服务器实例以使用加密连接:
- 使捐赠方 MySQL 服务器实例的客户端证书和密钥文件可供接收方主机使用。可以通过安全通道将文件分发到接收方主机,或将它们放在对接收方主机可访问的挂载分区上。要提供的客户端证书和密钥文件包括:
ca.pem
自签名证书颁发机构(CA)文件。client-cert.pem
客户端公钥证书文件。client-key.pem
客户端私钥文件。
- 在接收方 MySQL 服务器实例上配置以下 SSL 选项。
clone_ssl_ca
指定自签名证书颁发机构(CA)文件的路径。clone_ssl_cert
指定客户端公钥证书文件的路径。clone_ssl_key
指定客户端私钥文件的路径。
- 例如:
clone_ssl_ca=/*path*/*to*/ca.pem clone_ssl_cert=/*path*/*to*/client-cert.pem clone_ssl_key=/*path*/*to*/client-key.pem
- 要求使用加密连接,请在接收方发出
CLONE
语句时包含REQUIRE SSL
子句。
mysql> CLONE INSTANCE FROM '*user*'@'*example.donor.host.com*':*3306* IDENTIFIED BY '*password*' DATA DIRECTORY = '*/path/to/clone_dir*' REQUIRE SSL;
- 如果未指定 SSL 子句,则克隆插件默认尝试建立加密连接,如果加密连接尝试失败,则回退到非加密连接。
注意
如果您正在克隆加密数据,则默认情况下需要加密连接,无论是否指定了REQUIRE SSL
子句。使用REQUIRE NO SSL
会在尝试克隆加密数据时导致错误。
译文:
dev.mysql.com/doc/refman/8.0/en/clone-plugin-concurrent-ddl.html
7.6.7.4 克隆和并发 DDL
在 MySQL 8.0.27 之前,在克隆操作期间,包括TRUNCATE TABLE
在内的捐赠者和接收者 MySQL 服务器实例上的 DDL 操作是不允许的。在选择数据源时应考虑此限制。一种解决方法是使用专用的捐赠者实例,可以在克隆数据时阻止 DDL 操作。
为防止在克隆操作期间进行并发 DDL,捐赠者和接收者上会获取独占的备份锁。clone_ddl_timeout
变量定义了在捐赠者和接收者上,克隆操作等待备份锁的时间(以秒为单位)。默认设置为 300 秒。如果在指定的时间限制内未获得备份锁,则克隆操作将因错误而失败。
从 MySQL 8.0.27 开始,默认情况下允许在捐赠者上进行并发 DDL。捐赠者上的并发 DDL 支持由clone_block_ddl
变量控制。可以使用SET
语句动态启用和禁用捐赠者上的并发 DDL 支持。
SET GLOBAL clone_block_ddl={OFF|ON}
默认设置为clone_block_ddl=OFF
,允许在捐赠者上进行并发 DDL。
并发 DDL 操作的效果是否被克隆取决于 DDL 操作是否在克隆操作获取动态快照之前完成。
不允许在克隆操作期间进行的 DDL 操作,无论clone_block_ddl
设置如何,包括:
ALTER TABLE *
tbl_name* DISCARD TABLESPACE;
ALTER TABLE *
tbl_name* IMPORT TABLESPACE;
ALTER INSTANCE DISABLE INNODB REDO_LOG;
原文:
dev.mysql.com/doc/refman/8.0/en/clone-plugin-encrypted-data.html
7.6.7.5 克隆加密数据
支持对加密数据进行克隆。以下要求适用:
- 在将远程数据克隆时,需要安全连接以确保未加密表空间密钥在网络上传输时的安全性。表空间密钥在捐赠者处解密后传输,并在接收者处使用接收者主密钥重新加密。如果没有加密连接可用或在
CLONE INSTANCE
语句中使用REQUIRE NO SSL
子句,则会报告错误。有关为克隆配置加密连接的信息,请参见 为克隆配置加密连接。 - 当将数据克隆到使用本地管理的密钥环的本地数据目录时,启动克隆目录上的 MySQL 服务器时必须使用相同的密钥环。
- 当将数据克隆到使用本地管理的密钥环的远程数据目录(接收者目录)时,启动克隆目录上的 MySQL 服务器时必须使用接收者密钥环。
注意
innodb_redo_log_encrypt
和 innodb_undo_log_encrypt
变量设置在克隆操作进行时无法修改。
有关数据加密功能的信息,请参见 第 17.13 节,“InnoDB 数据静态加密”。
原文:
dev.mysql.com/doc/refman/8.0/en/clone-plugin-compressed-data.html
7.6.7.6 克隆压缩数据
支持对页面压缩数据进行克隆。在克隆远程数据时,需要满足以下要求:
- 接收方文件系统必须支持稀疏文件和空洞打孔,以便在接收方上进行空洞打孔。
- 捐赠方和接收方文件系统必须具有相同的块大小。如果文件系统块大小不同,则会报告类似以下错误:ERROR 3868 (HY000): Clone Configuration FS Block Size: Donor value: 114688 is different from Recipient value: 4096.
关于页面压缩功能的信息,请参见第 17.9.2 节,“InnoDB 页面压缩”。
原文:
dev.mysql.com/doc/refman/8.0/en/clone-plugin-replication.html
7.6.7.7 复制用的克隆
克隆插件支持复制。除了克隆数据外,克隆操作还会从捐赠者提取复制坐标并将其传输给接收者,这使得可以使用克隆插件为配置组复制成员和副本提供服务。使用克隆插件进行配置比复制大量事务要快得多且更有效率。
配置组复制成员也可以配置为使用克隆插件作为分布式恢复的选项,这样加入成员会自动选择从现有组成员检索组数据的最有效方式。有关更多信息,请参见 Section 20.5.4.2, “Cloning for Distributed Recovery”。
在克隆操作期间,二进制日志位置(文件名、偏移量)和gtid_executed
GTID 集都会从捐赠者的 MySQL 服务器实例中提取并传输到接收者。这些数据允许在复制流中的一致位置启动复制。二进制日志和中继日志(保存在文件中)不会从捐赠者复制到接收者。为了启动复制,接收者需要的二进制日志必须在数据克隆和启动复制之间不被清除。如果所需的二进制日志不可用,则会报告复制握手错误。因此,克隆实例应尽快添加到复制组中,以避免所需的二进制日志被清除或新成员明显滞后,需要更多的恢复时间。
- 在克隆的 MySQL 服务器实例上执行此查询,以检查已传输给接收者的二进制日志位置:
mysql> SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status;
- 在克隆的 MySQL 服务器实例上执行此查询,以检查已传输给接收者的
gtid_executed
GTID 集:
mysql> SELECT @@GLOBAL.GTID_EXECUTED;
在 MySQL 8.0 中,默认情况下,复制元数据存储库保存在在克隆操作期间从捐赠者复制到接收者的表中。复制元数据存储库保存了可以在克隆操作后正确恢复复制的与复制相关的配置设置。
- 在 MySQL 8.0.17 和 8.0.18 中,只会复制表
mysql.slave_master_info
(连接元数据存储库)。 - 从 MySQL 8.0.19 开始,表
mysql.slave_relay_log_info
(应用程序元数据存储库)和mysql.slave_worker_info
(应用程序工作程序元数据存储库)也会被复制。
要查看每个表中包含的内容列表,请参阅 Section 19.2.4.2, “Replication Metadata Repositories”。请注意,如果服务器上使用了设置 master_info_repository=FILE
和 relay_log_info_repository=FILE
(这在 MySQL 8.0 中不是默认设置且已被弃用),则不会克隆复制元数据存储库;只有在设置为 TABLE
时才会克隆。
要进行复制克隆,请执行以下步骤:
- 对于 Group Replication 的新成员,首先按照 Section 20.2.1.6, “Adding Instances to the Group” 中的说明配置 MySQL Server 实例以进行 Group Replication。同时,设置克隆的先决条件,详见 Section 20.5.4.2, “Cloning for Distributed Recovery”。当在加入成员上发出
START GROUP_REPLICATION
命令时,克隆操作将由 Group Replication 自动管理,因此您无需手动执行操作,也无需在加入成员上执行任何进一步的设置步骤。 - 对于源/复制 MySQL 复制拓扑中的副本,首先手动将数据从捐赠方 MySQL 服务器实例克隆到接收方。捐赠方必须是复制拓扑中的源或副本。有关克隆说明,请参阅 Section 7.6.7.3, “Cloning Remote Data”。
- 克隆操作成功完成后,如果您希望在接收方 MySQL 服务器实例上使用与捐赠方相同的复制通道,请验证哪些通道可以在源/复制 MySQL 复制拓扑中自动恢复复制,哪些需要手动设置。
- 对于基于 GTID 的复制,如果接收方配置为
gtid_mode=ON
并且从配置为gtid_mode=ON
、ON_PERMISSIVE
或OFF_PERMISSIVE
的捐赠方克隆,那么从捐赠方应用gtid_executed
GTID 集到接收方。如果接收方是从已在拓扑中的副本克隆而来,那么在克隆操作后,使用 GTID 自动定位的复制通道可以在启动通道后自动恢复复制。如果您只想使用这些相同通道,则无需执行任何手动设置。 - 对于基于二进制日志文件位置的复制,如果接收端是 MySQL 8.0.17 或 8.0.18,则从提供端的二进制日志位置不会应用到接收端,只会记录在性能模式
clone_status
表中。因此,接收端上使用基于二进制日志文件位置的复制通道必须手动设置以在克隆操作后恢复复制。确保这些通道未配置为在服务器启动时自动开始复制,因为它们尚未具有二进制日志位置,并尝试从头开始复制。 - 对于基于二进制日志文件位置的复制,如果接收端是 MySQL 8.0.19 或更高版本,则从提供端应用二进制日志位置到接收端。接收端上使用基于二进制日志文件位置的复制通道会自动尝试执行中继日志恢复过程,使用克隆的中继日志信息,在重新启动复制之前。对于单线程副本(
replica_parallel_workers
或slave_parallel_workers
设置为 0),在没有其他问题的情况下,中继日志恢复应该成功,使通道能够在没有进一步设置的情况下恢复复制。对于多线程副本(replica_parallel_workers
或slave_parallel_workers
大于 0),中继日志恢复可能会失败,因为通常无法自动完成。在这种情况下,会发出错误消息,您必须手动设置通道。
- 如果您需要手动设置克隆复制通道,或者希望在接收端使用不同的复制通道,以下说明提供了一个摘要和简化示例,用于将接收端 MySQL 服务器实例添加到复制拓扑中。还请参考适用于您的复制设置的详细说明。
- 要将一个接收方 MySQL 服务器实例添加到使用基于 GTID 的事务作为复制数据源的 MySQL 复制拓扑中,请根据需要配置实例,并按照 Section 19.1.3.4,“使用 GTID 设置复制”中的说明操作。按照以下简化示例为实例添加复制通道。
CHANGE REPLICATION SOURCE TO
语句(从 MySQL 8.0.23 开始)或CHANGE MASTER TO
语句(在 MySQL 8.0.23 之前)必须定义源的主机地址和端口号,并且应启用SOURCE_AUTO_POSITION
|MASTER_AUTO_POSITION
选项,如下所示:
mysql> CHANGE MASTER TO MASTER_HOST = '*source_host_name*', MASTER_PORT = *source_port_num*, ... MASTER_AUTO_POSITION = 1, FOR CHANNEL '*setup_channel*'; mysql> START SLAVE USER = '*user_name*' PASSWORD = '*password*' FOR CHANNEL '*setup_channel*'; Or from MySQL 8.0.22 and 8.0.23: mysql> CHANGE SOURCE TO SOURCE_HOST = '*source_host_name*', SOURCE_PORT = *source_port_num*, ... SOURCE_AUTO_POSITION = 1, FOR CHANNEL '*setup_channel*'; mysql> START REPLICA USER = '*user_name*' PASSWORD = '*password*' FOR CHANNEL '*setup_channel*';
- 要将一个接收方 MySQL 服务器实例添加到使用基于二进制日志文件位置的复制的 MySQL 复制拓扑中,请根据需要配置实例,并按照 Section 19.1.2,“设置基于二进制日志文件位置的复制”中的说明操作。按照以下简化示例为实例添加复制通道,使用在克隆操作期间传输给接收方的二进制日志位置:
mysql> SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status; mysql> CHANGE MASTER TO MASTER_HOST = '*source_host_name*', MASTER_PORT = *source_port_num*, ... MASTER_LOG_FILE = '*source_log_name*', MASTER_LOG_POS = *source_log_pos*, FOR CHANNEL '*setup_channel*'; mysql> START SLAVE USER = '*user_name*' PASSWORD = '*password*' FOR CHANNEL '*setup_channel*'; Or from MySQL 8.0.22 and 8.0.23: mysql> SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status; mysql> CHANGE SOURCE TO SOURCE_HOST = '*source_host_name*', SOURCE_PORT = *source_port_num*, ... SOURCE_LOG_FILE = '*source_log_name*', SOURCE_LOG_POS = *source_log_pos*, FOR CHANNEL '*setup_channel*'; mysql> START REPLICA USER = '*user_name*' PASSWORD = '*password*' FOR CHANNEL '*setup_channel*';
原文:
dev.mysql.com/doc/refman/8.0/en/clone-plugin-directories.html
7.6.7.8 克隆操作期间创建的目录和文件
当数据被克隆时,以下目录和文件会被创建用于内部使用。不应该被修改。
#clone
:包含克隆操作使用的内部克隆文件。在数据被克隆到的目录中创建。#ib_archive
:包含在克隆操作期间在捐赠者上归档的内部归档日志文件。*.#clone
文件:在接收端创建的临时数据文件,当数据从接收端数据目录中移除并在远程克隆操作期间克隆新数据时创建。
原文:
dev.mysql.com/doc/refman/8.0/en/clone-plugin-failure-handling.html
7.6.7.9 远程克隆操作失败处理
本节描述了克隆操作在不同阶段的失败处理。
- 先决条件被检查(参见远程克隆先决条件)。
- 如果在先决条件检查期间发生故障,则
CLONE INSTANCE
操作会报告错误。
- 在 MySQL 8.0.27 之前,在提供方和接收方上备份锁会阻止并发的 DDL 操作。从 MySQL 8.0.27 开始,仅当
clone_block_ddl
变量设置为ON
时(默认设置为OFF
)才会阻止提供方上的并发 DDL。参见 Section 7.6.7.4, “Cloning and Concurrent DDL”。
- 如果克隆操作无法在
clone_ddl_timeout
变量指定的时间限制内获得 DDL 锁,则会报告错误。
- 用户创建的数据(模式、表、表空间)和接收方上的二进制日志在将数据克隆到接收方数据目录之前被移除。
- 在远程克隆操作期间从接收方数据目录中移除用户创建的数据和二进制日志时,数据不会被保存,如果发生故障可能会丢失。如果数据很重要,应在启动远程克隆操作之前进行备份。
为了信息目的,警告会被打印到服务器错误日志中,以指定数据移除何时开始和结束:
[Warning] [MY-013453] [InnoDB] Clone removing all user data for provisioning: Started... [Warning] [MY-013453] [InnoDB] Clone removing all user data for provisioning: Finished
- 如果在移除数据时发生故障,接收方可能会留下部分在克隆操作之前存在的模式、表和表空间。在执行克隆操作期间或发生故障后的任何时候,服务器始终处于一致状态。
- 数据从提供方克隆。用户创建的数据、字典元数据和其他系统数据都会被克隆。
- 如果在克隆数据时发生故障,克隆操作将被回滚并移除所有克隆数据。在此阶段,接收方上先前存在的用户创建的数据和二进制日志也已被移除。
如果发生这种情况,您可以纠正故障原因并重新执行克隆操作,或放弃克隆操作并从在克隆操作之前进行的备份中恢复接收方数据。
- 服务器会自动重启(适用于不克隆到命名目录的远程克隆操作)。在启动过程中,会执行典型的服务器启动任务。
- 如果自动服务器重启失败,您可以手动重启服务器以完成克隆操作。
在 MySQL 8.0.24 之前,如果在克隆操作期间发生网络错误,且在五分钟内解决了错误,则操作会恢复。从 MySQL 8.0.24 开始,如果在捐赠实例上定义的clone_donor_timeout_after_network_failure
变量指定的时间内解决了错误,则操作会恢复。clone_donor_timeout_after_network_failure
的默认设置为 5 分钟,但支持 0 到 30 分钟的范围。如果操作未在分配的时间内恢复,则会中止并返回错误,捐赠者会删除快照。将设置为零会导致在发生网络错误时捐赠者立即删除快照。配置更长的超时时间允许更多时间解决网络问题,但也会增加捐赠实例上的增量大小,从而增加克隆恢复时间以及在克隆旨在作为副本或复制组成员时的复制延迟。
在 MySQL 8.0.24 之前,捐赠者线程在监听克隆协议命令时使用 MySQL Server wait_timeout
设置。因此,低wait_timeout
设置可能导致长时间运行的远程克隆操作超时。从 MySQL 8.0.24 开始,克隆空闲超时设置为默认的wait_timeout
设置,即 28800 秒(8 小时)。
原文:
dev.mysql.com/doc/refman/8.0/en/clone-plugin-monitoring.html
7.6.7.10 监控克隆操作
本节描述了监控克隆操作的选项。
- 使用性能模式克隆表监控克隆操作
- 使用性能模式阶段事件监控克隆操作
- 使用性能模式克隆工具监控克隆操作
- Com_clone 状态变量
使用性能模式克隆表监控克隆操作
克隆操作可能需要一些时间才能完成,这取决于数据量和与数据传输相关的其他因素。您可以使用clone_status
和 clone_progress
性能模式表在接收 MySQL 服务器实例上监视克隆操作的状态和进度。
注意
clone_status
和 clone_progress
性能模式表仅可用于监视接收 MySQL 服务器实例上的克隆操作。要监视捐赠 MySQL 服务器实例上的克隆操作,请使用克隆阶段事件,如使用性能模式阶段事件监控克隆操作中所述。
clone_status
表提供当前或最近执行的克隆操作的状态。克隆操作有四种可能的状态:未开始
、进行中
、已完成
和失败
。clone_progress
表提供当前或最近执行的克隆操作的进度信息,按阶段划分。克隆操作的阶段包括DROP DATA
、FILE COPY
、PAGE_COPY
、REDO_COPY
、FILE_SYNC
、RESTART
和RECOVERY
。
访问性能模式克隆表需要在性能模式上具有SELECT
和EXECUTE
权限。
要检查克隆操作的状态:
- 连接到接收方 MySQL 服务器实例。
- 查询
clone_status
表:
mysql> SELECT STATE FROM performance_schema.clone_status; +-----------+ | STATE | +-----------+ | Completed | +-----------+
如果在克隆操作期间发生故障,您可以查询clone_status
表以获取错误信息:
mysql> SELECT STATE, ERROR_NO, ERROR_MESSAGE FROM performance_schema.clone_status; +-----------+----------+---------------+ | STATE | ERROR_NO | ERROR_MESSAGE | +-----------+----------+---------------+ | Failed | xxx | "xxxxxxxxxxx" | +-----------+----------+---------------+
要查看克隆操作的每个阶段的详细信息:
- 连接到接收方 MySQL 服务器实例。
- 查询
clone_progress
表。例如,以下查询提供了克隆操作每个阶段的状态和结束时间数据:
mysql> SELECT STAGE, STATE, END_TIME FROM performance_schema.clone_progress; +-----------+-----------+----------------------------+ | stage | state | end_time | +-----------+-----------+----------------------------+ | DROP DATA | Completed | 2019-01-27 22:45:43.141261 | | FILE COPY | Completed | 2019-01-27 22:45:44.457572 | | PAGE COPY | Completed | 2019-01-27 22:45:44.577330 | | REDO COPY | Completed | 2019-01-27 22:45:44.679570 | | FILE SYNC | Completed | 2019-01-27 22:45:44.918547 | | RESTART | Completed | 2019-01-27 22:45:48.583565 | | RECOVERY | Completed | 2019-01-27 22:45:49.626595 | +-----------+-----------+----------------------------+
- 要监视其他克隆状态和进度数据点,请参考第 29.12.19 节,“性能模式克隆表”。
使用性能模式阶段事件监视克隆操作
克隆操作可能需要一些时间才能完成,这取决于数据量和与数据传输相关的其他因素。有三个阶段事件用于监视克隆操作的进度。每个阶段事件报告 WORK_COMPLETED
和 WORK_ESTIMATED
值。随着操作的进行,报告的值会进行修订。
可以在捐赠方或接收方 MySQL 服务器实例上使用此方法监视克隆操作。
按发生顺序,克隆操作阶段事件包括:
stage/innodb/clone (file copy)
: 表示克隆操作的文件复制阶段的进度。WORK_ESTIMATED
和WORK_COMPLETED
单位为文件块。在文件复制阶段开始时,就已知要传输的文件数量,并且根据文件数量估算出块的数量。WORK_ESTIMATED
设置为估计文件块的数量。每发送一个块后,WORK_COMPLETED
都会更新。stage/innodb/clone (page copy)
: 表示克隆操作的页面复制阶段的进度。WORK_ESTIMATED
和WORK_COMPLETED
单位为页面。一旦文件复制阶段完成,就会知道要传输的页面数量,并且将WORK_ESTIMATED
设置为此值。每发送一个页面后,WORK_COMPLETED
都会更新。stage/innodb/clone (redo copy)
: 表示克隆操作的重做复制阶段的进度。WORK_ESTIMATED
和WORK_COMPLETED
单位为重做块。一旦页面复制阶段完成,就会知道要传输的重做块数量,并且WORK_ESTIMATED
设置为此值。每发送一个块后,WORK_COMPLETED
都会更新。
以下示例演示了如何启用stage/innodb/clone%
事件仪器和相关的消费者表来监视克隆操作。有关性能模式阶段事件仪器和相关消费者的信息,请参见第 29.12.5 节,“性能模式阶段事件表”。
- 启用
stage/innodb/clone%
仪器:
mysql> UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'stage/innodb/clone%';
- 启用阶段事件消费者表,包括
events_stages_current
、events_stages_history
和events_stages_history_long
。
mysql> UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%stages%';
- 运行克隆操作。在此示例中,将本地数据目录克隆到名为
cloned_dir
的目录。
mysql> CLONE LOCAL DATA DIRECTORY = '/path/to/cloned_dir';
- 通过查询性能模式
events_stages_current
表来检查克隆操作的进度。显示的阶段事件取决于正在进行的克隆阶段。WORK_COMPLETED
列显示已完成的工作。WORK_ESTIMATED
列显示总共需要的工作量。
mysql> SELECT EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED FROM performance_schema.events_stages_current WHERE EVENT_NAME LIKE 'stage/innodb/clone%'; +--------------------------------+----------------+----------------+ | EVENT_NAME | WORK_COMPLETED | WORK_ESTIMATED | +--------------------------------+----------------+----------------+ | stage/innodb/clone (redo copy) | 1 | 1 | +--------------------------------+----------------+----------------+
- 如果克隆操作已经完成,
events_stages_current
表将返回一个空集。在这种情况下,您可以检查events_stages_history
表以查看已完成操作的事件数据。例如:
mysql> SELECT EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED FROM events_stages_history WHERE EVENT_NAME LIKE 'stage/innodb/clone%'; +--------------------------------+----------------+----------------+ | EVENT_NAME | WORK_COMPLETED | WORK_ESTIMATED | +--------------------------------+----------------+----------------+ | stage/innodb/clone (file copy) | 301 | 301 | | stage/innodb/clone (page copy) | 0 | 0 | | stage/innodb/clone (redo copy) | 1 | 1 | +--------------------------------+----------------+----------------+
使用性能模式克隆仪器监视克隆操作
性能模式提供了用于高级性能监控克隆操作的仪器。要查看可用的克隆仪器,并发出以下查询:
mysql> SELECT NAME,ENABLED FROM performance_schema.setup_instruments WHERE NAME LIKE '%clone%'; +---------------------------------------------------+---------+ | NAME | ENABLED | +---------------------------------------------------+---------+ | wait/synch/mutex/innodb/clone_snapshot_mutex | NO | | wait/synch/mutex/innodb/clone_sys_mutex | NO | | wait/synch/mutex/innodb/clone_task_mutex | NO | | wait/synch/mutex/group_rpl/LOCK_clone_donor_list | NO | | wait/synch/mutex/group_rpl/LOCK_clone_handler_run | NO | | wait/synch/mutex/group_rpl/LOCK_clone_query | NO | | wait/synch/mutex/group_rpl/LOCK_clone_read_mode | NO | | wait/synch/cond/group_rpl/COND_clone_handler_run | NO | | wait/io/file/innodb/innodb_clone_file | YES | | stage/innodb/clone (file copy) | YES | | stage/innodb/clone (redo copy) | YES | | stage/innodb/clone (page copy) | YES | | statement/abstract/clone | YES | | statement/clone/local | YES | | statement/clone/client | YES | | statement/clone/server | YES | | memory/innodb/clone | YES | | memory/clone/data | YES | +---------------------------------------------------+---------+
MySQL8 中文参考(二十二)(4)https://developer.aliyun.com/article/1566120