有状态服务断电后日志脏块需分层修复：先验证损坏（查启动日志与文件状态），再按mysql（--innodb_force_recovery）、postgresql（pg_resetwal）、redis（redis-check-aof）类型针对性处理，修复后必须校验数据一致性，并通过挂载volume、调优刷盘参数及ups保障预防。
有状态服务（如 MySQL、PostgreSQL、Redis）在 Docker 中遭遇强行断电后，日志脏块（dirty log blocks）是常见问题——本质是事务日志（如 MySQL 的 redo log、binlog，或 PostgreSQL 的 WAL）写入中途被中断，导致日志文件不完整或校验失败。这类问题不能靠简单重启解决，需分层定位与修复。
确认日志是否真的损坏
先别急着修复，先验证是否真存在脏块：
- 查看容器启动日志：docker logs
| head -50，重点找类似 "InnoDB: Database page corruption"、"WAL segment ... has wrong size" 或 "binlog checksum mismatch" 的报错 - 进入容器检查日志文件状态：docker exec -it
sh -c "ls -lh /var/lib/mysql/ib_logfile* /var/lib/mysql/mysql-bin.* 2>/dev/null" - 对比文件大小是否异常（例如 ib_logfile0 和 ib_logfile1 大小不一致，或 binlog 文件末尾无正常 EOF 标记）
按服务类型执行针对性修复
不同数据库对日志脏块的容忍和恢复机制差异很大，不能一概而论：
-
MySQL（InnoDB）：启动时自动尝试 crash recovery。若卡在 "Starting crash recovery..." 或报 "Log block checksum mismatch"，可临时启用跳过校验（仅限紧急恢复）：
在 docker run 或 docker-compose.yml 的 command 中加入 --innodb_force_recovery=1（数值 1–6 逐级升高，从只读恢复开始），再导出数据；切勿在生产环境长期启用 - PostgreSQL：WAL 损坏通常导致启动失败并提示 "could not locate a valid checkpoint record"。需检查 $PGDATA/pg_wal/ 目录下最新 WAL 文件是否截断；若有备份 + 归档 WAL，可用 pg_rewind 或 pg_basebackup 恢复；若无归档，且 wal_level = replica，可尝试 pg_resetwal -f（强制重置 WAL 起始位置，会丢失最近未归档事务）
- Redis（AOF 模式）：运行 redis-check-aof --fix /data/appendonly.aof（注意路径要匹配容器内 AOF 文件实际位置）；若提示 "AOF file is shorter than expected"，说明末尾脏块已被截断，可安全修复
修复后必须验证数据一致性
日志修复只是让服务“起来”，不代表数据正确：
- MySQL：执行 CHECK TABLE 表名；对关键业务表用 SELECT COUNT(*) 对比断电前快照（如有）
- PostgreSQL：运行 pg_checksums -D $PGDATA --check 验证页校验和（需开启 data checksums）
- 通用建议：从应用层触发一笔已知结果的测试交易（如创建测试订单、查询固定 ID 记录），确认读写逻辑闭环
避免下次再出现的关键配置
修复是补救，预防才是根本：
- 所有有状态服务容器必须挂载 独立 volume（不用 bind mount），并确保宿主机文件系统启用 journal（如 ext4 默认开启）
- MySQL 启动参数加 --innodb_flush_log_at_trx_commit=1 和 --sync_binlog=1（牺牲性能换一致性）
- Redis 必须启用 AOF + fsync everysec（或 always），禁用纯 RDB 模式
- 宿主机层面部署 UPS，并配置 systemd 在断电前 30 秒触发 docker stop --time=30 容器优雅终止（需硬件支持）
