《北京金融科技产业联盟：2023分布式数据库金融关键业务场景应急处理研究报告（55页）.pdf》由会员分享，可在线阅读，更多相关《北京金融科技产业联盟：2023分布式数据库金融关键业务场景应急处理研究报告（55页）.pdf（55页珍藏版）》请在三个皮匠报告上搜索。

1、分布式数据库金融关键业务场景应急处理研究报告北京金融科技产业联盟2023 年 10 月版权声明本报告版权属于北京金融科技产业联盟，并受法律保护。转载、编摘或利用其他方式使用本报告文字或观点的，应注明来源。违反上述声明者，将被追究相关法律责任。I编制委员会主任聂丽琴编委会成员王志刚李振编写组成员陈亮邓广俊刁现峰杜蓉冯六军高孝鑫郭智慧胡正策黄小慧黄炎黄元霞姜维莹李博文李国良李磊李思李萧萧路新英明玉琢申宇苏德财王登祎王枫王莉莉王嵩阳王栩吴洪辉许高峰徐雪涛叶强林张楠张毅周日明朱飞编审黄本涛张蕾II参编单位：北京金融科技产业联盟秘书处中国光大银行股份有限公司兴业银行股份有限公司华为技术有限公司中兴通讯股

2、份有限公司腾讯云计算（北京）有限责任公司蚂蚁科技集团股份有限公司北京国家金融科技认证中心有限公司飞腾信息技术有限公司北京奥星贝斯科技有限公司北京万里开源软件有限公司成都虚谷伟业科技有限公司上海爱可生信息技术股份有限公司上海热璞网络科技有限公司云南南天电子信息产业股份有限公司III摘要摘要近年来，在金融科技的推动下金融服务和产品不断推陈出新，数据处理呈现出体量巨大、并发量大、高处理性能、类型繁多等特点。银行的业务系统应对新挑战，不断扩容，架构在不同数据库和基础设施之上，变得更为复杂，加大了日常运维的难度和发生故障的风险。虽然单个数据库产品一般具备一定的故障探测和恢复能力，但银行数据库运维人员仍需

3、根据各种异常场景进行应急处理，在发生问题时最大程度缩短恢复时间、减少故障损失。本报告调研了参编单位现有应急处理方案，分析了金融关键业务场景中故障产生的原因，提炼出共性应急处理思路，形成普适的应急处理方案和修复验证指导，为金融机构进行关键业务场景的分布式数据库应急处置提供参考。IV目录目录一、研究背景一、研究背景.1二、应急处理思路1二、应急处理思路.1 1（一）应急预案.1（二）应急准备.5（三）应急演练.6（四）应急处置.7三、关键场景应急处理三、关键场景应急处理.8 8（一）特性分析.8（二）数据库组件故障.10（三）硬件故障.20（四）机房故障.34（五）数据库异常操作.38四、总结与展

4、望四、总结与展望.48481一、研究背景近两年随着国内数据库产业的蓬勃发展，银行中使用的数据库类型逐渐增多，特别是分布式数据库在金融关键业务场景的使用变得越来越普遍。数据库是金融业中金融资产的重要载体。无论哪种数据库，其稳定性、可靠性及可用性都是整个系统平稳运行的关键。虽然现有分布式数据库产品一般具备故障的自动探测、自动恢复能力，但不同分布式数据库的特性和操作方式不相同，银行数据库运维人员仍需根据各种异常场景做好应急处理，在发生问题时最大程度缩短恢复时间、减少故障损失。为了业务连续，运维人员需要在最短时间内判断及处理数据库异常，控制故障不进一步扩大，避免数据库停止服务，保证业务正常开展。其次，

5、一些常见的人为误操作可能会对业务数据、数据库系统的状态及性能会造成较大的影响，运维人员还需对常见误操作进行规范的应急处置，减少对业务及系统带来的负面影响。本课题通过调研参与单位现有应急处理方案，分析金融关键业务场景中故障产生原因，总结统一的应急处理思路，形成普适的应急处理方案和修复验证指导，为金融关键业务场景的分布式数据库应急处置提供参考。二、应急处理思路（一）应急预案分布式数据库在银行、证券、保险等金融机构生产环境运行时，都存在发生故障、停止服务的风险。保障生产系统2数据安全、确保服务稳定是金融机构科技部门最重要的工作之一。为了快速响应故障，保障分布式数据库生产系统数据安全、服务稳定，需要提

6、前分析可能产生风险的原因，并事先制定应急处置方案。分布式数据库系统技术栈包括分布式数据库组件，操作系统、服务器及服务器运行环境，服务器运行环境又包括机房环境和地域环境。分布式数据库生产系统主要面临的风险如下：1.系统故障1.系统故障指支撑分布式数据库运行的系统（或子系统）发生故障、停止服务。系统栈每一层中的系统都存在发生故障的概率。分布式数据库组件可能在运行过程中出现 bug 导致停止服务；操作系统在运行过程中可能会出现故障；服务器硬盘可能出现坏道，无法读取数据，内存可能部分失效，读取出错误内容等；机房环境可能出现供电故障，空调故障等情况；地区环境可能出现地震、台风等影响数据中心机房运行的灾难

7、。任何系统都存在发生故障的概率，数据库高可靠方案和系统及运维应急方案都是为在一定约束条件下降低故障发生的概率。当故障发生的概率足够小时，系统运行的安全就得到了保障。一般可以从以下三方面考虑，降低故障发生的概率：一是要选择故障率低的系统。比如选择经过检验的、故障率低的分布式数据库、操作系统、服务器、机房供电设备、空调等系统，建设机房时所选地区环境避免在地震带上，避3免历史上经常受到台风侵袭的地区等。二是准备冗余资源，确保系统栈中不存在单点故障。同等条件下如果准备两个或多个系统，其同时发生故障的概率将远远低于单个系统发生故障的概率。三是及时发现系统异常，并且一旦发生故障，能立刻自动或手动启动备用系

8、统保持/恢复线上服务，快速处理故障系统，恢复故障系统的服务。故障和故障处理，需要关注如下几点问题：（1）（1）各个系统在设计阶段要考虑预设屏蔽故障子系统的能力，单一系统（或子系统）发生故障时，该系统不再接收请求、提供服务。这种机制可使故障被限制在对服务影响最小的范围内，防止故障蔓延。（2）（2）分布式数据库最重要的资产是数据，必须着力避免因局部系统故障造成数据丢失。例如硬盘损坏时不能造成硬盘上的所有数据丢失。需要详细制定数据备份及恢复策略，在恢复系统服务时，保障数据不丢失。（3）（3）虽然所有技术冗余资源同时发生故障的概率很小，但仍需要制定相应的故障应急处理预案，包括业务处理方法或手动处理方法

9、。2.系统资源耗尽2.系统资源耗尽指系统资源耗尽，不能提供更多的服务，主要有两种场景：（1）（1）由于任务繁重，系统资源已全部投入服务，系统处理能力达到峰值，新的任务只能排队等待处理。此时系统4处于满负荷持续服务的状态，比如 CPU 满负载、网络带宽资源耗尽等。这种情况需要先排除是其他系统（子系统）故障而导致。（2）资源耗尽后，系统运行出现故障，造成停止服务。比如硬盘已满，但日志记录系统仍要写日志文件。对于此类资源耗尽风险，需要采取如下两类策略：一是一是事先预防策略。系统需要具备足够的横向扩展能力，通过增加服务器等资源增加峰值处理能力。二是二是监控应对策略。系统需要具备强大的监控告警能力，一旦

10、某种特定资源使用率超过阈值就进行告警，以便运维人员果断的启动增加部署资源流程。3.操作风险3.操作风险指生产运维人员在分布式数据库系统栈中进行系统操作时，发生操作失误，从而造成数据丢失或者系统停止服务的风险。主要应对措施包括以下几个方面：（1）做好培训。（1）做好培训。通过培训可使运维操作人员充分理解分布式数据库系统栈中相应系统的运作原理，熟练进行操作。（2）做好权限管理。（2）做好权限管理。通过权限设置，指定专项人员进行风险操作。（3）制定操作规程。（3）制定操作规程。完善数字化运维工具，通过支持双人操作的工具，操作规程等降低误操作的概率。（4）做好系统数据备份。（4）做好系统数据备份。在执

