数据库容灾技术.docx

数据库容灾技术（一）数据备份与恢复数据备份是以容灾为目的，为防止故障导致的数据丢失，而将全 部或者部分数据复制到其他存储介质的过程备份过的数据往往通过 压缩打包保存，提升存储效率备份数据一般不能直接提供数据库服 务，需要一套数据恢复操作流程进行备份逆操作，在现有数据库实例 或基于空闲资源搭建新实例，覆盖原有数据，才能再次通过该数据库 实例进行访问所以数据备份也称为数据冷备1. 数据备份数据库的备份技术从备份机制可分为物理备份和逻辑备份两种 物理备份是针对数据库的数据文件进行备份的方式物理备份往往是 将数据库的数据文件连同备份时间窗口内的重做日志一同进行备份 备份完成后，备份程序会重新执行重做日志，保持数据文件中数据的 一致性由于物理备份主要备份内容是复制数据库数据文件，能最大 程度利用10，备份效率很高逻辑备份是针对数据库的数据内容进 行备份的方式2. 数据恢复全量备份是基于时间点的数据库镜像，而增量备份是将此时间点 扩展到持续的时间窗口通过全量备份和增量备份，数据库可以恢复 备份覆盖的时间范围内任意时间点的数据状态同时数据恢复也可指 定恢复目标，将恢复范围限制为部分库表，可大幅降低恢复时间开销。

二）数据同步与传输按照监管要求，核心业务系统生产中心的数据库数据能实时同步 传输到异地的灾备中心下面以MySQL数据库场景为例，介绍几种不 同的同步传输技术，供数据库容灾架构规划参考1.主从复制MySQL 主从复制6 是一个异步的复制过程，主库发送更新事件到 从库，从库读取更新记录，并执行更新记录，使得从库的内容与主库 保持一致每一组主从复制的连接，都由三个独立的线程协作实现在主库 上为每一个连接到主库的从库创建一个二进制日志（以下简称“binlog”）输出线程每一个发送给从库的SQL事件或者数据变更 事件，都会基于binlog传输给从库而每一个从库都会为同步创建 一个I/O线程和一个SQL线程I/O线程连接到主库并请求主库发送 binlog事件到从库，读取到的binlog会更新到本地中继日志（以下 简称“relay-log”）文件而SQL线程读取到I/O线程写到relay-log 的更新事件后，在数据库中进行执行，从而完成数据从主库到从库的 同步2.半同步复制半同步复制是MySQL 5.5版本引入的机制7半同步复制出现前， 虽然异步复制可以满足主从实例之间的数据同步要求，但如果主库崩 溃，将从库提升为主库时，原来的主库上可能有一部分已经提交的数 据还没有来得及被从库接收，主从不一致将导致切换后的新主库丢失 这一部分数据。

半同步复制改进了事务提交的逻辑客户端在主库上写入一个事 务时，需要等待从库接收到主库相关的binlog数据，且主库接收到 从库的应答之后，客户端才能收到事务成功提交的消息早期的半同步复制存在一些缺陷主库在等待应答的过程中，存 储引擎内部已经提交的事务，只是阻塞返回客户端消息而已，此时如 果有其他会话对该会话事务修改数据进行查询会查询到数据如果此 时出现主库故障转移，非发起数据库提交的客户端可能会出现幻读 所以MySQL 5.7版本对半同步进行了优化，称为增强半同步复制优 化后一个事务在存储引擎内部提交之前，必须要先收到从库的应答确 认，否则不进行事务的最后提交，从而解决上述提到的幻读问题3. 组复制MySQL 在 5.7 版本正式推出组复制（MySQL Group Replication8， 以下简称“MGR”机制OMGR集群由若干个节点共同组成一个复制组， 一个事务的提交，必须经过组内大多数节点决议并通过才能得以提交引入组复制，主要是为了解决异步主从复制和半同步复制可能产 生数据不一致的问题组复制依靠分布式一致性协议实现了分布式架 构下数据的最终一致性，提供了 MySQL集群的多主写入方案。

