记录一次MySQL（MariaDB）的运维

一、前言

在某台运行 OpenCloudOS 的服务器上，业务侧反馈数据库偶尔会出现连接失败的情况。登录服务器后，我第一时间查看了 MariaDB 的错误日志（/www/server/data/*.err），发现日志中并没有明显的 “Fatal Error”，但数据库在短时间内频繁重启，且伴随大量异常连接记录。本次记录正是基于这份日志，对 MariaDB 10.6.20 的运行状态进行一次完整的复盘与修复。

二、日志分析

通过对日志的分段解读，可以将问题归纳为以下三类。

1. 配置异常：max_allowed_packet严重超限

日志中反复出现如下警告：

Warning: option 'max_allowed_packet': unsigned value 107374182400 adjusted to 1073741824

分析：

• 配置文件中 max_allowed_packet被设置为 100GB
• 而 MariaDB 的实际上限仅为 1GB
• 服务在启动阶段强制进行了修正： max_allowed_packet=256MB

虽然数据库能够启动，但这种明显不合理的配置通常意味着：

• 面板（如宝塔）或人工误操作
• 存在潜在的内存分配风险

2. 服务不稳定：反复启停

日志显示，在几分钟内 MariaDB 连续经历了多次完整的启动与关闭流程：

Starting mariadbd daemon...
ready for connections.
Normal shutdown...
Starting mariadbd daemon...

并且出现了典型的资源冲突提示：

A mysqld process already exists

分析：

• 数据库并非崩溃，而是“被正常关闭”
• 极有可能是：
  • 面板守护进程误判
  • systemd与 mysqld_safe启动方式冲突
  • 定时任务或监控脚本干预

这种“假死—重启”的行为，会直接导致业务短连接失败。

3. 安全风险：本地与远程双重威胁

（1）本地 root 无密码访问

Access denied for user 'root'@'localhost' (using password: NO)

分析：

• 有程序或脚本直接使用 root用户连接数据库
• 未提供密码，说明：
  • root 密码未设置
  • 应用配置错误

这是一个典型的高危操作习惯。

（2）外网扫描与恶意探测

日志中还出现了大量外部连接：

IP address '139.59.42.255' could not be resolved
This connection closed normally without authentication
host: 'azpdcgy8hmls.stretchoid.com'

分析：

• 3306端口暴露在公网
• 正在遭受自动化扫描（如 Stretchoid）
• 虽然当前未被攻破，但攻击面过大

三、修复措施

针对上述问题，我采取了以下修复手段。

1. 修正数据库配置

编辑 my.cnf，将不合理的参数调整为安全范围：

[mysqld]
max_allowed_packet = 256M
innodb_buffer_pool_size = 1G
bind-address = 127.0.0.1

随后重启数据库：

2. 稳定数据库运行环境

• 统一使用 systemd管理 MariaDB，禁用多余的 mysqld_safe守护脚本
• 检查并清理面板中可能存在的重复监控任务
• 设置合理的重启策略，避免“误判重启”

3. 安全加固

在腾讯云轻量主机的防火墙添加禁止来自公网IP登录的规则

四、总结

这次运维事件并不涉及复杂的 SQL 优化或大版本升级，而是一个典型的 “配置 + 稳定性 + 安全”​ 的综合问题。最大的收获在于：很多时候，数据库“能启动”并不代表“运行健康”。通过一次看似普通的错误日志排查，及时消除了潜在的安全隐患，也避免了未来可能出现的业务中断。