11、行风险操作前先对相关数据进行备份。（5)及时恢复。（5)及时恢复。一旦出现误操作，按照操作规程及时恢5复数据、恢复服务。分布式数据库在金融关键业务场景的应急处理并不仅仅指系统栈中系统突然发生故障后进行的处理工作，还包括系统设计及故障处理能力。完备的应急处理需要从系统规划建设阶段开始重视并落实。分布式数据库系统运行风险的处理思路也对系统栈中的各个系统的厂商、应用系统开发商及运维系统开发商都提出了要求，所以需要建立和各厂商及开发商的沟通渠道。高效、及时、可达的沟通渠道，能够把需求和问题反馈到各厂商及开发商，并得到顺利解决。此外，建议在分布式数据库上线前，针对各种运行风险事先准备应急预案，并为预案顺

12、利执行创造条件，包括完成应急预案制定、应急演练、应急培训等事宜。保证从分布式数据库上线开始，应急预案就是真实可用的。一旦出现任何系统故障或报警，能根据应急预案进行处置。（二）应急准备应急准备工作指系统故障或风险事件发生前，为防范风险进行的所有工作，包括以下内容：1.组织层面1.组织层面有效处置突发事件，快速恢复重要业务应进一步完善应急组织架构中的应急指挥层、应急执行层、应急保障层设置。根据事件影响程度及持续时间等因素对突发事件进行风险等级划分，并根据不同等级的风险事件制定突发事件应急处理流程，依据其可能造成的危害程序、紧急程度和发展态势，6划分预警级别并且建立相应的预警信息发布机制，这是应急准

13、备的重要部分。2.实施层面2.实施层面在项目实施中，准备应急预案、制定完善运维操作规程、上线分布式数据库系统及运维管理系统、组织安排运维团队等系统上线前所做的工作都是应急准备工作的一部分。3.其他3.其他在系统上线后仍有应急准备工作需要处理，包括系统日常运行监控、系统定期巡检、系统运行情况分析、应急预案更新升级、日常数据备份、定期验证备份数据的可用性、定期应急演练，等。此外，金融机构应根据应急演练实际情况完善应急预案及操作规程等合规操作，并进行操作合规性审计。（三）应急演练数据中心所在地区发生地震、台风，机房火灾、机房长时间停电；一个数据中心中的所有服务器同时故障；服务器硬盘同时故障等事件都属

14、于极低概率事件。这类极低概率事件在几年，甚至分布式数据库对外提供服务的整个生命周期中可能都不会发生一次。但是，应急预案的内容需包括对这类事件的处置应对。应急准备工作在组织层面、实施层面、其他方面包括了处置应对这类极低概率事件的工作。由于缺少实际事件的检验，一旦发生这类极低概率事件，相关领导、业务人员、技术人员、厂商/合作方人员，处理故障、问题的资源是否就位，处置是否有序、高效，排除故7障、解决问题、恢复服务是否迅速及时，整体应急准备工作是否完备，都需要通过定期的应急演练来检验、完善。分布式数据库涉及的极低概率事件的应急演练，可以纳入灾备切换、信息科技相关等应急演练中一并考虑，统一组织。应急演练

15、工作应在应急准备工作完成后安排实施。组织安排应急演练工作实际上是对应急预案的实施落地。首先要做好组织动员工作，建议成立行领导牵头，相关业务部门、技术部门参与的应急演练小组，协调相关厂商、合作方安排相关人员参与应急演练工作。次之是做好应急演练方案，明确岗位职责，细化演练流程，保障方案可行性。其次是保障支撑应急演练的各项资源就位，包括备品备件、通讯线路等。再次是做好业务合作方、技术产品/服务合作方等的沟通协调工作，提前通知对方本单位的应急演练计划，请合作方做好支持安排。最后是完善应急演练组织的沟通机制，工具。应急演练应严格按照应急预案，应急演练方案来落实实施。且应制定持续改进的机制和方案，在应急演

16、练完成后，全面总结应急演练过程中的经验和教训，完善应急预案和其他应急准备工作。（四）应急处置当有系统发生故障或者存在风险时，需要启动应急风险处置预案。风险处置最重要的原则之一是在保障数据安全和操作合规的前提下，采用最短的时间恢复生产，并按照应急预案演练的情况推进其他步骤。如果出现应急预案没有覆盖的风险，应根据风险影响范8围进行汇报，同时按照审慎的原则进行处理，比如尽量确保在分析和处置风险的过程中，获得应用开发商和具体系统厂商的参与和支持。在完成问题处置后应梳理处置过程，并将风险及处置情况纳入应急预案中，以防范之后的风险。三、关键场景应急处理（一）特性分析数据库系统是按照特定数据结构组织、存储和

17、管理数据的基础软件，根据架构不同可分为集中式数据库和分布式数据库。分布式数据库是物理上分散而逻辑上集中的数据库系统，利用分布式事务处理、数据自动分片、数据多副本存储等技术，将分散在计算机网络的多个逻辑相关的节点连接起来共同对外提供服务。如图 1 所示，分布式数据库比较典型的技术架构包括管理模块、计算模块和存储模块 3 个部分。9图 1 分布式数据库典型技术架构计算模块负责解析应用程序查询请求、生成查询计划，并将查询计划自动分配到各计算节点并行执行。存储模块负责执行计算层数据操作请求，并实现数据在硬件层面的持久化保存，确保数据不丢失。存储层将数据按分片进行多副本存储，保障数据可靠性。管理模块负责

18、协调分布式时钟和维护元数据，并提供数据库参数配置和运行监控。分布式数据库具有天然复杂性，产品自身组件、操作系统、磁盘和服务器等故障，都可能导致集群的少量节点实例不可用。且分布式数据库在金融业的架构形态通常有单中心、同城互备、同城双活、两地三中心等，当网络设备发生故障，10除了导致部分节点实例不可用外，还可能出现集群分裂情况等。因此集群中任何节点的软硬件故障或者任何节点之间的网络连接故障都需要被妥善处理。分布式数据库需要建立应付各种异常场景的处理方案应对金融业数据零丢失和业务高连续性的要求。较为典型的故障场景包括：数据库自身组件故障、操作系统故障、硬件故障、机房故障、数据库操作异常等。在每个场景

19、下，应急处理流程都包括通知相关人员、尝试修复、备份数据、恢复数据库和测试验证等步骤。建立和执行有效的应急处理流程，可以帮助金融机构最大限度地减少数据库故障和安全事件对业务运营的影响，保障金融行业的数据安全和运营稳定。下面将针对典型异常场景故障进行应急处理方案介绍。（二）数据库组件故障1.管理节点宕机（二）数据库组件故障1.管理节点宕机在分布式数据库集群中，管理节点为集群提供各类管理服务，所以总控服务需要高可用的设计，一般使用多副本一致协议来保证管理节点的高可用性。下面以 Paxos 协议为例，通过对分布式数据库集群进行配置来指定管理节点的副本数。管理节点的各副本基于 Paxos 协议选举 le

20、ader，leader副本上任后为集群提供总控服务，当管理节点当前 leader发生故障卸任时，其他的副本重新选举产生新的 leader，并继续提供总控服务，从而实现总控服务的高可用。所以任何一个管理节点的故障对分布式数据库集群整体业务没有影响，但当超过半数的服务异常后，分布式数据库集群将无法11提供服务，此时需要依赖备集群恢复业务。当人为原因、机器的故障、内部选举机制等，数据库运行异常，导致某节点无法正常工作时，产生了管理节点宕机时，解决方法是：可采用高可用架构设置管理节点，为管理节点提供多副本保障，某节点宕机时，其他节点可接管故障节点的工作，保障数据库正常工作。如果是数据问题，其他的副本重

21、新选举产生新的 leader，并继续提供总控服务，从而实现总控服务的高可用，保障数据库正常工作。通过 Paxos协议对故障节点进行数据修复，进行数据同步，保证管理节点集群数据的一致性。如果是机器故障，可重启或检查机器故障原因进行问题排除，机器正常重启后，可通过 Paxos 协议对故障节点修复数据，然后进行数据同步，保证管理节点集群数据的一致性。进行修复验证时，人为切换至原故障管理节点（已经修复正常），如数据库操作结果与其他目前在运行的管理节点操作结果一致，则修复成功。管理节点故障，主要可能原因如下：（1）机器报警。（2）无法正常保障数据库工作。（3）返回结果异常。（4）数据丢失或损坏。（5）主