MGR技术与Oracle RAC类似，对集群网络的要求非常高网络 延时和不稳定会严重影响MGR集群的正常工作，所以多用在单数据中 心的内网环境中，对于主备和多活容灾架构下异地同步的场景，存在 一定的短板4. 分组强同步半同步复制机制保障了主库故障切换时事务数据能够在至少一 个从库中持久化存储，保证切换过程不丢失最新数据随着数据库集 群规模逐渐增大，同城和异地多机房灾备架构对同步的要求也愈发提 高当跨多机房部署的集群出现大规模故障，例如机房故障或专线故 障时，主库和完成接收 binlog 数据的从库节点可能同时出现故障 因此在半同步的基础上，出现了分组强同步机制分组强同步机制能够保证在跨机房的场景下仍然保持高可用和 强同步的能力任何一个集群的从库可以分成若干组，在每一组中， 只要有一个从库返回成功，则认为该组复制成功当所有的组都复制 成功，主库的事务才能完成提交分组强同步复制算法可以保证已经提交成功事务的数据不丢失， 修复了 MySQL原生半同步可能丢失数据的隐患，确保在主库发生故障 情况下，不会因为二进制日志丢失导致从库丢失数据，进一步提升了 数据的可靠性5. 云数据库数据同步服务为了与数据库产品配套，云平台供应商和数据库厂商推出数据传 输服务（DTS）,该服务用于在异构数据库之间进行数据迁移、数据同 步和数据订阅oDTS支持在业务不影响源数据库服务的前提下进行数 据库迁移，利用实时同步通道构建异地容灾的高可用数据库架构。

DTS 往往支持在主流数据库之间进行结构迁移、全量数据迁移和实时增量 数据同步，其迁移同步任务还可按照同步范围并行进行同步数据传输服务在异地灾备场景下也被作为异步同步的重要方案三）故障自动切换当分布式数据库各类节点出现故障时，其监控系统应该能实时感 知到故障种类和范围，包括各类节点的进程故障、服务器故障、磁盘 故障和网络故障等，都可以依据预案配置，自动进行故障切换主备容灾架构下，容灾机房内会建设一套与生产机房相同规模的 服务如果生产中心出现灾难而不可用，数据库管理系统应该能自动 将数据库服务切换至灾备中心在异地容灾架构下，数据库甚至能够 抵御地理级灾难，如地震洪水等该类灾难可能会影响整个城市区域， 使得同城机房均不可用，从而将服务切换至异地容灾中心1.集中式架构以SQL Server数据库为例，介绍集中式架构数据库的典型故障 切换技术SQL Server采用SQL Server Always On可用性组来支持 对一组分散的数据库实施故障转移一个可用性组支持一组读写主数 据库，以及一至八组对应的辅助数据库（包括一个主副本和最多四个 同步提交辅助副本），每个副本承载一组辅助数据库，同时也是可用 性组的潜在故障转移目标。

发生故障转移时，数据库通过一组独立的 服务器故障转移群集服务，将实例的资源所有权转移到指定的故障转 移节点然后SQL Server实例在故障转移节点上重新启动，使数据 库恢复如常无论在任何时刻，故障转移群集中只有一个节点可以承 载故障转移群集实例和基础资源Always On可用性组主副本将每个主数据库的事务日志记录发送 到每个辅助数据库，每个次要副本则缓存事务日志记录，然后将日志 记录应用到相应的辅助数据库主数据库与每个连接的辅助数据库独 立进行数据同步因此一个辅助数据库可以挂起或失败，但不会影响 其他辅助数据库，一个主数据库也可以挂起或失败，也不会影响其他 主数据库2.分布式架构分布式数据库架构由于进程、磁盘和服务器等故障，往往导致集 群的少量节点实例不可用，应对措施主要是通过冗余和副本节点进行 替换止损，替换过程中可能出现主备切换或主从切换；对于交换机、 路由器等网络设备发生故障，除了导致部分节点实例不可用外，还可 能出现集群分裂情况，因此分布式数据库需要建立应付各种类型和规 模故障的容灾能力1）计算节点故障切换 当其中一个计算节点出现故障，流量以秒级切换至其他计算节点 整个切换过程对用户透明，应用代码无需变更，应用进程无需重启。

