在生产环境中遇到MySQL连接异常卡顿，表现为应用连接数据库时经常出现5-10秒的延迟。通过分析MySQL错误日志，发现关键错误：IP address '172.16.238.2' could not be resolved: Temporary failure in name resolution。本文记录完整排查过程与解决方案。

问题背景

在生产环境中，我们遇到了MySQL数据库连接异常卡顿的问题，表现为应用连接数据库时经常出现5-10秒的延迟。通过分析MySQL错误日志，发现以下关键错误信息：

IP address '172.16.238.2' could not be resolved: Temporary failure in name resolution

这个错误表明MySQL在处理连接时遇到了DNS解析问题，导致连接建立过程严重延迟。

排查思路与过程

第一阶段：初步分析与假设验证

1.1 检查AppArmor安全策略

假设：AppArmor安全策略可能拦截了MySQL的网络解析操作。

验证过程：

sudo aa-status | grep mysql

结果：无输出，表明AppArmor并未加载MySQL相关策略，排除了此可能性。

1.2 检查DNS配置

分析：查看系统DNS配置文件

cat /etc/resolv.conf

发现：

nameserver 127.0.0.53

系统使用本地的systemd-resolved服务作为DNS解析器。

第二阶段：深入分析DNS解析机制

2.1 理解MySQL的DNS解析机制

MySQL在建立连接时会执行"双向验证"流程：

  1. 正向解析：通过IP查询对应的主机名
  2. 反向验证：通过主机名查询对应的IP地址
  3. 比对验证：确保两次查询的IP地址一致

这个机制虽然增强了安全性，但在内网环境中容易因DNS配置问题导致性能问题。

2.2 检查hosts文件配置

cat /etc/hosts

发现：

10.94.34.78 ilink-pv.saicmotor.com
10.94.34.79 ilink-pv.saicmotor.com

这些配置是为应用访问特定服务准备的，与MySQL的反向解析需求无关。

第三阶段：根本原因分析

3.1 问题本质

当客户端IP 172.16.238.2 连接数据库时：

  1. MySQL需要反向解析该IP的主机名
  2. 系统查询 /etc/hosts 无相关记录
  3. 请求转发至 127.0.0.53（systemd-resolved）
  4. 内网DNS服务器无法解析该IP的PTR记录
  5. DNS查询超时（5-10秒）
  6. MySQL连接建立延迟

3.2 与其他服务器的差异对比

服务器类型 DNS配置 反向解析能力 连接性能
其他正常服务器 正确配置DNS或无需解析 快速响应 正常
本问题服务器 本地systemd-resolved 无法解析内网IP 严重延迟

第四阶段：解决方案制定与实施

4.1 方案对比分析

方案一：配置外部DNS

  • 优点：理论上能解决问题
  • 缺点：依赖外部服务、存在性能损耗、稳定性风险
  • 适用性：不推荐用于生产环境

方案二：优化AppArmor配置

  • 优点：解决潜在安全策略问题
  • 缺点：无法根本解决DNS解析延迟
  • 适用性：辅助方案

方案三：跳过DNS解析（推荐）

  • 优点：彻底解决问题、性能最优、稳定性高
  • 缺点：需要修改MySQL配置
  • 适用性：生产环境标准实践

4.2 最终解决方案

步骤1：修改MySQL配置文件

sudo vim /etc/mysql/mysql.conf.d/mysqld.cnf

步骤2：添加关键参数

在 [mysqld] 段落中添加：

skip-name-resolve

步骤3：保留应用所需hosts配置

确保 /etc/hosts 中保留应用访问所需配置：

10.94.34.78 ilink-pv.saicmotor.com
10.94.34.79 ilink-pv.saicmotor.com

步骤4：重启MySQL服务

sudo systemctl restart mysql

第五阶段：验证与测试

5.1 验证MySQL配置

mysql -u root -p -e "SHOW VARIABLES LIKE 'skip_name_resolve';"

预期输出：ON

5.2 测试应用访问

ping -c 3 ilink-pv.saicmotor.com

验证应用访问不受影响。

5.3 监控连接性能

通过应用日志监控数据库连接时间，确认延迟问题解决。

问题总结与经验分享

根本原因

MySQL在建立连接时的DNS反向解析机制，在内网DNS配置不完善的情况下导致连接延迟。

解决方案优势

  1. 性能提升：连接建立时间从秒级降至毫秒级
  2. 稳定性增强：不再依赖外部DNS服务
  3. 维护简化：减少网络配置复杂度

生产环境最佳实践

  1. 标准配置：生产环境MySQL建议始终配置 skip-name-resolve
  2. 权限管理：使用IP地址而非主机名进行权限配置
  3. 网络规划：确保内网DNS服务配置完善
  4. 监控预警：建立数据库连接性能监控

延伸思考

  1. 安全权衡：在内网环境中，IP地址验证通常足够安全
  2. 架构优化：考虑使用连接池减少频繁连接建立
  3. 容器化部署：在容器环境中此问题更为常见，需特别注意

结语

通过系统性的排查分析，我们不仅解决了当前的性能问题，更重要的是理解了MySQL网络连接机制的底层原理。在生产环境中，合理配置 skip-name-resolve 参数是确保数据库连接性能和稳定性的关键措施。

对于内网部署的MySQL数据库，除非有特殊安全需求，否则都应该配置 skip-name-resolve 参数，这是经过实践验证的最佳实践。