chutian52
chutian52
@flike
sys.log输出如下 ``` 2018/10/15 12:00:57 - INFO - main.go:[144] - [main] "main" "Ignore broken pipe signal" "" conn_id=0 ```
@flike 对Go版本有什么要求没？
基本上是操作一段时间后，然后停止相关操作。这次复现是昨天晚上7点左右不再操作，然后今天上午8点30左右再操作，就出现了上述问题。当时最后的操作是set autocommit=0后不再有其他操作。 需要确定问题是由于闲置或者是设置参数的问题。
我昨晚只操作了set autocommit=0，然后强制关掉了连接。我再试试看，目前使用的是master拉下来的最新代码
@flike 今天过来看到的情况依然是不可以连接。但是可以通过控制max_conns_limit情况下，模拟出另外一个连接被阻塞的场景 ``` max_conns_limit : 1 ``` 现在出现的现象是，如果开启了一个事务，并没有被正确关闭。可能就导致下一个连接出现错误。主要体现在 ``` 2018-10-17 09:47:50.272 INFO 2302 --- [ost-startStop-1] o.s.web.context.ContextLoader : Root WebApplicationContext: initialization completed in 699 ms 2018-10-17 09:47:50.347 INFO 2302 --- [ost-startStop-1]...
上述的现象只有在每次连接的时候才会出现，但也不是每次都会出现。一旦释放了，就不会再出现上述问题了。只有在重启的时候回出现这个问题。
差不多等待时间需要5分钟左右
@flike 连接被夯住的现象复现了。 基本操作如下 步骤一、重启kingshard，执行如下命令 ``` $mysql -uroot -proot -hlocalhost -P9696 mysql> show databases(); mysql> use starter_shopping_cart; mysql> set autocommit=0; mysql> select * from shopping_cart; ``` 强制退出 二、重启slave节点 三、重新使用`mysql -uroot -proot...
我查了下资料，SIGPIPE是由于服务端断开了连接，但是客户端依然使用断开的连接发送数据，具体连接参考https://www.cnblogs.com/lit10050528/p/5116566.html 我个人推测，是否是由于连接池里面的连接本身没有释放的问题？ 我在sys.log里面看到了如下的日志 ``` 2018/10/17 15:00:15 - ERROR - node.go:[141] - [Node] "checkSlave" "Ping" "db.Addr=localhost:3306|error=connection was bad" conn_id=0 ``` 另外对于隔夜就出现无法连接的情况，我发现mysql-server本身是有一个wait_timeout参数的。具体如下 ``` mysql> select @@wait_timeout; +----------------+ | @@wait_timeout | +----------------+ |...