之前我们重点建设了数据克隆的一个服务，其实起这个名字也琢磨了好久，说逻辑备份恢复很多业务同学都不大能理解，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
本文转载自微信公众号「杨建荣的学习笔记」，可以通过以下二维码关注。转载本文请联系杨建荣的学习笔记公众号。
