数据库切换故障案例分析.docx

《数据库切换故障案例分析.docx》由会员分享，可在线阅读，更多相关《数据库切换故障案例分析.docx（8页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、数据库切换故障案例分析-ISD白彦涛Xianzhi.He2022-06-18 11:47:08 回复 转载到 gonewi thwi nd 人品天堂家族 电子技术 esrxxrts海涛菜鸟群4群 志同道合.广东省直真网管 广东项目组（公司）数据库切换故障案例分析2022-06-10北京直真节点技术开辟有限公司Beijing ZZNode Technologies Development Co., Ltd.称目录1 .案例背景22 .案例概述23 .操作过程23.1 ：数据准备23.2 ：查看切换状态23.3 ：及时恢复23.4 ：查看数据库运行状况24 .确定故障案例原因24.1 1 INF0

2、R切换到备机上浮现启动异常24.2 /0PT/DBNM下自动生成.SHJISTORY文件导致数据库MC切换失败24.3 及时恢复数据库到主数据原服务器启动失败25 .解决故障案例恢复数据服务25.1 准备此前备份数据库数据（全库备份文件）25. 2数据库初始化26. 3创建数据库27. 4数据导入25.5启动应用28. 案例分析28.1 服务器操作系统备份26. 2数据库备份26. 3主业务应用采集备份26.4测试（备）系统搭建26. 5总结21 .案例背景传输综合网管二期二阶段整建期间，升级MC软件后，进行数据库双机切换失败， 目前数据库单机运行。为满足数据库安全运行要求，提供服务器故障无影

3、响提供传输综合网管服务，进 行MC双机数据库切换测试。测试中浮现数据库chunks文件PD无法拉起，无法 正常访问，导致数据库不能提供数据服务。因此，局方贾工、HP工程师高鹏、集成商厂家马立伟、白彦涛全力进行此次MC 双机切换测试。2 .案例概述申请于2022-11-19日晚12:00至2022-11-20日早5:00间进行数据网MC双机 切换测试。实施前我们已经做好数据库全库备份工作，以便浮现腹胀并配置好热备服 务器的Informix数据库环境，MC手动切换数据库到热备服务器上，监测启动是 否正常。但在MC切换过程中，导致chunks文件无法读取，数据库启动失败。 3.操作过程2022-11

4、-20日00： 20分开始进行MC切换3.1 ：数据准备准备工作：提前和Informix厂家、HP厂家确定MC双机切换时间，以便为浮现异常问 题时，能得到第一时间支持解决。提前和HP确定切换MC方案，并确定一旦发现MC切换失败，则及时恢复到 现在数据库葬主服务器运行状态，确保能在最短期内恢复应用使用。MC切换前5个小时，做好数据库全库备份工作，以便意外情况发生减少数 据丢失。审核inf or双机配置环境，确保主备服务器参数配置一致（此前已经和inf or 夏工确认过），并修改数据库内核参数和主数据库服务器一致。3.2 ：查看切换状态手动切换双机从主数据库服务器到热备服务器。cmrunpkg到热

5、备服务器切换成 功，但数据库启动3秒后住手运行查看状态浮现：informixtnmsbakl:/opt/dbnm # onstat -shared memory not initialized for INFORMIXSERVER 5 tms_db，3.3 ：及时恢复发现切换不成功，及时从备份服务器切换到主数据库服务器，启动数据库正常， 检查没有问题。（前提是无人访问主数据库服务器，使之不能在/opt/dbnm下出 现.sh.history的文件否则将导致该目录忙而引起无法挂载盘阵并正常启动数 据库）3.4 ：查看数据库运行状况三次检查热备服务器参数等后确定符合infor要求，再次me切换，依

6、然浮现2 的情况，而后及时切换到主数据库服务器，数据库启动正常，启动主业务应用无 法启动，检查数据库发现其中一 chunks文件浮现PD状态，c00000013ef047e8149099995000PD-B-/opt/dbnm/lnkdev/datadbs214.确定故障案例原因2022-11-20日：03： 00将浮现问题上报并协调infor厂家协助解决。4. 1 infor切换到备机上浮现启动异常故障现象：手动切换数据库到热备服务器后，onstat -显示数据库启动正常：informixtnmsdb:/opt/dbnm # onstat -IBM Informix Dynamic Serv

7、er Version 11.50. FC5 一一 On-Line - Up 15:38:41 8134840 Kbytes - onstat - m显示最后20行日志信息： 00:52:55 On-Line Mode00:52:56 SCRAPI: Started dbScheduler thread.00:52:57 Booting Language from module 00:52:57 Loading Module 00:52:57 SCRAPI: Started 2 dbWorker threads.00:53:08 kaio. c, line 2231, thread 51, pr

