容灾双活

如何做到“高可用/容灾”

正如上图所示，整个容灾体系分为很多层（本文的重点是数据高可用层）：

• 业务的高可用主要体现在游戏分区、地域单元化等操作上，不仅仅是解决服务器压力的问题，同时也是为容灾考虑。
• 应用架构高可用保障主要包括：Web端的负载均衡、应用的无状态，消息的可重复投递等操作。
• 数据库高方面可以通过一主多备、读写分离以及自动Failover等部署实现高可用的保障。
• 在硬件、存储方面，高可用的保障措施包括硬件冗余、Raid、共享存储等。

数据库故障识别

数据库远程探测主机或实例通常是通过数据库外部短连接进行更新或查询记录的方法直观地探测数据库是否可用，根据查询或更新的结果感知故障情况。

远程探测主机或实例可用性的常用方法

（三）当出现连接成功，Socket超时或SQL超时（hang）的情况时，说明主机可以连接，端口在监听，但数据库无法响应。这种故障是目前所有故障中最难判断的一种，一般需要结合采集实时DB性能、主机存储数据和网络性能信息进行综合判断。

（四）当出现连接成功，更新报错或者DB层连接失败的情况时，说明数据库内存产生了错误，如too many connection等问题，这类错误是由于数据库的使用不当或客户端的驱动存在问题导致，这种问题不是主机的故障，需要进行应用级别的告警，而非实例级别的failover。

除此之外还有一对多的探测模式，例如三节点探测模式。

• 点探测模式最重要的是可以通过选举协议（如RAFT协议）选取一个leader，然后由内部通信判断哪一个节点是孤岛，也就是少数派自动降级，不再对外提供服务，同时结合外部的HA进行链路上的Failover或切换，从而规避了双写问题的出现，使得实例的可用性达到最大。

常机房故障都被认为是大面积故障，例如整个机房断电、整个机房火灾或两个机房之间的网络断开等情况。

左侧和右侧分别是单独的机房，机房外部的探测系统可以从外部探测机房内的状况，这其中有一个很容易被忽略的关键点：不仅仅需要探测机房内的主机或服务器实例，探测机房之间核心路由器、交换机等网络设备也是至关重要。通过机房主机间二层网络探测是最直接、方便的探测方式，可以直观地反应机房当前的网络状况。

当机房级别的故障产生时，一般不建议进行全自动化切换。因为在机房出现故障时，很难判断到底是机房内哪一部分出现了问题。但如果将机房容灾做成一个产品，外部一旦触发机房故障切换动作（这个过程可以是人来判断或半自动化判断，切换的过程可以是自动化操作），就可以按照之前的预案进行容灾操作。

双机房部署时，当两边的机房都部署了HA，最重要的是要避免HA的脑裂，因为两边的HA都想接管自己机房的实例，如果判断发现对端机房服务器不可达、连接超时，而本机房DB备库可用时，则可能会启动备库提供服务。但这种情况不应该出现，因为两边的数据库都是主库，会出现双写情况发生。在双机房部署时，实现机房级别的容灾，应该避免应用跨机房访问，或跨机房访问后，能自动关闭应用，流量自动failover。

保证数据可靠性

在金融行业内保证数据的可靠性是非常重要的前提。通常所讲的数据可靠性包括两个方面：RPO和RTO，最好的情况是RPO为零，RTO最小，RPO为零意味着所有的数据均不丢失，数据完整；RTO最小意味着对用户的影响最小。

更多情况下，我们考虑的是多机之间的互备；实际上，单机单库情况下某些点也是非常重要的：

第一点，硬盘方面采用SAS、SATA或SSD均可，重点是做RAID5/RAID10，同时RAID卡带备用电池BBU；

第二点，做到日志盘与数据盘分离，因为顺序读/写和随机读/写对磁盘的要求是不同的。

第三点，日志及时转移，避免在主机堆积，所有数据库级别采取的日志都需要转移到第三方存储上。

第四点，注意FSYNC vs ASYNC mysql的“双1”配置，pgsql的sync配置，因为性能和安全二者不可得兼，需要在不同的业务的DB上选择合适的配置，要选择在断电情况下，数据文件，日志文件结构能保证完整的数据库，如PG，MSSQL。

第五点，注意SSD的磨损指数、机架的功率负载、机器的质保期等等，当然云计算条件下这些自己就不用考虑了。

第六点，注意进行及时的数据备份、日志备份

一主一备架构

一主一备是最常见的也是最简单的数据库容灾架构，一主一备通常采用Share-nothing结构，两边存储相互独立。在一主一备的情况下，为了保证可靠性，DB间的数据同步方式采用的是半同步模式。链路切换过程最为重要的四步包括master RO、wait sync to master on slave、switch Route、slave RW。每个步骤都要有超时、回滚以及主库故障时的对应措施。切换后，元数据需要进行更新，因为主库角色已经发生了改变；旧主库需要进行重搭、只读或者与新主库复制关系搭建等操作。

该架构的优点是：架构简单，资源利用少、成本较低；但是它的可靠性并不是很高，这是因为主备之间采用半同步模式，但并不能保障数据的完全不丢失，当网络和主库同时断开时，备库和主库的数据一定是不同步的，此时会有少量的数据丢失。

保障数据的可靠性

share-noting架构，存储是相互独立的。下面讲一下share-disk架构，即共享存储架构。共享存储架构中master和slave都在server层，两者的存储都不在本地。使用共享存储发生切换时，master server挂掉之后切到slave上，下面的共享存储仍旧正常，可直接通过数据对外提供服务。由于事物日志和数据文件相互分离，slave接管之后需要将事物日志应用下去，从而导致recovery的时间会很长。因此使用共享存储架构时，事物日志一定要保留的尽可能短。

链路切换过程十分简单，因为它不涉及master RO、Wait sync to master on slave外部操作。切换后处理也需要进行元数据更新，以及旧主库重搭（重搭的代价很小）、旧主库只读、旧主库与新主库复制关系搭建等操作。

共享存储的优点是架构比较简单，上层的server切换非常轻量；缺点是共享存储必须保证可靠，这是因为共享存储也并非单点结构，数据需要写多份。