search

CodisLabs / codis

Proxy based Redis cluster solution supporting pipeline and scaling dynamically
MIT License
13.16k stars 2.69k forks source link

codis-server 实例一旦宕机，整个集群就会显示 TIMEOUT #1060

Closed zwsuo closed 7 years ago

zwsuo commented 7 years ago

你好，我遇到一个很重要的问题是，运行 codis-server 实例的服务器不能宕机，一旦宕机， FE 界面上看到的所有节点的 KEYS 那一列全都显示 “TIMEOUT”.

我描述一下我的场景：

  1. 共5台服务器，且运行都正常，可正常读写
    1. A/B 两台服务器，只运行 codis-proxy
    2. C/D/E 三台服务器，每台上面都运行 codis-server ，zookeeper
    3. codis-dashboar / codis-ha / codis-fe 三个组件在 C 服务器运行
  2. 共有三个 group ，每个 group 中3个 codis-server 实例，一主二从，如附件截图1。

现在问题是，我停掉 D 或者 E 服务器上的 codis-server 进程，可以自动切换主从，一切正常，但是只要我把 D 或者 E 服务器关机，所有的 codis-server 实例就会显示 TIMEOUT，请问这个是什么原因或者需要怎么修正这个问题？ 1 2

zwsuo commented 7 years ago

@spinlock

spinlock commented 7 years ago

TIMEOUT 说明 dashboard 对 codis-server 的 INFO 指令在 timeout 时间内没返回。所以你看看 dashboard 的 log。

另外，几个问题，zk 为什么不是单独的机器，为什么要和 codis-server 放在一起？是不是因为你把 zk 干掉了，所以 dashboard 出错了。

此外，DataCenter 字段同一个机房的话，填一样的就可以了，而不是每个机器一个。

通常我的习惯是，codis-server 和 codis-proxy 是混部的，一般 codis-proxy 占不了很多内存。

zwsuo commented 7 years ago
  1. zk down 一个，显示还有一个 leader，一个 follower，不过日志里确实有 zk 的报错：
2016/12/01 12:45:24 topom_cache.go:75: [ERROR] store: load sentinel failed
[error]: zk: could not connect to a server
    8   /usr/local/go/work/src/github.com/CodisLabs/codis/pkg/models/zk/zkclient.go:306
            github.com/CodisLabs/codis/pkg/models/zk.(*Client).Read.func1
    7   /usr/local/go/work/src/github.com/CodisLabs/codis/pkg/models/zk/zkclient.go:112
            github.com/CodisLabs/codis/pkg/models/zk.(*Client).shell
    6   /usr/local/go/work/src/github.com/CodisLabs/codis/pkg/models/zk/zkclient.go:310
            github.com/CodisLabs/codis/pkg/models/zk.(*Client).Read
    5   /usr/local/go/work/src/github.com/CodisLabs/codis/pkg/models/store.go:243
            github.com/CodisLabs/codis/pkg/models.(*Store).LoadSentinel
    4   /usr/local/go/work/src/github.com/CodisLabs/codis/pkg/topom/topom_cache.go:147
            github.com/CodisLabs/codis/pkg/topom.(*Topom).refillSentinel
    3   /usr/local/go/work/src/github.com/CodisLabs/codis/pkg/topom/topom_cache.go:74
            github.com/CodisLabs/codis/pkg/topom.(*Topom).refillCache
    2   /usr/local/go/work/src/github.com/CodisLabs/codis/pkg/topom/topom.go:250
            github.com/CodisLabs/codis/pkg/topom.(*Topom).newContext
    1   /usr/local/go/work/src/github.com/CodisLabs/codis/pkg/topom/topom_stats.go:109
            github.com/CodisLabs/codis/pkg/topom.(*Topom).RefreshProxyStats
    0   /usr/local/go/work/src/github.com/CodisLabs/codis/pkg/topom/topom.go:200
            github.com/CodisLabs/codis/pkg/topom.(*Topom).Start.func2
        ... ...
[stack]:
    3   /usr/local/go/work/src/github.com/CodisLabs/codis/pkg/topom/topom_cache.go:75
            github.com/CodisLabs/codis/pkg/topom.(*Topom).refillCache
    2   /usr/local/go/work/src/github.com/CodisLabs/codis/pkg/topom/topom.go:250
            github.com/CodisLabs/codis/pkg/topom.(*Topom).newContext
    1   /usr/local/go/work/src/github.com/CodisLabs/codis/pkg/topom/topom_stats.go:109
            github.com/CodisLabs/codis/pkg/topom.(*Topom).RefreshProxyStats
    0   /usr/local/go/work/src/github.com/CodisLabs/codis/pkg/topom/topom.go:200
            github.com/CodisLabs/codis/pkg/topom.(*Topom).Start.func2
        ... ...
2016/12/01 12:45:27 topom_api.go:46: [WARN] [0xc420142c00] API call /api/topom/group/promote/9b05f7cce0b464807ba7b810756be0d9/2/192.168.13.96:6480 from 192.168.13.96:9370 []
2016/12/01 12:45:27 topom_group.go:210: [WARN] group-[1] will promote index = %!s(MISSING)

所以，如果这样的话， zk 就是不允许 down 掉了？那么 zk 就需要3台单独的机器是吗？基本是单独的机器，那么即使 codis-server 机器3台正常运行，那么 zk 如果 down 一个的话，跟现在应该也是同样现象了吧？

  1. codis-server 和 codis-proxy 不在同一个机器是因为 proxy 如果 down 掉一个，那么 ha 功能就受影响了，在给出的文档 ”2.5.3 工作原理“ 一节中有这么一段话：