8、oc id 11647, kaiothread() ERROR.00:53:08 Fatal error in ADM VP at mt. c:1385500:53:08 Unexpected virtual processor termination, pid = 11647, exit = 0x10000:53:08 PANIC: Attempting to bring system down00:53:08 semctl: errno = 2200:53:08 semctl: errno = 22显示出错约过3秒所有时间，查看数据库状态：onstat -显示: informixtnmsb

9、akl:/opt/dbnm # onstat 一shared memory not initialized for INFORMIXSERVER tms db此时数据库已经宕掉。一故障分析：已经将当时出错的online. log文件提交infor工程师，并远程协助解决。目前 无法确定切换到热备服务器上重启后数据库自动住手运行的切当原因。后重新确定热备服务器和主用服务器相关参数问题：要安装HP KAIO driverasyncdsk并链接到核心。确认为该操作系统本身参数未配置所致。而此项内容在MC切换测试前，邮件和Informix厂家确认需要修改参数内容时， 向来未提及。解决故障： 安装HP：

10、KAIO driver asyncdsk,并链接到核心。然后做双机切换。初步确定：待下次双机切换测试口寸，确保局方、informix厂家、HP厂家、集成商等全 部在场，确保出线异常，第一之间排除解决。4. 2 /opt/dbnm下自动生成.shjiistoiy文件导致数据库MC切换失败 故障现象：当从热备服务器手动切换回主数据库服务器时，由于数据库安装目录存在.sh_history文件，导致该目录忙，无法挂载盘阵，导致数据库无法挂载并启 动。,informixtnirisdb: /opt/dbnm # pwd/opt/dbnminformixtnmsdb:/opt/dbnm # Is -al-

11、rw1 Informix Informix 3454 11 月 20 日20:55 . sh history故障分析：一由于该文件记录了曾经登陆到该服务器所做的命令操作信息，导致该文件处于一 直在用状态，导致数据库路径忙碌，无法挂载数据库盘阵。如果不登陆服务器本 身，便不会产生该文件，进而不会影响MC双机磁盘空间挂载。解决故障：已经提交HP厂家，目前没有明确解决方案。但建议尽量不要登陆数据库服 务器本身，这样便不会产生.sh_history ,也不会影响MC双机切换正常切换 4.3及时恢复数据库到主数据库服务器启动失败 故障现象：发现切换到热备数据库失败后及时恢复，切换到主数据库，数据库启动正

12、常，启 动应用程序失败，检查原因排除应用程序原因，检查数据库，发现库tnsmdb2 无法访问，访问是浮现：dbaccess回车后进入，选择我们的库 回车显示：311: Cannot open system catalog (systables).155: ISAM error: Primary and Mirror chunks are badOnstat - d检查chunks文件，浮现PD状态：Chunksaddresschunk/dbs offset size free bpages flags pathnamec00000013ef047e8149099995000PD-B-/opt/

13、dbnm/lnkdev/datadbs21HP判断该磁盘处于读写状态，在用，且很正常。故障分析：提交Informix厂家工程师，和IBM工程师远程协助解决，目前诊断确定原因在： 当MC切换数据库*,由于不能正常切换数据库，浮现10错误，底层chunks文 件数据受影响，导致逻辑序列数据发生改变，以致在数据库启动时请求对该 chunks文件读取是无法正确读取其信息，所做请求失败。可能的原因是磁盘设 备浮现问题、chunks文件所使用裸设备不存在、该链接设备不存在等问题，导 致该chunks文件为PD状态。经 IBM 工程师测试确定：dd if= /opt/dbnm/lnkdev/datadbs2

14、1of=/dev/null bs=2000k写入该chunks文件数据显示能正常写入，说明该 chunks文件存在，且磁盘设备经HP厂家确认为正常。目前IBM确定该问题引起原因：浮现10错误，底层chunks文件数据受影响， 导致逻辑序列数据发生改变，以致在数据库启动时请求对该chunks文件读取是 无法正确读取其信息，所做请求失败故障处理：IBM和informix厂家协力解决该chunks文件仍拉起无果，建议：1）：重新初始化数据库：oninit - iv将数据库库文件重新初始化（会导致数 据全部丢失）2）：重新建库：dbaccess sysmastercreate database tnm

