MySQL 8.0+ 物理克隆（Clone Plugin）主从架构部署指南

MySQL 8.0+ 物理克隆（Clone Plugin）主从架构部署指南

作者 在 未分类

这份教程整合了前面的所有步骤与注意事项，是专为 MySQL 8.0+ 生产环境设计的 物理克隆 (Clone Plugin) 主从搭建完整指南。

架构说明与风险提示

  • 适用场景：主库数据量较大（如数百至数千万条记录），需要快速部署一台全新的从库 [1.3.1]。
  • 实现原理：从库直接通过网络将主库的数据文件物理拉取并覆写，避开了解析 SQL 脚本的开销，速度极快 [1.3.1]。
  • 数据安全警告：克隆操作会完全清空并覆盖从库现有的全部数据和账号配置。务必在全新的、无业务数据的服务器上进行操作！
  • 密码提醒：克隆完成后，从库的 root 密码及所有用户权限将完全与主库同步，不再保留从库原密码。

第一阶段：环境与参数统一

MySQL Clone 插件对系统运行环境要求极高。在执行克隆前，必须确保主从库的核心参数完全匹配，否则克隆任务会直接终止并报错 [1.3.1]。

1. 查询主库环境参数

登录主库（Donor），记录以下关键配置：

SELECT @@global.character_set_server, @@global.collation_server, @@global.lower_case_table_names;

2. 修改从库配置文件

打开从库（Recipient）的配置文件 /etc/my.cnf（或 /etc/mysql/my.cnf），按主库查询到的参数进行修改，并补充复制配置：

[mysqld]
# 核心标识（必须唯一）
server-id = 2                       # 务必保证与主库不同

# 高可用与复制配置
gtid_mode = ON                      # 开启 GTID 功能
enforce_gtid_consistency = ON       # 强制 GTID 一致性

# 字符集与大小写规范（必须与主库完全一致）
character-set-server = utf8mb4      # 替换为你主库实际查到的值
collation-server = utf8mb4_0900_ai_ci
lower_case_table_names = 1         # 必须与主库保持完全一致

3. 重启从库生效

systemctl restart mysqld

第二阶段：主库配置与权限准备

需要在主库上创建两个用户：一个用于物理数据克隆，另一个用于日后的增量日志同步。

1. 登录主库

mysql -u root -p

2. 创建克隆授权用户

-- 替换 '从库IP' 为真实的从库服务器 IP
CREATE USER 'clone_user'@'从库IP' IDENTIFIED BY 'ClonePass123!';
GRANT BACKUP_ADMIN ON *.* TO 'clone_user'@'从库IP';

3. 创建主从复制账号

CREATE USER 'repl_user'@'%' IDENTIFIED BY 'ReplPass123!';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
FLUSH PRIVILEGES;

4. 主库加载 Clone 插件

INSTALL PLUGIN clone SONAME 'mysql_clone.so';

第三阶段：从库执行物理克隆

1. 登录从库

mysql -u root -p

2. 从库加载插件并设置许可白名单

INSTALL PLUGIN clone SONAME 'mysql_clone.so';

-- 声明允许向当前从库传输数据的 Donor 列表
SET GLOBAL clone_valid_donor_list = '主库IP:3306';

3. 启动物理克隆

-- 执行此命令后，从库的数据目录将被覆盖，完成后从库 MySQL 服务会自动重启
CLONE INSTANCE FROM 'clone_user'@'主库IP':3306 IDENTIFIED BY 'ClonePass123!';

进程监控与报错排查：克隆执行过程中，如果终端出现报错终止，可查阅从库的错误日志 /var/log/mysqld.log 获取具体失败的配置项（如某些参数不兼容）。

第四阶段：重置从库身份（关键步骤）

物理克隆会连同主库的系统配置一并拉取过来，这将导致从库的 server-id 和 server-uuid 与主库相同。如果不消除冲突，后续主从链路将无法正常连通。

  1. 停止从库服务: 在从库系统的 Shell 终端中运行：
systemctl stop mysqld
  1. 重置系统的 server-uuid: 删除物理数据目录下的 auto.cnf 文件。再次启动 MySQL 时，系统会自动为你生成一个全新的、唯一的 UUID。
# 假设你的数据目录在 /var/lib/mysql
rm -f /var/lib/mysql/auto.cnf
  1. 校验 /etc/my.cnf 中的 server-id: 重新检查配置文件，确保其设置依然生效：
server-id = 2  # 再次确认未被改写，且不同于主库
  1. 启动从库服务: 
    
systemctl start mysqld

---

## 第五阶段：配置并启动增量同步

此时，从库的数据快照已与克隆完成时刻的主库保持完全一致，且拥有独立节点身份。接下来需要建立链路，接收主库后续产生的所有改动（Binlog）[1.3.1]。

### 1. 登录从库

> **特别提醒**：此时必须使用**主库的 root 密码**登录从库。

```sql
mysql -u root -p

2. 配置主从复制源

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='主库IP',
  SOURCE_PORT=3306,
  SOURCE_USER='repl_user',
  SOURCE_PASSWORD='ReplPass123!',
  SOURCE_AUTO_POSITION = 1; -- 启用 GTID 自动定位

3. 启动复制线程

START REPLICA;

4. 检查主从同步状态

SHOW REPLICA STATUS\G

重点关注以下三个返回值，确保链路健康：

  • Replica_IO_Running: Yes（成功连上主库并读取 Binlog）
  • Replica_SQL_Running: Yes（成功在本地应用增量日志）
  • Seconds_Behind_Master: 0（数值为 0 说明增量同步已经完全追平主库）

运维安全与善后建议

  1. 修改从库本地管理密码：如果不希望从库保持和主库一样的 root 密码，可在同步正常后在从库执行： 
    
ALTER USER 'root'@'localhost' IDENTIFIED BY 'SlaveNewPassword!';

2. **主库回收临时克隆权限**：克隆完成后，出于安全考虑可将主库上的临时克隆账号清理或撤销权限：
```sql
DROP USER 'clone_user'@'从库IP';

发表评论