当前位置: 首页 > 手机学院 > 手机资讯 >正文

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

来源:互联网时间:2021-02-26 10:04:36编辑:网友分享
之前我们重点建设了数据克隆的一个服务,其实起这个名字也琢磨了好久,说逻辑备份恢复很多业务同学都不大能理解,GET到我们要解决的问题,而数据克隆的

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

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

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

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

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

【编辑推荐】

  1. 小心这个把我坑惨的MySQL双引号!
  2. 实现 MySQL 读写分离的利器 mysql-proxy
  3. 2020年MySQL5.7系列实战课程--备份恢复篇
  4. MySQL字段默认值设置详解
  5. MySQL锁 深入理解Mysql锁与事务隔离级别

上一篇: 阿里面试题:线上接口变慢,如何排查

下一篇:很抱歉没有了

您可能感兴趣的文章

相关阅读