主从切换必须得到全部 proxy 确认，因此如果 proxy 异常，必然导致主从切换失败。

真实测试结果也确实如此，所以把 proxy 单独部署出去，这样 codis-server 如果 down 掉一台，还是可以保证 ha 功能的正常，可以自动切换主从。

spinlock commented 7 years ago

那是 3.0 的文档，3.1 的话，推荐用 redis-sentinel 了。这样的话，dashboard 挂了也没有关系，codis-ha 可以废弃了。

jiacrash2580 commented 7 years ago

你这fe界面是3.1的，要用sentinel，别用ha，按说zookeeper掉一个不影响

zwsuo commented 7 years ago

这个界面是 3.1 的吗？我专门 clone 的 2.0.14的代码。

zwsuo commented 7 years ago

其实，我现在最想解决的问题是 TIMEOUT 的问题，ha 或者 sentinel ，这个都可以起到自动切换主从的功能，这个现在已经可以实现了，主要是 TIMEOUT 不知道是怎么来的。

spinlock commented 7 years ago

其实，Codis2 问题挺多的。还是建议升级。回到你的问题上来，

2016/12/01 12:45:24 topom_cache.go:75: [ERROR] store: load sentinel failed
[error]: zk: could not connect to a server

这句已经说明问题了，更新 codis-server 信息流程是这样的：

  1. dashboard 获取 codis-server 列表
  2. dashboard 从 codis-server 拉取 INFO 数据，并更新自己的缓存
  3. FE 从 dashboad 获取缓存

注意一点，codis3 和 codis2 不一样的地方在于 dashboard 也缓存了 zk 的数据，就是说在不修改集群信息的情况下，dashboard 使用缓存会跳过过程 1，直接进行过程 2，也就是说，虽然此时 zk 挂了，dashboard 还是能知道有哪些 codis-server 在线的。

那么问题来了。你的 ZK 挂了，但是 codis-ha 不知道，他告诉 dashboard 去切换 主从关系，这时候 dashboard 内部逻辑是先 invalid 对 ZK 的 cache 然后做各种事儿（显然 ZK 已经挂了，所以各种操作包括 HA 切换都会失败，但是缓存已经没有了）。

此后，回到刚才，dashboard 再获取 stats 的时候，因为 cache 已经没有了，过程1 要去读 ZK 显然失败了。所以过程2 拿到的 codis-server 列表都是空的，所以过程 3 从 dashboard 拿到的缓存结果也都是空的。（没有数据在 FE 显示是 TIMEOUT，因为一般只有 TIMEOUT 才会没有数据）

spinlock commented 7 years ago

但是 Codis3.1 用 redis-sentinel 以后，ha 不经过 zk 也不经过 dashboard，那么每个 proxy 独立计算的话，就不存在单点的问题了。

spinlock commented 7 years ago

话说掉 zk 的话，你 dashboard.toml 里面 zk 地址是不是只写了一个。。。

zwsuo commented 7 years ago

不是，是写了三个地址：

[root@web-codis01-online-ali-bjc conf]# cat dashboard.toml
coordinator_name = "zookeeper"
coordinator_addr = "web-codis01-online-ali-bjc.vhouhn.com:2181,web-codis02-online-ali-bjc.vhouhn.com:2181,web-codis03-online-ali-bjc.vhouhn.com:2181"
product_name = "codis_ABC.DEF.com"
product_auth = ""
admin_addr = "0.0.0.0:18080"
[root@web-codis01-online-ali-bjc conf]#
zwsuo commented 7 years ago

感谢耐心解答，我现在使用 3.1 版本来试一下。

spinlock commented 7 years ago

能提供一下完整的 dashboard log 吗？最好是 info 的

On Thu, Dec 1, 2016 at 15:13 zwsuo notifications@github.com wrote:

不是，是写了三个地址：

[root@web-codis01-online-ali-bjc conf]# cat dashboard.toml coordinator_name = "zookeeper" coordinator_addr = "web-codis01-online-ali-bjc.vhouhn.com:2181,web-codis02-online-ali-bjc.vhouhn.com:2181,web-codis03-online-ali-bjc.vhouhn.com:2181" product_name = "codis_ABC.DEF.com" product_auth = "" admin_addr = "0.0.0.0:18080" [root@web-codis01-online-ali-bjc conf]#

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/CodisLabs/codis/issues/1060#issuecomment-264095776, or mute the thread https://github.com/notifications/unsubscribe-auth/AAsHpTDtd9CoQ83dqzagjZg0A7MkVZ0gks5rDnOPgaJpZM4LA__f .

zwsuo commented 7 years ago

我把昨天和今天的 dashboard log 打了一个包，请见附件。 dashboard.log_11.30-12.01.tar.gz

zwsuo commented 7 years ago

你好，我按你说的，把 zookeeper 也单独拿出来部署了，没有跟 codis-server 在一起，codis-server 服务器只运行 codis-server，但是单独关一台还是同样的 TIMEOUT ， 这个情况下 zk 是没有任何变化的，还是 TIMEOUT ，所以看起来不是 zk 造成的。

是 sentinel 的问题吗？我现在还是用的 codis-ha，代码是 codis3.1 ，是需要用 codis-server --sentinel 吗？

spinlock commented 7 years ago

@zwsuo 我看了一下你的 log 有点多，但是似乎看不出太多问题。wnzheng@gmail.com 我们私下讨论，然后把讨论结果贴过来吧。