gorm使用，连接db报错

[lz1988]

[mysql] 2018/03/30 11:27:22 packets.go:36: unexpected EOF
[mysql] 2018/03/30 11:27:22 connection.go:311: invalid connection
[mysql] 2018/03/30 11:42:32 packets.go:36: unexpected EOF
[mysql] 2018/03/30 11:42:32 connection.go:311: invalid connection
[mysql] 2018/03/30 12:20:17 packets.go:36: unexpected EOF
[mysql] 2018/03/30 12:20:17 connection.go:311: invalid connection
[mysql] 2018/03/30 13:02:30 packets.go:36: unexpected EOF
[mysql] 2018/03/30 13:02:30 connection.go:311: invalid connection
[mysql] 2018/03/30 13:06:19 packets.go:36: unexpected EOF

[lz1988]

packets.go

[scofier]

问题解决了么？

[hyacinthus]

我在升级了一次后也遇到了这个问题
后台日志大量出现
[mysql] 2018/06/21 23:36:51 packets.go:36: unexpected EOF
(invalid connection)

虽然重试之后就连上了

但是会有影响 一部分比例的请求会失败

不知道怎么才能保持长连接

[hyacinthus]

后来我设置了服务器参数解决了。 就是服务器单方面关闭了连接。
但是比较诡异的是之前没这个问题，在我最近升级了一次后才出现的。
也许是mysql客户端改了什么默认参数吧。

[lz1988]

目前我给的参数，问题依旧，不知道是不是gorm还需要哪里设置，或者mysql配置也需要调整
maxidleconns = 500
maxopenconns = 500
maxlifetime = 0

[lvzhihao]

应该是连接重试的逻辑代码改动过了吧，我去掉服务中间的lb就没这些问题，lb基本都不会支持长连接，超时主动断开后就出现异常eof了。之前代码会尝试重连，现在会直接报错。

---

看了下应该是mysql的驱动变更带来的影响：
go-sql-driver/mysql#657
讨论了半天也没啥个结果，有赞成也有反对的，看里程碑应该在1.5才考虑解决。

我个人看暂时只能两个方案：

db.DB().SetConnMaxLifetime(60 * time.Second) //这个时间和lb的idle超时短就行了

db.DB().SetMaxIdleConns(0) //不要使用连接池

[lz1988]

如果设置了SetConnMaxLifetime，实际的使用当中是否有效？

[lz1988]

不使用SetMaxIdleConns，那么连接池的意义就不大了。

[lvzhihao]

设置SetConnMaxLifetime是有效果的。 mawubian <notifications@github.com> 于2018年8月9日周四 下午2:08写道：

…

不使用SetMaxIdleConns，那么连接池的意义就不大了。 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/jinzhu/gorm/issues/1822#issuecomment-411647459>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAr_8A2wXPLSkCI_mSLwcI7I3uCEASjmks5uO9HdgaJpZM4TBUrR> .

[lz1988]

这个参数给了值，依旧还是会报错

[hyacinthus]

只要客户端的时间短于服务器的时间就可以的，你需要检查下服务器上是多久超时。

[lvzhihao]

你先要确认你服务端的idle超时是多少，然后设置一个比它小的值就不会有问题的。 王瑞华 <notifications@github.com> 于2018年8月16日周四 上午11:49写道：

…

只要客户端的时间短于服务器的时间就可以的，你需要检查下服务器上是多久超时。 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/jinzhu/gorm/issues/1822#issuecomment-413416693>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAr_8OZA70loNAScUJ_82rma6PelZmszks5uROvSgaJpZM4TBUrR> .

[lz1988]

设置db.DB().SetConnMaxLifetime(60 * time.Second) 时间，但是还是会提示连接丢失的情况。

[lvzhihao]

你要看你服务器的空闲超时设置多少，然后设置一个比服务器超时小的数值即可，我例子里的60秒只是个参考，具体情况要按你的生产环境来。 mawubian <notifications@github.com> 于2018年8月17日周五 下午5:41写道：

…

设置db.DB().SetConnMaxLifetime(60 * time.Second) 时间，但是还是会提示连接丢失的情况。 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/jinzhu/gorm/issues/1822#issuecomment-413813890>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAr_8LCek_3QEXCBkcPQqGo1eRONWKkpks5uRo-7gaJpZM4TBUrR> .

[lz1988]

mysql> SHOW VARIABLES LIKE '%timeout%';
+------------------------------+----------+
| Variable_name | Value |
+------------------------------+----------+
| connect_timeout | 10 |
| innodb_rollback_on_timeout | OFF |
| interactive_timeout | 28800 |
| lock_wait_timeout | 31536000 |
| net_read_timeout | 30 |
| net_write_timeout | 60 |
| wait_timeout | 28800 |
+------------------------------+----------+