数据库高可用架构浅析

数据库作为信息系统重要的基础设施，一直承担着压舱石的角色。互联网应用的高并发、海量数据使得数据库的负载越来越重，这在数据大集中的情况下愈发明显。而数据库作为信息系统唯一的“单点”，稳定性、可用性是首先要保证的目标。这里的单点并不是指数据库没有高可用方案，而是因为数据库只要涉及到数据的复制就一定是有状态的，有状态的应用更加难以运维，并且在遭遇异常时并不能做到真正意义上的无缝切换。

传统关系型数据库经过几十年的发展，目前高可用方案都已经非常成熟，目前数据库常用的高可用方案主要包括：主机HA、数据库主备和数据库集群方案。主机HA由于其适用范围广、切换时间短被广泛应用于生产环境的各类数据库上，主机层面的高可用这里不再讨论。

主备方案

主备方案是目前数据库最常用的高可用方案。主备模式主要涉及到两个问题：①数据同步问题；②主备切换问题。

数据同步涉及到不同同步模式的选择，如果采用同步模式备机宕机可能影响主机业务，同时影响性能，如果采用异步模式可能造成数据的丢失。由于银行业务的特殊性，信息系统的rpo要求等于0，即不允许数据的丢失，所以银行业一般采用同步模式，同时现在的数据库产品为了保证性能和可用性会在同步和异步之间有一个折中方案。下面就以DB2 HADR、ORACLE ADG、MYSQL半同步为例介绍一下主备方案。

DB2 High Availability Disaster Recovery

上图是hadr的架构图，可以看到hadr总共有四种同步模式：

SYNC：主备数据库都将日志成功落盘，应用才能提交。这是最大数据保护模式，但性能损耗较大。

NEARSYNC：日志只要写到主机磁盘和备机的缓冲区，就可以提交。这种模式类似半同步，也是生产环境一般采用的方式。

ASYNC：日志只要写到主机磁盘同时发送到主机的TCP层，就可以进行提交，可能造成数据丢失。

SUPERASYNC：主库只要成功落盘，就可以提交。性能最好，可能造成数据丢失。

如果因为网络问题造成复制延迟过大，不能及时同步日志信息的话，DB2数据库会自动切换为异步模式，来保证主库的可用性。DB2 V9.7开始，HADR 开始支持ROS(Read On Standby)，备机可以接收连接，执行读操作。Db2数据库执行”db2pd -hadr”命令可以查看hadr当前的状态，包括 Local Catchup、Remote Catchup、Remote Catchup Pending、Peer、Disconnect Peer、Disconnected几种。

Local Catchup：备机正在从本地磁盘读取日志并进行重放。

Remote Catchup：主机正在将日志发送给备机，备机正在接收日志，写到磁盘并且应用日志。

Remote Catchup Pending：备机读取完本机的日志后会进入该状态。

Peer：日志不是从磁盘中读取，而是直接通过网络传输到备机，进行应用。

Disconnect Peer：主备之间网络有延迟，但是延迟的窗口还在hadr_peer_window参数值以内，这部分事务是无法提交的，当网络恢复后变为peer状态。这样保证了数据不丢失的同时有一定的网络波动容忍性。

Disconnected：主备之间网络中断，如果设置了hadr_peer_window延迟缓冲窗口，超过了hadr_peer_wait_limit设置的值就认为主备连接中断，如果未设置hadr_peer_window窗口，则超过hadr_timeout参数值就认为连接中断。

Oracle Active DataGuard

Oracle从11g开始推出active data guard功能，支持备库以read only的方式打开，同时应用日志，这样就从另一个层面支持了读写分离。oracle adg支持三种数据保护模式。

最大保护模式：该模式提供了最大级别的数据保护，redo日志在至少一个物理备库成功应用后主库才可以提交，如果备库发生宕机，主库找不到可以写入的备库时，主库的业务会中断。该模式对性能影响较大。

最大可用模式：redo日志在至少一个物理备库成功应用后主库才可以提交，如果备库发生宕机，主库找不到可以写入的备库时，会自动降级为最大性能模式，这种模式是一种折中方式，在提供数据保护的情况下保证了主库的可用性，是生产环境中一般采用的方案。

最大性能模式：主库的提交不受备库的影响，保证了主库的可用性和性能，但是可能造成数据丢失。

下图为adg架构图：

主库向备库发送日志有两种方式，一是通过归档进程arch发送，这样的话就需要等待redo日志切换归档日志生成后才能进行发送，这个明显是异步的。另一种方式是通过lgwr进程进行发送，lgwr在写redo的同时将redo通过lns进程发送到备库，备库通过rfs进程进行redo日志接收，mrp进程进行日志apply。另外，adg支持备库的实时应用（real_time_apply），使用该功能需要在备库创建standby redo log，srl只在备库是活动的，srl大小必须和orl的大小一致，个数一版按照每个日志线程N+1的数量来配置，使用srl的好处除了支持实时应用外还能提高性能。通过alter database recover managed standbydatabase using current logfile;命令启动实时应用。

MySQL semi-replication

Mysql从5.7开始支持半同步，下图是mysql半同步的原理图，与db2和oracle不同的是，mysql半同步不是基于物理redo的同步，而是基于binlog的偏逻辑的复制。主库将数据改变记录到binlog日志中，dump线程不断读取binlog中的内容，从库的io线程负责接收binlog并写入中继日志relay log中，同时io线程会更新master.info文件中的位置信息。从库的sql线程负责对relay log中的信息进行apply，已经应用过得relay log会进行清理。

在Mysql5.7之前的版本，主库先提交事务，然后将binlog传递到备库并刷到relay log中，然后备库会返回给主库ack表示已经收到relay log，这时主库才给应用返回提交ok。这种方式如果在发送binlog的时候主库宕机则会有数据丢失的风险。

5.7之后支持after_sync模式，主库必须等到备库的relay log落盘后返回的ack才能进行提交，这样就保证所有改变都写入到了备库的relay log，解决了数据丢失的问题。半同步通过rpl_semi_sync_master_timeout参数控制窗口大小，如果超过该窗口未收到反馈，就会变成异步模式。

总结

对于数据库来说，其实任何主备方案都涉及到几个问题：

一是同步方案的选择，如果要做到rpo=0一定要支持同步，同时要支持同步模式的智能切换，在备库宕机时不能一直影响主库的业务；

二是考量同步对性能的影响，以及业务读写分离对一致性的要求，像db2、postgresql都提供了三种以上的同步模式，根据性能要求选择合适的同步模式，例如数据是发送到备库的缓存，还是落盘，亦或是落盘后apply成功主库才能提交？

三是关于切换方案怎么做，可能现在数据库都只会提供主从复制，但是很少有直接提供切换方案的，这个时候就需要考虑是否有开源的主流切换方案，如果没有是否可以使用虚拟机或者主机层面的集群软件，亦或是自行开发网关，进行探活、切换、注册等。