22、副本数据不一致。2.计算节点和数据节点宕机2.计算节点和数据节点宕机计算节点和数据节点是分布式数据库的核心，分布式数12据库在每个节点上只存储部分数据，使用多副本一致性协议来保证分区的数据在多个节点上的一致性。任何一个节点故障，其他节点上的分区副本依然会构成多数派，可以重新选举出新的主副本来提供服务，这个切换过程需要在保证RPO=0 的同时尽量缩短自动切换时间。但如果分区多个副本所在的节点发生故障，那么剩下的节点将无法合法的选举出主副本，这些分区将无法正常提供服务，但其他正常分区依然可以提供服务。当人为原因、机器故障、内部选举机制等导致数据库运行异常，此类节点无法正常工作时产生计算节点和数据节

23、点宕机时，解决方法是：计算节点和数据节点都采用高可用架构，有多副本保障。当某计算节点宕机时，其他计算节点可接管故障节点的工作，保障计算节点正常工作；当某数据节点宕机时，其他数据节点中的副本可转正为主本，保障数据节点正常工作。如果是计算节点数据问题，其他的计算节点重新选举产生新的主节点，并继续提供总控服务，从而实现总控服务的高可用，保障数据库正常工作。然后通过一致性协议对故障计算节点进行数据修复，进行数据同步，保证计算节点集群数据的一致性。如果是数据节点数据问题，可切换到其他有该故障节点副本的数据节点，其副本会转正为主本，进行数据库操作，保障数据库正常工作。然后通过一致性协议对故障数据节点进行数

24、据修复，进行数据同步，保证数据节点集群数据的一致性。如果是机器问题，可重启或检查机器故障原因进行解决，机器正常重启后，可通过一致性13协议对故障节点进行数据修复，进行数据同步，保证计算和数据节点集群数据的一致性。进行修复验证时，人为切换到原故障计算和数据节点（已经修复正常），如数据库操作结果与其他目前在运行的计算和数据节点操作结果一致，则修复成功。计算和数据节点故障，主要可能原因如下：（1）机器报警。（2）无法正常保障数据库工作。（3）返回结果异常。（4）数据丢失或损坏。（5）主副本数据不一致。3.数据代理节点宕机3.数据代理节点宕机分布式数据库集群一般会提供数据库代理组件以便准确地将 SQL

25、 请求路由至合适的计算和数据节点上。代理组件接收用户发出的 SQL 请求，并将 SQL 请求转发至最佳目的地，从而减少跨越节点的远程事务。数据库代理节点一般是无状态的，不记录事务的状态。当一个节点故障后，业务应用可以访问新的数据库代理节点来获得数据库服务。业务系统和数据库代理节点之间可以部署负载均衡服务来保障更高的可用性。当人为原因或机器的故障，数据库运行异常，数据代理节点无法正常工作发生宕机时，解决方案为：数据库代理节点采用高可用架构，某节点宕机时其他代理节点可接管故障节点的工作，保障数据库正常工作。如果是硬件或软件的问14题，需要重启或检查机器故障原因进行解决，业务应用可以访问新的数据库代

26、理节点来获得数据库服务。业务系统和数据库代理节点之间可以部署负载均衡服务来保障更高的可用性。修复验证时，人为切换到原故障管理节点（已经修复正常），进行数据库操作，代理组件接收用户发出的 SQL 请求，并将 SQL 请求转发至最佳目的地，如果操作一些正常，则表示已经修复成功。数据库代理节点故障，主要可能原因可能是机器报警，无法正常保障数据库工作，返回结果异常，时间延迟较长等情况。4.GTS/GTM 全局事务服务异常4.GTS/GTM 全局事务服务异常为保证全局的事务顺序，分布式数据库集群一般会提供一个全局时间戳服务（简称 GTS）或者全局事务管理器（简称 GTM），事务提交时候通过时间戳服务获取

27、事务版本号。因此 GTS/GTM 是分布式数据库的核心，需要保证高可用。GTS/GTM 服务默认也是多副本的，因此其高可用能力跟普通表的能力一样，在下述异常场景下依然能够保证时间戳的正确性。（1）有主改选：原 Leader 主动发起改选的场景称为有主改选。新 leader 上任之前先获取旧 leader 的最大已经授权的时间戳作为新 leader 时间戳授权的基准值。因此该场景下，GTS 提供的时间戳不会回退。（2）无主选举：原 leader 与多数派成员发生网络隔离，15等 lease 过期之后，原 follower 会重新选主，这一个过程称为无主选举。选举服务保证了无主选举场景下，新旧Le

28、ader 的 lease 是不重叠的，因此能够保证本地时钟一定大于旧主提供的最大时间戳。因此新 leader 能够保证 GTS提供的时间戳不回退。当人为原因、机器的故障、内部选举机制等，数据库运行异常，GTS 或者 GTM 节点无法正常工作产生宕机时，解决方法是：GTS/GTM 全局事务服务采用高可用架构，某节点宕机时，其他节点通过选举接管故障节点的工作，保障数据库正常工作。新 leader 上任之前先获取旧 leader 的最大已经授权的时间戳作为新 leader 时间戳授权的基准值。保障 GTS本地时钟一定大于旧主提供的最大时间戳。修复后进行检查，预期是当前的 GTS 本地时钟一定大于旧主

29、提供的最大时间戳或者当前 GTM 提供的全局事务号大于旧主提供的最大全局事务号。GTS/GTM 全局事务服务故障，主要可能原因如下：机器报警、无法正常保障数据库工作或返回结果异常。5.操作系统故障5.操作系统故障分布式事务数据库服务运行在操作系统中，操作系统中核心资源（如：CPU、磁盘、内存、I/0、网络等）是数据库服务正常运行的基础保障。为保障分布式事务数据库在不同资源占用比场景下服务的稳定性和可靠性，需提前准备各项核心资源的阶梯占用以及资源匮乏等场景下的预案。通常情况下，在磁盘空间（包括 inode 耗尽）、内存占用以及以上16组合场景时，数据库服务均会出现异常。解决方法是对系统资源进行日

30、常容量监控和预警。6.文件系统为只读模式6.文件系统为只读模式现象为数据库服务异常退出，重启过程中无错误日志输出，且重启过程不断报错，并带有“Read-only file system”字样。解决方案为：确认问题原因是否为文件系统被设置为只读情况，以及被设置为只读模式原因。解决文件系统被设置为只读模式原因后，重启服务器，进行修复确认，查看文件系统模式及数据库服务运行是否正常。故障产生的原因是：一般情况文件系统被设置为只读模式是由于系统发现磁盘硬件（Riad 卡，硬盘）故障或文件系统中文件被损坏后而采取的保护机制导致的，比如文件系统错误、磁盘坏道、RAID 卡故障、inode 资源耗尽、IO 繁

31、忙、硬盘背板故障、硬盘线缆故障、HBA 卡故障、内核相关硬件驱动 bug、FW 固件类问题以及系统没有正常关机，也会导致磁盘出现文件系统错误。为了保护数据不破坏分区中已有内容，Linux 在挂载文件系统时会以 read-only 只读方式加载。7.总体 CPU 资源占用过高7.总体 CPU 资源占用过高业务系统通常上线后资源使用率较为稳定，此场景下CPU 使用率相比较日常表现突然变高或者不断攀升，导致系统运行速度变慢或运行异常。解决方案为：观察 CPU 使用率分布，确认具体导致 CPU突然飙高的原因是软件还是硬件。软件层面问题通常可以确17定为某一个程序引起，可通过观察确认具体引发 CPU 繁

32、忙的操作，采取关闭不必要的进程或操作即可恢复 CPU 使用率；如判定为硬件问题，则需要升级硬件进行处理。进行修复确认，预期是解决 CPU 飙高的软件原因或硬件原因后，CPU 使用率恢复至正常水平。此种故障分为软件原因和硬件原因。软件原因通常会存在新增应用程序占用（如挖矿、测试软件等）、有语法错误的 SQL（如简单 SQL 因连接符号或标点符号等写错导致变为一个超大的复杂 SQL）、中毒等情况；硬件原因主要来自机房散热、驱动故障、CPU 寿命等情况。8.单核 CPU 跑满8.单核 CPU 跑满现象为总体没有明显的资源瓶颈，查看进程实时动态信息时发现单核跑满，且磁盘调入内存跑满。解决方案为：进入

33、BIOS 查看网卡队列情况，如为单队列网卡则需要升级或者更换为多队列网卡；如为多队列网卡，则需要设置多队列，并且进入系统后进行多队列的 CPU 中断绑定处理。进行修复确认，预期是解决上述问题后，CPU 使用率分散到所有核，且磁盘调入内存较为均匀。故障原因通常为多队列网卡未开启多个队列、多队列处理未绑定到多个 CPU 上或者网卡本身为单队列等等。9.I/O 资源占用过高9.I/O 资源占用过高通常，业务系统上线后资源使用率较为稳定，如 I/O 使用率相比较日常突然变高、I/O 卡顿或进程实时动态信息中18I/O 等待所占用的 CPU 时间百分比数值变大，产生系统运行速度变慢或运行异常甚至操作系统

