分布式数据库金融关键业务场景应急处理研究

分布式数据库金融关键业务场景应急处理研究报告202310编制委员会主任聂丽琴编委会成员王志刚 李 振编写组成员陈亮邓广俊刁现峰杜蓉冯六军高孝鑫郭智慧胡正策黄小慧黄炎黄元霞姜维莹李博文李国良李磊李思李萧萧路新英明玉琢申宇苏德财王登祎王枫王莉莉王嵩阳王栩吴洪辉许高峰徐雪涛叶强林张楠张毅周日明朱飞编审黄本涛 张 蕾参编单位：中国光大银行股份有限公司兴业银行股份有限公司华为技术有限公司中兴通讯股份有限公司腾讯云计算（北京）有限责任公司蚂蚁科技集团股份有限公司北京国家金融科技认证中心有限公司飞腾信息技术有限公司上海热璞网络科技有限公司云南南天电子信息产业股份有限公司摘 要本报告调研了参编单位现有应急处理方案，分析了金融关键目 录一、研究背景 1二、应急处理思路 1（）应预案 1（二应准备 5（三应演练 6（四应处置 7三、关键场景应急处理 8（一特分析 8（）数库组故障 10（三硬故障 20（四机故障 34（五数库异操作 38四、总结与展望 48一、研究背景虽然现有分布式数据库产品一般具备故障的自动探测、自动恢复能力，但不同分布式数据库的特性和操作方式不相同，银行数据库运维人员仍需根据各种异常场景做好应急处理，在发生问题时最大程度缩短恢复时间、减少故障损失。为了业务连续，运维人员需要在最短时间内判断及处理数据库异常，控制故障不进一步扩大，避免数据库停止服务，保证业务正常开展。其次，一些常见的人为误操作可能会对业务数据、数据库系统的状态及性能会造成较大的影响，运维人员还需对常见误操作进行规范的应急处置，减少对业务及系统带来的负面影响。本课题通过调研参与单位现有应急处理方案，分析金融关键业务场景中故障产生原因，总结统一的应急处理思路，形成普适的应急处理方案和修复验证指导，为金融关键业务场景的分布式数据库应急处置提供参考。二、应急处理思路（一）应急预案分布式数据库在银行、证券、保险等金融机构生产环境运行时，都存在发生故障、停止服务的风险。保障生产系统系统故障（或子系统发生故障、停止服务。系统栈每一层中的系统都存在发生故障的概率。分布式数据库组件可能在运行过程中出现bug系统及运维应急方案都是为在一定约束条件下降低故障发免历史上经常受到台风侵袭的地区等。动或手动启动备用系统保持/恢复线上服务，快速处理故障各个系统在设计阶段要考虑预设屏蔽故障子系统（或子系统分布式数据库最重要的资产是数据，必须着力避虽然所有技术冗余资源同时发生故障的概率很小，但仍需要制定相应的故障应急处理预案，包括业务处理方法或手动处理方法。系统资源耗尽指系统资源耗尽，不能提供更多的服务，主要有两种场景：由于任务繁重，系统资源已全部投入服务，系统处理能力达到峰值，新的任务只能排队等待处理。此时系统CPU子系统故障而导致。一是事先预防策略。系统需要具备足够的横向扩展能力，通过增加服务器等资源增加峰值处理能力。二是监控应对策略。系统需要具备强大的监控告警能力，一旦某种特定资源使用率超过阈值就进行告警，以便运维人员果断的启动增加部署资源流程。操作风险指生产运维人员在分布式数据库系统栈中进行系统操做好培训。通过培训可使运维操作人员充分理解分布式数据库系统栈中相应系统的运作原理，熟练进行操作。做好权限管理。通过权限设置，指定专项人员进行风险操作。制定操作规程。完善数字化运维工具，通过支持双人操作的工具，操作规程等降低误操作的概率。做好系统数据备份。在执行风险操作前先对相关数据进行备份。（5)及时恢复。一旦出现误操作，按照操作规程及时恢复数据、恢复服务。分布式数据库在金融关键业务场景的应急处理并不仅仅指系统栈中系统突然发生故障后进行的处理工作，还包括系统设计及故障处理能力。完备的应急处理需要从系统规划建设阶段开始重视并落实。分布式数据库系统运行风险的处理思路也对系统栈中的各个系统的厂商、应用系统开发商及运维系统开发商都提（二）应急准备应急准备工作指系统故障或风险事件发生前，为防范风险进行的所有工作，包括以下内容：组织层面根据事件影响程度及持续时间等因素对突发事件进行风险等级划分，并根据不同等级的风险事件制定突发事件应急处划分预警级别并且建立相应的预警信息发布机制，这是应急准备的重要部分。实施层面其他（三）应急演练数据中心所在地区发生地震、台风，机房火灾、机房长时间停电；一个数据中心中的所有服务器同时故障；服务器硬盘同时故障等事件都属于极低概率事件。这类极低概率事件在几年，甚至分布式数据库对外提供服务的整个生命周期中可能都不会发生一次。但是，应急预案的内容需包括对这类事件的处置应对。应急准备工作在组织层面、实施层面、其他方面包括了处置应对这类极低概率事件的工作。相关领导、业务人员、技术人员、厂商/合作方人员，处理障、解决问题、恢复服务是否迅速及时，整体应急准备工作是否完备，都需要通过定期的应急演练来检验、完善。再次是做好业务合作方、技术产品/服务合作方等的沟通协施。且应制定持续改进的机制和方案，在应急演练完成后，全面总结应急演练过程中的经验和教训，完善应急预案和其他应急准备工作。（四）应急处置如果出现应急预案没有覆盖的风险，应根据风险影响范三、关键场景应急处理（一）特性分析1的技术架构包括管理模块、计算模块和存储模块3个部分。图1分布式数据库典型技术架构计算模块负责解析应用程序查询请求、生成查询计划，并将查询计划自动分配到各计算节点并行执行。管理模块负责协调分布式时钟和维护元数据，并提供数据库参数配置和运行监控。网络连接故障都需要被妥善处理。分布式数据库需要建立应付各种异常场景的处理方案应对金融业数据零丢失和业务高连续性的要求。较为典型的可以帮助金融机构最大限度地减少数据库故障和安全事件对业务运营的影响，保障金融行业的数据安全和运营稳定。下面将针对典型异常场景故障进行应急处理方案介绍。（二）数据库组件故障1管理节点宕机Paxos通过对分布式数据库集群进行配置来指定管理节点的副本Paxos副本上任后为集群提供总控服务，当管理节点当前leader一个管理节点的故障对分布式数据库集群整体业务没有影提供服务，此时需要依赖备集群恢复业务。PaxosPaxos进行修复验证时，人为切换至原故障管理节点（已经修复正常），如数据库操作结果与其他目前在运行的管理节点操作结果一致，则修复成功。管理节点故障，主要可能原因如下：机器报警。无法正常保障数据库工作。返回结果异常。数据丢失或损坏。主副本数据不一致。2.计算节点和数据节点是分布式数据库的核心，分布式数举出新的主副本来提供服务，这个切换过程需要在保证RPO=0然可以提供服务。协议对故障节点进行数据修复，进行数据同步，保证计算和数据节点集群数据的一致性。进行修复验证时，人为切换到原故障计算和数据节点（已经修复正常），如数据库操作结果与其他目前在运行的计算和数据节点操作结果一致，则修复成功。计算和数据节点故障，主要可能原因如下：机器报警。无法正常保障数据库工作。返回结果异常。数据丢失或损坏。3.数据代理节点宕机分布式数据库集群一般会提供数据库代理组件以便准确地将SQL接收用户发出的SQLSQL数据库代理节点之间可以部署负载均衡服务来保障更高的可用性。据库代理节点之间可以部署负载均衡服务来保障更高的可用性。（已经修复正常SQLSQL数据库代理节点故障，主要可能原因可能是机器报警，无法正常保障数据库工作，返回结果异常，时间延迟较长等情况。4GTS/GTM全局事务服务异常一个全局时间戳服务（GTS）或者全局事务管理器（简GTM），事务提交时候通过时间戳服务获取事务版本号。GTS/GTM是分布式数据库的核心，需要保证高可用。GTS/GTM有主改选：原Leader主改选。新leaderleader的最大已经leader时间戳授权的基准值。因此该场景下，GTSleaderleasefollower称为无主选举。选举服务保证了无主选举场景下，新旧LeaderleaseleaderGTS提供的时间戳不回退。行异常，GTSGTM方法是：GTS/GTM正常工作。新leaderleaderleaderGTS本地时钟一定大于旧主提供的最大时间戳。GTSGTMGTS/GTM全局事务服务故障，主要可能原因如下：机器报警、无法正常保障数据库工作或返回结果异常。5.操作系统故障（如：CPUI/0、网络等是数据库（inode组合场景时，数据库服务均会出现异常。解决方法是对系统资源进行日常容量监控和预警。6.文件系统为只读模式Read-onlyfilesystem”字样。（Riad故障或文件系inodeIOHBAbugFWread-onlyCPU业务系统通常上线后资源使用率较为稳定，此场景下CPUCPUCPU定为某一个程序引起，可通过观察确认具体引发CPUCPUCPU（SQL（SQLSQL）、中毒等情况；硬件原因主要来自机房散热、驱动故障、CPUCPUBIOS列则CPU进行修复确认，预期是解决上述问题后，CPU使用率分散到所有核，且磁盘调入内存较为均匀。故障原因通常为多队列网卡未开启多个队列、多队列处理未绑定到多个CPU上或者网卡本身为单队列等等。I/O资源占用过高I/OI/OCPUI/OI/Obug、异常操作等，综合考虑并确认I/OI/OI/Obug、异常操作等并进行对应升级修复。进行修复确认，预期是解决I/O飙高、卡顿的软件原因或硬件原因后，I/O使用率恢复至正常水平。（SQL（如无索引、全表扫描等bug内存消耗过大解决方案为：服务正常情况下，内存偶发性增加大概率是因为业务系统中存在高消耗内存SQLSQLSQL进行修复确认，预期试运行一段时间后观察内存使用率情况以及服务运行情况，均稳定运行。故障原因大多为软件问题，主要原因有高消耗内存的SQL操作、内存参数设置不合理及内存碎片回收待优化。磁盘占用满解决方案为：查看磁盘占用（du-Sh*等）命令，了解数据库服务。进行修复确认，在数据库服务启动后，观察磁盘写入情况，预期是占用情况恢复正常。网络负载过高现象是网络流量过大引发丢包、重传、网络延迟过大，从而导致系统服务响应变慢、报错。解决方案为：通过观察网卡进出流量、网卡本身负载能力及相关硬件配置情况，确认具体网络负载过高的原因，确认是否为存在大量写入和读取数据操作导致网络流量增加，或实际流量较高但网卡或者交换机等硬件性能不足情况。如为软件层面操作问题，等待业务执行完成并及时监控即可；如为硬件性能不足情况，则需要升级或者更新硬件设备。进行修复确认，预期是修复后观察网络流量及丢包率、重传率、网络延迟等参数均正常。（三）硬件故障服务器宕机服务器宕机通常是指应用的服务器处于一种非正常运在排查时需要判断服务器宕机的严重程度，可在宕机发生后等待一段时间，此时宕机系统若恢复即常说的假死，若CPU、提高服务器内故障处理时，对于访问量过高超出系统承载能力的短暂性突增或者异常的访问可等待一段时间或手动杀死进程或宕机恢复后系统进行修复验证步骤为：检查系统日志，是否有报错；检查系统各项功能是否正常，并检查对应日志；检查应用各项功能是否正常，并检查对应日志。金融关键业务场景下，分布式数据库，可能出现宕机的原因主要包括：访问量过高超出系统的承载能力，包括正常的短暂性突增，或者异常的访问，如非法攻击的情况。早期建设的传统集群，部分已不能满足现今的系系统的应用程序设计存在不合理的异常或漏洞，例如对业务支撑的系统资源不合理，或例如死循环或多线程造成死锁，消耗系统资源的逻辑导致资源耗尽。存在系统内核程序错误或故障，包括软死锁等情况。在一定环境中，人为的误操作也可能导致服务器宕机情况的发生。正在大量占用服务器内存、CPU、磁盘或网络，或者网站的电源故障服务器电源按照通用标准可以分为ATX电源和SSI电源两种。ATXSSI（power）与用PC种类较多，不同服务器产品的输入/输出电压、功率、功能及拓扑结构都有可能不同。电源故障可能导致系统运行不稳定，当磁盘出现坏磁道、CPU超频工作不稳定、主机莫名重新启动、服务器运行时噪音较大等情况。免电源故障对系统的影响，实现长时间不间断运行。N+1NUPS台UPSUPS通过冗余电源和热插拔技术配合，可实现热插拔冗余电源，从而提高服务器系统的稳定性和可靠性。为磁盘磁道正常读写、CPU磁盘损坏磁盘损坏主要有以下场景：故障提示。即磁盘自我监测、分析错误报告其磁磁盘无法识别。启动时显示磁盘无法识别，或系统无法显示磁盘。系统运行出错。服务器运行不断出现程序错误且磁盘扫描停滞甚至死机。运行报错。扫描磁盘发现错误或显示坏道。初始化死机。包含其他部件与磁盘故障的可能。故障产生的可能原因包括：磁盘系统故障，发生系统中断、跳出、停滞等现象。这些现象的发生可能存在磁盘或系统的故障。磁盘物理故障，一般表现为无法识别磁盘存储数据，或者是无法读取数据，导致用户无法使用磁盘。磁盘运行故障，主要表现在扫描磁盘的时候发现来预防磁盘故障。也就是N+1N对于磁盘故障，首先确认业务在分布式数据库保有数据备份情况下的稳定运行，备份数据启动承载切换的业务后，再进行故障磁盘的更换。磁盘系统故障在排除系统故障后对磁盘进行检修，磁盘物理故障需要保证备份数据的可用，或对现有数据进行转移后对磁盘进行检查维修。内存条故障内存故障产生原因如下：内存故障导致注册表读取错误情况，包括安全模出现内存损坏安装系统提示解压缩文件出错故障的原因，一般是内存的质量不良或稳定性差造成的，无法正常读取某一文件或系统安装文件损坏。在内存短路导致主机无法加电的情况下，可能存在电源质量不稳定或其他部件接触或需要更换的问题。若出现蓝屏死机或无法启动的情况，根据蓝屏时的出错提示或无法提示则应是内存中某种虚拟文件出错，可内存条故障预防首先应保证使用环境符合国家机房标题。采用带有ECC对存在于机器内存损坏的硬件故障需要使用替换法。首先备份重要资料，换上性能良好的内存条，进行重新安装。同理，在金融关键业务场景中，内存条的质量不良或稳定性差极大的影响系统的整体性能，建议使用高质量的内存条硬件。统稳定性的提升。主板故障发出非正常的报警声等与主板有关的问题。主板故障产生原因：主板无法启动的故障原因包括安装问题中的接触不良、主板及主板上各元件的制作工艺质量问题。对于连接外设键盘、鼠标、打印机出现不支持或主板的电源安全故障，主板电源是否通过稳压器过滤和是否具有滤波功能的电容来稳定供电电流保护主板的正常使用；显卡与主板的松动导致故障，或显卡与主板非正常兼容。金融关键业务集群出现主板故障对于系统来说有较大I/OCPUCPU主板故障恢复后，需要对系统进行验证，首先可查看硬件故障指示灯是否熄灭，然后检查服务器硬件错误日志、操作系统启动日志、应用日志等。阵列卡故障阵列卡故障特征：RAID显示多块硬盘呈离线状态或丢失状态。RAIDonlineRAIDRAID磁盘阵列卡故障原因：服务器硬件故障导致的阵列卡故障，如电路板损坏、磁头损坏、盘面损坏以及其他固件损坏等。断电、电压不稳导致的阵列卡故障。管理员在维护过程中由于误操作导致硬盘盘序出RAIDRAIDRAID磁盘阵列卡故障检查时，由于阵列卡的特殊性，处理不当可能造成数据丢失，所以对于阵列卡的处理方式应该更加的谨慎，针对不同的故障产生原因，采取恰当的处理方式：若是由电源原因造成的阵列卡故障，为了防止数若是服务器硬件导致的阵列卡故障，先要确认数据是否丢失，若无数据丢失则修复对应的硬件之后再行处理。若有数据丢失，则要将情况报告给磁盘阵列厂商或者专业的磁盘阵列数据恢复公司进行处理。值得注意的是，谨慎选择初始化或者ReBuild等可能导致数据丢失的处理方式。biosprotected用。网卡故障网卡是局域网或互联网中连接计算机和传输介质的接口，是电脑与网络的一道桥梁，一旦网卡发生故障，便不能上网。网卡故障一般会出现如下几种症状：在“设备管理器”里无“网络适配器”。正常情况下，打开“设备管理器”时，里面有一排像“RealtekRTL8139/8111在“设备管理器”中有“网络适配器”，并且也RealtekRealtekRTL8139”当插上网线时，电脑右下角提示“网络电缆没有一般网卡正常工作时，网卡绿色指示灯会亮，如在排除网络本身故障以及电脑系统问题的情况下，若网卡只有发送包而无收到包，也可以确定为网卡故障。网卡故障原因如下：外部原因有可能是雷电、静电原因等，特别是雷电源输出电压异常也有可能导致网卡故障。网线有短路情况或路由器、交换机故障也可能导致网卡故障。自身原因则有可能是网卡本身的元件质量问题。网卡故障排查的几种处理方式：首先把系统置于非正常工作的状态将网卡重新进行插拔。将网卡驱动卸载后再重新安装。将网卡换到别的插槽上。若以上几种处理方式都无法使网卡正常工作，则证明网卡已损坏，此时需要更换新的网卡。Windows环境下，在处理完毕网卡故障后，可以通过下面几步判断网卡是否正常。“WIN+R”打开运行窗口，输入“CMD”命令。在命令行窗口中输入ipconfig，点击确定。若能成功查看到网络信息，如网关、ip地址等则证明网卡故障修复成功。8.网络设备故障网络交换设备是服务器之间网络通讯的必备要素，分为路由器、交换机（二层和三层）等。UPS端口故障。因为不规范的水晶头插拔时间长了引起端口的破坏的故障。预防策略除了规范插拔网线的动作外，还可以采用更加合适尺寸的水晶头让插拔动作更平滑。模块故障。网络设备内部模块出现故障，预防方式是对网络设备轻拿轻放，避免潮湿等。线缆故障。线缆与网络设备连接的不规范导致的类故障的预防是在日常巡检过程中和布网阶段进行反复确认。背板故障。对背板故障的预防，除了保持机房干网络设备的故障检测方式是查看状态指示灯和错误日志。还可以通过统一的监控运维平台查看。网络设备故障排除后的确认方式是查看网络设备的状态指示灯和错误日志。还可以通过统一的监控运维平台查看网络设备的状态。（四）机房故障数据库的高可用和强一致贯穿数据库的整个生命周期。本地或同城机房故障应用于金融领域的分布式数据库产品应具备自动或手2region11、2此故障可采取跨中心强同步，使管理节点或协调节点多IDC图2同城双中心-多数派在备机房3图3同城双中心-多数派在主机房IDCIDC不是完美的跨IDC进行修复验证的步骤为：验证实例手动切换到同机房和同城机房对数据读写的影响时长。验证新的主节点自动建立起到其他备节点的同步备复制不受影响。验证系统产生的业务数据或与其他应用的交互数异地机房故障应用于金融领域的分布式数据库产品应具备自动或手分布式数据库采用两地三中心部署架构，在region112AZ12两地三中心的架构方案的优势是，在两地三中心的场景中能做到数据中心异常的时候自动切换。劣势是，如果采用强同步模式，则因为延迟过长，易导致事务执行缓慢。异地之间采用的异步模式，当异地(region1)整个可用区不可用的时候，可能会出现部分数据丢失的可能。因此建议异地之间（region1和region2）数据同步采用异步模式。图4两地三中心架构示意图修复验证步骤如下：主集群机房级故障后，备集群可以接管业务。对生产主集群和灾备集群进行数据一致性、完整性、可用性验证。主集群恢复后可以自动恢复同步关系，并在生产系统正常恢复后切回原主集群。（五）数据库异常操作为了避免或减少数据库的异常操作（如异常删库、安全问题导致被拖库、SQL注入、事务操作等），在数据库使用过程中，就要通过备份、安全审计、业务压测等场景，避免出现此类问题或者出现此类问题后能快速的恢复。1.异常删库应用于开发或运维人员误操作，导致正常数据丢失。针对异常删库的场景，有三个方案。通过备份逻辑日志和物理备份的方式，从备份恢复。图5异常删库恢复示意图制作延迟备机。图6异常删库恢复示意图-制作延迟备机回收站机制。通过将数据库的元数据上移到接入层，对drop、truncatedroptruncateupdate等无效，成本低廉，适用场景有限。修复验证：修复后需对恢复后的数据进行验证对比并对业务进行验证，看是否存在异常。此类故障产生原因为误操作导致数据丢失。2.异常拖库处理方案为进行数据库上线前检查访问数据库的网络的访问日志，发现是否有非授权的IP访问或者越界的访问行为。将数据库执行日志接入到审计系统。拖库后审视受影响的数据库，检查敏感信息，评估是否有更大的业务损失。例如数据库中如果存储了用户名和密码，则评估该表的业务系统是否有泄露的风险，及时针对此措施添加安全策略。进行修复验证，步骤如下：数据库数据对比，评估数据受损情况。故障产生原因是：WEB漏洞注入。利用网站恶意挂马拖库。内部信息泄露。3.SQL注入SQL被当作SQL（被拖库、被删除等）。SQLSQLServerSQL注入漏洞审阅，因为SQLServer处理方案是：sqlsql4or11以就不会出现sql确认每种数据的类型，比如是数字，数据库则必须使用int规定数据长度，从一定程度上防止sqlsqlsql过滤参数中含有的一些数据库关键词。修复验证时，需进行数据恢复挖掘，减少数据损失。故障产生原因为：SQLSQLWEB网络传输请求类型。数据库设计的字符类型。4.大事务操作维护性质大事务操作比如常规的数据库表结构变更等MySQLPT借助PT工具功能进行onlineddl任务发起。在onlineddl操作成功后需进行修复验证，查验表结构变更是否正常。一般这种故障是由于表结构变更产生的。事务长时间不提交。在业务处理中可能存在查询数据量SQL获取的数据量级大或SQL单个事务操作过大指在业务处理中可能存在涉及跨多个分片/分区表数据交互的复杂事务导致事务执行时间长，长期占用计算和内存资源，造成性能堵塞。可将大事务合理的拆分成单个较小的事务，分多批进行处理。因为该故障主要发生在大数据向数据库灌入数据的场景中，所以适当地提高大数据的入库并发度，将单个大事务入库改成多个子任务入库，可一定程度上避免此类问题。处理后需验证拆解事务后业务执行效率是否改善，调整优化数据库并发后执行效率是否改善。故障可能是由业务逻辑，数据库整体运行性能，底层硬件架构性能造成的。单个事务操作过多指在业务处理中可能存在同一个事务中进行多个增删改操作或在查询操作中涉及多层嵌套查SQL应急止损措施指在业务运行中，某个新增业务的SQL未SQL，与业SQLSQLkillSQLSQL连接数超出阀值指在互联网背景下金融业务需在上线前合理的