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

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

之前我们重点建设了数据克隆的一个服务，其实起这个名字也琢磨了好久，说逻辑备份恢复很多业务同学都不大能理解，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

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。