誘發場景:消費消息隊列時在進入主消費邏輯以前就執行了一條插入mysql的數據日誌(起初是爲了看看消息是否已經進入了消費程序邏輯),在未走入主消費邏輯以前出現MySQL server has gone away報錯。php
致使出現這種報錯的可能緣由下面這篇文章分析的比較全面
https://www.jb51.net/article/23781.htmmysql
個人場景中最有多是:mysql長鏈接好久沒有新的請求發起,達到了server端的timeout,被server強行關閉。
此後再經過這個connection發起查詢的時候,就會報錯server has gone awaynginx
(個人消費進程是一個常駐進程寫法以下
[muread@ucloud-test-ics-3 config.d]$ cat repair-allocation-consume.ini
[program:repair-allocation-consume]
command = nohup /usr/bin/php /data/nginx/wms/yii cron/repair-allocation-consume >> /var/log/superLog/repair-allocation-consume.log 2>&1 & ; 啓動命令,能夠看出與手動在命令行啓動的命令是同樣的
autostart = true ; 在 supervisord 啓動的時候也自動啓動
user=root ; 運行用戶
numprocs=1 ; 進程數量
autorestart = true ; 程序異常退出後自動重啓
startretries = 2 ; 啓動失敗自動重試次數,默認是 3
redirect_stderr = true ; 把 stderr 重定向到 stdout,默認 false
stdout_logfile_maxbytes = 20MB ; stdout 日誌文件大小,默認 50MB
stdout_logfile_backups = 20 ; stdout 日誌文件備份數
stdout_logfile = /var/log/superLog/repair-allocation-consume.log ; 確保日誌目錄存在且可寫入
)sql
解決方法:
1.添加MQ成功消費以後的消費確認機制 見 https://segmentfault.com/a/1190000004924668 中的$msg->delivery_info['channel']->basic_ack($msg->delivery_info['delivery_tag']);
2.將消費程序——常駐進程改爲普通命令
3.mysql日誌改爲文件日誌segmentfault