数据库容灾技术与数据库的容灾架构紧密相关，在设计数据库容灾技术时，除了要考虑数据库容灾架构还要对数据的备份、恢复、传输等具体操作的实现细节。一套完整的数据库容灾技术既要有采用数据备份保护和恢复数据的功能，也要有保证数据安全、正确、高效传输的功能，同时还要有强大的应激防护能力。

数据备份是以容灾为目的，为防止故障导致的数据丢失，而将全部或者部分数据复制到其他存储介质的过程。备份过的数据往往通过压缩打包保存，提升存储效率。备份数据一般不能直接提供数据库服务，需要一套数据恢复操作流程进行备份逆操作，在现有数据库实例或基于空闲资源搭建新实例，覆盖原有数据，才能再次通过该数据库实例进行访问。所以数据备份也称为数据冷备。

1.数据备份

数据库的备份技术从备份机制可分为物理备份和逻辑备份两种。物理备份是针对数据库的数据文件进行备份的方式。物理备份往往是将数据库的数据文件连同备份时间窗口内的重做日志一同进行备份。备份完成后，备份程序会重新执行重做日志，保持数据文件中数据的一致性。由于物理备份主要备份内容是复制数据库数据文件，能最大程度利用IO，备份效率很高。逻辑备份是针对数据库的数据内容进行备份的方式。

全量备份是基于时间点的数据库镜像，而增量备份是将此时间点扩展到持续的时间窗口。通过全量备份和增量备份，数据库可以恢复备份覆盖的时间范围内任意时间点的数据状态。同时数据恢复也可指定恢复目标，将恢复范围限制为部分库表，可大幅降低恢复时间开销。

按照监管要求，核心业务系统生产中心的数据库数据能实时同步传输到异地的灾备中心。下面以MySQL数据库场景为例，介绍几种不同的同步传输技术，供数据库容灾架构规划参考。

MySQL主从复制6是一个异步的复制过程，主库发送更新事件到从库，从库读取更新记录，并执行更新记录，使得从库的内容与主库保持一致。

每一组主从复制的连接，都由三个独立的线程协作实现。在主库上为每一个连接到主库的从库创建一个二进制日志(以下简称“binlog”)输出线程。每一个发送给从库的SQL事件或者数据变更事件，都会基于binlog传输给从库。而每一个从库都会为同步创建一个I/O线程和一个SQL线程。I/O线程连接到主库并请求主库发送binlog事件到从库，读取到的binlog会更新到本地中继日志（以下简称“relay-log”）文件。而SQL线程读取到I/O线程写到relay-log的更新事件后，在数据库中进行执行，从而完成数据从主库到从库的同步。

半同步复制是MySQL 5.5版本引入的机制7。半同步复制出现前，虽然异步复制可以满足主从实例之间的数据同步要求，但如果主库崩溃，将从库提升为主库时，原来的主库上可能有一部分已经提交的数据还没有来得及被从库接收，主从不一致将导致切换后的新主库丢失这一部分数据。

半同步复制改进了事务提交的逻辑。客户端在主库上写入一个事务时，需要等待从库接收到主库相关的binlog数据，且主库接收到从库的应答之后，客户端才能收到事务成功提交的消息。

早期的半同步复制存在一些缺陷。主库在等待应答的过程中，存储引擎内部已经提交的事务，只是阻塞返回客户端消息而已，此时如果有其他会话对该会话事务修改数据进行查询会查询到数据。如果此时出现主库故障转移，非发起数据库提交的客户端可能会出现幻读。所以MySQL 5.7版本对半同步进行了优化，称为增强半同步复制。优化后一个事务在存储引擎内部提交之前，必须要先收到从库的应答确认，否则不进行事务的最后提交，从而解决上述提到的幻读问题。

MySQL在5.7版本正式推出组复制（MySQL Group Replication8，以下简称“MGR”）机制。MGR集群由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点决议并通过才能得以提交。

引入组复制，主要是为了解决异步主从复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议实现了分布式架构下数据的最终一致性，提供了MySQL集群的多主写入方案。

MGR技术与Oracle RAC类似，对集群网络的要求非常高。网络延时和不稳定会严重影响MGR集群的正常工作，所以多用在单数据中心的内网环境中，对于主备和多活容灾架构下异地同步的场景，存在一定的短板。

半同步复制机制保障了主库故障切换时事务数据能够在至少一个从库中持久化存储，保证切换过程不丢失最新数据。随着数据库集群规模逐渐增大，同城和异地多机房灾备架构对同步的要求也愈发提高。当跨多机房部署的集群出现大规模故障，例如机房故障或专线故障时，主库和完成接收binlog数据的从库节点可能同时出现故障。因此在半同步的基础上，出现了分组强同步机制。

分组强同步机制能够保证在跨机房的场景下仍然保持高可用和强同步的能力。任何一个集群的从库可以分成若干组，在每一组中，只要有一个从库返回成功，则认为该组复制成功。当所有的组都复制成功，主库的事务才能完成提交。

分组强同步复制算法可以保证已经提交成功事务的数据不丢失，修复了MySQL原生半同步可能丢失数据的隐患，确保在主库发生故障情况下，不会因为二进制日志丢失导致从库丢失数据，进一步提升了数据的可靠性。

