ERP系统容灾方案要点分析

ERP系统容灾的要点在数据库上。

Web服务器和应用服务器上因为没有存放业务数据，只需要提供冗余即可，不管是本地高可用集群（HACluster）、远程高可用集群、还是基于负载均衡器的服务器冗余（负载均衡集群），都是成熟的解决方案，企业可用根据自身情况选择合适的解决方案。

在数据库的数据容灾方面，由于采用磁带备份的冷备份方式基本不能满足RPO要求，所以本方案重点讨论联机数据复制技术。根据数据复制的发起点不同，有多种主流技术，如基于存储的磁盘级容灾，基于存储网络的容灾，基于主机的容灾和基于数据库的容灾，可参考下图：

一般来说，级别越低的技术，通用性越强，实施越简单，对硬件要求越高，备份系统可用性越低，反之，级别越高的容灾技术，技术实现越复杂，对硬件依赖性越小，但备份系统可用更好。

实际上，磁盘级容灾、存储网络级容灾和主机级容灾都是基于数据块复制的技术，数据量和占用带宽比较大，实际传输数据量在交易数据量的8-10倍左右，并要求主机或存储同构，而数据库级容灾是基于数据库日志的容灾技术，数据量和占用带宽比较小，对硬件平台没有要求。

但是，这并不是最重要的。最重要的是数据库系统对数据的一致性和完整性是有严格要求的，为了提高备份系统的可用性，必须保证备份数据库是随时可以打开的，必须完整复制交易数据，保证交易数据一致性。而基于存储或基于主机的数据复制技术，好处是对应用透明，但坏处就是无法区分数据的内容，只能对数据块和逻辑卷进行复制，难以保证容灾备份数据库在所有检验时间点的一致性，有可能出现单次检验失败的情况，或者出现灾备数据库无法打开的情况。

还有一个对数据库容灾有影响但通常被忽略的问题是缓存问题，在存储系统中，缓存（Cache或Buffer）几乎无处不在，文件系统有缓存，存储有缓存，RAID控制器上有缓存，磁盘上也有缓存。由于数据库采用了预写式日志（WriteAhead Logging）技术，在发出Commit指令更新数据库表中的数据时，实际上只是把内存中的日志缓存写到存储上，并没有实际更新数据，见下图所示：

为了保证数据的一致性，对于数据库日志（Redo Log）采用了Direct IO，跳过了操作系统中文件系统的缓存，但是依然可能写在存储的缓存上。而实际更新数据（Data Block）时，很有可能写在存储系统的缓存上就返回了，而且更新数据是按数据页（Page）更新的，“脏数据”也会同时更新到磁盘上，数据库能通过Redo Log来保证数据一致性的问题。

这就导致只有Redo Log的数据是最新的、准确的，这也是数据库保证数据一致性的基础，通过逻辑卷复制或存储复制的数据复制技术，即使采用的是同步复制技术，也存在没有复制缓存数据的问题，而就是复制了缓存数据，因为数据库的本身机制就决定了磁盘上存在“脏数据”，依然只能通过数据库来保证数据的一致性。

基于上述分析，我们认为数据库数据容灾最适合的技术就是数据库级容灾技术，基于对数据库日志的捕获、重做来保证数据一致性。

 现在只有包括沃信科技T3数据库容灾软件在内的少数几种软件是利用该项技术进行数据库容灾。