Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

codis运行一段时间之后就会出现slot is not ready的错误,这个是什么原因 #607

Closed
chenspnjupt opened this issue Dec 30, 2015 · 19 comments

Comments

@chenspnjupt
Copy link

No description provided.

@yangzhe1991
Copy link
Member

发下具体的log吧

@chenspnjupt
Copy link
Author

2015/12/30 09:36:08 backend.go:48: [INFO] backend conn [0xc820117a40] to _:6379, stop and exit
2015/12/30 09:36:08 slots.go:77: [INFO] slot-0193 is not ready: key = shakestealCountLimit
_

2015/12/30 09:36:08 session.go:77: [INFO] session [0xc8236ece60] closed: {"ops":1,"lastop":1451439368,"create":1451439368,"remote":"
_:42976"}, error = slot is not ready, may be offline
2015/12/30 09:36:08 slots.go:77: [INFO] slot-0139 is not ready: key = currencyflowAccount
_
2015/12/30 09:36:08 session.go:77: [INFO] session [0xc838ee6af0] closed: {"ops":2,"lastop":1451439368,"create":1451439368,"remote":"_:59398"}, error = slot is not ready, may be offline
2015/12/30 09:36:08 slots.go:77: [INFO] slot-0014 is not ready: key = currencyflowAccount
_

2015/12/30 09:36:08 session.go:77: [INFO] session [0xc840294b40] closed: {"ops":7,"lastop":1451439368,"create":1451439368,"remote":"****:54565"}, error = slot is not ready, may be offline

@spinlock
Copy link
Member

其实 IP 地址没有必要隐藏的呀,除非是公网可访问?

not ready 是因为,对应的 slot 所指向的 codis-server 是错误的. 这里错误的是指,不存在或者未指定.

你去确认一下出问题的这些 slot 存在哪个 group 以及对应 group 下面的 codis-server 有哪些?

@chenspnjupt
Copy link
Author

slot肯定是存在的;我现在是通过监控,将proxy再次运行就可以了,但是有1分钟的延期;但是对于实时业务非常不利

@chenspnjupt
Copy link
Author

这个判断slot是否offline的机制是怎样的?我看下代码,谢谢!

@yangzhe1991
Copy link
Member

“slot肯定是存在的”这个结论是怎么得出的?所有的slot都分配了group吗?

@yangzhe1991
Copy link
Member

至于代码的话,log不是已经有文件名和行号了嘛。。

@spinlock
Copy link
Member

不是 slot 不存在的问题. 是对应 group 有问题. (slot 0~1023 无论分配group与否都是存在的.)

master 分支上的代码,对 group 处理的比较暴力. 正确的代码应该是 dev3.0 上的,分别如下:
https://github.com/wandoulabs/codis/blob/master/pkg/proxy/router/router.go#L151
https://github.com/wandoulabs/codis/blob/dev3.0/pkg/proxy/router/router.go#L151

只要访问的时候.对应 bc 不存在,就算 not ready:
https://github.com/wandoulabs/codis/blob/master/pkg/proxy/router/slots.go#L78

另外,其实你可以自己 grep 代码的.

@chenspnjupt
Copy link
Author

已经在现网使用了,那肯定存在了; 好吧,谢谢提醒,我研究下

@chenspnjupt
Copy link
Author

应该找到原因了,应该是这里:
c, err := s.listener.Accept()
if err != nil {
return
} else {
ch <- c
}
如果accept失败,那么server会退出;进而router、slot都会被close掉;导致整个proxy退出;
应该可以打印告警,反正客户端会进行重连

@spinlock
Copy link
Member

这个地方是问题,但是不会导致 slot not ready。

这个地方正确的 fix 是 https://github.com/wandoulabs/codis/blob/dev3.0/pkg/proxy/proxy.go#L314 ,但是奇怪忘记改 master 了。。。抱歉~

谢谢!!

@spinlock
Copy link
Member

不对,你说的对。这个时候 router 退出了,导致退出前 reset 所有 slot,所以会看到 slot not ready。

这是个问题。尽快 fix 一下。

谢谢!

@chenspnjupt
Copy link
Author

哦,如果slot被close掉,那会调用reset,bc置为nil;在slot中判断为nil就会报slot not ready的错误

@spinlock
Copy link
Member

是这样的。

虽然不accept 新连接,但是旧连接指令路由过来的话,就会遇到已经 reset 过的 slot,会导致这个现象。

总之,是 accept 的问题。PS. 我以为我们之前 fix 了的。抱歉,master 分支上给忘了。。

@yangzhe1991
Copy link
Member

感谢@chenspnjupt ,现在加上了一个handle error的逻辑。如果不是go定义的“临时错误”还会退出。

但是按照目前的退出逻辑,proxy会将自己标记为offline,并最终退出进程的,莫非你当时遇到这个问题后会一直报错、proxy不退?

@chenspnjupt
Copy link
Author

会退出的,但是会对业务造成一小段时间的影响

@yangzhe1991
Copy link
Member

这个应该也没啥办法,因为accept出问题的时候,通常网络也是有问题的,尤其是加上区分不同error的逻辑后,退出的概率就更小了。还有就是在client端加上重试和重连的逻辑,请求遇到错误就扔掉这个连接重新连,加上用jodis或其他方式监听zk上可用的proxy列表,会比较安全。

@chenspnjupt
Copy link
Author

是的,在accept失败后进行计数, 如果只是偶尔几次,那就打印出错原因,但是不退出;当前的客户端会重新连接;感谢回复

@spinlock
Copy link
Member

应该不必担心了,其实这么处理已经足够了。

因为 fix 过程,参考了 go runtime 源码里 http server 对 accept 的过程的处理。相信应该是足够了的。
https://golang.org/src/net/http/server.go L 1898

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants