MySQL数据实时克隆的初步设计

这是学习笔记的第 2327篇文章

之前我们重点建设了数据克隆的一个服务，其实起这个名字也琢磨了好久，说逻辑备份恢复很多业务同学都不大能理解，GET到我们要解决的问题，而数据克隆的概念就比较清晰。

先来说说我们对数据克隆的定义

1）数据克隆快速从线上导出指定库/表数据，并构建虚拟环境，从而来提供高效的数据服务；

2）功能方面实现了业务自助提取数据，分钟级构建环境，可以通过workbench等工具访问数据，无需DBA介入；

3）安全方面支持数据库操作日志审计，已接入ES审计，并提供了库/表访问过滤，虚拟环境随机分配，临时密码交付，同时限定了虚拟环境的使用时长。

适用场景：

1）线上配置数据的快速查看；

2）提取线上表结构；

3）日志数据查询，线上大表；

4）线上SQL异常，快速构建虚拟环境进行SQL优化，压测等；

5）指定大表的变更和数据操作影响评估；

6）数据补丁合并，基于业务逻辑的数据操作和数据补丁整理。

而从数据克隆的使用来看，其实能够满足一些不确定的需求，比如做一些全量的查询过滤等，但是因为是和线上环境隔离的，所以就不会同步线上的数据，在这一点上可以更进一步，那就是落地实时数据克隆，从而能够实现实时的数据同步，当然这种同步是一种多源幂等复制，打个比方，源库有10张表，我们的目标环境可能只克隆了2张表，那么在做实时复制时，就需要排除那8张表，而且同一个实例上面有多套环境，所以会自然开启多源复制模式。

如果排除一些琐碎的细节，我们可以概括为：实时克隆的核心是对于GTID_SET的管理，在设计上需要考虑如下的一些因素：

基础限定和配置

1. 同一个实例的数据库只能克隆一次

2. 数据开启GTID，实时克隆暂不支持MySQL 5.5版本

3. 数据库参数slave_exec_mode值为IDEMPOTENT

4. 设置数据库参数skip-slave-errors=1146

5. 实时克隆环境建议为只读

6. 克隆的数据库复制账号为db_clone_repl

7. 通常克隆环境的表数量小于源库环境

GTID变更流程

1. 数据逻辑备份时，需要包含GTID值，并记录到导出记录中

2. 数据逻辑恢复时，可以参考如下的步骤：

a) 如果已有数据复制通道运行

i. 暂停复制通道Channel

ii. 得到固定的GTID_SET值

iii. 追加导出的GTID至GTID_SET,并更新至GTID_PURGED

iv. 启动复制通道Channel

b) 如果没有数据复制通道运行

i. 追加导出的GTID至当前GTID_SET,并更新至GTID_PURGED

ii. 启动复制通道Channel

注：复制通道Channel的命名为db_clone_【源IP】_【源端口】

3. 每天的定时任务清理环境时，自动执行reset master操作清空GTID_SET

各大平台都可以找到我

• 微信公众号：杨建荣的学习笔记
• Github：@jeanron100
• CSDN：@jeanron100
• 知乎：@jeanron100
• 头条号：@杨建荣的学习笔记
• 网易号：@杨建荣的数据库笔记
• 大鱼号：@杨建荣的数据库笔记
• 腾讯云+社区：@杨建荣的学习笔记