2006 MySQL server has gone away

诱发场景：消费消息队列时在进入主消费逻辑之前就执行了一条插入mysql的数据日志（起初是为了看看消息是否已经进入了消费程序逻辑），在未走入主消费逻辑之前出现MySQL server has gone away报错。

导致出现这种报错的可能原因下面这篇文章分析的比较全面
https://www.jb51.net/article/23781.htm

我的场景中最有可能是：mysql长连接很久没有新的请求发起，达到了server端的timeout，被server强行关闭。
此后再通过这个connection发起查询的时候，就会报错server has gone away

（我的消费进程是一个常驻进程写法如下
[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 ; 确保日志目录存在且可写入
）

解决方法：
1.添加MQ成功消费之后的消费确认机制 见 https://segmentfault.com/a/1190000004924668  中的$msg->delivery_info['channel']->basic_ack($msg->delivery_info['delivery_tag']);
2.将消费程序——常驻进程改成普通命令
3.mysql日志改成文件日志