网站菜单怎么做,网站升级建设费用,太原seo网站建设,如何创建一个app平台关系数据库中的事务故障恢复并不是一个新问题#xff0c;自70年代关系数据库诞生之后就一直伴随着数据库技术的发展#xff0c;并且在分布式数据库的场景下又遇到了一些新的问题。本文将会就事务故障恢复这个问题#xff0c;分别讲述单机数据库、分布式数据库中遇到的问题和…关系数据库中的事务故障恢复并不是一个新问题自70年代关系数据库诞生之后就一直伴随着数据库技术的发展并且在分布式数据库的场景下又遇到了一些新的问题。本文将会就事务故障恢复这个问题分别讲述单机数据库、分布式数据库中遇到的问题和几种典型的解决方案以及 OceanBase 在事务故障恢复方面的相关实践。
一、从单机数据库说起
大家都知道数据库中事务具有四大属性ACID其中和事务故障恢复相关的属性是 A 和 D
原子性Atomicity事务内的修改要么都生效要么都不生效持久性Durability如果数据库宕机已经完成提交的事务结果不应该丢失
例如在如下图所示的两个事务执行过程中 在数据库出现宕机时Trx1 还没有执行完成而 Trx2 已经完成提交原子性和持久性要求在宕机恢复后Trx1 的所有修改都不生效且 Trx2 的所有修改都必须被持久化。为了达到这个要求数据库必须在宕机重启后执行两个动作
回滚移除所有未完成以及回滚事务的修改重做重新执行已经完成提交的事务的修改确保持久性
1.1 Shadow Paging
一种比较简单的保证事务原子性和持久性的方法是 Shadow Paging。这个方法非常容易理解数据库维护两个独立的数据“版本”分别称为 master 和 shadow 版本写事务的所有修改操作写入在 shadow 版本上其他事务读取仅读取 master 版本shadow 版本对读取不可见当写事务提交时需要在完成提交前将 shadow 版本切换为 master 版本。 当数据库发生宕机重启时并不需要做对应的回滚和重做操作仅回收可能残留的 shadow 版本数据即可。 LMDBLightning Memory-Mapped Database 就是一个真正应用了 Shadow Paging 方法的数据库例子。LMDB 是一个基于内存文件映射的 KV 数据库事务修改时采用 Copy-on-write 的方式对 Btree 索引结构进行修改当写事务在修改数据时会对修改部分 Copy 出新的 Btree并在事务提交前将新的根节点落盘读取事务总是从当前生效的最新根节点开始执行。 1.2 数据落盘策略
回顾前文在宕机重启时必须要执行回滚和重做两个操作。回滚的目的是消除磁盘上存在的未提交事务的修改但 Shadow Paging 方法在事务提交前并不会修改 master 版本所以无需执行回滚操作重做的目的是将已经提交但是没有完成落盘的事务修改恢复出来但 Shadow Paging 方法在事务提交前一定已经将所有修改完成落盘并修改 master 版本所以也无需执行重做操作。 由此可以看出事务故障恢复所需要执行的操作和事务执行过程中数据落盘的策略是相关的。 数据库领域中将事务执行过程中数据落盘的策略归纳描述为两点
Steal/No-Steal指事务在执行过程中是否允许未提交的事务修改磁盘上的最新数据Force/No-Force指事务在提交前是否要求将所有修改落盘
实现了 Steal 属性的数据库系统需要在宕机重启后做回滚操作以消除未提交事务的修改实现 No-Force 的数据库系统需要宕机重启对已提交事务做重做操作来恢复出未落盘的修改。 Shadow Paging 属于 No-Steal Force 的系统所以宕机恢复的过程非常简单。但是宕机恢复过程的简单是以运行时的复杂为代价的No-Steal 要求事务在提交前都不能落盘对大事务不友好Force 在事务提交时增加了写盘压力和延时。通常来说Steal No-Force 对注重运行时表现的系统是比较理想的。
1.3 Logging
那么如何实现一个满足 Steal No-Force 的数据库系统呢接下来我们分析几种基于日志的实现方法。
1.3.1 Redo 日志
如果在事务修改过程中生成 Redo记录修改后的新值日志则在宕机重启后系统可以通过回放 Redo 日志进行已提交事务的重做过程但是无法做到未提交事务的回滚因此采用 Redo 日志的系统规则如下
对于每一次修改产生 Redo 日志记录包含修改后的新值事务 Commit 前Commit 日志落盘事务的所有修改不能落盘No-Steal事务提交成功前事务的所有日志记录非数据必须先落盘 No-Force
RocksDB 是一个典型的使用 Redo 日志的例子暂不讨论 WriteUnprepared事务的写入在提交前不能落盘缓存在内存中事务专属的 WriteBatch中当事务确定提交时首先生成所有修改的 Redo 日志并落盘然后才能将 WriteBatch 中的数据写入到 memtable 中。 Redo 日志属于 No-Steal No-Force 的系统如前文所述No-Steal 意味着对大事务运行不友好。
1.3.2 Undo/Redo 日志
如果在事务修改过程中同时记录修改前的旧值作为 Undo 日志实现中并不一定采用日志形式在宕机重启后系统就拥有了回滚未提交事务的能力这种做法称为 Undo/Redo 日志
对每一次修改产生日志同时记录旧值和新值未提交事务允许落盘在修改落盘之前对应的日志记录必须先落盘Steal事务提交成功前事务的所有日志记录非数据必须先落盘 No-Force
大名鼎鼎的 Oracle 数据库就是采用这种模式事务的每一次修改都会产生对应的 undo record记录在 undo block 中和 redo record并且在刷脏页之前保证脏页上对应的未落盘事务日志必须先落盘在事务 commit 前要保证事务的所有日志落盘完成。 Undo/Redo 日志属于 Steal No-Force 系统目前绝大多数流行的关系数据库系统都采用了这样的思路例如 Oracle、MySQL、PostgreSQL 等。
1.3.3 日志回收
任何基于日志的系统都会遇到日志回收的问题。虽然我们可以保留所有日志来满足事务故障恢复的需求但是日志空间不能无限的膨胀下去并且如果在宕机重启时总是从整个数据库的第一条日志开始重做宕机恢复的速度也无法满足系统要求。因此我们需要一种手段来尽可能的减少宕机恢复依赖的日志数量这个手段就是Checkpoint。
一种最为简单的 Checkpoint 方法流程如下
停止所有事务执行暂停新开启事务并结束运行中的事务将当前内存中所有未落盘的修改落盘记录当前点为一次生效的 checkpoint恢复事务执行
这个方法的正确性也很容易理解因为在第二步之后磁盘上已经有了完整的数据不再需要任何日志。但这个方法的问题也很明显就是要停止所有事务执行这几乎是无法接受的。
有很多不同的 Checkpoint 方法可以避免这个问题我们以 Oracle 中的 Media recovery checkpoint 举例其过程为
取当前 SCNRedo point通知 dbwr 将当前所有脏页落盘完成后将 SCN 作为 checkpoint 点更新到元信息中 整个过程中不影响正常事务的执行其正确性的关键在于完成脏页落盘后Redo point 前日志对应的修改都完全落盘了不再需要依赖日志回放来进行故障恢复。 二、分布式数据库带来的问题
在分布式数据库中事务故障恢复的目的仍然是要保证事务的原子性和持久性。和单机数据库的不同在于在分布式数据库中数据的修改位于不同的节点。 比如在这个例子中事务的修改涉及到3个不同的节点当事务要提交时必须保证3个节点上的数据同时提交而不能部分提交、部分回滚。
2.1 Saga
Saga 是1887年提出的一种把长事务拆小并保证整体事务原子性的方法也可以用来解决分布式事务的问题。其核心思路是对每个子事务产生对应的“补偿事务”当分布式事务整体提交时依次提交各个节点上的子事务如果过程中遭遇失败则对已经提交的节点上的子事务执行补偿事务回滚已提交的修改。 如上图例中事务在3个节点上各自产生一个子事务在分布式事务提交时提交各个子事务在第3个节点上提交子事务失败需要对另外两个成功提交的子事务执行补偿事务完成回滚操作。 这种方法的优点在于正常提交流程处理简单而缺点在于补偿回滚过程逻辑处理复杂。
2.2 两阶段提交
两阶段提交可能是最为知名的分布式事务原子性解决方案了。两阶段提交顾名思义整个事务提交流程分为两阶段来执行
Prepare协调者通知参与者 Prepare参与者写 Prepare 日志成功后回复协调者 Prepare okCommit协调者收到所有参与者 Prepare 成功应答后通知参与者 Commit
每个节点都需要将每个阶段的结果记录在持久化的日志中用以恢复自身状态。 协议流程本身很简单两阶段提交协议的核心在于协议应对宕机时的处理当参与者发生宕机时如果参与者还没有回复过协调者 Prepare ok则协调者假定参与者决定回滚当协调者发生宕机时参与者会按照自己的状态决定下一步动作。 上图是两阶段提交参与者的状态机如果参与者已经回复过 Prepare ok处于 Prepared 状态则参与者必须依赖协调者的消息通知才能决定最终事务状态我们称参与者的这个状态为“事务未决”。如果此时协调者发生宕机则两阶段提交流程会阻塞。这也是所有应用两阶段提交协议的系统所必须要解决的问题。 应用两阶段提交协议的系统很多我们以 PG-XC 为例PG-XC 的数据存储在不同的 Data Node 上在分布式事务提交时通过 Coordinator 执行两阶段提交协议保证多个 Data Node 上事务修改的原子性。 另外近几年比较流行的 Percolator 协议可以看做是两阶段提交协议的变种Percolator 包含了一套完整的分布式事务解决方案本文聚焦在其中事务原子性的部分。Percolator 是 Google 提出的在仅支持行级事务的Bigtable 基础上将单行事务“组合”成多行事务的方案。
当多行事务发起提交时
选定其中一行作为Primary record将该行写入到 Bigtable 中Primary record 上会记录整个事务的状态此时为未提交状态将其他行作为“Secondary record”分别写入到 Bigtable 中其中都包含了 Primary record 的位置信息通过查询 Primary record 上的事务状态来决定自身状态修改 Primary record 上的事务状态为已提交异步清理 Secondary record 上的状态 从两阶段提交协议的角度分析 Percolator其每行上的事务都是整个分布式事务的参与者Primary record 相当于协调者当所有参与者都持久化成功后修改 Primary record 上事务状态的过程也就等价于协调者写的 commit 日志。
三、OceanBase 事务故障恢复
OceanBase 采用 share-nothing 架构数据按照分片规则分布在各个节点上每个节点均有自己的存储引擎各自管理不同的数据分区每个分区通过 Paxos 同步日志实现高可用当事务操作一个单独的数据分片时执行的是单机事务当事务操作不同数据分片时执行的是分布式事务会遇到分布式事务的原子性问题。
3.1 单机事务故障恢复
OceanBase 采用基于 MVCC 的事务并发控制这意味着事务修改会保留多个数据版本并且单个数据分片上的存储引擎基于 LSM-tree 结构会定期进行转储compaction操作。
如下图所示事务的修改会以新版本数据的形式写入到内存中最新的活跃 memtable 上当 memtable 内存使用达到一定量时memtable 冻结并生成新的活跃 memtable被冻结的 memtable 会执行转储转变为磁盘上的 sstable。数据的读取通过读取所有的 sstable 和 memtable 上的多版本进行合并来得到所需要的版本数据。 单机事务故障恢复采用了 Undo/Redo 日志的思路实现。事务在写入时会生成 Redo 日志借助 MVCC 机制的旧版本数据作为 Undo 信息实现了 Steal No-Force 的数据落盘策略。在事务宕机恢复过程中通过 Redo日志进行重做恢复出已提交未落盘的事务并通过恢复保存的旧版本数据来回滚已经落盘的未提交事务修改。
3.2 分布式事务故障恢复
当事务操作多个数据分片时OceanBase 通过两阶段提交来保证分布式事务的原子性。 如上图所示当分布式事务提交时会选择其中的一个数据分片作为协调者在所有数据分片上执行两阶段提交协议。还记得前文提到过的协调者宕机问题么在 OceanBase 中由于所有数据分片都是通过 Paxos 复制日志实现多副本高可用的当主副本发生宕机后会由同一数据分片的备副本转换为新的主副本继续提供服务所以可以认为在 OceanBase 中参与者和协调者都是保证高可用不宕机的多数派存活绕开了协调者宕机的问题。 在参与者高可用的实现前提下OceanBase 对协调者进行了“无状态”的优化。在标准的两阶段提交中协调者要通过记录日志的方法持久化自己的状态否则如果协调者和参与者同时宕机协调者恢复后可能会导致事务提交状态不一致。但是如果我们认为参与者不会宕机那么协调者并不需要写日志记录自己的状态。 上图是两阶段提交协议协调者的状态机在协调者不写日志的前提下协调者如果发生切主或宕机恢复它并不知道自己之前的状态是 Abort 还是 Commit。那么协调者可以通过询问参与者来恢复自己的状态因为参与者是高可用的所以一定可以恢复出整个分布式事务的状态。 除此之外OceanBase 还对两阶段提交协议的时延进行了优化将事务提交回应客户端的时机提前到 Prepare 阶段完成后标准两阶段提交协议中为 Commit 阶段完成后。 在上图中绿色部分表示写日志的动作左侧为标准两阶段提交协议用户感知到的提交时延是4次写日志耗时以及2次 RPC 的往返耗时右侧图中 OceanBase 的两阶段提交实现由于少了协调者的写日志耗时以及提前了应答客户端的时机用户感知到的提交时延是1次写日志耗时以及1次 RPC 的往返耗时。
四、总结
关系数据库领域虽然历史悠久但是仍然充满了活力。这些年来随着硬件的发展新的技术和思路也不断的涌现出来从本文描述的单机数据库到分布式数据库中事务故障恢复的的方案相信大家也都能感受到这些年来数据库技术的发展是如何一步步适应着硬件的发展趋势。未来又会怎样更大的内存、更快速的网络、更廉价的硬盘、甚至是非易失性内存的普及这些变化会给数据库技术带来怎样的可能性让我们一起拭目以待。迫不及待的同学欢迎加入 OceanBase 团队一起创造数据库技术的未来
