利用 MySQL 克隆插件搭建主从

20天前 20.0k 0

前言:

MySQL 的 Clone 插件是一个强大的功能,首次引入于 MySQL 8.0.17 版本。简单来说,Clone Plugin 是一款物理克隆数据工具,它能够帮助我们快速、高效地克隆或复制数据库,极大地简化了数据库迁移、备份和恢复的过程,让我们在处理大量数据时更加得心应手。本篇文章我们一起来学习下如何使用克隆插件。

克隆插件介绍

克隆插件的工作原理是创建存储在 InnoDB 中的 schema、table、tablespaces 和 data dictionary metadata的物理快照。这个快照实际上是一个完整的数据目录,MySQL克隆插件可以使用这个目录来配置并恢复一个 MySQL 服务器。

使用克隆插件,用户可以执行本地克隆和远程克隆两种操作:

  • 本地克隆:将数据从启动克隆操作的 MySQL 服务器克隆到该服务器主机上的指定目录下。
  • 远程克隆:涉及到本地 MySQL 服务器(接收方)和远程 MySQL 服务器(发送方),克隆的数据通过网络从发送方传输到接收方。默认情况下,远程克隆操作会删除接收方数据目录中的现有数据,并用克隆的新数据替换。

不过克隆插件的使用也是有一定的限制的,参考官方文档,总结几点如下:

  1. DDL阻塞与兼容性:
    • 在早期版本中,克隆操作期间会阻塞源服务器(Donor)上的所有 DDL 操作,但从 MySQL 8.0.27 开始,克隆命令不再阻塞 Donor 上的 DDL 操作。
    • 克隆操作要求源和目标 MySQL 服务器版本兼容,通常不允许跨大版本克隆。直至最近更新(如MySQL 8.0.37),小版本间的克隆限制有所放宽,但仍需注意版本兼容性。
  2. 存储引擎限制:
    • 克隆操作仅支持InnoDB表,对于其他存储引擎的表,只会克隆其表结构而不会复制数据。
  3. 配置与日志不复制:
    • 克隆插件不会复制 Donor 服务器的配置参数和二进制日志(Binlog)设置,这意味着目标实例需要独立配置。
  4. 操作系统与网络限制:
    • 捐赠者和接受者必须运行在相同的操作系统上,并且在某些情况下,要求网络连接直接而不通过MySQL Router。
    • 指定的 Donor 端口不能是X Protocol端口。
  5. 字符集与排序规则:
    • 源和目标 MySQL 服务器必须具有相同的字符集和排序规则。

利用 Clone Plugin 搭建主从

下面我们来具体操作下如何利用远程克隆来搭建主从复制:

# 主从服务器安装克隆插件
mysql> INSTALL PLUGIN clone SONAME 'mysql_clone.so';

# 写入my.cnf配置文件
[mysqld]
plugin-load-add=mysql_clone.so

# 查看插件状态 确认为 ACTIVE
mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS
FROM INFORMATION_SCHEMA.PLUGINS
WHERE PLUGIN_NAME = 'clone';
+------------------------+---------------+
| PLUGIN_NAME | PLUGIN_STATUS |
+------------------------+---------------+
| clone | ACTIVE |
+------------------------+---------------+

# 从节点执行远程克隆
# 远程克隆语法:
CLONE INSTANCE FROM 'user'@'host':port
IDENTIFIED BY 'password'
[DATA DIRECTORY [=] 'clone_dir']
[REQUIRE [NO] SSL];

DATA DIRECTORY:是一个可选子句,用于在接收端指定要克隆的数据的目录。
如果不想删除接受方原数据目录中的现有数据,可以使用此选项修改数据copy的目录,必须有绝对路径,且目录必须不存在。
不指定的话,则默认克隆到接受方的数据目录下。

# 执行克隆操作,用户需要有BACKUP_ADMIN权限,建议使用管理员账号
mysql> CLONE INSTANCE FROM 'root'@'172.16.255.49':3306 IDENTIFIED BY 'xxxxxxx';
Query OK, 0 rows affected (12.40 sec)

# 克隆完成后 数据库服务会自动重启,再次进入查看克隆状态
mysql> select * from performance_schema.clone_status\G;
*************************** 1. row ***************************
ID: 1
PID: 0
STATE: Completed
BEGIN_TIME: 2024-07-03 16:41:34.473
END_TIME: 2024-07-03 16:41:56.788
SOURCE: 172.16.255.49:3306
DESTINATION: LOCAL INSTANCE
ERROR_NO: 0
ERROR_MESSAGE:
BINLOG_FILE: bin-log.000007
BINLOG_POSITION: 153538
GTID_EXECUTED: 4bab9d8c-0ea8-11ef-a209-0050569c2bf5:1-380

# 状态无误后,从库即可开启主从复制
mysql> CHANGE REPLICATION SOURCE TO SOURCE_HOST='172.16.255.49',
-> SOURCE_PORT = 3306,
-> SOURCE_USER='repl',
-> SOURCE_PASSWORD='xxxx',
-> MASTER_AUTO_POSITION = 1;
Query OK, 0 rows affected, 3 warnings (0.05 sec)

mysql> start REPLICA;
Query OK, 0 rows affected (0.02 sec)

mysql> SHOW REPLICA STATUS\G
*************************** 1. row ***************************
Replica_IO_State: Waiting for source to send event
Source_Host: 172.16.255.49
Source_User: repl
Source_Port: 3306
Connect_Retry: 60
Source_Log_File: bin-log.000007
Read_Source_Log_Pos: 154754
Relay_Log_File: relay-log.000002
Relay_Log_Pos: 414
Relay_Source_Log_File: bin-log.000007
Replica_IO_Running: Yes
Replica_SQL_Running: Yes

自己做过一遍才发现,使用克隆插件搭建主从真的方便快速很多,原来搭建主从至少需要源端备份+目标端恢复两个步骤,遇到数据库比较大的情况将非常耗时。而有了克隆插件,只需一条命令即能实现物理克隆,确实方便快速很多。

其实 MySQL 克隆插件使用场景还有很多,下面列举几种使用场景:

  1. 快速构建测试环境:在开发和测试环境中快速创建与生产环境数据一致的数据库副本,以进行功能测试、性能测试等。
  2. 灾难恢复:在数据库发生故障时,可以快速从备份或另一个健康实例克隆数据,以减少恢复时间和业务中断。
  3. 数据库迁移:在升级硬件、切换服务器时,使用克隆插件可以快速迁移数据而无需长时间的停机。
  4. 水平扩展:在数据库需要增加读取能力时,可以快速克隆数据库到新的服务器上,作为只读从库。
  5. 数据库物理备份:克隆插件可以用于构建本地或远程的热备节点,以提高数据的可用性和容错能力。

总结:

综上所述,MySQL 克隆插件适用于需要快速、高效地复制数据库的场景,尤其是在对数据一致性、速度和停机时间敏感的应用中。然而,其使用也受限于一定的条件和环境,因此在具体应用时需充分评估其适用性和局限性。

参考:

  • https://dev.mysql.com/doc/refman/8.0/en/clone-plugin.html

相关文章

【TiDB 社区智慧合集】TiDB 在核心场景的实战应用
如何理解数据库增量备份
Navicat for MySQL 17 | 实现更明智的业务决策
tidb8.1的磁盘选择,关于网络ssd,和本地ssd的选择对性能影响很大,差距60倍。
ORA-00600 internal error code, arguments [25026]
ORA-01555 caused by SQL statement below (SQL ID

发布评论