Linux MariaDB如何进行故障恢复
导读:Linux MariaDB 故障恢复实战指南 一 快速定位与应急 查看服务状态与系统日志,优先定位启动失败原因: 执行:systemctl status mariadb.service、journalctl -xe 常见现象与处置要点:...
Linux MariaDB 故障恢复实战指南
一 快速定位与应急
- 查看服务状态与系统日志,优先定位启动失败原因:
- 执行:
systemctl status mariadb.service、journalctl -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
- 日志目录缺失:如 /var/log/mariadb/ 不存在或权限错误,创建并授权:
- 执行:
- 检查错误日志获取 InnoDB/启动细节:
tail -n 50 /var/log/mariadb/mariadb.log - 若只是连接异常(如 ERROR 2003),确认服务运行与网络/防火墙:
systemctl start mariadb、firewall-cmd --zone=public --add-port=3306/tcp --permanent & & firewall-cmd --reload。
二 非正常关机导致的 InnoDB 恢复
- 典型症状:日志出现 InnoDB: Database was not shut down normally、log sequence number mismatch,实例反复崩溃无法进入正常恢复流程。
- 只读导出法(优先尝试,尽量不改动原库):
- 以只读强制模式启动实例(逐级尝试,最高到 6,能导出就停在该级别):
mariadbd --user=mysql --datadir=/var/lib/mysql --skip-grant-tables --skip-networking --innodb-force-recovery=1- 逐级升到 2/3/4/5/6,只要能启动即可
- 立即逻辑备份:
mysqldump -u root --single-transaction --databases 需要的库 > backup.sql - 备份完成后,停止实例,清理数据目录,重装 MariaDB,导入备份并验证
- 以只读强制模式启动实例(逐级尝试,最高到 6,能导出就停在该级别):
- 重装与加固要点(示例):
- 重装:
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/mysqlsystemctl start mariadb
- 适用场景:支持 InnoDB 在线热备/增量备,恢复速度快、一致性好,适合大库与严格 RPO/RTO 要求。
四 Galera 集群异常与脑裂处置
- 现象:节点无法加入集群、报错如 WSREP has not yet prepared node for application use,多节点环境出现“脑裂”。
- 处置思路(确保业务连续性优先):
- 选择数据最新的节点作为“新主”,在该节点上引导新集群:
- 方式一:删除/修改 /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://"
- 方式一:删除/修改 /var/lib/mysql/grastate.dat(如将
- 其他节点以普通方式加入:
systemctl start mariadb - 若节点长期无法加入或数据量大,建议重建新集群,从健康节点导出数据再导入(避免反复失败造成二次损坏)。
- 选择数据最新的节点作为“新主”,在该节点上引导新集群:
五 常见故障速查表
| 症状 | 快速检查 | 处理要点 |
|---|---|---|
| 服务起不来,状态报错 | systemctl status mariadb、journalctl -xe、tail /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..6 → mysqldump → 重装/重建 → 导入验证 |
| 磁盘满导致卡死/启动失败 | df -h |
清理或扩容分区,再启动 |
| 无法远程连接 | ERROR 2003 (HY000) |
systemctl start mariadb、firewall-cmd 放行 3306、检查 bind-address |
| 表损坏/索引异常 | mysqlcheck 报错 |
mysqlcheck --auto-repair --check --optimize 库名 表名 |
| 无备份且仅文件在 | 数据文件(如 ibdata1、库目录)尚在 | 在相近版本实例上做“物理移植”:停库→拷文件→改属主→启动→立即 mysqldump 导出→重建库导入 |
声明:本文内容由网友自发贡献,本站不承担相应法律责任。对本内容有异议或投诉,请联系2913721942#qq.com核实处理,我们将尽快回复您,谢谢合作!
若转载请注明出处: Linux MariaDB如何进行故障恢复
本文地址: https://pptw.com/jishu/781667.html
