Linux MariaDB故障排查技巧有哪些

Linux MariaDB故障排查技巧

一 快速定位与通用流程

• 查看服务状态与系统日志：使用systemctl status mariadb与journalctl -xe获取失败原因与调用栈；必要时按时间过滤：journalctl -u mariadb --since “2025-12-22 10:00:00”。
• 定位错误日志：默认在**/var/log/mariadb/error.log或/var/log/mysql/error.log**；若自定义路径，查看**/etc/my.cnf或/etc/mysql/my.cnf中的log_error**。
• 实时跟踪与关键字筛选：用tail -fn 30 /var/log/mariadb/mariadb.log实时查看，配合**grep -i “failed|error|access denied”**快速定位。
• 手工前台启动验证：在**/usr/sbin下执行mysqld --verbose --help确认配置加载路径，必要时用strace mysqld 2> & 1 | tee strace.log**跟踪系统调用以发现配置、权限或依赖问题。
• 多配置文件与依赖检查：排查**/etc/my.cnf /etc/my.cnf.d/ /usr/local/mysql/etc/my.cnf等多处配置覆盖；用ldd $(which mysqld)检查缺失的libaio、libnuma**等依赖。

二 服务无法启动高频场景与修复

• 目录与权限类：
  • 日志目录缺失或无写权限：创建并授权**/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:mysql /var/run/mariadb。
• 数据目录未初始化或权限错误：确保datadir（如**/var/lib/mysql**）为空后执行初始化（以发行版脚本为准），如mysql_install_db --user=mysql --datadir=/var/lib/mysql，完成后chown -R mysql:mysql /var/lib/mysql。
• 端口被占用或重复实例：检查netstat -tlnp | grep 3306与ps aux | grep mysqld，结束异常进程或调整端口。
• 磁盘空间不足：执行df -h，清理或扩容后再启动。
• InnoDB日志损坏导致启动失败：错误日志含InnoDB: Corrupted file-level record时，先在**/etc/my.cnf.d/server.cnf中设置innodb_force_recovery=1尝试启动，能启动后立刻mysqldump全量逻辑备份，再重建实例恢复数据（从1逐级尝试，避免直接设到6**）。

三 连接失败与访问异常排查

• 服务未运行：用systemctl start mariadb启动，必要时systemctl enable mariadb设置开机自启。
• 本地 socket 连接失败（ERROR 2002）：检查**/var/lib/mysql/mysql.sock是否存在；若my.cnf中socket路径不同，可用mysql --socket=/path/to/mysql.sock**指定，或创建软链统一路径。
• 远程连接失败（Communications link failure）：确认实例监听0.0.0.0:3306、云安全组/本机防火墙放行3306，用户具备远程主机访问权限（如**‘user’@‘%’`），并核对JDBC URL中的host、port、useSSL、serverTimezone等参数。
• 访问被拒绝（Access denied）：核对用户名、主机、密码；必要时在维护窗口重置密码并刷新权限。

四 性能与运行期问题定位

• 慢查询定位：开启慢查询日志（在my.cnf中设置slow_query_log=1、slow_query_log_file、long_query_time），用mysqldumpslow或pt-query-digest分析，结合EXPLAIN优化索引与SQL。
• 资源瓶颈：用top/htop、vmstat、iostat观察CPU、内存、I/O，确认是否存在swap抖动、I/O 饱和或连接数打满。
• 连接数问题：通过**SHOW STATUS LIKE ‘Threads_connected’; 与SHOW PROCESSLIST; **识别连接风暴、长时间事务与阻塞。
• 配置核对：确认innodb_buffer_pool_size、max_connections、query_cache_size等与实例规格匹配，避免过小导致性能劣化或过大引发换页与内存紧张。

五 应急与恢复建议

• 有备份时：优先选择物理备份+时间点恢复或**逻辑备份（mysqldump）**恢复，恢复前在测试环境验证一致性。
• 无有效备份且InnoDB损坏：将innodb_force_recovery从1逐级尝试至6以只读方式启动，成功后立即全量备份/导出，随后重建实例并导入数据。
• 变更风险控制：任何修复前先备份my.cnf、datadir、错误日志与关键表；变更遵循“单变量调整、可回滚”原则，并在灰度/维护窗口执行。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！