“数据不能丢，业务不能停”是关键核心业务系统的诉求，这对数据库的高可用性提出了很高的要求。中国数据库想要挑起大梁，服务好关键业务场景，必须具备强大的高可用能力，拥有相对完善的高可用解决方案，从而最大程度地保障业务的连续性。现在有哪些主流的数据库高可用解决方案？企业该如何选择适合的高可用解决方案？如何更好保障业务连续性？
针对以上问题，近日南大通用GBase 8s产品经营部总经理崔志伟接受了数据库技术社区ITPUB的采访，他表示：对业务连续性的追求没有止境，当前国内数据库市场有着丰富的数据库高可用架构，企业需要根据业务场景需要来选择合适的高可用解决方案。
数据库高可用架构演进历程
高可用性（HA，High Availability）是指系统在面对硬件故障、软件崩溃、网络问题等各种故障情况时，仍然保持运行并提供服务的能力。通过设计减少系统不能提供服务的时间，通过冗余和自动故障转移等方法来提高系统的可用性，避免单点故障，从而确保系统的高稳定性和持续性。
早期的数据库并没有高可用架构，主要通过定期数据库备份和日志归档等方式来提供可用性，数据库很容易成为单点故障点，彼时高可用更多是通过操作系统层面提供集群软件来管理包括数据库在内的软硬件，比如IBM高可用性集群软件HACMP，它主要用于AIX操作系统，提供高可用性和故障转移功能，确保关键业务应用的连续运行。
上个世纪90年代，随着互联网的兴起和企业对数据依赖性的增加，高可用性成为数据库系统设计中的一个关键因素。数据库开始引入冗余和故障转移机制，以提高系统的可靠性和可用性。
数据库高可用架构随着存储、网络等硬件技术的发展、业务需求不断演进，从单机到主备式集群，再到共享存储集群，再到分布式集群，出现了越来越丰富的高可用方案。
以Oracle这位行业引领者为例，陆续推出了主机HA（Highly Available）、ADG（Active DataGuard）、RAC（Real Application Cluster）、OGG（Oracle Golden Gate）等多种形式。这些高可用架构可以单独使用，也可以组合使用，多年来，为金融机构、电信运营商的关键核心业务提供了稳定可靠的高可用服务。
比如，Oracle主备式高可用ADG，早期称为DG，主节点可读可写，但是备节点无法提供查询。Oracle 11g引入了Active Data Guard（ADG），允许备节点用于查询，从而减轻主节点的负载，进一步提高了系统高可用性。后面，ADG又提供了最大保护、最大可用、最大性能三种数据保护模式，供用户灵活选择。
2000年发布的Oracle 9i是一个重要的里程碑，推出了Real Application Clusters（RAC）技术。RAC是属于典型的shared-everything架构，即共享存储集群技术，允许多个服务器共享一个数据库实例，从而提供了高可用性和负载均衡能力。如果一个节点发生故障，其他节点可以继续提供服务，确保系统的连续性。随着RAC技术不断成熟，越来越多的大型企业的核心数据库选用了RAC技术。
在国产化替代背景下，虽然国产数据库的技术堆栈发生了变化，但是业务对数据库的高可用要求并不会弱化，只会越来越高。国产数据库需要在高可用性技术上达到Oracle的同等水平甚至有所突破才能逐步实现各行业关键核心业务的替换。
目前，国产数据库大多已经借鉴Oracle构建了自己的完整高可用架构，以南大通用GBase 8s数据库为例，就有一整套对标Oracle高可用的技术栈来确保业务系统的高可用服务。
比如，GBase 8s主备式集群支持HAC和RHAC两种集群方式。HAC是一主一备集群模式，可以根据网络传输条件选择全同步、近同步和异步三种redo log复制形式，对标Oracle ADG的最大保护、最大可用、最大性能三种工作模式。RHAC支持一主多备，采用异步传输机制。
GBase 8s共享存储高可用集群SSC（对标Oracle RAC），采用共享磁盘方式实现节点高可用，数据仅存储一份，支持多写多读，有效利用硬件资源，避免数据重复存储问题，共享存储支持磁盘阵列也支持分布式存储。
在集中式数据库领域，RAC共享存储集群有较高的技术难点，被视为珠穆朗玛峰般的存在，而国产数据库在类RAC集群的突破无疑叩开了高端场景的大门。不过虽然很多国产数据库拥有类RAC集群，但是能够支持多写多读的并不多，很多备节点都是只读状态，集群吞吐量小于单机处理能力。
崔志伟指出，所有IT技术最终都要服务于业务发展。国产数据库高可用架构已经实现了从无到有。走到了从有到优的路上，接下来，大家在不断完善高可用方案的同时，都会向着降低主备切换时间方向努力，不断提升业务连续性，提升集群吞吐量。
如何选择合适的高可用方案？
可能有人说，既然业务连续性那么重要，就尽量使用更高级别的高可用架构，如果您不差钱，悉听尊便。但现实中，即使银行这样非常有实力的金融机构，在构建高可用时也要反复权衡思量，不敢任性，因为高可用方案太烧钱了。无论同城灾备还是异地灾备，机房、网络等都需要大量真金白银投入。
崔志伟介绍，不同的高可用解决方案有各自的特点，他建议企业可以根据业务场景需要，结合自身资金、机房、网络条件选择不同的高可用解决方案。
比如主备式集群这一常见的高可用方案，比较适合小数据量，以及对数据一致性等要求不是特别严苛的业务场景。
一方面，主备式集群的冗余需要多存储数据副本，会带来额外存储成本。另一方面，出现故障后，数据同步、主备切换需要一定的时间。如果数据量达到几十T，会带来较高的存储成本，也会增大主备切换的时间窗口。此外，主备式集群的数据同步不太容易保证两个节点的数据强一致性，很多国产数据库会通过读写分离插件弥补这方面的不足。
共享存储集群，很好地解决了存储成本和数据强一致性问题，适合大数据量以及对数据强一致性要求较高的业务场景。
共享存储集群用最少的硬件、最少的数据库，实现高性能，保持业务连续性，是整体性价比较高的一个高可用方案。只不过，共享存储集群集群比较复杂，有较高的技术门槛，需要数据库的维护和开发人员具有比较高的专业能力。此外，共享存储集群对硬件、数据库软件有较为苛刻的要求。为了实现数据强一致性，信息同步需要非常高的网络带宽，比如Oracle RAC心跳网络基本万兆起步，而Oracle一体机在内部心跳甚至会使用40GB的专业高速网络。
崔志伟指出，一般政企客户数据量没有那么大的业务场景，大多会选择主备式集群高可用方案，但是在类似金融领域需要数据强一致性的业务场景，以及大数据量（数据量超过10T、20T）的业务场景，会选择共享存储集群解决方案。
GBase 8s提供了相对完善的高可用解决方案供企业灵活选用，比如主备高可用HAC/RHAC、共享存储集群高可用SSC、数据实时同步ER。
• GBase 8s HAC集群，适用于对网络延迟比较敏感的业务，建议同城或同机房部署，考虑到单服务器磁盘可用容量的限制，数据量不超过10T时可以采用HAC。远距离传输、异地容灾的业务场景，可以采用RHAC集群。由于远距离传输，带宽小，会增大网络延迟，RHAC会通过异步检查点机制和数据压缩来优化对带宽的使用。
• GBase 8s共享存储高可用集群SSC，是类RAC技术，支持共享存储，保证数据的强一致性，集群为主控对等管理模式，集群节点数最多可达16个，所有节点均可读写。当主节点失效时，辅助节点可以升级为主控节点，保障系统的高可用。在数据量低于100TB的业务场景中，相对于分布式数据库而言，共享存储集群是性价比最高的高可用方案。对于数据量超过100T的业务，分布式数据库可能比集中式数据库更为合适。
• GBase 8s 数据实时交换共享集群（对标OGG），内置以表为单位的数据实时同步能力，更多应用在数据交换共享场景，比如，部省市县数据实时交换共享业务场景，商超门店等平行单位之间数据实时交换共享场景。
企业可以单独部署主备高可用或者共享存储集群高可用，也可以组合使用，搭建同城双中心（SSC+HAC）、两地三中心（SSC+HAC+RHAC）等更高级别的高可用方案。
GBase 8s两地三中心方案
目前，GBase 8s高可用集群解决方案可以实现RPO=0，RTO＜30s，在真实业务场景中，大概10-15s就能完成主备切换。
GBase 8s高可用集群凭借出色的能力，已经服务了众多金融、轨道交通、能源、政府等行业的关键核心业务，赢得了关键行业客户的信赖。
比如，国家电网调度云平台，业务数据超过50TB，采用SSC+RHAC高可用方案成功替换Oracle，通过上千公里远程异地容灾方案建设，实现本地、异地读写分离双活集群秒级数据同步，数据库对应用完全透明，最长持续运行超过600天。
深圳地铁CLC二期与互联网票务管理系统在生产云主中心及各站点处搭建SSC+HAC方式，实现高可用集群功能。满足4000并发稳定运行1小时以上，千万级数据量，毫秒级查询响应。
某西南城商行核心系统采用SSC+HAC高可用方案，数据库完成替换之后，持续在线运行超过760天，充分体现了GBase 8s的稳定性。
小结：追求业务连续性无止境
未来，GBase 8s将不断优化完善其高可用方案，比如提供更细颗粒度的资源管控能力，在主节点出现故障后，锁住受影响部分事务涉及的表，其他表依然能打开去做交易。另外，提供会话保持以及事务保持能力。在共享存储集群中支持数据分片，减少冲突等等。
“保证客户业务连续性最好，不论数据库发生什么样的故障，对客户来讲没有感知，这是我们追求的终极目标。”崔志伟说，GBASE南大通用将持续打造用户值得信赖的数据库，越来越多的真实用户场景已经将GBase 8s打磨得更稳定可靠，目前其SSC集群已经上线了几百套，客户的认可给了他很大的信心。
数字经济时代，企业对业务连续性的追求永无止境。但是在有限资源的情况下，高可用也好，业务连续性也好，需要用户和厂商共同努力，才能取得更好的效果。
“在用户侧，领导和技术团队应该制定出合理的高可用切换目标，破开关键系统和高可用能力之间的强绑定，根据系统业务的真正特点去设计高可用目标。而在数据库厂商侧，则应该根据用户的应用场景需求去优化自己产品的高可用能力，不要总是拼一个不怎么靠谱的故障切换时间。”借用白鳝老师在其文章中这段话结尾，希望在用户与厂商共同努力下，系统高可用能力能不断精进，业务连续性能得到更好的保障。