分布式数据库金融关键业务
场景应急处理研究报告
北京金融科技产业联盟
2023 年 10 月
编制委员会
主任
聂丽琴
编委会成员
王志刚 李 振
编写组成员
陈 亮 邓广俊 刁现峰 杜 蓉 冯六军 高孝鑫 郭智慧胡正策 黄小
慧 黄 炎 黄元霞 姜维莹 李博文 李国良李 磊 李 思 李萧萧 路
新英 明玉琢 申 宇 苏德财王登祎 王 枫 王莉莉 王嵩阳 王 栩
吴洪辉 许高峰徐雪涛 叶强林 张 楠 张 毅 周日明 朱 飞
编审
黄本涛 张 蕾
参编单位：
北京金融科技产业联盟秘书处
中国光大银行股份有限公司
兴业银行股份有限公司
华为技术有限公司
中兴通讯股份有限公司
腾讯云计算（北京）有限责任公司
蚂蚁科技集团股份有限公司
北京国家金融科技认证中心有限公司
飞腾信息技术有限公司
北京奥星贝斯科技有限公司
北京万里开源软件有限公司
成都虚谷伟业科技有限公司
上海爱可生信息技术股份有限公司
上海热璞网络科技有限公司
云南南天电子信息产业股份有限公司
摘 要
近年来，在金融科技的推动下金融服务和产品不断推陈出新， 数
据处理呈现出体量巨大、并发量大、高处理性能、类型繁多等 特点。
银行的业务系统应对新挑战，不断扩容，架构在不同数据 库和基础
设施之上，变得更为复杂，加大了日常运维的难度和发 生故障的风
险。虽然单个数据库产品一般具备一定的故障探测和 恢复能力，但
银行数据库运维人员仍需根据各种异常场景进行应 急处理，在发生
问题时最大程度缩短恢复时间、减少故障损失。
本报告调研了参编单位现有应急处理方案，分析了金融关键
业务场景中故障产生的原因，提炼出共性应急处理思路，形成普
适的应急处理方案和修复验证指导，为金融机构进行关键业务场
景的分布式数据库应急处置提供参考。
目 录
一、研究背景 ............................................................................................1
二、应急处理思路 ....................................................................................1
（一）应急预案 ...............................................................................1
（二）应急准备 ...............................................................................5
（三）应急演练 ...............................................................................6
（四）应急处置 ...............................................................................7
三、关键场景应急处理 ............................................................................8
（一）特性分析 ...............................................................................8
（二）数据库组件故障 .................................................................10
（三）硬件故障 .............................................................................20
（四）机房故障 .............................................................................34
（五）数据库异常操作 .................................................................38
四、总结与展望 ......................................................................................48
一、研究背景
近两年随着国内数据库产业的蓬勃发展，银行中使用的
数据库类型逐渐增多，特别是分布式数据库在金融关键业务
场景的使用变得越来越普遍。数据库是金融业中金融资产的
重要载体。无论哪种数据库，其稳定性、可靠性及可用性都 是
整个系统平稳运行的关键。
虽然现有分布式数据库产品一般具备故障的自动探测、
自动恢复能力，但不同分布式数据库的特性和操作方式不相
同，银行数据库运维人员仍需根据各种异常场景做好应急处
理，在发生问题时最大程度缩短恢复时间、减少故障损失。
为了业务连续，运维人员需要在最短时间内判断及处理数据
库异常，控制故障不进一步扩大，避免数据库停止服务，保
证业务正常开展。其次，一些常见的人为误操作可能会对业
务数据、数据库系统的状态及性能会造成较大的影响，运维
人员还需对常见误操作进行规范的应急处置，减少对业务及
系统带来的负面影响。
本课题通过调研参与单位现有应急处理方案，分析金融
关键业务场景中故障产生原因，总结统一的应急处理思路，
形成普适的应急处理方案和修复验证指导，为金融关键业务
场景的分布式数据库应急处置提供参考。
二、应急处理思路
（一）应急预案
分布式数据库在银行、证券、保险等金融机构生产环境
运行时，都存在发生故障、停止服务的风险。保障生产系统
数据安全、确保服务稳定是金融机构科技部门最重要的工作 之
一。为了快速响应故障，保障分布式数据库生产系统数据安
全、服务稳定，需要提前分析可能产生风险的原因，并事 先制
定应急处置方案。
分布式数据库系统技术栈包括分布式数据库组件，操作
系统、服务器及服务器运行环境，服务器运行环境又包括机
房环境和地域环境。分布式数据库生产系统主要面临的风险
如下：
1. 系统故障
指支撑分布式数据库运行的系统（或子系统）发生故障、
停止服务。系统栈每一层中的系统都存在发生故障的概率。
分布式数据库组件可能在运行过程中出现bug 导致停止服务；
操作系统在运行过程中可能会出现故障；服务器硬盘可能出 现坏
道，无法读取数据，内存可能部分失效，读取出错误内 容等；
机房环境可能出现供电故障，空调故障等情况；地区 环境可能
出现地震、台风等影响数据中心机房运行的灾难。
任何系统都存在发生故障的概率，数据库高可靠方案和
系统及运维应急方案都是为在一定约束条件下降低故障发 生
的概率。当故障发生的概率足够小时，系统运行的安全就 得到
了保障。一般可以从以下三方面考虑，降低故障发生的概率：
一是要选择故障率低的系统。比如选择经过检验的、故
障率低的分布式数据库、操作系统、服务器、机房供电设备、
空调等系统，建设机房时所选地区环境避免在地震带上，避
免历史上经常受到台风侵袭的地区等。
二是准备冗余资源，确保系统栈中不存在单点故障。同
等条件下如果准备两个或多个系统，其同时发生故障的概率
将远远低于单个系统发生故障的概率。
三是及时发现系统异常，并且一旦发生故障，能立刻自
动或手动启动备用系统保持/恢复线上服务，快速处理故障 系
统，恢复故障系统的服务。故障和故障处理，需要关注如 下几
点问题：
（1） 各个系统在设计阶段要考虑预设屏蔽故障子系统
的能力，单一系统（或子系统）发生故障时，该系统不再接
收请求、提供服务。这种机制可使故障被限制在对服务影响
最小的范围内，防止故障蔓延。
（2） 分布式数据库最重要的资产是数据，必须着力避
免因局部系统故障造成数据丢失。例如硬盘损坏时不能造成
硬盘上的所有数据丢失。需要详细制定数据备份及恢复策略， 在
恢复系统服务时，保障数据不丢失。
（3） 虽然所有技术冗余资源同时发生故障的概率很小，
但仍需要制定相应的故障应急处理预案，包括业务处理方法
或手动处理方法。
2. 系统资源耗尽
指系统资源耗尽，不能提供更多的服务，主要有两种场
景：
（1） 由于任务繁重，系统资源已全部投入服务，系统
处理能力达到峰值，新的任务只能排队等待处理。此时系统
处于满负荷持续服务的状态，比如 CPU 满负载、网络带宽资
源耗尽等。这种情况需要先排除是其他系统（子系统）故障 而
导致。
（2） 资源耗尽后，系统运行出现故障，造成停止服务。
比如硬盘已满，但日志记录系统仍要写日志文件。对于此类
资源耗尽风险，需要采取如下两类策略：
一是事先预防策略。系统需要具备足够的横向扩展能力，
通过增加服务器等资源增加峰值处理能力。
二是监控应对策略。系统需要具备强大的监控告警能力，
一旦某种特定资源使用率超过阈值就进行告警，以便运维人
员果断的启动增加部署资源流程。
3. 操作风险
指生产运维人员在分布式数据库系统栈中进行系统操
作时，发生操作失误，从而造成数据丢失或者系统停止服务
的风险。主要应对措施包括以下几个方面：
（1） 做好培训。通过培训可使运维操作人员充分理解
分布式数据库系统栈中相应系统的运作原理，熟练进行操作。
（2） 做好权限管理。通过权限设置，指定专项人员进
行风险操作。
（3） 制定操作规程。完善数字化运维工具，通过支持
双人操作的工具，操作规程等降低误操作的概率。
（4） 做好系统数据备份。在执行风险操作前先对相关
数据进行备份。
（5)及时恢复。一旦出现误操作，按照操作规程及时恢
复数据、恢复服务。
分布式数据库在金融关键业务场景的应急处理并不仅
仅指系统栈中系统突然发生故障后进行的处理工作，还包
括系统设计及故障处理能力。完备的应急处理需要从系统
规划建设阶段开始重视并落实。
分布式数据库系统运行风险的处理思路也对系统栈中
的各个系统的厂商、应用系统开发商及运维系统开发商都
提出了要求，所以需要建立和各厂商及开发商的沟通渠道。高
效、及时、可达的沟通渠道，能够把需求和问题反馈到各厂
商及开发商，并得到顺利解决。
此外，建议在分布式数据库上线前，针对各种运行风险 事
先准备应急预案，并为预案顺利执行创造条件，包括完成应
急预案制定、应急演练、应急培训等事宜。保证从分布式数
据库上线开始，应急预案就是真实可用的。一旦出现任何 系统
故障或报警，能根据应急预案进行处置。
（二）应急准备
应急准备工作指系统故障或风险事件发生前，为防范风
险进行的所有工作，包括以下内容：
1. 组织层面
有效处置突发事件，快速恢复重要业务应进一步完善应
急组织架构中的应急指挥层、应急执行层、应急保障层设置。
根据事件影响程度及持续时间等因素对突发事件进行风险
等级划分，并根据不同等级的风险事件制定突发事件应急处
理流程，依据其可能造成的危害程序、紧急程度和发展态势，
划分预警级别并且建立相应的预警信息发布机制，这是应急
准备的重要部分。
2. 实施层面
在项目实施中，准备应急预案、制定完善运维操作规程、
上线分布式数据库系统及运维管理系统、组织安排运维团队等
系统上线前所做的工作都是应急准备工作的一部分。
3. 其他
在系统上线后仍有应急准备工作需要处理，包括系统日
常运行监控、系统定期巡检、系统运行情况分析、应急预案
更新升级、日常数据备份、定期验证备份数据的可用性、定
期应急演练，等。此外，金融机构应根据应急演练实际情况
完善应急预案及操作规程等合规操作，并进行操作合规性审
计。
（三）应急演练
数据中心所在地区发生地震、台风，机房火灾、机房长
时间停电；一个数据中心中的所有服务器同时故障；服务器
硬盘同时故障等事件都属于极低概率事件。这类极低概率事
件在几年，甚至分布式数据库对外提供服务的整个生命周期
中可能都不会发生一次。但是，应急预案的内容需包括对这
类事件的处置应对。应急准备工作在组织层面、实施层面、
其他方面包括了处置应对这类极低概率事件的工作。
由于缺少实际事件的检验，一旦发生这类极低概率事件， 相
关领导、业务人员、技术人员、厂商/合作方人员，处理故障、
问题的资源是否就位，处置是否有序、高效，排除故
障、解决问题、恢复服务是否迅速及时，整体应急准备工作 是
否完备，都需要通过定期的应急演练来检验、完善。
分布式数据库涉及的极低概率事件的应急演练，可以纳
入灾备切换、信息科技相关等应急演练中一并考虑，统一组
织。应急演练工作应在应急准备工作完成后安排实施。组织
安排应急演练工作实际上是对应急预案的实施落地。首先要
做好组织动员工作，建议成立行领导牵头，相关业务部门、
技术部门参与的应急演练小组，协调相关厂商、合作方安排
相关人员参与应急演练工作。次之是做好应急演练方案，明确
岗位职责，细化演练流程，保障方案可行性。其次是保障支撑
应急演练的各项资源就位，包括备品备件、通讯线路等。 再次是
做好业务合作方、技术产品/服务合作方等的沟通协调工作，
提前通知对方本单位的应急演练计划，请合作方做好支持安
排。最后是完善应急演练组织的沟通机制，工具。
应急演练应严格按照应急预案，应急演练方案来落实实
施。且应制定持续改进的机制和方案，在应急演练完成后，
全面总结应急演练过程中的经验和教训，完善应急预案和其
他应急准备工作。
（四）应急处置
当有系统发生故障或者存在风险时，需要启动应急风险
处置预案。风险处置最重要的原则之一是在保障数据安全和
操作合规的前提下，采用最短的时间恢复生产，并按照应急
预案演练的情况推进其他步骤。
如果出现应急预案没有覆盖的风险，应根据风险影响范
围进行汇报，同时按照审慎的原则进行处理，比如尽量确保
在分析和处置风险的过程中，获得应用开发商和具体系统厂
商的参与和支持。在完成问题处置后应梳理处置过程，并将 风
险及处置情况纳入应急预案中，以防范之后的风险。
三、关键场景应急处理
（一）特性分析
数据库系统是按照特定数据结构组织、存储和管理数据
的基础软件，根据架构不同可分为集中式数据库和分布式数
据库。分布式数据库是物理上分散而逻辑上集中的数据库系
统，利用分布式事务处理、数据自动分片、数据多副本存储 等
技术，将分散在计算机网络的多个逻辑相关的节点连接起来
共同对外提供服务。如图 1 所示，分布式数据库比较典型
的技术架构包括管理模块、计算模块和存储模块 3 个部分。
图 1 分布式数据库典型技术架构
计算模块负责解析应用程序查询请求、生成查询计划，
并将查询计划自动分配到各计算节点并行执行。
存储模块负责执行计算层数据操作请求，并实现数据在
硬件层面的持久化保存，确保数据不丢失。存储层将数据按 分
片进行多副本存储，保障数据可靠性。
管理模块负责协调分布式时钟和维护元数据，并提供数
据库参数配置和运行监控。
分布式数据库具有天然复杂性，产品自身组件、操作系
统、磁盘和服务器等故障，都可能导致集群的少量节点实例 不
可用。且分布式数据库在金融业的架构形态通常有单中心、同
城互备、同城双活、两地三中心等，当网络设备发生故障，
除了导致部分节点实例不可用外，还可能出现集群分裂情况
等。因此集群中任何节点的软硬件故障或者任何节点之间的
网络连接故障都需要被妥善处理。
分布式数据库需要建立应付各种异常场景的处理方案应
对金融业数据零丢失和业务高连续性的要求。较为典型的 故
障场景包括：数据库自身组件故障、操作系统故障、硬件 故
障、机房故障、数据库操作异常等。在每个场景下，应急 处
理流程都包括通知相关人员、尝试修复、备份数据、恢复 数据
库和测试验证等步骤。建立和执行有效的应急处理流程， 可以
帮助金融机构最大限度地减少数据库故障和安全事件对业务
运营的影响，保障金融行业的数据安全和运营稳定。下面将
针对典型异常场景故障进行应急处理方案介绍。
（二）数据库组件故障
1.管理节点宕机
在分布式数据库集群中，管理节点为集群提供各类管理
服务，所以总控服务需要高可用的设计，一般使用多副本一
致协议来保证管理节点的高可用性。下面以 Paxos 协议为例，
通过对分布式数据库集群进行配置来指定管理节点的副本
数。管理节点的各副本基于 Paxos 协议选举 leader，leader 副本
上任后为集群提供总控服务，当管理节点当前 leader 发生故
障卸任时，其他的副本重新选举产生新的 leader，并继续提供
总控服务，从而实现总控服务的高可用。所以任何一个管理
节点的故障对分布式数据库集群整体业务没有影响，但当
超过半数的服务异常后，分布式数据库集群将无法
提供服务，此时需要依赖备集群恢复业务。
当人为原因、机器的故障、内部选举机制等，数据库运
行异常，导致某节点无法正常工作时，产生了管理节点宕机
时，解决方法是：可采用高可用架构设置管理节点，为管理
节点提供多副本保障，某节点宕机时，其他节点可接管故障
节点的工作，保障数据库正常工作。如果是数据问题，其他
的副本重新选举产生新的 leader，并继续提供总控服务，从而
实现总控服务的高可用，保障数据库正常工作。通过 Paxos 协
议对故障节点进行数据修复，进行数据同步，保证管理节点
集群数据的一致性。如果是机器故障，可重启或检查机器故
障原因进行问题排除，机器正常重启后，可通过 Paxos 协议对
故障节点修复数据，然后进行数据同步，保证管理节点 集群数据的
一致性。
进行修复验证时，人为切换至原故障管理节点（已经修
复正常），如数据库操作结果与其他目前在运行的管理节点
操作结果一致，则修复成功。
管理节点故障，主要可能原因如下：
（1） 机器报警。
（2） 无法正常保障数据库工作。
（3） 返回结果异常。
（4） 数据丢失或损坏。
（5） 主副本数据不一致。2.
计算节点和数据节点宕机
计算节点和数据节点是分布式数据库的核心，分布式数
据库在每个节点上只存储部分数据，使用多副本一致性协议
来保证分区的数据在多个节点上的一致性。任何一个节点故
障，其他节点上的分区副本依然会构成多数派，可以重新选
举出新的主副本来提供服务， 这个切换过程需要在保证
RPO=0 的同时尽量缩短自动切换时间。但如果分区多个副本
所在的节点发生故障，那么剩下的节点将无法合法的选举出
主副本，这些分区将无法正常提供服务，但其他正常分区依
然可以提供服务。
当人为原因、机器故障、内部选举机制等导致数据库运
行异常，此类节点无法正常工作时产生计算节点和数据节点
宕机时，解决方法是：计算节点和数据节点都采用高可用架
构，有多副本保障。当某计算节点宕机时，其他计算节点可
接管故障节点的工作，保障计算节点正常工作；当某数据节
点宕机时，其他数据节点中的副本可转正为主本，保障数据 节
点正常工作。如果是计算节点数据问题，其他的计算节点重
新选举产生新的主节点，并继续提供总控服务，从而实现总
控服务的高可用，保障数据库正常工作。然后通过一致性协
议对故障计算节点进行数据修复，进行数据同步，保证计算
节点集群数据的一致性。如果是数据节点数据问题，可切换
到其他有该故障节点副本的数据节点，其副本会转正为主本，
进行数据库操作，保障数据库正常工作。然后通过一致 性协议
对故障数据节点进行数据修复，进行数据同步，保证 数据节点
集群数据的一致性。如果是机器问题，可重启或检查机器故
障原因进行解决，机器正常重启后，可通过一致性
协议对故障节点进行数据修复，进行数据同步，保证计算和
数据节点集群数据的一致性。
进行修复验证时，人为切换到原故障计算和数据节点
（已经修复正常），如数据库操作结果与其他目前在运行的
计算和数据节点操作结果一致，则修复成功。
计算和数据节点故障，主要可能原因如下：
（1） 机器报警。
（2） 无法正常保障数据库工作。
（3） 返回结果异常。
（4） 数据丢失或损坏。
（5） 主副本数据不一致。
3.数据代理节点宕机
分布式数据库集群一般会提供数据库代理组件以便准
确地将SQL 请求路由至合适的计算和数据节点上。代理组件
接收用户发出的SQL 请求，并将 SQL 请求转发至最佳目的地，
从而减少跨越节点的远程事务。数据库代理节点一般是无状态
的，不记录事务的状态。当一个节点故障后，业务应用可以
访问新的数据库代理节点来获得数据库服务。业务系统和数
据库代理节点之间可以部署负载均衡服务来保障更高的可
用性。
当人为原因或机器的故障，数据库运行异常，数据代理
节点无法正常工作发生宕机时，解决方案为：数据库代理节 点
采用高可用架构，某节点宕机时其他代理节点可接管故障节
点的工作，保障数据库正常工作。如果是硬件或软件的问
题，需要重启或检查机器故障原因进行解决，业务应用可以 访
问新的数据库代理节点来获得数据库服务。业务系统和数据
库代理节点之间可以部署负载均衡服务来保障更高的可 用性。
修复验证时，人为切换到原故障管理节点（已经修复正
常），进行数据库操作，代理组件接收用户发出的 SQL 请求，
并将 SQL 请求转发至最佳目的地，如果操作一些正常，则表示
已经修复成功。
数据库代理节点故障，主要可能原因可能是机器报警，
无法正常保障数据库工作，返回结果异常，时间延迟较长等
情况。
全局事务服务异常
为保证全局的事务顺序，分布式数据库集群一般会提供
一个全局时间戳服务（简称 GTS）或者全局事务管理器（简
称 GTM），事务提交时候通过时间戳服务获取事务版本号。
因此 GTS/GTM 是分布式数据库的核心，需要保证高可用。
GTS/GTM 服务默认也是多副本的，因此其高可用能力跟普
通表的能力一样，在下述异常场景下依然能够保证时间戳的
正确性。
（1） 有主改选：原Leader 主动发起改选的场景称为有
主改选。新 leader 上任之前先获取旧 leader 的最大已经授权
的时间戳作为新 leader 时间戳授权的基准值。因此该场景下，
GTS 提供的时间戳不会回退。
（2） 无主选举：原 leader 与多数派成员发生网络隔离，
等 lease 过期之后，原 follower 会重新选主，这一个过程称为
无 主 选 举 。 选 举 服 务 保 证 了 无 主 选 举 场 景 下 ， 新 旧
Leader 的 lease 是不重叠的，因此能够保证本地时钟一定大
于旧主提供的最大时间戳。因此新 leader 能够保证 GTS 提
供的时间戳不回退。
当人为原因、机器的故障、内部选举机制等，数据库运
行异常，GTS 或者 GTM 节点无法正常工作产生宕机时，解
决方法是：GTS/GTM 全局事务服务采用高可用架构，某节
点宕机时，其他节点通过选举接管故障节点的工作，保障数
据库正常工作。新leader 上任之前先获取旧 leader 的最大已经
授权的时间戳作为新leader 时间戳授权的基准值。保障 GTS 本
地时钟一定大于旧主提供的最大时间戳。
修复后进行检查，预期是当前的 GTS 本地时钟一定大于
旧主提供的最大时间戳或者当前GTM 提供的全局事务号大于
旧主提供的最大全局事务号。
GTS/GTM 全局事务服务故障，主要可能原因如下：
机器报警、无法正常保障数据库工作或返回结果异常。
5.操作系统故障
分布式事务数据库服务运行在操作系统中，操作系统中
核心资源（如：CPU、磁盘、内存、I/0、网络等）是数据库
服务正常运行的基础保障。为保障分布式事务数据库在不同
资源占用比场景下服务的稳定性和可靠性，需提前准备各项
核心资源的阶梯占用以及资源匮乏等场景下的预案。通常情
况下，在磁盘空间（包括 inode 耗尽）、内存占用以及以上
组合场景时，数据库服务均会出现异常。
解决方法是对系统资源进行日常容量监控和预警。
6.文件系统为只读模式
现象为数据库服务异常退出，重启过程中无错误日志输
出，且重启过程不断报错，并带有“Read-only file system” 字样。
解决方案为：确认问题原因是否为文件系统被设置为只
读情况，以及被设置为只读模式原因。解决文件系统被设置
为只读模式原因后，重启服务器，进行修复确认，查看文件
系统模式及数据库服务运行是否正常。
故障产生的原因是：一般情况文件系统被设置为只读模
式是由于系统发现磁盘硬件（Riad 卡，硬盘）故障或文件系
统中文件被损坏后而采取的保护机制导致的，比如文件系统
错误、磁盘坏道、RAID 卡故障、inode 资源耗尽、IO 繁忙、
硬盘背板故障、硬盘线缆故障、HBA 卡故障、内核相关硬件
驱动 bug、FW 固件类问题以及系统没有正常关机，也会导致磁
盘出现文件系统错误。为了保护数据不破坏分区中已有内容，
Linux 在挂载文件系统时会以 read-only 只读方式加载。
7. 总体 CPU 资源占用过高
业务系统通常上线后资源使用率较为稳定，此场景下
CPU 使用率相比较日常表现突然变高或者不断攀升，导致系
统运行速度变慢或运行异常。
解决方案为：观察 CPU 使用率分布，确认具体导致CPU
突然飙高的原因是软件还是硬件。软件层面问题通常可以确
定为某一个程序引起，可通过观察确认具体引发CPU 繁忙的
操作，采取关闭不必要的进程或操作即可恢复 CPU 使用率； 如
判定为硬件问题，则需要升级硬件进行处理。
进行修复确认，预期是解决 CPU 飙高的软件原因或硬件
原因后，CPU 使用率恢复至正常水平。
此种故障分为软件原因和硬件原因。软件原因通常会存
在新增应用程序占用（如挖矿、测试软件等）、有语法错误 的
SQL（如简单 SQL 因连接符号或标点符号等写错导致变为一
个超大的复杂 SQL）、中毒等情况；硬件原因主要来自机房
散热、驱动故障、CPU 寿命等情况。
8. 单核 CPU 跑满
现象为总体没有明显的资源瓶颈，查看进程实时动态信 息
时发现单核跑满，且磁盘调入内存跑满。
解决方案为：进入 BIOS 查看网卡队列情况，如为单队列
网卡则需要升级或者更换为多队列网卡；如为多队列网卡， 则需
要设置多队列，并且进入系统后进行多队列的 CPU 中断绑定处
理。
进行修复确认，预期是解决上述问题后，CPU 使用率
分散到所有核，且磁盘调入内存较为均匀。
故障原因通常为多队列网卡未开启多个队列、多队列处
理未绑定到多个 CPU 上或者网卡本身为单队列等等。
9. I/O 资源占用过高
通常，业务系统上线后资源使用率较为稳定，如 I/O 使用
率相比较日常突然变高、I/O 卡顿或进程实时动态信息中
I/O 等待所占用的 CPU 时间百分比数值变大，产生系统运行
速度变慢或运行异常甚至操作系统卡顿的问题。
解决方案是：观察磁盘 I/O 的使用情况，判断是否软件
进程或线程存在 I/O 使用频繁，如判定为非软件系统问题， 则
需要进一步排查硬盘故障类硬件问题或其他偶发性情况， 偶
发性问题需要进一步排查操作系统 bug、异常操作等，综合
考虑并确认I/O 繁忙的原因。软件层面问题通常可以确定为
某一个程序引起，并通过观察可确认具体引发I/O 繁忙的操作，
此时关闭不必要的进程或操作即可恢复I/O 使用率； 如判定为
硬盘故障类硬件问题，则需要升级硬件进行处理， 如为其他偶
发性问题，则需要进一步排查操作系统 bug、异常操作等并
进行对应升级修复。
进行修复确认，预期是解决 I/O 飙高、卡顿的软件原因
或硬件原因后，I/O 使用率恢复至正常水平。
故障原因分为软件原因和硬件原因。软件原因通常会存
在新增应用程序占用（读写压力高的测试软件、系统级别频
繁刷日志等）、不合理的表结构设计及 SQL 设计（如无索引、
全表扫描等）、操作系统 bug 等；硬件原因主要来自磁盘损坏。
10. 内存消耗过大
数据库使用过程中，通常会占用较多的内存，一般不影
响数据库服务。而当内存溢出、内存碎片泄漏等情况导致服
务被异常关闭时，可能出现内存消耗过大的问题。
解决方案为：服务正常情况下，内存偶发性增加大概率
是因为业务系统中存在高消耗内存SQL 语句；出现服务异
常关闭情况下，通过分布式事务数据库日志以及操作系统日
志等信息进行分析，确认退出原因，大概率存在启动内存参数
不合理、内存占用过高被操作系统误杀等情况。如为 SQL 操
作，则需要优化 SQL 或者数据库支持情况；如为内存参数等
内容则需要采取调整数据库启动内存参数设置、优化内存碎
片回收机制等对应措施。
进行修复确认，预期试运行一段时间后观察内存使用率
情况以及服务运行情况，均稳定运行。
故障原因大多为软件问题，主要原因有高消耗内存的SQL
操作、内存参数设置不合理及内存碎片回收待优化。
11. 磁盘占用满
现象为磁盘突然使用率增加，直至占满，导致数据库服
务异常退出。
解决方案为：查看磁盘占用（du -Sh *等）命令，了解
占用磁盘的文件，从而分析具体磁盘快速写满的原因。清理
出部分空间后，按照磁盘用满的原因做对应处理，然后启动
数据库服务。
进行修复确认，在数据库服务启动后，观察磁盘写入情
况，预期是占用情况恢复正常。
故障原因通常为压测过程中不断写入数据和日志，数据
库异常报错不断进行错误日志写入，操作系统异常不断写入
操作系统错误日志，缺乏监控手段导致正常数据和日志写入
刷满磁盘等情况。
12. 网络负载过高
现象是网络流量过大引发丢包、重传、网络延迟过大，
从而导致系统服务响应变慢、报错。
解决方案为：通过观察网卡进出流量、网卡本身负载能
力及相关硬件配置情况，确认具体网络负载过高的原因，确
认是否为存在大量写入和读取数据操作导致网络流量增加，
或实际流量较高但网卡或者交换机等硬件性能不足情况。如
为软件层面操作问题，等待业务执行完成并及时监控即可；
如为硬件性能不足情况，则需要升级或者更新硬件设备。
进行修复确认，预期是修复后观察网络流量及丢包率、
重传率、网络延迟等参数均正常。
故障原因分为软件原因和硬件原因。软件原因通常为大
量写入和读取数据操作，需确认是否为业务正常行为；硬件 层
面通常为网卡及交换机等设备性能不足或损坏情况，需要更
新或升级硬件。
（三）硬件故障
1. 服务器宕机
服务器宕机通常是指应用的服务器处于一种非正常运
行的状态，例如服务器假死、停止使用或者关闭，系统无法
从错误中恢复过来或系统硬件层面出问题，以致系统长时间
无响应无法对外部指令进行响应，服务器的宕机会给用户的
正常使用带来较大的影响。
在排查时需要判断服务器宕机的严重程度，可在宕机发
生后等待一段时间，此时宕机系统若恢复即常说的假死，若
仍未恢复则需要查询系统日志，分析宕机前后系统日志的报
错情况，其次查看监控数据是否有指标异常，例如资源的消
耗异常，最后可查看服务器硬件故障情况。
服务器宕机故障预防可以从以下几方面着手：一是从软
件出发，查看程序设计是否合理，数据查询是否有死循环。
二是从硬件出发，配置分布式软件，从而形成冗余硬件资源。 针
对高并发或存在大量计算、海量存储的情况，升级服务器硬件
配置，加大网络带宽、升级服务器 CPU、提高服务器内存、
扩展存储服务器。三是在系统的设计中考虑合理的警报和监
控框架，尽早发现和诊断故障问题，缩短排查与处理时间。
故障处理时，对于访问量过高超出系统承载能力的短暂
性突增或者异常的访问可等待一段时间或手动杀死进程或 重
启，排查异常访问来源。对于早期建设的不能满足需求的传
统集群需要对系统的软硬件进行升级与优化。对于系统设计
的不合理之处，需要对业务的支撑资源重新划分调配，优 化业
务系统的查询或多线程的处理。当系统内部参数配置不合理
时进行参数的优化和调整。存在系统内核故障或错误时需要
升级内核。对于人为的误操作，则需要提高操作人员的能力。
宕机恢复后系统进行修复验证步骤为：
（1） 检查系统日志，是否有报错；
（2） 检查系统各项功能是否正常，并检查对应日志；
（3） 检查应用各项功能是否正常，并检查对应日志。
金融关键业务场景下，分布式数据库，可能出现宕机的
原因主要包括：
（1） 访问量过高超出系统的承载能力，包括正常的短
暂性突增，或者异常的访问，如非法攻击的情况。
（2） 早期建设的传统集群，部分已不能满足现今的系
统需求，服务器配置过低，导致即便访问量不算太高也超出
了系统承载能力的情况。
（3） 系统的应用程序设计存在不合理的异常或漏洞，
例如对业务支撑的系统资源不合理，或例如死循环或多线
程造成死锁，消耗系统资源的逻辑导致资源耗尽。
（4） 系统内部参数配置不合理，例如允许连接数过低。
（5） 存在系统内核程序错误或故障，包括软死锁等情
况。
（6） 在一定环境中，人为的误操作也可能导致服务器
宕机情况的发生。
为了尽可能减少服务器宕机故障的发生频率，维护系统
稳定运行。要减少运行环境的负荷过载，因此要监控运行环 境
中的操作系统、网络以及各类硬件资源的使用，当有软件 正在
大量占用服务器内存、CPU、磁盘或网络，或者网站的 并发
访问数超过带宽资源，系统资源出现暂时性不足，例如磁盘
空间耗尽、内存耗尽等情况时，及时进行告警，然后进行干
预。
2. 电源故障
服务器电源按照通用标准可以分为ATX 电源和SSI 电源
两种。ATX 主要用于台式机、低端服务器或工作站，该标准
使用较为普遍；随着服务器技术的发展，适用于各种档次的
服务器标准 SSI 标准诞生。系统服务器电源（power）与用
于个人的 PC 服务器电源都是一种开关电源。作为硬件服务
器的能量源发挥着无形的巨大作用，目前服务器的电源模块
种类较多，不同服务器产品的输入/输出电压、功率、功能 及
拓扑结构都有可能不同。
电源故障可能导致系统运行不稳定，当磁盘出现坏磁道、
CPU 超频工作不稳定、主机莫名重新启动、服务器运行时
噪音较大等情况。
故障产生原因通常包括电源模块质量较低、电源的功率
不足、电源的稳定性较差等原因。比如电源模块在电压输出 偏
低或偏高的转换过程有能量损耗，从而造成模块发热严重、 输出
噪音大，电源模块启动困难且反应较慢、电源启动后迅 速烧毁
冒烟或短路、电源模块损坏较快等情况。
不同的应用对服务器电源的要求不同，在分布式数据库
的金融业，尤其强调数据的安全性和系统的稳定性，因而要 求
服务器电源要具有很高的可靠性。因此分布式数据库需要考
虑到服务器电源故障问题，需具备在电源故障情况下的数据
保障能力。
在分布式数据库的金融关键业务场景下，为了预防服务
器电源故障，大部分服务器均采用冗余电源。也就是服务器
采用高质量的冗余电源模块组件，并在机柜内提供冗余电源，
一方面，具有均流、故障切换等功能，另一方面，能有效避
免电源故障对系统的影响，实现长时间不间断运行。N+1 冗
余即运行系统所需的N 个额定容量的组件数量再增加一台， 一
个电源发生故障，系统仍能持续运行。除了服务器电源冗余、
机柜电源冗余，还有机房的 UPS 冗余。也就是说任何一台
UPS 发生故障时，由额外增加的一台 UPS 不间断提供电力， 提
高系统可靠性，同时依靠均流技术并行运行。
通过冗余电源和热插拔技术配合，可实现热插拔冗余电
源，从而提高服务器系统的稳定性和可靠性。
发现电源故障，可以通过更换电源组件或检查电源状态
来进行故障检查，最终通过更换电源组件解决出现的电源故
障问题，保证系统稳定性。
修复后，可通过检查电源状态、服务器状态、操作系
统状态、应用状态来进行修复确认，修复完成后，系统现象
为磁盘磁道正常读写、CPU 超频工作稳定、主机开关启动正
常，服务器运行时噪音较小。
3. 磁盘损坏
磁盘损坏主要有以下场景：
（1） 故障提示。即磁盘自我监测、分析错误报告其磁
头、磁盘、电路等部件与预存的安全值发生冲突，自动发生 警
告信息。
（2） 磁盘无法识别。启动时显示磁盘无法识别，或系
统无法显示磁盘。
（3） 系统运行出错。服务器运行不断出现程序错误且
磁盘扫描停滞甚至死机。
（4） 运行报错。扫描磁盘发现错误或显示坏道。
（5） 初始化死机。包含其他部件与磁盘故障的可能。
故障产生的可能原因包括：
（1） 磁盘系统故障，发生系统中断、跳出、停滞等现
象。这些现象的发生可能存在磁盘或系统的故障。
（2） 磁盘物理故障，一般表现为无法识别磁盘存储数
据，或者是无法读取数据，导致用户无法使用磁盘。
（3） 磁盘运行故障，主要表现在扫描磁盘的时候发现
错误。磁盘运行故障一般发生在坏道的产生，需要对磁盘进
行隔离，保障磁盘的正常使用。
在分布式数据库的金融关键业务场景下，为了预防服务
器磁盘故障，大部分服务器采用冗余磁盘，并做磁盘阵列，
来预防磁盘故障。也就是N+1 冗余，即运行系统所需 N 个磁
盘，再增加一块或多块磁盘。多块磁盘做磁盘阵列后，一个
硬盘发生故障，系统仍能持续正常运行。
对于磁盘故障，首先确认业务在分布式数据库保有数据
备份情况下的稳定运行，备份数据启动承载切换的业务后，
再进行故障磁盘的更换。磁盘系统故障在排除系统故障后对
磁盘进行检修，磁盘物理故障需要保证备份数据的可用，或
对现有数据进行转移后对磁盘进行检查维修。
磁盘运行故障则需要对磁盘进行隔离，查看坏道分布情
况。对于少量坏道，可以尝试软件修复，对于大量集中的坏
道，可以对磁盘进行分区，然后把分区隔离，避免坏道扩散。 对
于分布均匀或坏道较多的情况则需要更换磁盘。
更换故障硬盘后，往往需要重新做磁盘阵列的同步，从
而把数据恢复到新磁盘中。分布式数据库需要在磁盘的存储
中保证数据存储的分布式策略，确保数据在集群的磁盘中存
在不止一份可用的相同数据，在集群中一个磁盘的损坏可自
动切换到备份数据的磁盘，单个磁盘的故障不影响系统数据
的安全可用性。
磁盘修复后，应表现为不再出现磁盘损坏场景描述现象， 在
系统运行中可查询该磁盘的完整数据，分布式数据库的数 据
分布策略在磁盘修复后完成磁盘数据分布初始状态，磁盘 数据
与备份数据具备一致性。
4. 内存条故障
内存条故障常见开机报警、读取出错、解压出错、内存 短
路主机无法加电、蓝屏死机、无法启动等场景。内存损坏导
致系统注册表报错情况较为常见，系统在正常启动进入桌面
后，系统提示注册表读取错误，需重新启动电脑修复该错误，
再次启动电脑后，仍旧提示注册表读取错误，其次在主机使
用环境恶劣，如湿度过大在长时间使用过程后，内存金 手指表
面氧化，造成内金手指与插槽接触电阻增大对电流通过的阻
碍，形成内存自检错误，表现为开机内存报警。
内存故障产生原因如下：
（1） 内存故障导致注册表读取错误情况，包括安全模
式的设置原因、长时间未进行磁盘碎片整理及错误检查，以
及则存在于机器内存损坏的硬件故障。
（2） 出现内存损坏安装系统提示解压缩文件出错故障
的原因，一般是内存的质量不良或稳定性差造成的，无法正
常读取某一文件或系统安装文件损坏。
（3） 在内存短路导致主机无法加电的情况下，可能存
在电源质量不稳定或其他部件接触或需要更换的问题。
（4） 若出现蓝屏死机或无法启动的情况，根据蓝屏时
的出错提示或无法提示则应是内存中某种虚拟文件出错，
可能存在接触不良、内存插槽脚短路、内存条安装不正确或内
存插槽变形等问题。
内存条故障预防首先应保证使用环境符合国家机房标
准，如温度、湿度、静电等等，避免因为温度、湿度、静电 等
原因导致内存条故障。其次，严格控制操作人员具备相关 技术
能力，从而避免内存条安装接触不良、安装不正确等问 题。采
用带有ECC 校验的内存条，从而能够发现错误，自动纠正错
误。
内存条故障检查主要考虑接触不良、安装不正确、插槽
变形等问题。具备相关技术能力的安装人员首先仔细检查机
器安装环境，然后按照标准步骤进行，并细化安装后的检查流
程，减少人为操作造成的故障。对于电路短路或断路问题， 需要技
术人员确保安装运行环境的电源导线正确连接。
对存在于机器内存损坏的硬件故障需要使用替换法。首
先备份重要资料，换上性能良好的内存条，进行重新安装。
同理，在金融关键业务场景中，内存条的质量不良或稳定性
差极大的影响系统的整体性能，建议使用高质量的内存条硬
件。
更换内存条后，检验是否存在同样的故障，能否读取系
统文件。更换高质量的内存条后，应有响应速度的提升及系
统稳定性的提升。
5. 主板故障
主板故障通常表现为主板无法启动、系统不能识别键盘
和鼠标、外连接的如打印机不能正常工作、显卡提示警告或
发出非正常的报警声等与主板有关的问题。
主板故障产生原因：
（1） 主板无法启动的故障原因包括安装问题中的接触
不良、主板及主板上各元件的制作工艺质量问题。
（2） 对于连接外设键盘、鼠标、打印机出现不支持或
不能正常工作的故障，存在连接接口松动、接触不良、线路 故
障、连接外设硬件故障及主板线路或主板故障问题。
（3） 主板的电源安全故障，主板电源是否通过稳压器
过滤和是否具有滤波功能的电容来稳定供电电流保护主板 的
正常使用；
（4） 显卡与主板的松动导致故障，或显卡与主板非正
常兼容。
金融关键业务集群出现主板故障对于系统来说有较大
风险，在集群建设之初应选用高质量的主板硬件，确保主板
及主板上各元件的制作工艺优良，具备承载金融核心业务或
关键业务的能力，不出现质量问题。
常用主板故障检查方法：观察法、清洁法、插拔交换法、 软
件诊断法。如观察主板及电容等是否有烧毁迹象、是否接
触不良，清洁因灰尘过多造成的故障，使用插拔交换的排除
法确定故障所在元件如主板或 I/O 设备，通过诊断程序或测试
软件对主板进行辅助硬件维修，读线路及芯片状态识别故障部
位如接口等。系统安装中由专业技术员进行操作，为防止主
板电源故障问题，应确保主板电容上的电压不超过额定值，
确保供电电源通过稳压器过滤。计算机主板不宜在长期高负
载的情况下工作，易导致电容过热。出现主板异常的情况下，
及时联系硬件厂商进行处理。应用方在工作状态可利用万用
表来检测 CPU 周围的三极管、二极管是否工作正常， 以便检
查 CPU 供电的正常情况；出现断针或断裂现象，须及时联系
分布式数据库厂家做好数据备份及应用业务的切换， 由硬件
厂商更换新配件。
主板故障恢复后，需要对系统进行验证，首先可查看硬
件故障指示灯是否熄灭，然后检查服务器硬件错误日志、操
作系统启动日志、应用日志等。
6. 阵列卡故障
阵列卡全称为磁盘阵列卡，主要用来做 RAID，把所有
硬盘整合成一个大磁盘，再在这个大磁盘上做分区。
阵列卡故障特征：
（1） RAID 磁盘阵列中物理硬盘指示灯告警。
（2） 显示多块硬盘呈离线状态或丢失状态。
（3） RAID 信息丢失，所有物理硬盘不再是 online 状态。
（4） 无法进入 RAID 管理界面或查看 RAID 相关信息时
死机。
磁盘阵列卡故障原因：
（1） 服务器硬件故障导致的阵列卡故障，如电路板损
坏、磁头损坏、盘面损坏以及其他固件损坏等。
（2） 断电、电压不稳导致的阵列卡故障。
（3） 管理员在维护过程中由于误操作导致硬盘盘序出
现错误或在配置 RAID 阵列信息时出错误导致数据丢失均有
可能造成阵列卡故障。
（4） RAID 在同步数据或者重建过程中，同组 RAID 阵列
中有其他硬盘掉线导致同步失败。
磁盘阵列卡故障检查时，由于阵列卡的特殊性，处理不
当可能造成数据丢失，所以对于阵列卡的处理方式应该更加
的谨慎，针对不同的故障产生原因，采取恰当的处理方式：
（1） 若是由电源原因造成的阵列卡故障，为了防止数
据丢失，需要先将系统电源关闭，再依次检查硬盘，处理电
源问题。
（2） 若是服务器硬件导致的阵列卡故障，先要确认数据
是否丢失，若无数据丢失则修复对应的硬件之后再行处理。
（3） 若有数据丢失，则要将情况报告给磁盘阵列厂商
或者专业的磁盘阵列数据恢复公司进行处理。
值得注意的是，谨慎选择初始化或者ReBuild 等可能导
致数据丢失的处理方式。
在阵列卡故障修复后，首先查看硬件故障指示灯是否熄
灭，然后进入阵列卡 bios 中查看阵列卡是否正常，若显示
online 和 protected 则代表阵列卡故障修复成功，可正常使
用。
7. 网卡故障
网卡是局域网或互联网中连接计算机和传输介质的接
口，是电脑与网络的一道桥梁，一旦网卡发生故障，便不能 上
网。网卡故障一般会出现如下几种症状：
（1） 在“设备管理器”里无“网络适配器”。正常情 况下，
打开“设备管理器”时，里面有一排像“Realtek RTL8139/8111”
的英文，此英文就是我们的网卡设备。如果 没有此“网络适配
器”及英文就表示网卡没有识别到，或网卡损坏。
（2） 在“设备管理器”中有“网络适配器”，并且也 有
“RealtekRTL8139”等一排英文，但是在“RealtekRTL8139” 上面有
个感叹号。并且无论我们如何安装驱动，重装系统等， 此感叹
号都无法消失，也就是说网卡都无法正常工作，此种 现象也表
示网卡故障。
（3） 当插上网线时，电脑右下角提示“网络电缆没有 插
好”，若无论如何插拔网线，或者更换全新网线，排除网线
及网络故障时，电脑依然提示“网络电缆没有插好”时， 此时
也为网卡故障。
（4） 一般网卡正常工作时，网卡绿色指示灯会亮，如
果插上网线，网卡指示灯完全不亮，也可以断定为网卡故障。
（5） 在排除网络本身故障以及电脑系统问题的情况下，
若网卡只有发送包而无收到包，也可以确定为网卡故障。
网卡故障原因如下：
（1） 外部原因有可能是雷电、静电原因等，特别是雷
电，是导致网卡故障的最主要原因之一，尤其是夏天雷雨季 节。
（2） 电源输出电压异常也有可能导致网卡故障。
（3） 网线有短路情况或路由器、交换机故障也可能导
致网卡故障。
（4） 自身原因则有可能是网卡本身的元件质量问题。
在分布式数据库的金融关键业务场景下，为了预防服务
器网卡故障，大部分服务器采用双网卡绑定，来预防网卡故
障。也就是采用两块网卡，虚拟成一块网卡来使用，当一块
网卡出现故障，另一块网卡依然能正常运行，系统仍能持续
正常运行。
网卡故障排查的几种处理方式：
（1） 首先把系统置于非正常工作的状态
（2） 将网卡重新进行插拔。
（3） 将网卡驱动卸载后再重新安装。
（4） 将网卡换到别的插槽上。
（5） 若以上几种处理方式都无法使网卡正常工作，则
证明网卡已损坏，此时需要更换新的网卡。
Windows 环境下，在处理完毕网卡故障后，可以通过下
面几步判断网卡是否正常。
（1） “WIN+R”打开运行窗口，输入“CMD”命令。
（2） 在命令行窗口中输入ipconfig，点击确定。
若能成功查看到网络信息，如网关、ip 地址等则证明网
卡故障修复成功。8.
网络设备故障
网络交换设备是服务器之间网络通讯的必备要素，分为
路由器、交换机（二层和三层）等。
网络设备一般会进行高可用部署，比如双机并行，并采 用
“聚合链路”等解决方案，预防网络设备故障：
（1） 电源故障产生的故障。因为极端天气、人为影响、
设备老化等原因引起的故障。其预防方式也和大多数电源故
障一致，即采用 UPS 进行容灾和引入稳压器进行防控。
（2） 端口故障。因为不规范的水晶头插拔时间长了引
起端口的破坏的故障。预防策略除了规范插拔网线的动作外， 还
可以采用更加合适尺寸的水晶头让插拔动作更平滑。
（3） 模块故障。网络设备内部模块出现故障，预防方
式是对网络设备轻拿轻放，避免潮湿等。
（4） 线缆故障。线缆与网络设备连接的不规范导致的
各类故障，例如接口不紧导致脱落、交叉直连混用等。对此 类
故障的预防是在日常巡检过程中和布网阶段进行反复确 认。
（5） 背板故障。对背板故障的预防，除了保持机房干
燥外，还需要考虑散热问题，不要在出风口进行遮挡或者布
线混乱导致散热降低。
网络设备的故障检测方式是查看状态指示灯和错误日
志。还可以通过统一的监控运维平台查看。
网络设备故障排除后的确认方式是查看网络设备的状
态指示灯和错误日志。还可以通过统一的监控运维平台查看
网络设备的状态。
（四）机房故障
数据库的高可用和强一致贯穿数据库的整个生命周期。
在数据库尤其是核心数据库在构建的时候，采用高可用架构， 能
够避免在灾难的时候，降低数据库容灾做的不充分对业务 响
应时长的影响。在常见灾难下，主节点选择，一般采用分 布式
协调组件来实现，通过选举产生新的主，避免业务恢复 过程中
出现过长时间的中断。
分布式数据的容灾架构，包括同城互备、同城双活、两 地
三中心。此处介绍遇到机房级灾难情况下系统的应对措施。 以两
地三中心架构为例，可划分为：同城互备、同城双活、两地三
中心。此处介绍遇到机房级灾难情况下系统的应对措 施。以两
地三中心架构为例，可划分为：本地或同城机房故 障、异地机
房故障两个灾难场景。
1. 本地或同城机房故障
应用于金融领域的分布式数据库产品应具备自动或手
动灾难恢复能力，灾备方案包括在与主生产中心同城的数据
中心部署具备计算能力的节点并保存数据副本的同城多中心
部署架构。
如图 2 所示，分布式数据库采用同城双中心部署架构，
在 region1 中建 1、2 两个同城数据中心，同城主中心发生火灾、
电力中断等灾难时产生本地或同城机房故障。
此故障可采取跨中心强同步，使管理节点或协调节点多
数派部署在备中心。方案的优势是主中心宕掉之后能自动切
换到备中心，实现跨 IDC 容灾切换下具备两套的数据一致性。
方案的劣势是备中心故障会引起主中心只读。
图 2 同城双中心-多数派在备机房
如图 3 所示，管理节点或协调节点的多数派在主机房，
此方案跨中心强同步。方案的优势是可将管理节点或协调节
点多数派放到主机房，当备机房不可用之后，系统退化成主
机房强同步模式。方案的劣势是主机房故障后，切换到备机
房时，备机房会变成只读模式，需要手动操作，才能恢复备
机房的读写。
图 3 同城双中心-多数派在主机房
对于两个数据中心来说，没有很完美的数据中心异常自
动切换方案，需要做一些权衡。上面两种方案做了跨IDC 强
同步，但是都不能做到任意IDC 异常系统自动切换，因此并
不是完美的跨IDC 容灾方案。
进行修复验证的步骤为：
（1） 验证实例手动切换到同机房和同城机房对数据读
写的影响时长。
（2） 验证新的主节点自动建立起到其他备节点的同步
任务；新的备节点自动建立起到新的主节点的同步任务，主
备复制不受影响。
（3） 验证系统产生的业务数据或与其他应用的交互数
据是否一致，包括日间产生的交易数据和日终报表产生的汇
总数据，针对发出交易指令但未收到确认的存疑事务进行人
工校验处置。
2. 异地机房故障
应用于金融领域的分布式数据库产品应具备自动或手
动灾难恢复能力，灾备方案包括在与生产中心处于不同地理
区域的城市建立异地数据中心，形成两地三中心或多地多中
心的多集群灾备部署架构。
分布式数据库采用两地三中心部署架构，在region1 中建
1、2 两个同城数据中心为主集群，region2 灾备机房搭建备集群，
region1 发生地域级灾难造成 AZ1、2 同时发生火灾、电力中断等
灾难。
两地三中心的架构方案的优势是，在两地三中心的场景
中能做到数据中心异常的时候自动切换。劣势是，如果采用
强同步模式，则因为延迟过长，易导致事务执行缓慢。异地 之
间采用的异步模式，当异地(region1)整个可用区不可用的时
候，可能会出现部分数据丢失的可能。因此建议异地之间
（region1 和region2）数据同步采用异步模式。
图 4 两地三中心架构示意图
修复验证步骤如下：
（1） 主集群机房级故障后，备集群可以接管业务。
（2） 对生产主集群和灾备集群进行数据一致性、完整
性、可用性验证。
（3） 主集群恢复后可以自动恢复同步关系，并在生产
系统正常恢复后切回原主集群。
（五）数据库异常操作
为了避免或减少数据库的异常操作（如异常删库、安全
问题导致被拖库、SQL 注入、事务操作等），在数据库使
用过程中，就要通过备份、安全审计、业务压测等场景，
避免出现此类问题或者出现此类问题后能快速的恢复。
1.异常删库
应用于开发或运维人员误操作，导致正常数据丢失。
针对异常删库的场景，有三个方案。
（1） 通过备份逻辑日志和物理备份的方式，从备份恢
复。
图 5 异常删库恢复示意图
（2） 制作延迟备机。
图 6 异常删库恢复示意图-制作延迟备机
（3） 回收站机制。通过将数据库的元数据上移到接入
层，对drop、truncate 等高位场景，做回收站机制，不实际
的删除库里面的内容。
方案一成本低廉，恢复时间较长，适用于对恢复时间不
敏感的业务。方案二成本较高，通过延迟备机的场景，可以
迅速的将数据库恢复到对应的时间点。方案三能针对特殊命
令制作回收站，比如 drop、truncate 等操作，但是对 update 等无
效，成本低廉，适用场景有限。
修复验证：修复后需对恢复后的数据进行验证对比并对
业务进行验证，看是否存在异常。
此类故障产生原因为误操作导致数据丢失。
2.异常拖库
现象是外部利用信息漏洞进行恶意攻击，导致数据库拖
库。拖库是由于数据库的不合理的网络策略，权限策略，存 储
策略导致数据库被非法或者不合理的使用。
处理方案为进行数据库上线前检查访问数据库的网络
策略、业务账号的权限是否设置合理，关键敏感数据是否是
密文存储，并保证有完整日志。数据库上线后定期分析数据
的访问日志，发现是否有非授权的IP 访问或者越界的访问
行为。将数据库执行日志接入到审计系统。拖库后审视受影
响的数据库，检查敏感信息，评估是否有更大的业务损失。
例如数据库中如果存储了用户名和密码，则评估该表的业务
系统是否有泄露的风险，及时针对此措施添加安全策略。
进行修复验证，步骤如下：
（1） 数据库数据对比，评估数据受损情况。
（2） 进行数据恢复挖掘，减少数据损失。
故障产生原因是：
（1） WEB 应用漏洞导致拖库。
（2） 漏洞注入。
（3） 利用网站恶意挂马拖库。
（4） 内部信息泄露。
（5） 远程下载数据文件。
注入
在数据交互中，前端的数据传入到后台处理时，没有做
严格的判断，导致其传入的“数据”拼接到 SQL 语句中后， 被
当作SQL 语句的一部分执行，从而导致数据库受损（被拖库、
被删除等）。
SQL 注入是一种攻击方式，在这种攻击方式中，在字符
串中插入恶意代码，然后将该字符串传递到 SQL Server 的实
例以进行分析和执行。构成 SQL 语句的任何过程都应进行注
入漏洞审阅，因为SQL Server 将执行其接收到的所有语法
有效的查询。
处理方案是：
（1） 进行 sql 预编译，防止 sql 注入攻击代码层，当传入
参数 4 or 1 = 1 时，被当作是一个纯字符串参数，所以就不
会出现sql 注入了。
（2） 确认每种数据的类型，比如是数字，数据库则必
须使用int 类型来存储。
（3） 规定数据长度，从一定程度上防止sql 注入。
（4） 严格限制数据库权限，能最大程度减少 sql 注入
的危害。
（5） 避免直接响应一些 sql 异常信息，sql 发生异常后，自
定义异常响应。
（6） 过滤参数中含有的一些数据库关键词。
修复验证时，需进行数据恢复挖掘，减少数据损失。
故障产生原因为：
（1） 代码层面没有对 SQL 进行预处理，导致 SQL 执行
时被 WEB 拼凑。
（2） 网络传输请求类型。
（3） 数据库设计的字符类型。
（4） 网络漏洞。
4.大事务操作
维护性质大事务操作比如常规的数据库表结构变更等
操作。该操作可以在变更窗口期，通过制作镜像表的过程等 数
据同步完毕后，切换对应的原目的表。MySQL 使用常规 PT 工
具来实现自动化操作。处理方案为确定变更的表结构信息，
借助 PT 工具功能进行onlineddl 任务发起。在 onlineddl 操作
成功后需进行修复验证，查验表结构变更是否正常。一般这
种故障是由于表结构变更产生的。
事务长时间不提交。在业务处理中可能存在查询数据量
大、执行时间长的复杂事务导致事务长时间不提交或数据库
异常发生主备切换未通知应用切断连接，线程僵死而导致活 跃
内存或连接池资源被长期占用。可通过数据库的系统工具， 监控
事务的状态，及时发现未提交的事务，及时报警。修复 验证时
检查：数据库连接使用是否正常，应用操作是否异常， 应用操作
数据是否一致。该故障的产生原因可能是：事物 SQL 获取的数据
量级大或SQL 存在性能问题，事物长时间不进行提交，数据库
异常僵死或卡住，资源长时间占用不被释放， 异常发生主备切
换等。
单个事务操作过大指在业务处理中可能存在涉及跨多
个分片/分区表数据交互的复杂事务导致事务执行时间长，
长期占用计算和内存资源，造成性能堵塞。可将大事务合理
的拆分成单个较小的事务，分多批进行处理。因为该故障主
要发生在大数据向数据库灌入数据的场景中，所以适当地提
高大数据的入库并发度，将单个大事务入库改成多个子任务
入库，可一定程度上避免此类问题。处理后需验证拆解事务
后业务执行效率是否改善，调整优化数据库并发后执行效率
是否改善。故障可能是由业务逻辑，数据库整体运行性能，
底层硬件架构性能造成的。
单个事务操作过多指在业务处理中可能存在同一个事
务中进行多个增删改操作或在查询操作中涉及多层嵌套查
询、聚合查询导致事务执行占用资源较大，影响事务的原子 性、
一致性。处理时需合理的评估该事务是否影响数据库性 能，可
以通过监控每个 SQL 的耗时，来评估是否将单个或者批量不
合理的小事务合并进行。修复后需检查整体资源的下 降情况，确
保业务逻辑整合后，效率有所提升。此故障可能 是因业务逻辑
复杂未进行合理拆解或数据库表设计与业务逻辑需求不匹配
而产生。
应急止损措施指在业务运行中，某个新增业务的 SQL 未
经过测试评估，直接下发数据库，导致整个数据库性能达到
瓶颈，影响其他业务运行。处理时需通过定位慢 SQL，与业
务侧及时沟通，通过评估 SQL 重要性、SQL 的大小，选择将
对应的事务 kill。并在业务上线前做好 SQL 审计及环境压测测
试。修复后需关注业务运行的性能情况，排除其他性能问题。
此故障一般是因为业务压力大底层资源性能跟不上、业务逻
辑及 SQL 复杂或前期的业务预估不合理导致。
5. 连接数超出阀值
连接池占满，主备切换异常指在互联网背景下金融业务
也存在业务挤兑、固定时段交易频发，客户端连接数据库数 量
激增引起瞬时压力，连接池耗尽从而影响整个系统业务连续
性。比如某历史业绩稳定的投资经理新发理财产品，加之重
点宣传，客户争相通过各零售代销渠道申购，在开放申购 时点
客户端连接会话数激增，造成数据库连接池占满，发生主备
切换等异常处理操作影响客户申购体验。解决这类问题
需在上线前合理的评估业务的连接数量是否会超过整个数
据库的连接池。如果业务建立的连接池超过数据库的连接池。 则
针对性能要求比较高的业务场景，强制建议使用连接池， 合
理的设置连接池的资源，避免总连接池超过数据库的连接 池。
针对短连接的业务场景，通过业务测的压测，评估要达 到业务
容量的QPS， 数据库的连接池是否设置合理。需压测评估后才
上线。处理后通过业务高峰期查看数据库使用情况 是否达到预
估，完成修复验证。此类故障产生原因可能是业 务并发预估不
合理、业务并发突增、业务逻辑优化欠缺或数 据库底层环境整
体性能不足。
无空余链接。业务运行设计中，如大量采用长链接需求，
可能导致连接不释放，没有多余的空余连接提供使用，后续
连接业务出现等待异常。处理时可合理的设置操作系统的
keepalive 参数，加快非活跃连接的回收，能做到在应急场景
下，有效的使用数据库连接数。业务侧可以根据业务重要性，
将非核心业务，削峰处理。临时停掉非核心业务，给核 心业务
提供足够的链接。修复后需检查连接回收后，是否满 足业务并
发需求以及业务削峰后，是否得到缓解。此类故障一般是业
务连接不释放或业务连接方式使用不正确造成。
6. 并发数过高
在互联网背景下金融业务也存在业务挤兑、固定时段交
易频发，客户并发数激增，未进行合理分片，产生热点节点，
数据库资源无法合理应用从而影响部分用户业务连续性。
场景描述：
某历史业绩稳定的投资经理新发理财产品，加之重点宣
传，客户争相通过各零售代销渠道申购，在开放申购时点并
发数激增，热点节点，发生主备切换等异常处理操作影响客
户申购体验。
处理方案：
并发数过多主要原因是业务对数据库资源评估不合理
导致的。针对并发数过多场景，短期应该与业务沟通，对部 分
非核心业务做限制。长远看需要对业务评估业务场景是否合
理，如果合理，则需通过扩容 DB 或者增加Redis、MQ 等中
间件的场景，避免该问题发生。
修复验证步骤如下：
（1） 业务改造后是否得到缓解。
（2） 底层扩容或改造架构后是否得到缓解。
故障产生原因：
（1） 业务架构和后端数据库架构不匹配。
（2） 后端数据库资源跟不上。
（3） 架构设计是否合理。
7.业务死锁
并发数较大场景下存在不同会话对同数据执行读写操
作，形成锁争用无法自动释放而影响业务执行。在业务逻辑 中，
业务表做DDL 操作时，该表还在进行频繁的DML 操作并且
还存在查询效率低下的 select 查询并发，导致 DDL 时获取锁超
时，业务下发中断。
处理步骤如下：
（1） 对死锁做监控，及时发现，及时解决。
（2） 优化业务 SQL 减少低效 SQL 运行。
（3） 优化业务逻辑，减少锁并发冲突的情况。
修复验证步骤如下：
（1） 剔除锁后，看业务是否恢复。
（2） 业务逻辑及 SQL 优化后是否避免。
故障一般是由业务逻辑问题或低效 SQL 导致。
8.业务中断
现象是在正常业务环境，运维人员对该环境进行数据压
测，导致数据库性能达到瓶颈，业务中断无法使用。
处理方案为：
（1） 停止压测任务，及时恢复业务的使用；
（2） 高可用架构中，压测将性能打满，通过主备切换的
方式进行业务的恢复。
（3） 压测在测试环境或者不使用的备机进行，以免影响
现有业务。
进行修复验证，查看业务是否恢复使用，性能恢复正常。
故障产生原因是：
（1） 操作不合理，在业务库进行压测。
（2） 压测并发参数调整不合理，导致资源打满。
9.极端场景数据抢救
分布式数据库在一些异常场景下导致集群不可正常使
用，数据丢失。通常可通过冷(热)补丁、主备机、备份恢复、 容灾
等手段进行修复，从而使集群可正常提供服务。但是，
当上述手段失效场景下，如无冗余极端场景下，数据发生文
件损坏，数据库无法启动，可使用抢救工具导出数据的能力，
避免数据全部丢失，从而进行有损用户数据抢救。
数据恢复成功后可通过数据库的运行状态、主备数据一
致性校验等手段判断是否完全恢复正常，可能存在两种情况，
一是无损恢复，二是有损恢复。当数据库数据丢失、数据库 服
务异常等场景出现时，优先使用冷(热)补丁、主备机、备 份恢
复、容灾等手段进行无损(或有损)修复；当无其他可用 手段时，
可尝试通过数据抢救工具，从数据库文件内离线解 析数据，再
将数据恢复至新集群。如果数据恢复是有损的， 需要业务评估
数据是否可用。该故障可能是存储服务异常、存储设备异常、
数据库文件损坏或人为(程序)原因误删除数 据库相关文件等原
因产生。
10.副本集数据同步延迟
副本集中的多个副本可以划分为主节点、备节点两类，
节点之间的数据复制路径可以是星型、链式或者混合模型，
具体模型的规划设计需要根据节点性能、各类任务负载压力、
网络带宽/延时等情况综合决定。
节点间数据复制延迟称为数据同步延迟。延迟时长和节
点性能、各类任务负载压力、网络带宽/延时等情况相关。 缩
短延迟时间是分布式数据库设计部署的一项重要任务。通
常来说，一个数据中心的两个节点间数据同步延迟时间短，
同城数据中心之间的延迟时间稍长，异地数据中心之间的延
迟时间最长。
节点间数据复制可以选择同步或异步模式。同步模式可
保证两个节点间数据的一致性，当一个节点出现故障后，另 一
个节点可以持续提供服务。可是同步模式只适用于两个节点
间的数据同步延迟时间非常短的情况，否则，会极大的影响
数据库事务的完成时间，从而延长事务完成时间、降低系统
的交易吞吐率，造成交易堵塞、服务失效。目前技术基本 能做
到同城同步复制，异地同步复制仍存在挑战。
异步模式把主节点的交易事务和节点之间的数据复制
解耦，数据同步不影响交易事务的执行。但是同时会带来数
据同步的延迟。也就是说两个节点之间的数据是存在不一致
的。
无论是数据同步的同步模式还是异步模式，都要做好延
迟时间监控和预警工作，一旦延迟时间增大或有增大趋势时， 需
要及时排查并确定问题原因，及时增加相应资源，解决问 题。
对于异步模式，需要注意设计部署足够大的操作日志空
间，保证数据同步延迟时间增大时也不会丢失数据。
四、总结展望
金融业数据库应急处理的重要意义体现在保障金融业
务的连续性、防范和减少数据风险、提升业务效率和响应速
度、保护客户利益和维护信誉，以及适应监管要求和法规要 求
等方面。随着金融业务的不断发展和数字化转型，金融机 构高
度重视并不断加强金融业数据库的应急处理能力，以应对日
益复杂和多变的风险挑战。下面是对未来金融业数据库