34、卡顿的问题。解决方案是：观察磁盘 I/O 的使用情况，判断是否软件进程或线程存在 I/O 使用频繁，如判定为非软件系统问题，则需要进一步排查硬盘故障类硬件问题或其他偶发性情况，偶发性问题需要进一步排查操作系统 bug、异常操作等，综合考虑并确认 I/O 繁忙的原因。软件层面问题通常可以确定为某一个程序引起，并通过观察可确认具体引发 I/O 繁忙的操作，此时关闭不必要的进程或操作即可恢复 I/O 使用率；如判定为硬盘故障类硬件问题，则需要升级硬件进行处理，如为其他偶发性问题，则需要进一步排查操作系统 bug、异常操作等并进行对应升级修复。进行修复确认，预期是解决 I/O 飙高、卡顿的软件原因或硬

35、件原因后，I/O 使用率恢复至正常水平。故障原因分为软件原因和硬件原因。软件原因通常会存在新增应用程序占用（读写压力高的测试软件、系统级别频繁刷日志等）、不合理的表结构设计及 SQL 设计（如无索引、全表扫描等）、操作系统 bug 等；硬件原因主要来自磁盘损坏。10.内存消耗过大10.内存消耗过大数据库使用过程中，通常会占用较多的内存，一般不影响数据库服务。而当内存溢出、内存碎片泄漏等情况导致服务被异常关闭时，可能出现内存消耗过大的问题。解决方案为：服务正常情况下，内存偶发性增加大概率19是因为业务系统中存在高消耗内存 SQL 语句；出现服务异常关闭情况下，通过分布式事务数据库日志以及操作系统

36、日志等信息进行分析，确认退出原因，大概率存在启动内存参数不合理、内存占用过高被操作系统误杀等情况。如为 SQL 操作，则需要优化 SQL 或者数据库支持情况；如为内存参数等内容则需要采取调整数据库启动内存参数设置、优化内存碎片回收机制等对应措施。进行修复确认，预期试运行一段时间后观察内存使用率情况以及服务运行情况，均稳定运行。故障原因大多为软件问题，主要原因有高消耗内存的SQL 操作、内存参数设置不合理及内存碎片回收待优化。11.磁盘占用满11.磁盘占用满现象为磁盘突然使用率增加，直至占满，导致数据库服务异常退出。解决方案为：查看磁盘占用（du-Sh*等）命令，了解占用磁盘的文件，从而分析具体

37、磁盘快速写满的原因。清理出部分空间后，按照磁盘用满的原因做对应处理，然后启动数据库服务。进行修复确认，在数据库服务启动后，观察磁盘写入情况，预期是占用情况恢复正常。故障原因通常为压测过程中不断写入数据和日志，数据库异常报错不断进行错误日志写入，操作系统异常不断写入操作系统错误日志，缺乏监控手段导致正常数据和日志写入刷满磁盘等情况。2012.网络负载过高12.网络负载过高现象是网络流量过大引发丢包、重传、网络延迟过大，从而导致系统服务响应变慢、报错。解决方案为：通过观察网卡进出流量、网卡本身负载能力及相关硬件配置情况，确认具体网络负载过高的原因，确认是否为存在大量写入和读取数据操作导致网络流量增

38、加，或实际流量较高但网卡或者交换机等硬件性能不足情况。如为软件层面操作问题，等待业务执行完成并及时监控即可；如为硬件性能不足情况，则需要升级或者更新硬件设备。进行修复确认，预期是修复后观察网络流量及丢包率、重传率、网络延迟等参数均正常。故障原因分为软件原因和硬件原因。软件原因通常为大量写入和读取数据操作，需确认是否为业务正常行为；硬件层面通常为网卡及交换机等设备性能不足或损坏情况，需要更新或升级硬件。（三）硬件故障1.服务器宕机（三）硬件故障1.服务器宕机服务器宕机通常是指应用的服务器处于一种非正常运行的状态，例如服务器假死、停止使用或者关闭，系统无法从错误中恢复过来或系统硬件层面出问题，以致

39、系统长时间无响应无法对外部指令进行响应，服务器的宕机会给用户的正常使用带来较大的影响。在排查时需要判断服务器宕机的严重程度，可在宕机发生后等待一段时间，此时宕机系统若恢复即常说的假死，若21仍未恢复则需要查询系统日志，分析宕机前后系统日志的报错情况，其次查看监控数据是否有指标异常，例如资源的消耗异常，最后可查看服务器硬件故障情况。服务器宕机故障预防可以从以下几方面着手：一是从软件出发，查看程序设计是否合理，数据查询是否有死循环。二是从硬件出发，配置分布式软件，从而形成冗余硬件资源。针对高并发或存在大量计算、海量存储的情况，升级服务器硬件配置，加大网络带宽、升级服务器 CPU、提高服务器内存、扩

40、展存储服务器。三是在系统的设计中考虑合理的警报和监控框架，尽早发现和诊断故障问题，缩短排查与处理时间。故障处理时，对于访问量过高超出系统承载能力的短暂性突增或者异常的访问可等待一段时间或手动杀死进程或重启，排查异常访问来源。对于早期建设的不能满足需求的传统集群需要对系统的软硬件进行升级与优化。对于系统设计的不合理之处，需要对业务的支撑资源重新划分调配，优化业务系统的查询或多线程的处理。当系统内部参数配置不合理时进行参数的优化和调整。存在系统内核故障或错误时需要升级内核。对于人为的误操作，则需要提高操作人员的能力。宕机恢复后系统进行修复验证步骤为：（1）检查系统日志，是否有报错；（2）检查系统各

41、项功能是否正常，并检查对应日志；（3）检查应用各项功能是否正常，并检查对应日志。22金融关键业务场景下，分布式数据库，可能出现宕机的原因主要包括：（1）访问量过高超出系统的承载能力，包括正常的短暂性突增，或者异常的访问，如非法攻击的情况。（2）早期建设的传统集群，部分已不能满足现今的系统需求，服务器配置过低，导致即便访问量不算太高也超出了系统承载能力的情况。（3）系统的应用程序设计存在不合理的异常或漏洞，例如对业务支撑的系统资源不合理，或例如死循环或多线程造成死锁，消耗系统资源的逻辑导致资源耗尽。（4）系统内部参数配置不合理，例如允许连接数过低。（5）存在系统内核程序错误或故障，包括软死锁等情

42、况。（6）在一定环境中，人为的误操作也可能导致服务器宕机情况的发生。为了尽可能减少服务器宕机故障的发生频率，维护系统稳定运行。要减少运行环境的负荷过载，因此要监控运行环境中的操作系统、网络以及各类硬件资源的使用，当有软件正在大量占用服务器内存、CPU、磁盘或网络，或者网站的并发访问数超过带宽资源，系统资源出现暂时性不足，例如磁盘空间耗尽、内存耗尽等情况时，及时进行告警，然后进行干预。2.电源故障2.电源故障服务器电源按照通用标准可以分为 ATX 电源和 SSI 电源23两种。ATX 主要用于台式机、低端服务器或工作站，该标准使用较为普遍；随着服务器技术的发展，适用于各种档次的服务器标准 SSI

43、 标准诞生。系统服务器电源（power）与用于个人的 PC 服务器电源都是一种开关电源。作为硬件服务器的能量源发挥着无形的巨大作用，目前服务器的电源模块种类较多，不同服务器产品的输入/输出电压、功率、功能及拓扑结构都有可能不同。电源故障可能导致系统运行不稳定，当磁盘出现坏磁道、CPU 超频工作不稳定、主机莫名重新启动、服务器运行时噪音较大等情况。故障产生原因通常包括电源模块质量较低、电源的功率不足、电源的稳定性较差等原因。比如电源模块在电压输出偏低或偏高的转换过程有能量损耗，从而造成模块发热严重、输出噪音大，电源模块启动困难且反应较慢、电源启动后迅速烧毁冒烟或短路、电源模块损坏较快等情况。不同

