关系数据库中的事务故障恢复并不是一个新问题，自70年代关系数据库诞生之后就一直伴随着数据库技术的发展，并且在分布式数据库的场景下又遇到了一些新的问题。本文将会就事务故障恢复这个问题，分别讲述单机数据库、分布式数据库中遇到的问题和几种典型的解决方案，以及 OceanBase 在事务故障恢复方面的相关实践。
关系型数据库
关系型数据库 分类中有 3 篇文章
可串行化（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个副本失败而不会导致事务无法推进。
另外，论文中还提到了其他尝试解决此问题的方法（三阶段提交），并表示不屑一顾……….（三阶段提交实际上并没有改善提交过程的容灾）