mysql rpo是什么意思_揭开数据库RPO等于0的秘密（上）

前言

传统商业关系数据库都声称可以做到故障恢复后不丢数据(即RPO为0)，跟故障前的数据状态是强一致的，实际是否一定如此？ 开源数据库MySQL在金融核心业务都不敢用，最重要的一个原因是做不到不丢数据。但是有些基于MySQL修改的数据库为何又说自己是强一致的呢？新兴的分布式数据库OceanBase声称是金融级的分布式关系型数据库，强一致，绝对不丢数据，这个是真的吗？

本文分为上下两篇。 上篇分析传统关系数据库Oracle/MySQL在应对故障时保障数据不丢失的机制，以及分析AliSQL和PolarDB在这方面探索的改进措施。下篇分析蚂蚁的OceanBase在数据安全方面的创新之处。

数据库的容灾设计

数据库写策略：WAL机制(Write Ahead Logging)

数据库在读数据的时候，会将数据所在块读入到数据库内部的缓存中。如Oracle里称为Buffer Cache，MySQL称为Buffer Pool。当数据修改后，这些缓存中的块就被称为脏块(Dirty Block)。为了性能考虑，数据库(DBWn进程)并不会立即把这些脏块写回到磁盘上。这个有个风险，当数据库进程宕掉时，磁盘上的数据并不是最新的数据。即使数据库进程恢复了，也找不回原来的数据修改。所以，数据库在修改数据之前，都会先在日志缓冲区记录块修改的日志(即事务日志)，并把这个日志先写回磁盘上。有个例外如Oracle的direct load。

这个技术就是Write Ahead Logging技术。有了这个事务日志，数据库就有能力维持缓存和磁盘上数据最终一致，即使数据库宕机。对于一个数据库软件来说，发生异常的时候只要事务日志没有丢失，它就敢承诺数据库服务恢复后，数据绝对不丢。即RPO为0。或者说事务日志是安全可靠的，那么数据就是安全可靠的。当然，严格的说还有一个前提是数据文件没有损坏，或者有数据文件的备份可以还原。否则会比较麻烦。比如说从第一个事务日志开始恢复到最新的状态。时间太久意义不大。

日志文件打开方式：Direct IO和Buffered IO

这节继续说事务日志的安全性。数据库(LGWR进程)在写事务日志时，为了性能也是会先写入一个日志缓存(Log Buffer)。然而不同数据库对将Log Buffer中的事务日志写到盘上的策略不尽相同，这个后面每个数据库再具体分析。这里要说的是写到磁盘上这个动作是否可靠。

OS里为了提升文件的读写性能，设计了缓存机制(Page Cache和Buffer Cache)。数据库有自己的缓存(Buffer Cache和Log Buffer)，不需要使用OS的缓存(因为数据库更懂自己的数据)。Direct IO选项就是指定数据库打开数据文件和事务日志文件的方式。另外一种方式就是Buffered IO，数据写到内核缓冲区就返回了。这有个风险就是一旦操作系统宕机再恢复，这个内核缓冲区数据就丢失了，磁盘上的数据很可能也不是最新的。

所以数据库的事务日志打开方式必须使用Direct IO，才可以保证事务日志的绝对安全可靠。

副本复制(Replication)技术

上节说了如果保证事务日志在单机上的可靠性，这节继续说事务日志的安全性。当机器因为存储硬件宕机再也起不来时，或者机器起来了，但是硬盘损坏导致事务日志文件损坏打不开时，数据库里的数据还是找不回来，还是保证不了RPO为0.

所以，为了抵抗单机故障数据丢失风险，要将事务日志的安全级别提高，要在另外一台主机上也保存一份事务日志。这是日志复制(Relication)技术。为了减少在异机恢复时间，也在该主机上维护一份数据副本。先简单称这个副本为备副本。当前的主库上的数据称为主副本。备副本的数据要尽可能的跟主副本数据保持一致，这种一致性保持不是通过业务双写实现(那是业务层面的容灾方案)，而是通过将主副本的事务日志复制到备副本机器上并在备副本上应用。类似于在备副本上恢复数据。

大部分关系数据库都是这么做的。在Oracle里这个技术叫Dataguard，在MySQL里叫Replication，SQLServer里叫Mirror。当然SQLServer也有Replication技术。不同数据库在这个Replication细节上会有点区别。

首先是复制的事务日志的格式分两类。 一类就是原始的事务日志，记录的是数据块的变化。备副本在应用这个事务日志的时候会严格比对数据块的相关内容是