聊聊国产数据库的高可用架构

高可用架构是关键数据库运行肯定思考的，昨天我的文章里也说过，数据库出缺点无法怕，只需不出现业务遭到重大影响的意外就可以了。而确保业务不出意外的方案中肯定少不了数据库的高可用架构。

早期数据库是没有高可用架构的，数据库就成了驰名的单点缺点点。起初引入了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的高可用部署架构。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上成功零数据失落的方案是如出一辙的。