MySQL 8.0 容器频繁崩溃排查实录：从端口误配到内存 OOM 的踩坑与修复_Mysql

上周在daylay项目的云服务器部署中，我遇到了一个非常典型的“薛定谔的mysql故障”：用navicat连接数据库一直提示超时，排查完端口映射以为解决了，结果隔几个小时mysql容器还是会自动崩溃，反复折腾了两天才定位到真正的根因。整个过程踩了好几个低级坑，也积累了不少小内存服务器跑mysql的避坑经验，这里完整记录下来。

第一阶段：端口连通性故障的排查

一开始用户提供的连接信息是火山云服务器、端口22、root用户，我下意识就把这个当成mysql的连接信息用了，结果连了半天一直提示连接失败。第一反应是docker端口映射没生效，赶紧登录服务器执行docker ps查看容器状态，发现mysql 8.0容器的端口映射明明是0.0.0.0:16034->3306/tcp，完全正常。
这时候才反应过来：22端口是服务器的ssh端口，根本不是mysql的业务端口，属于典型的“把ssh连接信息和业务连接信息搞混”的低级失误。调整连接端口为16034之后，连通性测试立刻通过了，本以为问题解决了，结果没过几个小时，用户就反馈mysql又连不上了。

第二阶段：mysql反复崩溃的根因定位

连通性恢复后，我加了监控观察mysql的运行状态，发现它几乎是每2-3小时就会崩溃一次，重启后过几个小时又挂。登录服务器查看mysql容器的日志，发现报错信息全是内存不足，再执行dmesg | grep oom查看系统日志，果然看到多条oom killer杀死mysqld进程的记录：

out of memory: kill process 3420 (mysqld) score 999 or sacrifice child
killed process 3420 (mysqld) total-vm:1515520kb, anon-rss:512000kb, file-rss:0kb

再执行free -h查看服务器内存现状：这台火山云服务器只有2g内存，除了mysql容器占了近1g，还有十几个同名的update_news.py进程在后台运行，每个占用30-50m内存，加起来就吃掉了近600m内存，加上系统本身占用的内存，可用内存经常只剩几十m，mysql自然会被系统优先杀死。
除了内存不足的问题，我还顺手看了mysql的配置，发现默认配置也存在隐患：wait_timeout和interactive_timeout默认是28800秒（8小时），table_open_cache默认是4000，这些配置都是给大内存服务器准备的，在2g内存的机器上会占用大量不必要的内存。

第三阶段：修复方案与落地

确认根因后，我立刻做了四件事：

给mysql 8.0容器加了内存限制，启动参数加上--memory=768m --memory-swap=768m，避免容器吃光所有内存；
优化mysql配置，把wait_timeout和interactive_timeout降到300秒（5分钟），table_open_cache降到300，减少空闲连接和缓存占用的内存；
清理冗余的update_news.py进程，只保留1个运行实例，避免重复进程占用内存；
给用户提了硬件升级建议：如果业务有增长，最好把服务器内存加到4g，避免后续再出现资源不足的问题。
改完之后我观察了3天，mysql再也没有出现过崩溃的情况，用navicat连接公网ip:16034也一直稳定可用。

可带走的避坑经验

这次排查踩了好几个典型的云服务器部署坑，总结几个可以直接用的经验：

先确认端口再排查连通性：云服务器默认开22 ssh端口，业务端口（比如mysql的3306、redis的6379）都是自定义映射的，连不上先执行docker ps看端口映射，不要一上来就改配置，避免走错方向。
小内存服务器跑mysql必须做资源限制：docker启动mysql容器一定要加--memory参数限制最大内存，mysql 8.0最低建议给512m，生产环境至少1g，避免被oom killer杀死。
小内存场景要调整mysql默认配置：默认的wait_timeout=28800、table_open_cache=4000都是给8g以上内存的机器准备的，2g以下内存的服务器建议把wait_timeout降到300-600，table_open_cache降到200-400，能省出不少内存。
定时任务一定要加进程锁：很多python脚本如果没有做进程锁，会跑出大量重复实例，积少成多就会吃光内存，要么用systemd管理定时任务，要么在脚本里加文件锁避免重复运行。