为了与数据库产品配套，云平台供应商和数据库厂商推出数据传输服务（DTS），该服务用于在异构数据库之间进行数据迁移、数据同步和数据订阅。DTS 支持在业务不影响源数据库服务的前提下进行数据库迁移，利用实时同步通道构建异地容灾的高可用数据库架构。DTS 往往支持在主流数据库之间进行结构迁移、全量数据迁移和实时增量数据同步，其迁移同步任务还可按照同步范围并行进行同步。

数据传输服务在异地灾备场景下也被作为异步同步的重要方案。

当分布式数据库各类节点出现故障时，其监控系统应该能实时感知到故障种类和范围，包括各类节点的进程故障、服务器故障、磁盘故障和网络故障等，都可以依据预案配置，自动进行故障切换。

主备容灾架构下，容灾机房内会建设一套与生产机房相同规模的服务。如果生产中心出现灾难而不可用，数据库管理系统应该能自动将数据库服务切换至灾备中心。在异地容灾架构下，数据库甚至能够抵御地理级灾难，如地震洪水等。该类灾难可能会影响整个城市区域，使得同城机房均不可用，从而将服务切换至异地容灾中心。

以SQL Server数据库为例，介绍集中式架构数据库的典型故障切换技术。SQL Server采用SQL Server Always On可用性组来支持对一组分散的数据库实施故障转移。一个可用性组支持一组读写主数据库，以及一至八组对应的辅助数据库(包括一个主副本和最多四个同步提交辅助副本)，每个副本承载一组辅助数据库，同时也是可用性组的潜在故障转移目标。发生故障转移时，数据库通过一组独立的服务器故障转移群集服务，将实例的资源所有权转移到指定的故障转移节点。然后SQL Server实例在故障转移节点上重新启动，使数据库恢复如常。无论在任何时刻，故障转移群集中只有一个节点可以承载故障转移群集实例和基础资源。

Always On可用性组主副本将每个主数据库的事务日志记录发送到每个辅助数据库，每个次要副本则缓存事务日志记录，然后将日志记录应用到相应的辅助数据库。主数据库与每个连接的辅助数据库独立进行数据同步。因此一个辅助数据库可以挂起或失败，但不会影响其他辅助数据库，一个主数据库也可以挂起或失败，也不会影响其他主数据库。

分布式数据库架构由于进程、磁盘和服务器等故障，往往导致集群的少量节点实例不可用，应对措施主要是通过冗余和副本节点进行替换止损，替换过程中可能出现主备切换或主从切换；对于交换机、路由器等网络设备发生故障，除了导致部分节点实例不可用外，还可能出现集群分裂情况，因此分布式数据库需要建立应付各种类型和规模故障的容灾能力。

当其中一个计算节点出现故障，流量以秒级切换至其他计算节点。整个切换过程对用户透明，应用代码无需变更，应用进程无需重启。

计算节点自愈分为故障感知和故障处理两部分。故障感知是指通过节点代理的定时任务定期执行自愈监控项采集任务，对计算节点的监控指标进行采集，并上报至服务自愈模块，该模块对节点的监控数据进行分析，对可能的故障信息进行定位和二次检测，若确定为故障则发起故障处理任务。故障处理是指服务自愈模块检测到故障节点，任务调度模块创建自愈任务，自动对故障节点进行恢复处理，处理完成后故障节点重新上线恢复正常服务。

分布式数据库采用多副本保存数据，存储节点通过多副本方式构成集群。最常见的集群模式是主从集群，即一个主节点负责写入，并基于一定的一致性算法同步至其他从库。当对外提供数据库服务时，主库承担读写服务，从库提供只读服务。当主库节点故障时，系统会自动发现并尝试恢复主库，如果主库无法恢复则发起主从切换。

切换协调模块为切换核心模块，负责存储节点健康诊断、切换仲裁与协调，并变更集群的拓扑信息。如上图所示，数据库实例的三个节点代理构成了切换的协调者。节点代理通过与决策集群通信获取其托管的集群元信息，并借助集群取得集群中其它节点代理的通讯方式。

金融类业务数据模型复杂度较高，往往需要多维度进行数据处理和分析。进行业务系统分布式改造时，分片策略往往无法避免一个事务可能跨越多个数据分片的情况，需要通过分布式事务保证数据的强一致性。为保障分布式事务在跨节点处理时事务的原子性和一致性，一般使用分布式协议处理。常用两阶段提交、三阶段提交协议保障事务的原子性；使用Paxos、Raft等协议同步数据库的事务日志从而保障事务的一致性。支持分布式事务是金融级分布式数据库产品的核心特性，分布式事务的容灾能力是分布式系统容灾能力的重要考量指标。

百度分布式数据库GaiaDB-X采用基于优化的XA协议及两阶段提交算法实现分布式事务机制。其优势有：1）自研DMVCC11算法，解决分布式全局读一致性问题；2）解决MySQL原生XA在事务一致性和持久性上的缺陷；3）在宕机等故障场景下，能够基于持久化的全局事务状态对悬挂事务进行提交或回滚，保证分布式事务的容灾恢复能力；4）支持备份恢复的事务一致性、死锁检测等高级功能。