快速掌握 PolarDB-X 拆分规则变更能力!
背景
PolarDB-X作为一款云原生分布式关系型数据库[6],支持通过拆分规则将一张逻辑表的数据分布在多个数据节点中。同时,也支持变更拆分规则,将数据进行重新分布[9]。数据重新分布(Repartition)的能力是分布式数据库的核心能力之一。当业务规模扩大时,它可以将数据分布到更多的节点,以达到水平扩展(ScaleOut)的目的。当业务规则剧烈变化时,它也可以将数据以新的拆分规则分布,从而提高查询的性能,更好地适应新的业务规则。下图展示如何将一张单表,通过一条简单的DDL语句online地变更为一个分库分表。
数据如何重新分布?
其实早在分布式数据库中间件大行其道的年代,开发人员就尝试过各种方式来解决数据Repartition的问题。但是无一例外,这些方案都非常复杂和危险,开发人员通常只能在半夜流量低峰期做Repartition,前前后后需要准备好详细的设计、论证、回滚方案。并且基于分布式的特点,在新老数据切换的那一段时间,几乎总是得在数据一致性和可用性之间做一个痛苦的选择。所以很多方案会有一个停写阶段或数据比对阶段,或两者皆有。
PolarDB-X充分论证了分布式数据库Repartition的各项技术细节后,能够做到Repartition过程中数据强一致、高可用、对业务透明、一条简单DDL语句搞定。
数据Repartition的关键问题
本文讨论的主要是表级别的数据Repartition。比如:将一张拆分表的数据按照新的规则重新分布到不同的数据节点。但是重新分布的过程需要时间,这段时间内又会有新的增量数据进入系统。当所有的数据都重新分布完成后,要将新老数据进行切换,最后停止双写并删掉所有的老数据。仔细研究上述过程的细节后,可以将其概括为这3个关键子问题,后续我们将按照这3个子问题评估各个实现方案:
- 如何进行存量、增量的数据同步?
a.比如:应用层双写、数据同步中间件、数据库触发器等。 - 如何进行流量切换?
a.主要考虑读写流量在新老数据中的迁移。 - 如何控制Repartition的整体流程?
a.主要考虑如何组合各个步骤,比如什么时候开启/停止增量数据同步,什么时候进行流量切换。
b.如果故障了怎么恢复或回滚等。
传统的Repartition方案
一个传统的Repartition流程大概是这样的:
- 应用集群初始状态的读写流量都在老的数据表上。
- 增加新表并开启双写。双写方式可能是应用层双写,或基于binlog数据同步,或数据库触发器实现双写等。但这个步骤,如果没有事务保证的话就很容易造成数据不一致。
- 启动存量数据同步。
- 可能会启动一个数据比对服务,如果有数据不一致的话,也需要人工介入处理。
- 当存量数据同步完成,增量数据追平后,将读流量切到新表,保持双写一段时间。
- 撤走老表的写流量,完成Repartition
但是如果我们仔细推敲一下,发现很多步骤根本就没办法保障数据一致性:
- 上述第2步,开启双写时,分布式系统无法保证所有节点都一起开启双写。所以一定有一段时间只有部分节点开启了双写。那就会出现Orphan Data Anomaly的问题(后文将说明)[2][8],造成新老表的数据不一致。传统的Repartition方案要解决这个问题的话,只能停写。
- 同理,上述第6步撤走老表的写流量时,也会出现数据不一致问题。
- 上述第2步,增量数据的双写一致性难以保障。
除了数据一致性问题外,依然存在很多繁琐但依然十分重要的问题:
- 整个流程基本由人工串联,多个环节需要人工介入。所以前期需要学习和理解成本,过程中也需要参与成本。
- 传统方案如果要避免数据不一致问题,在关键节点需要停写,这会对业务造成干扰。
- 整个流程十分脆弱地粘合在了一起,容错性非常差。
PolarDB-X的Repartition方案
PolarDB-X 是一款存储与计算分离的分布式数据库,所以在架构中会分为计算节点(CN)和存储节点(DN),以及一个元数据库(GMS)。CN负责SQL的parse、optimize、execute;DN负责数据存储;GMS负责存储元数据。为了性能考虑,每个CN节点都会缓存一份元数据。
如何进行存量、增量数据同步
增量数据双写
在分布式的增量数据双写场景中,双写的2端经常会分布在不同的DN节点中,所以自然地单机事务无法使用。而前文已经论证过,XA事务、binlog同步、触发器都无法保证双写的2端数据强一致。PolarDB-X使用了内置的基于TSO的分布式事务[7](👈感兴趣的同学可以点击直达文章)实现增量数据同步,从而保证了Repartition过程中,任意时刻读流量切换的数据的强一致性。
值得注意的是,如果一行数据的拆分列的值被修改了,那这行数据可能会路由到另一个数据节点[1]。所以这时候执行的其实是:原数据节点的delete操作+新数据节点的insert操作。在Repartition过程中,因为前后的拆分规则不同,所以一行数据的update操作,可能会演变成4个数据节点参与的分布式事务(如果有全局二级索引会更多)。PolarDB-X会处理好所有这些工作,用户无需任何感知,可将PolarDB-X视为一个单机数据库操作。
存量数据同步
在存量数据同步时,PolarDB-X会分段进行同步。每一段同步过程中,PolarDB-X会在TSO事务中,先尝试获取源端数据的S锁,然后再写入目标端。如果目标段已经有相同数据,则表明增量双写阶段已经将这些数据同步过了,忽略即可。
分布式事务与单机事务一样,会产生死锁。当存量同步而给原表某段数据加S锁时,如果业务Update流量较大,可能导致分布式死锁的发生,PolarDB-X有一个分布式死锁检测模块可以解决这个问题。死锁解除后,存量同步模块会重试。
如何进行流量切换
Online Schema Change
首先我们来看一下前文提到的Orphan Data Anomaly问题[2]是怎么发生的:当开启增量数据双写时,PolarDB-X的CN节点内存中的元数据不是同时刷新的,而是有一个先后顺序,所以一定存在一段时间,某些CN节点开启了增量双写,而另一些没有。于是会出现这样的情况:
- 计算节点CN0已开启双写,并在老表和新表分别写入了3条数据,如下图
- 计算节点CN1未开启双写,执行了delete语句,删除了id为3的一条数据,但是未删除新表的数据
- 新表和老表出现了数据不一致
这一问题在Google的Online, Asynchronous Schema Change in F1这篇论文中有过详细的论证。PolarDB-X引入了Online Schema Change(👈感兴趣的同学可以点击直达文章)以解决此类的问题,在此不再赘述。对于Repartition来说,引入下图中的这些状态,以此保证任意2个相邻状态都是兼容的,不会发生数据一致性问题。我们可以具体来看看其中几个最关键的状态:
- target_delete_only和target_write_only:如上所述,当我们有多个CN节点时,直接开启增量双写会导致Orphan Data Anomaly问题。所以在开启双写之前,我们先让所有的CN节点都达到target_delete_only状态,然后再达到target_write_only状态(就是双写状态)。CN节点在target_delete_only下,只会执行delete语句(如果是update,则转换成delete执行)。代入上图中的例子:CN1会先达到target_delete_only状态,所以即便未开启双写,也能够删除新表中id为3的数据,从而保证了数据的一致性。
- source_delete_only和source_absent:前文也论述过,如果直接停掉老表的双写,会造成数据不一致。所以我们在source_absent(也就是停止了双写的状态)之前引入了一个source_delete_only状态。它也保证了老表在下线过程中不会产生Orphan Data Anomaly问题。
如何控制整体流程并保证稳定性
PolarDB-X以DDL的形式为用户提供拆分规则变更(也就是Repartition)的能力,DDL也需要保障ACID特性,但数据重新分布可能需要花费较长时间,系统因断电等原因而故障在所难免。
DDL引擎
所以PolarDB-X也实现了一套稳定的DDL执行框架,它会将DDL分成很多个步骤,每个步骤都是幂等的。这样就可以保证DDL任务可以随时中断,然后恢复继续运行或者回滚。通过DDL将所有的步骤串联,也将所有的人工操作排除在外,开发人员再也不需要做Repartition的方案设计,再也不需要半夜三更手动执行数据库的高危操作了。
分布式MDL死锁检测
MySQL在5.7版本引入Online DDL能力后,使得DDL能够更好地与读写事务并行,相比于之前的版本有了很大的改善。Online DDL的基本原理是只在关键的时刻获取MDL锁,而不是在整个DDL阶段都持有MDL锁。PolarDB-X在执行Repartition时也会分多个阶段获取多次MDL锁,从而允许事务达到更高的并发度。但MDL锁有个危险的特性是:它是一个公平锁,并且可能造成MDL死锁。
多次获取MDL锁提高了性能的同时,实际上增加了MDL死锁产生的概率,而MDL死锁一旦发生,会导致后续所有的读写事务都被阻塞,MySQL的MDL默认超时时间1年,危害远大于普通的数据死锁。因此PolarDB-X也提供了一个分布式MDL死锁检测模块,用于在关键时刻解除分布式MDL死锁。
总结
灵活的拆分规则变更能力是分布式数据库的重要特性。PolarDB-X中有3种表类型:单表、广播表、分库分表。使用拆分规则变更能力,用户可以将数据表进行任意的表类型转换,从而更好地适应业务发展。PolarDB-X在提供拆分规则变更能力的同时,保证了数据的强一致、高可用、对业务透明、并且使用起来非常方便。本文简单阐述了PolarDB-X实现拆分规则变更过程中使用到的各项技术点,如读者可见,我们之所以将拆分规则变更能力集成到数据库内核中,是因为很多数据一致性问题非此不可解决。这也是分布式数据库区别于分布式数据库中间件的重要特性之一。
拆分规则变更能力只是PolarDB-X诸多特性中的一个。想要了解更多内容,欢迎关注公众号内的其他文章。
文章转自公众号:阿里云数据库