44、的应用对服务器电源的要求不同，在分布式数据库的金融业，尤其强调数据的安全性和系统的稳定性，因而要求服务器电源要具有很高的可靠性。因此分布式数据库需要考虑到服务器电源故障问题，需具备在电源故障情况下的数据保障能力。在分布式数据库的金融关键业务场景下，为了预防服务器电源故障，大部分服务器均采用冗余电源。也就是服务器采用高质量的冗余电源模块组件，并在机柜内提供冗余电源，一方面，具有均流、故障切换等功能，另一方面，能有效避24免电源故障对系统的影响，实现长时间不间断运行。N+1 冗余即运行系统所需的 N 个额定容量的组件数量再增加一台，一个电源发生故障，系统仍能持续运行。除了服务器电源冗余、机柜电源冗

45、余，还有机房的 UPS 冗余。也就是说任何一台 UPS 发生故障时，由额外增加的一台 UPS 不间断提供电力，提高系统可靠性，同时依靠均流技术并行运行。通过冗余电源和热插拔技术配合，可实现热插拔冗余电源，从而提高服务器系统的稳定性和可靠性。发现电源故障，可以通过更换电源组件或检查电源状态来进行故障检查，最终通过更换电源组件解决出现的电源故障问题，保证系统稳定性。修复后，可通过检查电源状态、服务器状态、操作系统状态、应用状态来进行修复确认，修复完成后，系统现象为磁盘磁道正常读写、CPU 超频工作稳定、主机开关启动正常，服务器运行时噪音较小。3.磁盘损坏3.磁盘损坏磁盘损坏主要有以下场景：（1）故

46、障提示。即磁盘自我监测、分析错误报告其磁头、磁盘、电路等部件与预存的安全值发生冲突，自动发生警告信息。（2）磁盘无法识别。启动时显示磁盘无法识别，或系统无法显示磁盘。（3）系统运行出错。服务器运行不断出现程序错误且磁盘扫描停滞甚至死机。25（4）运行报错。扫描磁盘发现错误或显示坏道。（5）初始化死机。包含其他部件与磁盘故障的可能。故障产生的可能原因包括：（1）磁盘系统故障，发生系统中断、跳出、停滞等现象。这些现象的发生可能存在磁盘或系统的故障。（2）磁盘物理故障，一般表现为无法识别磁盘存储数据，或者是无法读取数据，导致用户无法使用磁盘。（3）磁盘运行故障，主要表现在扫描磁盘的时候发现错误。磁盘

47、运行故障一般发生在坏道的产生，需要对磁盘进行隔离，保障磁盘的正常使用。在分布式数据库的金融关键业务场景下，为了预防服务器磁盘故障，大部分服务器采用冗余磁盘，并做磁盘阵列，来预防磁盘故障。也就是 N+1 冗余，即运行系统所需 N 个磁盘，再增加一块或多块磁盘。多块磁盘做磁盘阵列后，一个硬盘发生故障，系统仍能持续正常运行。对于磁盘故障，首先确认业务在分布式数据库保有数据备份情况下的稳定运行，备份数据启动承载切换的业务后，再进行故障磁盘的更换。磁盘系统故障在排除系统故障后对磁盘进行检修，磁盘物理故障需要保证备份数据的可用，或对现有数据进行转移后对磁盘进行检查维修。磁盘运行故障则需要对磁盘进行隔离，查

48、看坏道分布情况。对于少量坏道，可以尝试软件修复，对于大量集中的坏道，可以对磁盘进行分区，然后把分区隔离，避免坏道扩散。对于分布均匀或坏道较多的情况则需要更换磁盘。26更换故障硬盘后，往往需要重新做磁盘阵列的同步，从而把数据恢复到新磁盘中。分布式数据库需要在磁盘的存储中保证数据存储的分布式策略，确保数据在集群的磁盘中存在不止一份可用的相同数据，在集群中一个磁盘的损坏可自动切换到备份数据的磁盘，单个磁盘的故障不影响系统数据的安全可用性。磁盘修复后，应表现为不再出现磁盘损坏场景描述现象，在系统运行中可查询该磁盘的完整数据，分布式数据库的数据分布策略在磁盘修复后完成磁盘数据分布初始状态，磁盘数据与备份

49、数据具备一致性。4.内存条故障4.内存条故障内存条故障常见开机报警、读取出错、解压出错、内存短路主机无法加电、蓝屏死机、无法启动等场景。内存损坏导致系统注册表报错情况较为常见，系统在正常启动进入桌面后，系统提示注册表读取错误，需重新启动电脑修复该错误，再次启动电脑后，仍旧提示注册表读取错误，其次在主机使用环境恶劣，如湿度过大在长时间使用过程后，内存金手指表面氧化，造成内金手指与插槽接触电阻增大对电流通过的阻碍，形成内存自检错误，表现为开机内存报警。内存故障产生原因如下：（1）内存故障导致注册表读取错误情况，包括安全模式的设置原因、长时间未进行磁盘碎片整理及错误检查，以及则存在于机器内存损坏的硬

50、件故障。（2）出现内存损坏安装系统提示解压缩文件出错故障27的原因，一般是内存的质量不良或稳定性差造成的，无法正常读取某一文件或系统安装文件损坏。（3）在内存短路导致主机无法加电的情况下，可能存在电源质量不稳定或其他部件接触或需要更换的问题。（4）若出现蓝屏死机或无法启动的情况，根据蓝屏时的出错提示或无法提示则应是内存中某种虚拟文件出错，可能存在接触不良、内存插槽脚短路、内存条安装不正确或内存插槽变形等问题。内存条故障预防首先应保证使用环境符合国家机房标准，如温度、湿度、静电等等，避免因为温度、湿度、静电等原因导致内存条故障。其次，严格控制操作人员具备相关技术能力，从而避免内存条安装接触不良、

51、安装不正确等问题。采用带有 ECC 校验的内存条，从而能够发现错误，自动纠正错误。内存条故障检查主要考虑接触不良、安装不正确、插槽变形等问题。具备相关技术能力的安装人员首先仔细检查机器安装环境，然后按照标准步骤进行，并细化安装后的检查流程，减少人为操作造成的故障。对于电路短路或断路问题，需要技术人员确保安装运行环境的电源导线正确连接。对存在于机器内存损坏的硬件故障需要使用替换法。首先备份重要资料，换上性能良好的内存条，进行重新安装。同理，在金融关键业务场景中，内存条的质量不良或稳定性差极大的影响系统的整体性能，建议使用高质量的内存条硬件。28更换内存条后，检验是否存在同样的故障，能否读取系统文

52、件。更换高质量的内存条后，应有响应速度的提升及系统稳定性的提升。5.主板故障5.主板故障主板故障通常表现为主板无法启动、系统不能识别键盘和鼠标、外连接的如打印机不能正常工作、显卡提示警告或发出非正常的报警声等与主板有关的问题。主板故障产生原因：（1）主板无法启动的故障原因包括安装问题中的接触不良、主板及主板上各元件的制作工艺质量问题。（2）对于连接外设键盘、鼠标、打印机出现不支持或不能正常工作的故障，存在连接接口松动、接触不良、线路故障、连接外设硬件故障及主板线路或主板故障问题。（3）主板的电源安全故障，主板电源是否通过稳压器过滤和是否具有滤波功能的电容来稳定供电电流保护主板的正常使用；（4）

53、显卡与主板的松动导致故障，或显卡与主板非正常兼容。金融关键业务集群出现主板故障对于系统来说有较大风险，在集群建设之初应选用高质量的主板硬件，确保主板及主板上各元件的制作工艺优良，具备承载金融核心业务或关键业务的能力，不出现质量问题。常用主板故障检查方法：观察法、清洁法、插拔交换法、软件诊断法。如观察主板及电容等是否有烧毁迹象、是否接29触不良，清洁因灰尘过多造成的故障，使用插拔交换的排除法确定故障所在元件如主板或 I/O 设备，通过诊断程序或测试软件对主板进行辅助硬件维修，读线路及芯片状态识别故障部位如接口等。系统安装中由专业技术员进行操作，为防止主板电源故障问题，应确保主板电容上的电压不超过

54、额定值，确保供电电源通过稳压器过滤。计算机主板不宜在长期高负载的情况下工作，易导致电容过热。出现主板异常的情况下，及时联系硬件厂商进行处理。应用方在工作状态可利用万用表来检测 CPU 周围的三极管、二极管是否工作正常，以便检查 CPU 供电的正常情况；出现断针或断裂现象，须及时联系分布式数据库厂家做好数据备份及应用业务的切换，由硬件厂商更换新配件。主板故障恢复后，需要对系统进行验证，首先可查看硬件故障指示灯是否熄灭，然后检查服务器硬件错误日志、操作系统启动日志、应用日志等。6.阵列卡故障6.阵列卡故障阵列卡全称为磁盘阵列卡，主要用来做 RAID，把所有硬盘整合成一个大磁盘，再在这个大磁盘上做分

