在上周，互联网技术圈的一条重磅消息就是某旅游类门户网站的瘫痪，而据传这一情况出现是因为其后台的数据库被物理删除，造成数据的全部丢失。到笔者发稿时，该网站的业务尚未恢复，而这一情况出现已经超过 10 个小时。有人根据其业务进行估计，这一事故的出现，每小时将损失超过千万元。

我们先不论这一事故是操作失误还是设备故障抑或是有人故意为之，数据库引发的整个网站瘫痪也让人们开始重新关注和重视数据库的安全性以及高可用性。那么下来笔者也以这个事件为引子，谈谈有关数据库的数据灾备的一些观点。

“数据库灾备是什么 ”

数据库灾备指的是在同一时间，一个数据库在运行的同时，还有另外一个数据库在另一个不同的地点运行，同时完全和当前的主要运行的数据库实时同步。这样当主数据库发生任何问题的时候，另一个地点的数据库可以立刻接管业务，使整个业务不会中断。

在很多传统的数据库中，灾备是一种非常成熟的技术。例如 Oracle 的 DataGuard，DB2 的 HADR，都是鼎鼎有名的跨数据中心数据库灾备方案。使用了灾备机制的数据库，当主系统所在的数据中心出现故障后（不管是被人把系统干掉了，还是整个数据中心被地震震塌了），备系统可以在短时间内感知并接管数据服务，使得在线业务持续运行。

从技术的角度看，传统的灾备方案一般会将主库的日志顺序发送给备库，在备库上重新执行主库上的操作。这样主库和备库之间可能仅存在非常小的延时，基本实现同步。但是，在很多新型的分布式数据库中，灾备方案还并没有像传统数据库那样普及。因此，数据的安全性隐患也是很多企业在考虑使用新型分布式数据库时一个非常重要的因素。

“数据库灾备需要考虑的因素 ”

除了基本的数据复制功能外，灾备方案还有些什么其他重要的考虑因素呢？

1）主备库之间的延迟。既然主备库分别部署在不同的数据中心，互联网延迟则是必须考虑的因素。主备库之间的延迟越小，当主库出现故障时丢失的数据越少。例如如果主备库之间的延迟可以缩小到一秒钟以内，当主库所在的系统出现人为或非可控灾难的时候，主备库切换所造成的数据损失会被限定在一秒钟内，这样和整个门户网站的瘫痪比起来，企业所遭受的损失几乎可以忽略不计。

2）占用带宽小。一般来说，主备数据中心之间的网络带宽非常昂贵。由于主备数据中心之间的网络一般都是跨广域网的，因此其带宽的承受能力绝对不能像局域网那样假设为千兆或万兆带宽。因此，在网络传输时数据通道的条数，数据传输时的压缩比率都是非常重要的指标。

3）安全的传输通道。既然数据是跨广域网的传输，如果有人在机房外架设嗅探器，是否可以截获我们的网络通讯呢？如果主备节点之间总是以明文通讯，这绝对是一个非常重大的安全隐患。因此，主备数据中心之间的数据通讯是否加密则是第三个重要的安全指标。

这些跨数据中心复制的重要因素，在 SequoiaDB 企业版中得到了非常高的重视。在保证网络顺畅的环境中，使用 SequoiaDB 进行远程跨数据中心复制可以将主备库的延时限定在秒级，同时 SSL 数据通道配合数据压缩，使得数据在传输时高效安全可靠。

“事故预防 还需健全的权限管理 ”

当然，除了技术以外，很多灾难场景的发生都是人为产生的。再严密的加密措施也无法挡住 DBA 从内部贩卖数据；再严格的防火墙也挡不住系统管理员的 rm –rf。因此，对内部员工的培训、监管以及系统隔离是非常必要的。

例如，对于数据库管理员来说，主备库最好由完全不同的团队管理。譬如北京和上海两个数据中心完全可以由不同的 DBA 团队运营，就算其中一个团队出现问题，也不会对另一个团队运维的系统产生影响。

第二，数据的备份很多企业都非常重视，但是可能会存在一个团队能够管理和随意修改备份文件。这种情况下，假设这个团队的成员在内部进行破坏，将生产系统和备份全部销毁，会导致整个企业 IT 系统的完全瘫痪。因此，如何将历史数据和在线数据的管理隔离，也是企业内部安全流程非常重要的管理措施。

最后，笔者对该网站出现的故障深表同情，也希望各大其他的企业引以为鉴，多多注重数据安全，避免相同的事故重演。