13年老炮揭秘：Linux下H5开发，MySQL配置坑到哭

文章配图，仅供参考

　　我原以为，从最早那版MySQL用到现在，该踩的坑都踩透了——哪年在客户现场调慢查询的时候，为了个索引顺序熬了十三个小时，最后把两个索引换了顺序就救回来的事，我能背到滚瓜烂熟。结果去年九月这茬，直接把我那点“老炮经验”戳得稀碎：Linux下装的MySQL，H5项目跑起来就间歇性崩连，前端页面要么转圈圈到超时，要么直接弹502，连我写的debug脚本都查不出个所以然。

　　那天是周三，我把H5的Nginx配置、MySQL的my.cnf翻来覆去改了三遍，从端口到字符集，从缓存大小到连接数，能试的参数都试了，甚至把MySQL重装了两次，还是没辙。后来把负责H5前端的小杨叫到机房，让他对着屏幕模拟用户操作——他刚点完那个带列表的接口，我这边的MySQL进程直接挂了，系统日志里跳出来的东西，我他妈之前真没见过：“max_connections reached”的提示混着一行乱码似的字符，根本不是我之前碰到的那些常规报错。

　　我把运维阿凯叫过来，他攥着他那台旧笔记本，凑到我屏幕前瞅了三分钟，忽然拍大腿喊：“你之前是不是在MySQL里开了那个‘performance_schema’？我上周给另一台服务器装的时候，就因为这个跟Nginx抢端口，崩了三次！”我当时愣了，我之前用的老版本根本没这玩意儿，谁想到新版本默认开了就算了，还跟H5用的长连接串在同一端口池里？连我徒弟都插嘴说他前两天装测试环境的时候也碰到过，嫌麻烦直接关了。

　　那时候我才反应过来，好多老经验早就过时了——哪年我们还在抠MySQL的“key_buffer_size”调大小，现在换成新版本，这个参数的优先级连“table_open_cache”都不如，可我还抱着老习惯改，白耗了整整八个小时。

　　后来排查出问题的时候，我坐在那堆外卖盒里，点了根烟（机房不让抽，我偷偷来的），忽然想起之前跟别的老炮聊过，说Linux下的服务配置，从来不是靠经验混，是靠“踩一个，筛一个”的优胜劣汰。那些网上传的“标准配置”，说不定哪次更新就变了味，你再照着抄，死都不知道怎么死的。

　　我给徒弟们讲的时候，特意提了那个我忘了名字的运维，那天他帮我把MySQL的performance_schema关了，还教我用netstat -tulpn看端口占用——这事儿其实之前有文档说过，可我就是没注意，总觉得“这不是我踩过的坑”。

　　哦对，那次之后我还改了个习惯：现在装任何服务，先查“最近两周的更新日志”，不是那种大版本的更新，是那种小补丁级别的，里面藏的坑才是真要命的。

　　不过说实在的，这事也没那么绝，后来那台服务器跑了快三个月，没再崩过，除了一次阿凯误操作改了Nginx的超时时间，又触发了一次小问题——也算给我这老炮补了一课，别总觉得自己资历深，什么坑都躲得过。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!