易宝支付技术分享——加强数据管理，数据库常见事故梳理

大数据时代，数据量呈现爆炸式增长，数据库运维是互联网企业的核心，各个企业都在其上投入大量精力进行维护。易宝支付做为国内第三方支付的引领者，拥有多个产品，服务百万商户，肩负保障商户交易稳定和数据安全的责任，针对数据库可能出现的问题，易宝支付在技术和理论方面进行了不断的探索，近期，其技术团队针对数据库管理的问题进行了梳理，小编摘取如下，相信对更多的企业数据库运维有重要的参考价值。

(1) 事务内部的故障：事务内部故障可分为预期的和非预期的，其中大部分的故障都是非预期的。预期的事务内部故障是指可以通过事务程序本身发现的事务内部故障; 非预期的事务内部故障是不能由事务程序处理的，如运算溢出故障、并发事务死锁故障、违反了某些完整性限制而导致的故障等。

(2) 系统故障：系统故障也称为软故障，是指数据库在运行过程中，由于硬件故障、数据库软件及操作系统的漏洞、突然停电灯情况，导致系统停止运转，所有正在运行的事务以非正常方式终止，需要系统重新启动的一类故障。这类事务不破坏数据库，但是影响正在运行的所有事务。

(3) 介质故障：介质故障也称为硬故障，主要指数据库在运行过程中，由于磁头碰撞、磁盘损坏、强磁干扰、天灾人祸等情况，使得数据库中的数据部分或全部丢失的一类故障。

(4) 计算机病毒故障：计算机病毒故障是一种恶意的计算机程序，它可以像病毒一样繁殖和传播，在对计算机系统造成破坏的同时也可能对数据库系统造成破坏(破坏方式以数据库文件为主) 。

工作中常见的事故情况

BUG 类高并发短小事务坑

某年考试集中报名，应用频繁出现繁忙，线程报警，导致交易时断时续。查看数据库端负载稍微偏高，事务量是平常的 4 倍多，分析事务量与交易量并不成正比，进一步排查发现执行频率最高的 SQL 达到每秒 2000 次以上。通过一个简单的银行字典查询，开发人员定位问题为此考试接口为定制代码，有多次重复查询 BUG。紧急修复后交易正常。

总结：优化核心交易事务，精简代码，严格控制代码质量。

悲催的各种用尽坑

DBA 发现由于最初的设计原因，交易流水表 ID 使用的是 INT 类型的 sequence，这使得交易流水表 ID很快就会用尽并导致交易停止。于是排查类似的可能用尽的坑，发现数据库日志 SN 居然也能用尽，只有升级版本后才能解决此问题，再一看当前 SN 号一身冷汗，此时推算核心交易库将在半年后用尽 SN 进入只读模式，后果不堪设想。继续探坑又有新发现，LINUX 平台 ETX3 文件系统单文件最大只支持 2T，而线上已经有存到 1.5T。

总结：坑也是无穷无尽的，想不掉下去，那就积极主动探坑吧。

半死不活的硬件故障坑

某日短信通知系统中断，电话应急处理过程中 NOC 反馈未发现任何数据库服务器有可用性报警，但开发反馈应用无法连接数据库，于是 DBA 尝试登录此服务器发现能 ping 通，但 ssh 无法连接。立刻登陆远控卡发现 RAID 卡报错导致系统 hang，执行数据库切换方案后，业务恢复正常。

总结：系统 hang 会导致 Agent 报警，数据无法推送到服务端。报警策略一定要配置采集数据超时时间，避免不能及时发现故障。

数据库不可用导致应用无法启动的坑

线上有一些非核心数据库，如归档库，只对外提供历史数据的查询，为节约硬件成本，此库可用性标准 999。偶然一次代码上线过程中，应用启动后 hang 住了，日志无任何输出，问题无从查起。而此时某台历史库正在维护，由此推断是否和数据库有关，查代码后发现果然如此，代码对于数据库异常未做任何处理，无 try catch。此问题如果在上线阶段发生，其后果将是灾难性的。

总结：日志输出一定要遵循软件设计原则，系统日志的缺失对于紧急问题定位是灾难性的。

根据以上例子可发现，一些小小的失误都有可能造成数据库的崩溃。大家在使用的过程中一定要规范自己的习惯，切莫粗心大意造成无法挽回的损失。