DM 分库分表 DDL “悲观协调” 模式介绍丨TiDB 工具分享
背景
TiDB 作为分库分表方案的一个 “终结者”,获得了许多用户的青睐。在切换到 TiDB 之后,用户告别了分库分表查询和运维带来的复杂度。但是在从分库分表方案切换到 TiDB 的过程中,这个复杂度转移到了数据迁移流程里。TiDB DM 工具为用户提供了分库分表合并迁移功能,在数据迁移的过程中,支持将分表 DML 事件合并迁移,并一定程度支持上游分表进行 DDL 变更。
本文以及后续文章主要介绍分库分表合并迁移时,各分表 DDL 变更的协调。DM 的分库分表 DDL 协调可配置为 “悲观协调” 和 “乐观协调”,本文主要介绍 TiDB DM 分库分表 DDL 协调的 “悲观协调” 模式。后续文章会介绍 “乐观协调” 模式。
分库分表 DDL 的问题(简略版)
本节首先以一个例子粗略介绍分库分表 DDL 对数据迁移的影响,然后就这个问题给出更加正式的定义。
假设在两个上游有两个分表 t1、t2,下游表为 t。
t1 接下来的同步事件是 INSERT (3,3),t2 接下来的同步事件是 DROP COLUMN c2。如果 DROP COLUMN c2 先被同步到下游,在同步到 INSERT (3,3) 时就会因为缺少 c2 列而报错。
因此我们要对 DDL 同步事件进行特殊处理。
分库分表合并迁移的定义
接下来我们尝试使用更正式一点的语言来描述这个问题,从而引出如何正确解决这个问题。
从用户的角度来讲,数据库的用途主要的是查询,在分库分表合并前后,查询的结果应该是相同的(不考虑 LIMIT 等算子以及不确定性查询)。也就是说,各分表查询结果的并集应当等于迁移后的查询结果。容易得到一个满足此要求的充分条件:各分表数据的并集应当等于迁移后的表数据。考虑到同步延迟的影响,也就是当前时刻下游表的数据等于各分表在过去某时刻数据的并集。
对于这个定义而言,数据迁移就是让各分表的同步时刻不断向前推进。如果在同步某事件前,下游表与各分表满足定义,那么我们将一个分表的同步事件以相同影响的方式应用到下游,就将该分表的同步时刻正确地推进了。
分库分表 DDL 的问题(正式版)
从上面的定义来看,DDL 会造成两个方面的问题。
首先是 DDL 可能会变更表结构。参照之前的例子,如果 t1、t2 都有 DROP COLUMN c2 事件,DM 先同步到了 t2 的该事件,而同步事件需要以相同影响的方式应用到下游,我们应该只将下游 t2 对应的数据 DROP COLUMN。显然下游 t1、t2 的数据共享一个表结构,无法完成这个操作。因此 t2 的该事件暂时不能被同步。
另一个问题是,部分 DDL 即使不影响表结构,也会产生对数据产生影响。例如 ALTER TABLE DROP COLUMN c, ADD COLUMN c DEFAULT xx,会将一个分表的 c 列全部修改为 xx。目前 DM 的实现同样无法将这个事件以相同影响的方式应用到下游。
解决方法
对于上述 DDL 引入的问题并基于前文对于同步正确性的定义,我们可以得到一个满足要求的充分条件:当某分表出现 DDL 同步事件时,我们将其同步暂停;直到所有分表都出现该 DDL 同步事件时,我们将 DDL 应用到下游并恢复所有分表的同步。此时我们可以保证下游表的 DDL 产生的影响等于所有分表都进行了 DDL(不考虑非确定性 DDL,例如 DDL 新增列默认值为 current_timestamp)。
悲观协调例子
我们仍然以两张表 t1、t2 的合并迁移为例,观察 binlog 同步进度
左图中,当分表 t1 遇到 DDL 时,t2 同步事件还没有到这条 DDL,因此 t1 同步应当被暂停。当进展到右图时,t1、t2 分表都出现了相同的 DDL,因此此时可以将这条 DDL 应用到下游并恢复 t1、t2 的同步。
在某些情况下,t1、t2 可能位于一个 binlog 流之中,因此上图中看似独立的流的暂停与恢复,实际实现为在同一个 binlog 流中跳过事件及回滚同步位置。
如上图,我们需要在事件 1、2、4、5、6 之后同步事件 3,因此在 binlog 流中首次遇到事件 3 时跳过,并在事件 6 完成之后重新从事件 3 开始同步,并跳过已经同步的 4、5、6 事件。
悲观协调模式限制
可以看到这种协调模式解决方法有如下的限制:
-
出现 DDL 同步事件时分表会暂停,会导致同步延迟增加。这可能会导致恢复同步时,上游 binlog 已经被清理
-
不支持只变更部分分表以进行灰度测试时的场景。灰度期间其余分表的同步会暂停。此外如果灰度测试结果是回滚时,无法恢复同步
-
要求所有分表以相同的顺序出现 DDL 同步事件
-
如果分表由于误操作而进入 DDL 不一致的状态,修复操作较为复杂
-
对于 DM 的使用者而言,可能无法控制上游 DDL 的发起从而无法满足条件
因为悲观协调模式的种种限制,DM 也提供了新的乐观协调模式,我们将在后续的文章中具体介绍,希望大家能够在深入了解两种协调模式的原理和使用限制后,根据场景选择合适的模式进行分库分表的合并迁移。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
JDK ThreadPoolExecutor核心原理与实践
一、内容概括 本文内容主要围绕JDK中的ThreadPoolExecutor展开,首先描述了ThreadPoolExecutor的构造流程以及内部状态管理的机理,随后用大量篇幅深入源码探究了ThreadPoolExecutor线程分配、任务处理、拒绝策略、启动停止等过程,其中对Worker内置类进行重点分析,内容不仅包含其工作原理,更对其设计思路进行了一定分析。文章内容既包含了源码流程分析,还具有设计思路探讨和二次开发实践。 二、构造ThreadPoolExecutor 2.1线程池参数列表 大家可以通过如下构造方法创建线程池(其实还有其它构造器,大家可以深入源码进行查看,但最终都是调用下面的构造器创建线程池); public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue, ThreadFactory threadFactory, RejectedExecutionHa...
- 下一篇
XEngine:深度学习模型推理优化
摘要:从显存优化,计算优化两个方面来分析一下如何进行深度学习模型推理优化。 本文分享自华为云社区《XEngine-深度学习推理优化》,作者: ross.xw。 前言 深度学习模型的开发周期,包括训练阶段和部署阶段。训练阶段,用户需要收集训练数据,定义自己的模型结构,在CPU或者GPU硬件上进行训练,这个过程反复优化,直到训练出满意精度的模型。有了模型之后,我们需要将模型服务部署运行,我们期望服务延迟越低越好,吞吐越高越好。这里会从显存优化,计算优化两个方面来分析一下如何进行深度学习模型推理优化。 1. 显存优化 1.1 显存分布 模型推理需要占用一定量的显存空间(以GPU推理为例),其中主要包括如下4个部分: 不可控制空间 用户数据 模型参数 运行时空间 op计算的激活值 op计算需要的临时空间 其中“不可控制空间”指系统分配的空间,如每个进程CUDA Context所占用的显存空间,一般在100-300MB左右;“用户数据”指用户自行分配的显存空间,如模型输入输出Tensor占用的空间;“模型参数”指训练的深度学习模型的参数所占用的显存空间,我们需要将模型参数加载到显存中,才能进行计...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Red5直播服务器,属于Java语言的直播服务器
- Windows10,CentOS7,CentOS8安装Nodejs环境
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Docker使用Oracle官方镜像安装(12C,18C,19C)