服务器机房断电后的数据库一致性检查与恢复步骤

服务器机房突然断电，最让人头皮发麻的不是硬件损坏，而是数据库里那些正在写入的数据。电源断掉的那一刻，缓冲池里尚未刷入磁盘的脏页、正在执行的事务日志、以及文件系统本身的缓存，全部面临丢失或不一致的风险。恢复供电后，直接启动数据库实例是一个危险动作，你必须先完成一套严谨的完整性检查与修复流程。

机器重新通电后，第一反应往往是想立刻把数据库拉起来看数据丢没丢。这个冲动必须压住。首先登录操作系统，用 dmesg 或 /var/log/messages 查看内核日志，确认磁盘是否被正常识别，有没有出现 I/O error 或文件系统强制只读的报错。对于硬件 RAID 卡，用厂商工具检查阵列状态，确认电池后备单元是否失效、是否有磁盘被标记为 Foreign 或 Failed。如果存储层本身处于降级状态，此时启动数据库等于在流沙上盖房子，随时可能引发二次损坏。

存储确认无误后，检查文件系统。对于 ext4，执行 fsck -f 强制扫描；对于 XFS，使用 xfs_repair -n 先做只读检查，确认无严重元数据损坏后再去掉 -n 参数执行修复。这一步至关重要，因为断电可能导致文件系统的 journal 截断，某些正在写入的数据块可能处于“已分配但未写入”的中间态。如果跳过文件系统检查直接启动数据库，数据库引擎在读取这些损坏的数据文件时，轻则报错，重则导致整个表空间被标记为需要恢复，甚至引发页损坏连锁反应。

以 MySQL 的 InnoDB 引擎为例，它依赖双写缓冲和重做日志来保证崩溃恢复。正常启动时，InnoDB 会自动扫描 redo log，将已提交但未刷入数据文件的事务前滚，将未提交的事务回滚。但断电后的自动恢复并不总是可靠。启动前，先检查 my.cnf 中 innodb_force_recovery 参数，默认是 0。如果数据库启动失败或反复崩溃，需要逐步加大这个值从 1 到 6。值为 1 时仍然会执行完整的崩溃恢复，只是跳过某些损坏页的检查；值为 3 时不执行事务回滚；值为 6 时数据库进入只读的“抢救模式”。每调整一次，尝试启动并立即用 mysqldump 导出所有数据。注意，innodb_force_recovery 大于 0 时，任何写操作都可能导致数据永久损坏，所以目标永远是尽快把数据抽出来，而不是在原库上修复。

PostgreSQL 的机制类似，依赖 WAL 日志。断电后启动，PG 会自动进入恢复模式，回放 pg_wal 目录下未应用的日志段。如果启动时提示 "invalid record length" 或 "WAL segment already removed"，说明部分 WAL 文件损坏或丢失。此时不要立刻用 pg_resetwal，这个命令会强制清空 WAL 日志并将数据库重置到一个一致状态，代价是丢失所有未归档的事务，还可能破坏数据完整性。正确的做法是：先尝试从备份中恢复缺失的 WAL 段，或者使用 pg_rewind 工具如果这是集群中的从库。只有在确认所有其他手段都无效，且能接受数据丢失的前提下，才执行 pg_resetwal -f，然后立即用 pg_dumpall 重建数据库。

MongoDB 使用 WiredTiger 引擎时，断电可能导致集合文件头和检查点信息不一致。启动前，先用 mongod --repair 选项做修复，这个操作会遍历所有数据文件，丢弃损坏的文档并重建索引。但 --repair 需要额外的磁盘空间来存放修复过程中的临时文件，如果磁盘空间不足会直接失败。更安全的做法是，在启动后立即检查日志中是否有 "WT_CURSOR.search" 或 "checksum mismatch" 错误。如果某个集合损坏，可以用 db.collection.validate({full: true}) 做深度校验，然后从副本集的其他健康节点重新同步该集合的数据。

SQL Server 断电后，数据库可能处于 SUSPECT 状态。先尝试用 ALTER DATABASE SET EMERGENCY 将数据库置为紧急模式，然后执行 DBCC CHECKDB 带 REPAIR_ALLOW_DATA_LOSS 选项。这个名字本身就说明了风险——它可能删除损坏的页面来换取数据库可用。执行前必须先将 mdf 和 ldf 文件复制一份冷备。如果数据库连紧急模式都进不去，说明事务日志文件头损坏，需要借助第三方工具或从最近的完整备份加日志备份链做时间点恢复。永远不要在没有备份的情况下直接对生产库执行修复操作。

数据库成功启动不代表数据就完整了。断电瞬间正在执行的事务可能部分写入，比如订单表插入了记录但库存表没扣减。这类逻辑不一致无法被数据库引擎检测到，因为它只保证 ACID 事务的原子性，而跨表的业务原子性依赖应用层。恢复后必须跑一套数据校验脚本：检查订单金额汇总是否与支付流水匹配、库存数量是否与出入库记录一致、用户余额是否与账务明细对得上。对于核心业务表，建议直接计算关键列的校验和，与断电前的备份做比对。如果发现差异，需要结合 binlog 或 WAL 日志解析出断电时间点附近的事务，逐条回放或补偿。

经历一次这样的灾难后，必须把防御体系建立起来。第一，数据库所在服务器必须接入 UPS，并配置好当市电中断后自动通知数据库执行正常关机的脚本。第二，开启数据库的全量备份加连续归档，PostgreSQL 的 archive_command、MySQL 的 binlog 备份、SQL Server 的事务日志备份，确保能做到任意时间点恢复。第三，磁盘层面启用写缓存保护，硬件 RAID 卡必须配备电池或超级电容，文件系统挂载时使用 barrier 或 nobarrier 参数要谨慎评估。第四，定期做恢复演练，很多团队备份从不验证，真到用时发现备份文件也是坏的。只有把断电当作必然会发生的事件来设计架构，才能在它真正来临时从容应对。