55、区。阵列卡故障特征：（1）RAID 磁盘阵列中物理硬盘指示灯告警。（2）显示多块硬盘呈离线状态或丢失状态。（3）RAID 信息丢失，所有物理硬盘不再是 online 状态。（4）无法进入 RAID 管理界面或查看 RAID 相关信息时死机。30磁盘阵列卡故障原因：（1）服务器硬件故障导致的阵列卡故障，如电路板损坏、磁头损坏、盘面损坏以及其他固件损坏等。（2）断电、电压不稳导致的阵列卡故障。（3）管理员在维护过程中由于误操作导致硬盘盘序出现错误或在配置 RAID 阵列信息时出错误导致数据丢失均有可能造成阵列卡故障。（4）RAID 在同步数据或者重建过程中，同组 RAID 阵列中有其他硬盘掉线导致

56、同步失败。磁盘阵列卡故障检查时，由于阵列卡的特殊性，处理不当可能造成数据丢失，所以对于阵列卡的处理方式应该更加的谨慎，针对不同的故障产生原因，采取恰当的处理方式：（1）若是由电源原因造成的阵列卡故障，为了防止数据丢失，需要先将系统电源关闭，再依次检查硬盘，处理电源问题。（2）若是服务器硬件导致的阵列卡故障，先要确认数据是否丢失，若无数据丢失则修复对应的硬件之后再行处理。（3）若有数据丢失，则要将情况报告给磁盘阵列厂商或者专业的磁盘阵列数据恢复公司进行处理。值得注意的是，谨慎选择初始化或者 ReBuild 等可能导致数据丢失的处理方式。在阵列卡故障修复后，首先查看硬件故障指示灯是否熄灭，然后进入

57、阵列卡 bios 中查看阵列卡是否正常，若显示online 和 protected 则代表阵列卡故障修复成功，可正常使31用。7.网卡故障7.网卡故障网卡是局域网或互联网中连接计算机和传输介质的接口，是电脑与网络的一道桥梁，一旦网卡发生故障，便不能上网。网卡故障一般会出现如下几种症状：（1）在“设备管理器”里无“网络适配器”。正常情况下，打开“设备管理器”时，里面有一排像“RealtekRTL8139/8111”的英文，此英文就是我们的网卡设备。如果没有此“网络适配器”及英文就表示网卡没有识别到，或网卡损坏。（2）在“设备管理器”中有“网络适配器”，并且也有“Realtek RTL8139”等

58、一排英文，但是在“Realtek RTL8139”上面有个感叹号。并且无论我们如何安装驱动，重装系统等，此感叹号都无法消失，也就是说网卡都无法正常工作，此种现象也表示网卡故障。（3）当插上网线时，电脑右下角提示“网络电缆没有插好”，若无论如何插拔网线，或者更换全新网线，排除网线及网络故障时，电脑依然提示“网络电缆没有插好”时，此时也为网卡故障。（4）一般网卡正常工作时，网卡绿色指示灯会亮，如果插上网线，网卡指示灯完全不亮，也可以断定为网卡故障。（5）在排除网络本身故障以及电脑系统问题的情况下，若网卡只有发送包而无收到包，也可以确定为网卡故障。网卡故障原因如下：32（1）外部原因有可能是雷电、静

59、电原因等，特别是雷电，是导致网卡故障的最主要原因之一，尤其是夏天雷雨季节。（2）电源输出电压异常也有可能导致网卡故障。（3）网线有短路情况或路由器、交换机故障也可能导致网卡故障。（4）自身原因则有可能是网卡本身的元件质量问题。在分布式数据库的金融关键业务场景下，为了预防服务器网卡故障，大部分服务器采用双网卡绑定，来预防网卡故障。也就是采用两块网卡，虚拟成一块网卡来使用，当一块网卡出现故障，另一块网卡依然能正常运行，系统仍能持续正常运行。网卡故障排查的几种处理方式：（1）首先把系统置于非正常工作的状态（2）将网卡重新进行插拔。（3）将网卡驱动卸载后再重新安装。（4）将网卡换到别的插槽上。（5）若

60、以上几种处理方式都无法使网卡正常工作，则证明网卡已损坏，此时需要更换新的网卡。Windows 环境下，在处理完毕网卡故障后，可以通过下面几步判断网卡是否正常。（1）“WIN+R”打开运行窗口，输入“CMD”命令。（2）在命令行窗口中输入 ipconfig，点击确定。若能成功查看到网络信息，如网关、ip 地址等则证明网33卡故障修复成功。8.网络设备故障8.网络设备故障网络交换设备是服务器之间网络通讯的必备要素，分为路由器、交换机（二层和三层）等。网络设备一般会进行高可用部署，比如双机并行，并采用“聚合链路”等解决方案，预防网络设备故障：（1）电源故障产生的故障。因为极端天气、人为影响、设备老化

61、等原因引起的故障。其预防方式也和大多数电源故障一致，即采用 UPS 进行容灾和引入稳压器进行防控。（2）端口故障。因为不规范的水晶头插拔时间长了引起端口的破坏的故障。预防策略除了规范插拔网线的动作外，还可以采用更加合适尺寸的水晶头让插拔动作更平滑。（3）模块故障。网络设备内部模块出现故障，预防方式是对网络设备轻拿轻放，避免潮湿等。（4）线缆故障。线缆与网络设备连接的不规范导致的各类故障，例如接口不紧导致脱落、交叉直连混用等。对此类故障的预防是在日常巡检过程中和布网阶段进行反复确认。（5）背板故障。对背板故障的预防，除了保持机房干燥外，还需要考虑散热问题，不要在出风口进行遮挡或者布线混乱导致散热

62、降低。网络设备的故障检测方式是查看状态指示灯和错误日志。还可以通过统一的监控运维平台查看。网络设备故障排除后的确认方式是查看网络设备的状34态指示灯和错误日志。还可以通过统一的监控运维平台查看网络设备的状态。（四）机房故障（四）机房故障数据库的高可用和强一致贯穿数据库的整个生命周期。在数据库尤其是核心数据库在构建的时候，采用高可用架构，能够避免在灾难的时候，降低数据库容灾做的不充分对业务响应时长的影响。在常见灾难下，主节点选择，一般采用分布式协调组件来实现，通过选举产生新的主，避免业务恢复过程中出现过长时间的中断。分布式数据的容灾架构，包括同城互备、同城双活、两地三中心。此处介绍遇到机房级灾难

63、情况下系统的应对措施。以两地三中心架构为例，可划分为：同城互备、同城双活、两地三中心。此处介绍遇到机房级灾难情况下系统的应对措施。以两地三中心架构为例，可划分为：本地或同城机房故障、异地机房故障两个灾难场景。1.本地或同城机房故障1.本地或同城机房故障应用于金融领域的分布式数据库产品应具备自动或手动灾难恢复能力，灾备方案包括在与主生产中心同城的数据中心部署具备计算能力的节点并保存数据副本的同城多中心部署架构。如图 2 所示，分布式数据库采用同城双中心部署架构，在 region1 中建 1、2 两个同城数据中心，同城主中心发生火灾、电力中断等灾难时产生本地或同城机房故障。此故障可采取跨中心强同步

64、，使管理节点或协调节点多35数派部署在备中心。方案的优势是主中心宕掉之后能自动切换到备中心，实现跨 IDC 容灾切换下具备两套的数据一致性。方案的劣势是备中心故障会引起主中心只读。图 2 同城双中心-多数派在备机房如图 3 所示，管理节点或协调节点的多数派在主机房，此方案跨中心强同步。方案的优势是可将管理节点或协调节点多数派放到主机房，当备机房不可用之后，系统退化成主机房强同步模式。方案的劣势是主机房故障后，切换到备机房时，备机房会变成只读模式，需要手动操作，才能恢复备机房的读写。36图 3 同城双中心-多数派在主机房对于两个数据中心来说，没有很完美的数据中心异常自动切换方案，需要做一些权衡。

65、上面两种方案做了跨 IDC 强同步，但是都不能做到任意 IDC 异常系统自动切换，因此并不是完美的跨 IDC 容灾方案。进行修复验证的步骤为：（1）验证实例手动切换到同机房和同城机房对数据读写的影响时长。（2）验证新的主节点自动建立起到其他备节点的同步任务；新的备节点自动建立起到新的主节点的同步任务，主备复制不受影响。（3）验证系统产生的业务数据或与其他应用的交互数据是否一致，包括日间产生的交易数据和日终报表产生的汇总数据，针对发出交易指令但未收到确认的存疑事务进行人工校验处置。2.异地机房故障2.异地机房故障应用于金融领域的分布式数据库产品应具备自动或手37动灾难恢复能力，灾备方案包括在与生