过节点代理的定时任务定期执行自愈监控项采集任务，对计算节点的 监控指标进行采集，并上报至服务自愈模块，该模块对节点的监控数 据进行分析，对可能的故障信息进行定位和二次检测，若确定为故障 则发起故障处理任务故障处理是指服务自愈模块检测到故障节点， 任务调度模块创建自愈任务，自动对故障节点进行恢复处理，处理完 成后故障节点重新上线恢复正常服务2）存储节点故障切换 分布式数据库采用多副本保存数据，存储节点通过多副本方式构 成集群最常见的集群模式是主从集群，即一个主节点负责写入，并 基于一定的一致性算法同步至其他从库当对外提供数据库服务时， 主库承担读写服务，从库提供只读服务当主库节点故障时，系统会 自动发现并尝试恢复主库，如果主库无法恢复则发起主从切换代理节m fta计算节盘计箜节点计节盒来慝 北京百度网讯科技有限公司切换协调模块为切换核心模块，负责存储节点健康诊断、切换仲主库裁与协调，并变更集群的拓扑信息如上图所示，数据库实例的三个 节点代理构成了切换的协调者节点代理通过与决策集群通信获取其 托管的集群元信息，并借助集群取得集群中其它节点代理的通讯方式四）分布式事务容灾金融类业务数据模型复杂度较高，往往需要多维度进行数据处理 和分析。

进行业务系统分布式改造时，分片策略往往无法避免一个事 务可能跨越多个数据分片的情况，需要通过分布式事务保证数据的强致性为保障分布式事务在跨节点处理时事务的原子性和一致性，般使用分布式协议处理常用两阶段提交、三阶段提交协议保障事 务的原子性；使用 Paxos、Raft 等协议同步数据库的事务日志从而保 障事务的一致性支持分布式事务是金融级分布式数据库产品的核心 特性，分布式事务的容灾能力是分布式系统容灾能力的重要考量指标百度分布式数据库GaiaDB-X采用基于优化的XA协议及两阶段提交算法实现分布式事务机制其优势有：1）自研DMVCC11算法，解 决分布式全局读一致性问题；2）解决MySQL原生XA在事务一致性和持久性上的缺陷；3）在宕机等故障场景下，能够基于持久化的全局事务状态对悬挂事务进行提交或回滚，保证分布式事务的容灾恢复能 力；4）支持备份恢复的事务一致性、死锁检测等高级功能RDdis-mnstiir来源：北京百度岡讯科技有限公司上图为GaiaDB-X的分布式事务架构，其中分布式事务处理器（Distributed Transaction Manager，以下简称 “DTM” 负责 SQL路由并管理分布式事务，是业务端访问数据库服务的入口。

DTM使用Redis存储多版本的读视图基线并存储数据节点的分布式事务状态信 息在宕机等故障场景下，全局事务状态持久化在高可用Redis集群 中，故障自愈后，新节点能通过Redis恢复悬挂的事务，决定事务应 该提交或回滚，保障分布式事务的高可用能力当分布式表进行备份和恢复时，如何保证恢复数据的一致性也是考验分布式数据库的难题GaiaDB-X实现了基于全局事务点的备份恢复机制井岸：?来源：北京百度网讯科技有限掘司辛岗那备LDf.mX：如上卅“a評集站DC御怙疇册方址H串蔚静! =幷片 i Mtflu-rjzf'sfla^ 种一;牯竹洪担璀块Bc<113所有分片同时通过备库上定时任务启动备份任务独立进行备份， 根据备份结果获取全局事务标识（简称'GTID”，并从主库日志中解 析得到备份快照点及对应分片的全局事务信息，与备份数据一同备份 这样基于快照点与全局事务信息的对应关系，即可在备份恢复时保证 各分片的全局事务一致性五）应用应激防护1.过载保护为了保障数据库服务不受业务系。