高可用架构是关键数据库应用必须考虑的，昨天我的文章里也说过，数据库出故障不可怕，只要不出现业务受到严重影响的事故就可以了。而确保业务不出事故的方案中必然少不了数据库的高可用架构。

早期数据库是没有高可用架构的，数据库就成了著名的单点故障点。后来引入了HA，Oracle也祭出了OPS/RAC这个大杀器。98年的时候，我给客户上了第一个HA系统，当时数据库是在WINDOWS NT上的，HA软件用的就是著名的ROSE HA。自从Oracle RAC比较成熟后，数据库高可用基本上就是RAC的天下了。

2000年左右，Oracle推出了MAA高可用架构，Oracle RAC+DATAGUARD的组合构建了十分优秀的高可用体系。这些年O记的高可用方案越来越丰富，0数据丢失备份一体机，基于MAA+OGG的白金MAA架构等，层出不穷。很多商业银行也借助Oracle MAA构建出新的两地三中心架构，这个架构比起大型机中型机时代来，既安全又便宜。

进入国产数据库时代，技术堆栈发生了巨大的变化，不过高可用这个问题在国产数据库时代并不会弱化。我们依然需要为国产数据库构建类似Oracle HA/RAC/ADG/OGG等高可用架构以保障业务系统的安全运行。

国产数据库大多数已经模仿Oracle构建了自己的完整的高可用架构，以达梦数据库为例，就有一整套对标Oracle的技术栈来确保业务系统的高可用。

如上图，DM DataWatch是对标Oracle DataGuard的基于Redo复制的高可用解决方案，也是目前在达梦数据库应用中使用最为广泛的方案。

上图是目前在达梦用户中最为常用的一种基于DataWatch的高可用部署架构。A机房的主备库采用同步复制的模式，当主库故障时可以快速接管业务。B机房的备库可以根据网络条件选择同步或者异步复制模式，作为灾备解决方案。

而对于SLA要求更加严格的核心业务系统，达梦也可以利用其对标Oracle RAC的DM DSC集群+DataWatch的方案构建业务连续性更加优秀的高可用方案。

对于分布式数据库而言，其高可用解决方案则更为丰富，不过其建设成本也更高。我们以OceanBase为例，面对金融机构的业务连续性要求，在一套OceanBase分布式数据库集群中构建三地五中心的高可用架构。选择两个近地域，网络延时较低的城市的四个机房构建出四个业务ZONE，每个ZONE可以承担1/4的业务负载。而在较远地域的城市3建设第五个ZONE，如果你使用了4.X版本，第五个机房可以只放置日志，而不需要数据文件，从而节约成本。当然为了确保业务的性能，近地域机房之间的网络延时越低越好，最好能够低于2毫秒。

GaussDB也有类似的解决方案，上面是一个同城三中心双活的解决方案，AZ1/AZ2的8台服务器承担核心业务，可以通过全局负载均衡实现双活，AZ3只参与仲裁，因此在Server9上只部署了一个ETCD备实例。

经常有朋友问我，分布式数据库需要不需要类似Oracle ADG的架构呢?我的答案是根据自己的资金情况、机房情况、网络情况可以选择不同的高可用解决方案。对于不能出现严重故障的超关键的业务系统，怎么做高可用保障都是不为过的。上图是一个运营商的 CRM系统，主备集群分别位于两个城市。其中城市A的三个ZONE分别凡不在IDC1和IDC2两个数据中心里，构建了同城高可用环境。同时通过日志将数据复制到异地的另外一个OB集群里，平时这个集群承担一部分读的业务。这个模式是不是和Oracle RAC+ADG十分类似?

GaussDB在一些金融行业用户侧主推了一个基于Dorado双集群的高可用解决方案。采用的是GaussDB集中式部署模式，主库的Redo Log会写一份Shared Redo Log，这个Redo Log被Dorado同步复制到远程的另外一个Dorado集中式存储中，因此备AZ的GaussDB Standby数据库是零数据丢失的。这个和当年我们在Oracle ADG上实现零数据丢失的方案是一模一样的。