DigitalOcean VPS上MariaDB意外停止的原因及解决办法咨询

提供的日志内容： #

2022-09-06 14:20:02 0 [Note] /usr/sbin/mysqld (initiated by: unknown): Normal shutdown
2022-09-06 14:20:02 0 [Note] Event Scheduler: Purging the queue. 0 events
2022-09-06 14:20:02 0 [Note] InnoDB: FTS optimize thread exiting.
2022-09-06 14:20:02 0 [Note] InnoDB: Starting shutdown...
2022-09-06 14:20:02 0 [Note] InnoDB: Dumping buffer pool(s) to /var/lib/mysql/ib_buffer_pool
2022-09-06 14:20:02 0 [Note] InnoDB: Buffer pool(s) dump completed at 220906 14:20:02
2022-09-06 14:20:04 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2022-09-06 14:20:04 0 [Note] InnoDB: Shutdown completed; log sequence number 292509498; transaction id 183124
2022-09-06 14:20:04 0 [Note] /usr/sbin/mysqld: Shutdown complete

2022-09-06 14:20:04 0 [Note] InnoDB: Using Linux native AIO
2022-09-06 14:20:04 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2022-09-06 14:20:04 0 [Note] InnoDB: Uses event mutexes
2022-09-06 14:20:04 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-09-06 14:20:04 0 [Note] InnoDB: Number of pools: 1
2022-09-06 14:20:04 0 [Note] InnoDB: Using SSE2 crc32 instructions
2022-09-06 14:20:04 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2022-09-06 14:20:04 0 [Note] InnoDB: Completed initialization of buffer pool
2022-09-06 14:20:04 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2022-09-06 14:20:04 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2022-09-06 14:20:04 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-09-06 14:20:04 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2022-09-06 14:20:04 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2022-09-06 14:20:04 0 [Note] InnoDB: Waiting for purge to start
2022-09-06 14:20:04 0 [Note] InnoDB: 10.3.34 started; log sequence number 292509498; transaction id 183125
2022-09-06 14:20:04 0 [Note] Plugin 'FEEDBACK' is disabled.
2022-09-06 14:20:04 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2022-09-06 14:20:04 0 [Note] Server socket created on IP: '::'.
2022-09-06 14:20:04 0 [Note] Reading of all Master_info entries succeeded
2022-09-06 14:20:04 0 [Note] Added new Master_info '' to hash table
2022-09-06 14:20:04 0 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.3.34-MariaDB-0ubuntu0.20.04.1'  socket: '/run/mysqld/mysqld.sock'  port: 3306  Ubuntu 20.04
2022-09-06 14:20:04 0 [Note] InnoDB: Buffer pool(s) load completed at 220906 14:20:04

原因分析 #

从日志来看，MariaDB是正常关闭后立刻自动重启的，但发起关闭的主体显示为unknown，可能的触发原因包括：

1. 系统OOM Killer触发：当VPS内存不足时，Linux内核会终止占用内存较多的进程（比如mysqld），虽然日志里没直接报错，但需要排查系统日志确认。
2. 服务管理工具的自动重启策略：比如systemd配置了Restart参数（如always/on-failure），进程停止后会自动拉起，这是常见的服务保障机制。
3. 第三方脚本或定时任务：服务器上的定时脚本、监控工具可能触发了MariaDB的重启命令，但没留下相关记录。
4. MariaDB内部配置或异常：极少数情况下，某些配置冲突或内部线程异常会触发主动重启，但本次日志显示关闭过程完全正常，这种可能性较低。

可行解决办法 #

1. 排查OOM Killer记录 #

执行以下命令检查系统日志中是否有内存不足导致进程被杀死的记录：

grep -i "oom-killer" /var/log/syslog
# 或者查看内核日志
dmesg | grep -i oom

如果确认是OOM导致，要么升级VPS内存，要么调整MariaDB的内存配置（比如降低innodb_buffer_pool_size参数，当前日志显示为128M，可根据实际内存情况调整）。

2. 检查systemd服务配置 #

查看MariaDB的systemd服务配置，确认自动重启策略：

cat /etc/systemd/system/mariadb.service
# 或者用systemctl查看关键参数
systemctl show mariadb | grep Restart

如果Restart值为always或on-failure，说明这是预期的自动重启机制，若不需要可修改配置后重新加载：

sudo systemctl daemon-reload
sudo systemctl restart mariadb

3. 排查定时任务与第三方脚本 #

检查当前用户及root用户的定时任务：

crontab -l
sudo crontab -l

同时查看系统定时任务目录：

ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/

确认是否有脚本触发了MariaDB的停止或重启操作。

4. 监控系统资源 #

使用htop或vmstat实时监控内存、CPU使用情况，确认是否存在持续的资源瓶颈：

htop
# 或者查看内存使用
free -h

5. 检查MariaDB配置文件 #

查看MariaDB的主配置文件（通常为/etc/mysql/my.cnf或/etc/mysql/mariadb.conf.d/50-server.cnf），确认是否有异常配置参数导致重启，比如innodb_force_recovery等。

内容的提问来源于stack exchange，提问作者Omar Vásquez Sahuanay