15、sdb2 in datadbs;3）：将此前备份的数据库数据导入新建数据库中loadzz. sh tnmsdb2 tnmsdb2 fulldb 风险: 由于数据备份方式单一，备份数据存放位置存在安全隐患，不能保证备份数据的 完整性和导入数据的完整性。备注：依据以上情况分析，KAI0参数问题：一此参数服务器本身没有打开导致1： HP服务器操作系统本身有一个KAI0参数，HP KAIO driver asyncdsk并链 接到核心2：我们数据库的环境变量有一个关于此调优的参数：-一此参数在数据库的环境 变量中是打开的。KAI00N=l export KAIOON3:在和informix的邮件中，确

16、定需要修改参数时，并为涉及到服务器本身KAIO 参数。4：操作过程中，当确定该参数时，HP工程师问到该参数，并已得到我们 的答复是：环境变量中该参数也已打开，但并未提及服务器操作系统本身的KAIO 参数。此次数据库切换至主数据库服务器后无法提供正常的数据库服务，原因在于：MC 双机切换，浮现10错误，底层chunks文件数据受影响，导致逻辑序列数据发生 改变，以致在数据库启动时请求对该chunks文件读取是无法正确读取其信息， 所做请求失败，导致该数据库chunks文件处于宕机PD状态，无法拉起。5.解决故障案例恢复数据服务 由于数据库无法正常提供服务，chunks文件时钟无法拉起，进入应急方

17、案 5.1准备此前备份数据库数据（全库备份文件）传输综合网管每次测试升级前都会做数据库全库备份，存放路径： informixtnmsdb :/opt/dbnm/数据库备份脚本/tnmsdb2/record 该路径下存在MC双机测试前全库备份数据，存在形式是一张表存在： rw-r-r-1 informixinformix 5148 11 月 19 H 10:00 ems-rw-r-r-1 informix informix472791809 11 月 19 日 16:24ems_clear_event-rw-r-r-1 informix informix 15183580 11 月 19 日 1

18、6:19 ems_event此名表名称，可单独一张表导入数据库，也可启动导入脚本，进行全库数据表导 入。5. 2数据库初始化Oninit - iv进行数据库初始化，并删除数据库库文件和数据： informixtnmsdb:/opt/dbnm # oninit -sivThis action will initialize IBM Informix Dynamic Server;any existing IBM Informix Dynamic Server databases will NOT be accessibleDo you wish to continue (y/n)? yCheck

19、ing group membership to determine server run mode. succeededReading configuration file ?/opt/dbnm/etc/onconfig. tms_db，. succeededCreating /INFORMIXTMP/. infxdirs. succeededChecking config parameters. . . succeededAllocating and attaching to shared memory. succeededCreating resident pool 1074200 kby

20、tes. succeededAllocating 4000016 kbytes for buffer pool of 2K page size. . . succeededCreating infos file /opt/dbnm/etc/. infos. tms_db/z. . . succeededLinking conf file z/opt/dbnm/etc/. conf. tms_dbzz. . . succeededInitializing rhead structure. succeededWriting to infos file. succeededInitializatio

21、n of Encryption. succeededInitializing ASF. succeededInitializing Dictionary Cache and SPL Routine Cache. . succeededBringing up ADM VP. . . succeededCreating VP classes. . . succeededOnlining 14 additional cpu vps. . succeededOnlining 2 10 vps. .succeededForking main loop thread. . . succeededIniti

22、alizing dataskip structure.succeededChecking for temporary tables to drop. succeededForking onmode_mon thread. . . succeededCreating periodic thread. succeededVerbose output complete: mode = 1初始化数据库完成，目前数据库为无数据库新建库5. 3创建数据库创建数据库日志文件：onparams -a -d logdbs -s 400000增加chunks文件:onspaces -a datadbsl -p /

23、infordata/Informix/chunks/datachk4 -o 0 -s 20000000 检查数据库状态： infonnixtnnisdb:/opt/dbnm # onstat -dIBM Informix Dynamic Server Version 11. 50. FC5 一一 On-Line 一一 Up 00:04:16 8134840 Kbytes c00000013ef035f81490100000009999997PO-B-/opt/dbnm/Inkdev/datadbs21重新读取和加载该chunks文件后恢复正常，为P0状态。创建数据库：dbaccess sysm

24、astercreate database tnmsdb2 in datadbs5 . 4数据导入在该目录下:informixtnnisdb:/opt/dbnni/数据库备份脚本执行数据库 导入脚本：loadzz. sh tnmsdb2 tnmsdb2 fulldb 则将此前备份到：/opt/dbnm/数据库备份 脚本/tnmsdb2/record目录下的全库数据文件导入到新建tnmsdb2库中数据导入完毕后进行整个数据库的全库更新：update statistics ;目的 为提高新建库的读写速度。并检查数据库运行状态，确保数据库能提供正常服务。注：由于数据备份采用load方式，导入和导出会因