66、产中心处于不同地理区域的城市建立异地数据中心，形成两地三中心或多地多中心的多集群灾备部署架构。分布式数据库采用两地三中心部署架构，在 region1 中建 1、2 两个同城数据中心为主集群，region2 灾备机房搭建备集群，region1 发生地域级灾难造成 AZ1、2 同时发生火灾、电力中断等灾难。两地三中心的架构方案的优势是，在两地三中心的场景中能做到数据中心异常的时候自动切换。劣势是，如果采用强同步模式，则因为延迟过长，易导致事务执行缓慢。异地之间采用的异步模式，当异地(region1)整个可用区不可用的时候，可能会出现部分数据丢失的可能。因此建议异地之间（region1 和 regi

67、on2）数据同步采用异步模式。图 4 两地三中心架构示意图修复验证步骤如下：（1）主集群机房级故障后，备集群可以接管业务。（2）对生产主集群和灾备集群进行数据一致性、完整38性、可用性验证。（3）主集群恢复后可以自动恢复同步关系，并在生产系统正常恢复后切回原主集群。（五）数据库异常操作（五）数据库异常操作为了避免或减少数据库的异常操作（如异常删库、安全问题导致被拖库、SQL 注入、事务操作等），在数据库使用过程中，就要通过备份、安全审计、业务压测等场景，避免出现此类问题或者出现此类问题后能快速的恢复。1.异常删库1.异常删库应用于开发或运维人员误操作，导致正常数据丢失。针对异常删库的场景，有三

68、个方案。（1）通过备份逻辑日志和物理备份的方式，从备份恢复。图 5 异常删库恢复示意图（2）制作延迟备机。39图 6 异常删库恢复示意图-制作延迟备机（3）回收站机制。通过将数据库的元数据上移到接入层，对 drop、truncate 等高位场景，做回收站机制，不实际的删除库里面的内容。方案一成本低廉，恢复时间较长，适用于对恢复时间不敏感的业务。方案二成本较高，通过延迟备机的场景，可以迅速的将数据库恢复到对应的时间点。方案三能针对特殊命令制作回收站，比如 drop、truncate 等操作，但是对 update等无效，成本低廉，适用场景有限。修复验证：修复后需对恢复后的数据进行验证对比并对业务进

69、行验证，看是否存在异常。此类故障产生原因为误操作导致数据丢失。2.异常拖库2.异常拖库现象是外部利用信息漏洞进行恶意攻击，导致数据库拖库。拖库是由于数据库的不合理的网络策略，权限策略，存储策略导致数据库被非法或者不合理的使用。处理方案为进行数据库上线前检查访问数据库的网络策略、业务账号的权限是否设置合理，关键敏感数据是否是密文存储，并保证有完整日志。数据库上线后定期分析数据40的访问日志，发现是否有非授权的 IP 访问或者越界的访问行为。将数据库执行日志接入到审计系统。拖库后审视受影响的数据库，检查敏感信息，评估是否有更大的业务损失。例如数据库中如果存储了用户名和密码，则评估该表的业务系统是否

70、有泄露的风险，及时针对此措施添加安全策略。进行修复验证，步骤如下：（1）数据库数据对比，评估数据受损情况。（2）进行数据恢复挖掘，减少数据损失。故障产生原因是：（1）WEB 应用漏洞导致拖库。（2）漏洞注入。（3）利用网站恶意挂马拖库。（4）内部信息泄露。（5）远程下载数据文件。3.SQL 注入3.SQL 注入在数据交互中，前端的数据传入到后台处理时，没有做严格的判断，导致其传入的“数据”拼接到 SQL 语句中后，被当作 SQL 语句的一部分执行，从而导致数据库受损（被拖库、被删除等）。SQL 注入是一种攻击方式，在这种攻击方式中，在字符串中插入恶意代码，然后将该字符串传递到 SQL Serv

71、er 的实例以进行分析和执行。构成 SQL 语句的任何过程都应进行注入漏洞审阅，因为 SQL Server 将执行其接收到的所有语法有效的查询。41处理方案是：（1）进行 sql 预编译，防止 sql 注入攻击代码层，当传入参数 4 or 1=1 时，被当作是一个纯字符串参数，所以就不会出现 sql 注入了。（2）确认每种数据的类型，比如是数字，数据库则必须使用 int 类型来存储。（3）规定数据长度，从一定程度上防止 sql 注入。（4）严格限制数据库权限，能最大程度减少 sql 注入的危害。（5）避免直接响应一些 sql 异常信息，sql 发生异常后，自定义异常响应。（6）过滤参数中含有的

72、一些数据库关键词。修复验证时，需进行数据恢复挖掘，减少数据损失。故障产生原因为：（1）代码层面没有对 SQL 进行预处理，导致 SQL 执行时被 WEB 拼凑。（2）网络传输请求类型。（3）数据库设计的字符类型。（4）网络漏洞。4.大事务操作维护性质大事务操作4.大事务操作维护性质大事务操作比如常规的数据库表结构变更等操作。该操作可以在变更窗口期，通过制作镜像表的过程等数据同步完毕后，切换对应的原目的表。MySQL 使用常规 PT工具来实现自动化操作。处理方案为确定变更的表结构信息，42借助 PT 工具功能进行 onlineddl 任务发起。在 onlineddl操作成功后需进行修复验证，查验

73、表结构变更是否正常。一般这种故障是由于表结构变更产生的。事务长时间不提交。事务长时间不提交。在业务处理中可能存在查询数据量大、执行时间长的复杂事务导致事务长时间不提交或数据库异常发生主备切换未通知应用切断连接，线程僵死而导致活跃内存或连接池资源被长期占用。可通过数据库的系统工具，监控事务的状态，及时发现未提交的事务，及时报警。修复验证时检查：数据库连接使用是否正常，应用操作是否异常，应用操作数据是否一致。该故障的产生原因可能是：事物 SQL获取的数据量级大或 SQL 存在性能问题，事物长时间不进行提交，数据库异常僵死或卡住，资源长时间占用不被释放，异常发生主备切换等。单个事务操作过大指单个事务

74、操作过大指在业务处理中可能存在涉及跨多个分片/分区表数据交互的复杂事务导致事务执行时间长，长期占用计算和内存资源，造成性能堵塞。可将大事务合理的拆分成单个较小的事务，分多批进行处理。因为该故障主要发生在大数据向数据库灌入数据的场景中，所以适当地提高大数据的入库并发度，将单个大事务入库改成多个子任务入库，可一定程度上避免此类问题。处理后需验证拆解事务后业务执行效率是否改善，调整优化数据库并发后执行效率是否改善。故障可能是由业务逻辑，数据库整体运行性能，底层硬件架构性能造成的。单个事务操作过多单个事务操作过多指在业务处理中可能存在同一个事43务中进行多个增删改操作或在查询操作中涉及多层嵌套查询、聚

75、合查询导致事务执行占用资源较大，影响事务的原子性、一致性。处理时需合理的评估该事务是否影响数据库性能，可以通过监控每个 SQL 的耗时，来评估是否将单个或者批量不合理的小事务合并进行。修复后需检查整体资源的下降情况，确保业务逻辑整合后，效率有所提升。此故障可能是因业务逻辑复杂未进行合理拆解或数据库表设计与业务逻辑需求不匹配而产生。应急止损措施应急止损措施指在业务运行中，某个新增业务的 SQL 未经过测试评估，直接下发数据库，导致整个数据库性能达到瓶颈，影响其他业务运行。处理时需通过定位慢 SQL，与业务侧及时沟通，通过评估 SQL 重要性、SQL 的大小，选择将对应的事务 kill。并在业务上

76、线前做好 SQL 审计及环境压测测试。修复后需关注业务运行的性能情况，排除其他性能问题。此故障一般是因为业务压力大底层资源性能跟不上、业务逻辑及 SQL 复杂或前期的业务预估不合理导致。5.连接数超出阀值连接池占满，主备切换异常5.连接数超出阀值连接池占满，主备切换异常指在互联网背景下金融业务也存在业务挤兑、固定时段交易频发，客户端连接数据库数量激增引起瞬时压力，连接池耗尽从而影响整个系统业务连续性。比如某历史业绩稳定的投资经理新发理财产品，加之重点宣传，客户争相通过各零售代销渠道申购，在开放申购时点客户端连接会话数激增，造成数据库连接池占满，发生主备切换等异常处理操作影响客户申购体验。解决这

