温馨提示×

Linux MariaDB如何进行故障恢复

小樊
33
2025-12-26 05:08:55
栏目: 云计算

Linux MariaDB 故障恢复实战指南

一 快速定位与应急

  • 查看服务状态与系统日志,优先定位启动失败原因:
    • 执行:systemctl status mariadb.servicejournalctl -xe
    • 常见现象与处置要点:
      • 日志目录缺失:如 /var/log/mariadb/ 不存在或权限错误,创建并授权:mkdir -p /var/log/mariadb && chown -R mysql:mysql /var/log/mariadb
      • PID 目录不可写:如 /var/run/mariadb/ 不存在或不可写,创建并授权:mkdir -p /var/run/mariadb && chown -R mysql /var/run/mariadb
      • 数据目录未初始化:首次部署需初始化(确保数据目录为空):mysql_install_db --user=mysql --datadir=/var/lib/mysql --force && chown -R mysql:mysql /var/lib/mysql
  • 检查错误日志获取 InnoDB/启动细节:tail -n 50 /var/log/mariadb/mariadb.log
  • 若只是连接异常(如 ERROR 2003),确认服务运行与网络/防火墙:systemctl start mariadbfirewall-cmd --zone=public --add-port=3306/tcp --permanent && firewall-cmd --reload

二 非正常关机导致的 InnoDB 恢复

  • 典型症状:日志出现 InnoDB: Database was not shut down normallylog sequence number mismatch,实例反复崩溃无法进入正常恢复流程。
  • 只读导出法(优先尝试,尽量不改动原库):
    1. 以只读强制模式启动实例(逐级尝试,最高到 6,能导出就停在该级别):
      • mariadbd --user=mysql --datadir=/var/lib/mysql --skip-grant-tables --skip-networking --innodb-force-recovery=1
      • 逐级升到 2/3/4/5/6,只要能启动即可
    2. 立即逻辑备份:mysqldump -u root --single-transaction --databases 需要的库 > backup.sql
    3. 备份完成后,停止实例,清理数据目录,重装 MariaDB,导入备份并验证
  • 重装与加固要点(示例):
    • 重装:apt purge mariadb-* mysql-common galera-4 && rm -rf /var/lib/mysql/* && apt install mariadb-server
    • 导入:mysql < backup.sql
    • 安全:mariadb-secure-installation
  • 重要提示:
    • innodb_force_recovery > 0 仅用于“只读导出”,严禁在恢复模式下运行业务写入
    • 若级别 6 仍无法导出,说明损坏较重,直接基于最近可用备份恢复或寻求专业数据恢复服务。

三 使用 mariabackup 的物理恢复(推荐用于生产)

  • 备份(示例):mariabackup --backup --target-dir=/data/mysqlbak --user=backup --password=xxx
  • 准备(回放 redo,确保一致性):mariabackup --prepare --target-dir=/data/mysqlbak
  • 恢复(两种):
    • 复制回:mariabackup --copy-back --target-dir=/data/mysqlbak
    • 移动回:mariabackup --move-back --target-dir=/data/mysqlbak
  • 权限与启动:
    • chown -R mysql:mysql /var/lib/mysql
    • systemctl start mariadb
  • 适用场景:支持 InnoDB 在线热备/增量备,恢复速度快、一致性好,适合大库与严格 RPO/RTO 要求。

四 Galera 集群异常与脑裂处置

  • 现象:节点无法加入集群、报错如 WSREP has not yet prepared node for application use,多节点环境出现“脑裂”。
  • 处置思路(确保业务连续性优先):
    1. 选择数据最新的节点作为“新主”,在该节点上引导新集群:
      • 方式一:删除/修改 /var/lib/mysql/grastate.dat(如将 safe_to_bootstrap: 0 改为 1),然后启动:mysqld --wsrep-new-cluster
      • 方式二:直接引导:mysqld --defaults-file=/etc/my.cnf.d/server.cnf --user=mysql --wsrep-new-cluster --wsrep-cluster-address="gcomm://"
    2. 其他节点以普通方式加入:systemctl start mariadb
    3. 若节点长期无法加入或数据量大,建议重建新集群,从健康节点导出数据再导入(避免反复失败造成二次损坏)。

五 常见故障速查表

症状 快速检查 处理要点
服务起不来,状态报错 systemctl status mariadbjournalctl -xetail /var/log/mariadb/mariadb.log 修复目录/权限(如 /var/log/mariadb/var/run/mariadb)、初始化数据目录、必要时 mysql_install_db
InnoDB 崩溃无法启动 日志含 “not shut down normally”“log sequence number mismatch” 只读强制恢复导出:--innodb-force-recovery=1..6mysqldump → 重装/重建 → 导入验证
磁盘满导致卡死/启动失败 df -h 清理或扩容分区,再启动
无法远程连接 ERROR 2003 (HY000) systemctl start mariadbfirewall-cmd 放行 3306、检查 bind-address
表损坏/索引异常 mysqlcheck 报错 mysqlcheck --auto-repair --check --optimize 库名 表名
无备份且仅文件在 数据文件(如 ibdata1、库目录)尚在 在相近版本实例上做“物理移植”:停库→拷文件→改属主→启动→立即 mysqldump 导出→重建库导入

0