25、表的大小占用整个数据库恢复的 80%时间。恢复的及时有效性严重受到影响。5.5启动应用此时则重启应用服务，恢复应用。6 .案例分析鉴于传输综合网管一旦上线应用运行，各地市推广并积极应用，一旦浮现数据库 故障和主业务应用故障等浮现不可恢复*,则影响广泛，严重影响告警派单等正 常运行。为规避风险，避免下次发生其他故障修复时间过长，且弥补目前安全隐患，现计 划并做如下实施：6.1 服务器操作系统备份每月检查服务器运行情况，并申请磁带，进行服务器操作系统磁带备份。以便在 服务器操作系统浮现故障时及时恢复操作系统运行。6. 2数据库备份采用：ontape进行数据库0级备份。Ontape:备份和恢复ONL

26、INE数据、备份和恢复逻辑日志、改变数据库日志状态 等优点：ontape备份可以在ONLINE联机或者静止方式下进行，高效方便。入ontape在数据库发生故障无法访问时，可在最短期内，最有效率的及时恢复 数据库，及时性强入备份频率：每周进行一次数据库的0级备份入每周进行数据库的全库备份入每次数据库表更改前，进行数据库表更改先后的备份入备份数据存放位置：单独申请一块磁盘，专门存放数据库备份数据入（存放在盘阵上，读写速度要 快于本地服务器硬盘，能在数据库故障时缩短数据恢复时间）申请磁带，进行数据库数据库磁带备份入双份数据库数据备份，增加多重数据保护。避免单一数据库备份浮现丢失的不 可恢复操作。入避

27、免因load数据导致当数据库浮现不可恢复是导入数据过慢，影响系统恢复及 时*入6. 3主业务应用采集备份每次升级运行测试后，进行主业务应用和采集程序备份主业务应用程叙文件和采集程叙文件，可和数据库备份文件一起放在单独申请 的备份磁盘上入每次升级，磁带备份主业务应用程序和采集程序入一旦采集应用等浮现不可修复问题，可在第一时间安装部署主业务应用程序和 采集程序入6.4测试（备）系统搭建构建传输综合网管系统的测试系统，可避免当前数据库故障时，主业务应用不可 用，影响各地市以及告警派单等应用。而一旦浮现类似数据库等不可恢复情况，可暂时由测试系统代替正式系统提供应 用服务。进而在不影响告警派单和个地市应

28、用的基础上，专注解决正式系统故障 问题。6. 5总结由于此次我们考虑问题不周全，以致在乎外故障时间发生时，导致处理时间超长， 且不能及时恢复应用系统应用，反思：1：不管局方等任何第三方有没有要求，都要遵从操作流程，严格按照申请来进 行操作：提交申请报告，申请切换测试时间-一邮件往来整理提供切换测试文档（测试时间，操作内容，意外风险，相干责任人，回 退方案）一一邮件往来顺利完成，书写切换测试回报一一邮件往来一旦操作失败，第一时间电话告知用户并邮件通知。同时相关人等明确审 核问题并与第一时间解决。 带解决后：邮件告知浮现问题原因，解决过程和问 题解决情况。2：任何对数据库的操作前，一定要做好数据库

29、和数据库数据的备份工作强烈建议针对Informix数据库采用零级备份。以便在乎外故障情况下能在最 短的时间内恢复数据库服务。3：尽可在晚12点进行MC切换前10个小时住手主业务应用，全力备份数据库， 并告知各个应用部门，以免在做数据库全库备份时，各个应用部门操作引起数据 丢失。4：在infroimx和HP厂家商议考虑一切在做该操作的过程中浮现的任何可能发 生的情况，并严格制定出一旦发生该类情况，我们该如何及时恢复和避免的详细 切换和恢复方案，以便在乎外情况发生是能及时恢复应用5：有效的利用好测试系统（备用系统）。以便在单一数据库运行失败，且不能 提供服务时，能及时提供测试系统数据库和主业务应用服务给各个应用部门，确 保不影响在线业务运行的情况下，解决主数据库和主业务应用系统发生的故障。 解决后，并及时告知应用部门和及时恢复主系统运行。利用一切有效有利措施，全力保障传输（数据）综合网管应用系统实时在线提供服 务。待下次双机切换测试时，确保局方、Informix厂家、HP厂家、集成商等全部在 场，鉴于此次情况，并商讨在MC切换时浮现的任何可能故障，并确定一旦浮现 故障的避免和恢复方案，确保一旦浮现异常，第一时间内排除解决，在备用系统 未建立前，能在最快、最短的时间内恢复主系统运行。