分布式数据库事务故障恢复的原理与实践

关系数据库中的事务故障恢复并不是一个新问题,自70年代关系数据库诞生之后就一直伴随着数据库技术的发展,并且在分布式数据库的场景下又遇到了一些新的问题。本文将会就事务故障恢复这个问题,分别讲述单机数据库、分布式数据库中遇到的问题和几种典型的解决方案,以及 OceanBase 在事务故障恢复方面的相关实践。

继续阅读:

可串行化(Serializable):理想和现实

但凡是接触过数据库的同学一定不会对事务(transaction)的概念感到陌生,我第一次接触事务的概念还是在本科的数据库课本上,了解了事务并发控制概念,但在之后多年不严肃的前后台开发经历中,我几乎从来没有考虑过数据库的“隔离级别”,这让我产生了一种”数据库如此好用,世界如此美好“的幻觉…直到现在从事了数据库内核的开发工作,才对事务的并发控制有了一点点认真的理解。

这篇文章即是我对事务并发控制的一些粗浅的理解。

事务并发执行的正确性


一般来说,教科书中都是类似的描述事务:”数据库并发控制的基本单元“,事务管理器和执行引擎需要和并发控制协作,来保证数据库中事务的执行是”正确“的。数据库中事务并发控制的正确性,也就是我们常说的Isolation

PS:并发事务的正确性除了我们最常讨论的Isolation之外还有Consistency和Recoverable,限于篇幅,本文仅讨论Isolation。

继续阅读:

[paper note]Consensus on Transaction Commit

这篇论文的作者实在太吓人了,Jim Gray和Leslie Lamport,两个领域的扛把子。论文介绍的内容叫Paxos Commit,是用分布式共识算法解决分布式事务的原子提交问题,不愧是这两位大佬写出来的文章哈哈。

PS:这篇文章是我的paper note,主要是帮助自己理解和记忆,与其说是文章,其实更像是简单的笔记。

解决了什么问题


事务的属性是ACID,A代表原子性,事务要么全部提交,要么全部失败,不能出现提交了一半的情况。单机事务的原子性通过日志系统来保证,而在分布式事务里,通常的做法是两阶段提交(Tow Phase Commit,2PC)。

两阶段提交的一个重要问题是协调者宕机问题,参与者执行完Prepare状态后,参与者处于“未决”状态,意味着参与者自己无法决定事务状态,而如果此时协调者宕机,事务的状态将无法推进下去。

Paxos Commit希望解决这个问题,即在事务提交过程中,能够容忍F个副本失败而不会导致事务无法推进。

另外,论文中还提到了其他尝试解决此问题的方法(三阶段提交),并表示不屑一顾……….(三阶段提交实际上并没有改善提交过程的容灾)

继续阅读: