公有云项目教训（数据库灾备不要再踩坑）
最近的一个大客户迁移至天翼云，项目中有一个关键要求，必须实现应用数据的秒级同步。为此，我们采购了基于磁盘级的数据复制软件，以及该方式可以兼容mysql、mssql、oracle多种数据库，包打各种上层的数据，结果坑比较多，为此付出了教训。为避免再复错误，今天将经验总结一下。
一、问题发生在哪里？慎用磁盘级的数据灾备软件至数据库环境
刚开始一切风平浪静。我们采购了某厂商的数据灾备软件实现了操作系统级的数据灾备。从Windows、Linux多种环境，实现了数据灾备保存，并恢复操作，一切都好。甚至我们将数据备份的时间设置到了秒级，看上去真的很完美。
问题开始发生。当我们进行RedHat+Oracle进行备份、恢复时，问题出现了，恢复的Oracle数据库无法启动。
问题在哪里？后来，经某专业DBA介绍，一般来说是用这种方式做oracle的容灾备份，在发生灾难以后目标系统的数据库一般是只有2/3的机会是可以正常启动的。专业解释无法启动的原因有：1、存储的复制应该是捕捉原系统存储上的每一个变化，而不是每隔一段时间去复制一下原系统存储上文件内容的改变结果。如果主库磁盘故障，那么也会将故障数据写入到备库磁盘中，如异常断电情况。2、磁盘级灾备软件的block-size一般为4KB，为Oracle数据库的block-size一般设置为8K或16KB，数据块的不一致将导致校验错误，最终导致无法启动数据库。设想，如果Oracle正在写数据，而中途灾备软件将部分数据copy走，而恢复的时间点正好设置在这个时间，数据校验肯定出错。
二、我们该如何解决？用磁盘备份+原厂数据库DG软件相结合
在实际应用中，Oracle数据库与远程磁盘镜像技术应该是互为补充的关系。理论上，远程磁盘镜像可在存储层实现所有系统的容灾，而Data Guard则提供了更有效、可行、成本更低的Oracle数据库灾备方案。我觉得如果不是数据量大的惊人，其他方式没办法做到同步，或者要同时对数据库和应用进行容灾，存储级的方案是没有什么优势的。
在本次项目中，最终的交付物为：磁盘灾备软件进行定期的磁盘级快照 + Oracle Dataguard日志级线下客户私有云数据同步。
Oracle针对灾备系统的应用需求，提出了以下基本建议：1、对Oracle数据库系统，选择Data Guard方案; 2、对文件系统和非Oracle系统，选择远程磁盘镜像技术。
根据项目教训，我建议，针对数据库采用原生的数据同步软件（Dataguard、Mysql主从同步脚本），对操作系统、文件系统采用磁盘复制技术软件。
三、经验总结
Oracle Data Guard容灾方案是专为数据库备份而设计的，它提供了远程磁盘镜像技术所无法实现的功能，特别是在远程数据库备份过程中，Data Guard的优势更加明显。对于Oracle数据库远程异步备份而言，Data Guard则提供了更有效可行、成本更低的Oracle数据库灾备方案，而远程磁盘镜像技术却无法保证写操作顺序的一致性，导致数据坏块的可能性增大，很有可能使备份数据库无法打开。另外在网络资源占用上，Data Guard只传输相应DML语句的日志信息，而磁盘镜像技术传输交易所涉及的所有数据块及归档日志数据，其传输量是Data Guard的7倍。
在各种故障中，故障率最高的是磁盘故障（Corruption）。一旦出现磁盘坏块，磁盘镜像技术将忠实地将这种错误传播到备份数据库的磁盘中，导致备份数据库无法使用。而Data Guard传输的是日志文件，而且传输之前对日志文件的完整性进行了校验，因此，不可能发生损坏数据块的现象，使得数据安全性得到提高。
在实际应用中，Oracle Data Guard与远程磁盘镜像技术应该是互为补充的关系，远程磁盘镜像是在存储层实现所有系统的容灾，而Oracle Data Guard方案仅仅适用于对Oracle数据库系统的容灾备份。
希望以上文章能帮到您。
更多内容实时更新，请访问公众号。