77、类问题44需在上线前合理的评估业务的连接数量是否会超过整个数据库的连接池。如果业务建立的连接池超过数据库的连接池。则针对性能要求比较高的业务场景，强制建议使用连接池，合理的设置连接池的资源，避免总连接池超过数据库的连接池。针对短连接的业务场景，通过业务测的压测，评估要达到业务容量的 QPS，数据库的连接池是否设置合理。需压测评估后才上线。处理后通过业务高峰期查看数据库使用情况是否达到预估，完成修复验证。此类故障产生原因可能是业务并发预估不合理、业务并发突增、业务逻辑优化欠缺或数据库底层环境整体性能不足。无空余链接。无空余链接。业务运行设计中，如大量采用长链接需求，可能导致连接不释放，没有多余的

78、空余连接提供使用，后续连接业务出现等待异常。处理时可合理的设置操作系统的keepalive 参数，加快非活跃连接的回收，能做到在应急场景下，有效的使用数据库连接数。业务侧可以根据业务重要性，将非核心业务，削峰处理。临时停掉非核心业务，给核心业务提供足够的链接。修复后需检查连接回收后，是否满足业务并发需求以及业务削峰后，是否得到缓解。此类故障一般是业务连接不释放或业务连接方式使用不正确造成。6.并发数过高6.并发数过高在互联网背景下金融业务也存在业务挤兑、固定时段交易频发，客户并发数激增，未进行合理分片，产生热点节点，数据库资源无法合理应用从而影响部分用户业务连续性。场景描述：场景描述：45某历

79、史业绩稳定的投资经理新发理财产品，加之重点宣传，客户争相通过各零售代销渠道申购，在开放申购时点并发数激增，热点节点，发生主备切换等异常处理操作影响客户申购体验。处理方案：处理方案：并发数过多主要原因是业务对数据库资源评估不合理导致的。针对并发数过多场景，短期应该与业务沟通，对部分非核心业务做限制。长远看需要对业务评估业务场景是否合理，如果合理，则需通过扩容 DB 或者增加 Redis、MQ 等中间件的场景，避免该问题发生。修复验证步骤如下：（1）业务改造后是否得到缓解。（2）底层扩容或改造架构后是否得到缓解。故障产生原因：故障产生原因：（1）业务架构和后端数据库架构不匹配。（2）后端数据库资源

80、跟不上。（3）架构设计是否合理。7.业务死锁7.业务死锁并发数较大场景下存在不同会话对同数据执行读写操作，形成锁争用无法自动释放而影响业务执行。在业务逻辑中，业务表做 DDL 操作时，该表还在进行频繁的 DML 操作并且还存在查询效率低下的 select 查询并发，导致 DDL 时获取锁超时，业务下发中断。处理步骤如下：46（1）对死锁做监控，及时发现，及时解决。（2）优化业务 SQL 减少低效 SQL 运行。（3）优化业务逻辑，减少锁并发冲突的情况。修复验证步骤如下：（1）剔除锁后，看业务是否恢复。（2）业务逻辑及 SQL 优化后是否避免。故障一般是由业务逻辑问题或低效 SQL 导致。8.业

81、务中断8.业务中断现象是在正常业务环境，运维人员对该环境进行数据压测，导致数据库性能达到瓶颈，业务中断无法使用。处理方案为：（1）停止压测任务，及时恢复业务的使用；（2）高可用架构中，压测将性能打满，通过主备切换的方式进行业务的恢复。（3）压测在测试环境或者不使用的备机进行，以免影响现有业务。进行修复验证，查看业务是否恢复使用，性能恢复正常。故障产生原因是：（1）操作不合理，在业务库进行压测。（2）压测并发参数调整不合理，导致资源打满。9.极端场景数据抢救9.极端场景数据抢救分布式数据库在一些异常场景下导致集群不可正常使用，数据丢失。通常可通过冷(热)补丁、主备机、备份恢复、容灾等手段进行修复

82、，从而使集群可正常提供服务。但是，47当上述手段失效场景下，如无冗余极端场景下，数据发生文件损坏，数据库无法启动，可使用抢救工具导出数据的能力，避免数据全部丢失，从而进行有损用户数据抢救。数据恢复成功后可通过数据库的运行状态、主备数据一致性校验等手段判断是否完全恢复正常，可能存在两种情况，一是无损恢复，二是有损恢复。当数据库数据丢失、数据库服务异常等场景出现时，优先使用冷(热)补丁、主备机、备份恢复、容灾等手段进行无损(或有损)修复；当无其他可用手段时，可尝试通过数据抢救工具，从数据库文件内离线解析数据，再将数据恢复至新集群。如果数据恢复是有损的，需要业务评估数据是否可用。该故障可能是存储服务

83、异常、存储设备异常、数据库文件损坏或人为(程序)原因误删除数据库相关文件等原因产生。10.副本集数据同步延迟10.副本集数据同步延迟副本集中的多个副本可以划分为主节点、备节点两类，节点之间的数据复制路径可以是星型、链式或者混合模型，具体模型的规划设计需要根据节点性能、各类任务负载压力、网络带宽/延时等情况综合决定。节点间数据复制延迟称为数据同步延迟。延迟时长和节点性能、各类任务负载压力、网络带宽/延时等情况相关。缩短延迟时间是分布式数据库设计部署的一项重要任务。通常来说，一个数据中心的两个节点间数据同步延迟时间短，同城数据中心之间的延迟时间稍长，异地数据中心之间的延迟时间最长。48节点间数据复

84、制可以选择同步或异步模式。同步模式可保证两个节点间数据的一致性，当一个节点出现故障后，另一个节点可以持续提供服务。可是同步模式只适用于两个节点间的数据同步延迟时间非常短的情况，否则，会极大的影响数据库事务的完成时间，从而延长事务完成时间、降低系统的交易吞吐率，造成交易堵塞、服务失效。目前技术基本能做到同城同步复制，异地同步复制仍存在挑战。异步模式把主节点的交易事务和节点之间的数据复制解耦，数据同步不影响交易事务的执行。但是同时会带来数据同步的延迟。也就是说两个节点之间的数据是存在不一致的。无论是数据同步的同步模式还是异步模式，都要做好延迟时间监控和预警工作，一旦延迟时间增大或有增大趋势时，需要

85、及时排查并确定问题原因，及时增加相应资源，解决问题。对于异步模式，需要注意设计部署足够大的操作日志空间，保证数据同步延迟时间增大时也不会丢失数据。四、总结展望金融业数据库应急处理的重要意义体现在保障金融业务的连续性、防范和减少数据风险、提升业务效率和响应速度、保护客户利益和维护信誉，以及适应监管要求和法规要求等方面。随着金融业务的不断发展和数字化转型，金融机构高度重视并不断加强金融业数据库的应急处理能力，以应对日益复杂和多变的风险挑战。下面是对未来金融业数据库49应急处理的五点建议。一是引入人工智能和自动化技术。未来金融业数据库应急处理可以借助人工智能和自动化技术的不断发展来提高效率和减少人为

86、错误。例如，可以使用机器学习算法分析数据库异常，自动触发应急处理流程。同时，可以利用自动化工具执行数据库备份和恢复操作，提高响应速度。二是建立实时监控和预警系统，及时发现潜在风险和故障。通过监控数据库的性能指标、数据访问情况和安全事件，可以提前预警并采取相应措施，避免数据损失和业务中断。三是强化数据备份和恢复机制。数据备份和恢复是应急处理的核心环节。未来金融业数据库应急处理需要强化数据备份和恢复机制，确保数据的完整性和可用性。可以利用分布式备份和容灾技术，将数据分散存储在多个地点，以防止单点故障。同时，建立快速恢复机制，能够在短时间内恢复数据库，减少业务中断时间。四是加强安全防护和应急响应能力。通过引入先进的安全技术，如入侵检测系统和数据加密，来提高数据库的安全性；建立健全的应急响应机制，包括应急预案、演练和培训，有助于快速、有效地应对安全事件和威胁。五是加强合规管理和风险评估。金融机构需严格遵守法规和监管要求，建立合规框架和流程。同时，定期进行风险评估，识别和评估潜在的应急风险，制定相应的防范和处理策略。随着技术的不断发展和金融业务的日益复杂化，数据库复杂度不断增加，业务场景创新层出不穷，金融业数据库关键场景应急处理的研究也将持续深入下去。