MySQL数据库宕机快速恢复

以下是快速恢复MySQL数据库宕机的分步指南：

1. 确认宕机原因

• 查看MySQL错误日志：

  tail -n 100 /var/log/mysql/error.log

  常见错误：

  • InnoDB: Database page corruption on disk

  • Can't connect to MySQL server on 'localhost' (111)

  • Disk is full

• 检查系统资源：

  df -h                  # 查看磁盘空间
  free -h                # 查看内存使用
  dmesg | grep -i kill   # 检查是否因OOM被系统杀死

---

2. 尝试快速重启MySQL

• 强制重启服务：

  systemctl stop mysql    # 正常停止（若无效则跳过）
  pkill -9 mysqld         # 强制终止进程
  systemctl start mysql

---

3. 处理常见故障场景

场景1：磁盘空间不足

• 清理空间：

  # 删除大文件或旧日志
  rm -rf /var/log/mysql/mysql-slow.log.*
  ​
  # 清理二进制日志（需确认无复制依赖）
  PURGE BINARY LOGS BEFORE '2023-01-01 00:00:00';

场景2：InnoDB表损坏

• 强制恢复模式 ： 修改/etc/my.cnf，添加：

  [mysqld]
  innodb_force_recovery = 6   # 从1到6逐级尝试，6为最高级别

  启动MySQL后导出数据：

  mysqldump -u root -p --all-databases > backup.sql

  移除innodb_force_recovery并重启，重新导入数据。

场景3：主从复制中断

• 跳过错误或重建从库：

  -- 在从库执行
  STOP SLAVE;
  SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
  START SLAVE;
  -- 若持续错误，考虑重新同步数据

---

4. 从备份恢复

• 全量备份恢复：

  # 停止MySQL
  systemctl stop mysql
  ​
  # 恢复数据文件
  cp -r /backup/mysql/data /var/lib/mysql
  chown -R mysql:mysql /var/lib/mysql
  ​
  # 启动MySQL
  systemctl start mysql

• 增量恢复（使用二进制日志）：

  mysqlbinlog --start-datetime="2023-10-01 00:00:00" /var/lib/mysql/mysql-bin.00000* | mysql -u root -p

---

5. 高可用切换（如有集群）

• 主从切换：

  -- 在从库提升为主库
  STOP SLAVE;
  RESET SLAVE ALL;
  SET GLOBAL read_only = OFF;

• VIP漂移或DNS切换：

  # 使用keepalived或手动修改DNS指向新主库

---

6. 事后优化与预防

• 参数调优：

  [mysqld]
  innodb_buffer_pool_size = 物理内存的70%
  max_connections = 1000

• 监控告警：

  • 部署Prometheus + Grafana监控MySQL状态（如线程数、慢查询、复制延迟）。

• 定期备份验证：

  # 每日全备 + 二进制日志
  mysqldump --single-transaction --master-data=2 -A > backup.sql

---

关键命令速查表

场景	命令/操作
检查MySQL状态	systemctl status mysql
强制终止进程	kill -9 $(pgrep mysqld)
修复表损坏	mysqlcheck -u root -p --auto-repair --optimize --all-databases
导出所有数据库	mysqldump -u root -p --all-databases > backup.sql
查看当前连接	SHOW FULL PROCESSLIST;
检查InnoDB状态	SHOW ENGINE INNODB STATUS\G

---

总结

• 优先恢复服务：快速重启 → 资源清理 → 主从切换。

• 数据安全第一：若无法快速修复，立即从备份恢复。

• 事后根因分析：通过日志定位根本原因，优化配置或架构。