TiDB 3.0.2 PD leader 机器宕机后,重启异常

[2019/09/03 12:34:56.775 +08:00] [WARN] [expensivequery.go:160] [expensive_query] [cost_time=73.385333445s] [conn_id=53] [user=root] [txn_start_ts=0] [mem_max="0 Bytes"] [sql="show pump status"]
[2019/09/03 12:36:14.138 +08:00] [INFO] [client_batch.go:525] ["recycle idle connection"] [target=192.168.180.53:20160]
[2019/09/03 12:34:12.086 +08:00] [ERROR] [client_batch.go:278] ["batchRecvLoop error when receive"] [target=192.168.180.51:20160] [error="rpc error: code = Unavailable desc = transport is closing"] [stack="github.com/pingcap/tidb/store/tikv.(*batchCommandsClient).batchRecvLoop
	/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/store/tikv/client_batch.go:278"]
[2019/09/03 12:31:55.928 +08:00] [ERROR] [client_batch.go:255] ["batchRecvLoop re-create streaming fail"] [target=192.168.180.51:20160] [error="rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp 192.168.180.51:20160: i/o timeout""] [stack="github.com/pingcap/tidb/store/tikv.(*batchCommandsClient).reCreateStreamingClientOnce
	/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/store/tikv/client_batch.go:255
github.com/pingcap/tidb/store/tikv.(*batchCommandsClient).reCreateStreamingClient
	/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/store/tikv/client_batch.go:327
github.com/pingcap/tidb/store/tikv.(*batchCommandsClient).batchRecvLoop
	/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/store/tikv/client_batch.go:285"]
[

请检查一下 192.168.180.51:20160 的 tikv 日志和 tikv 服务状态是否正常,日子报错为 “show pump status” 超时,因为到 192.168.180.51:20160 访问输出 gRPC 连接失败。

TiKV 是正常的,

我做了什么

因为是测试环境,宕机以后,集群就瘫痪了, 我先做的是将leader的机器重启,恢复正常的运行状态

  1. 停掉所有的 集群 ansible-playboot stop.yml
  2. 重新启动 集群 ansible-playboot start.yml
  3. 卡住不动
  4. 关闭 binlog
  5. 重启TiDB 集群正常
  6. 开启binlog ansible-playboot start.yml --tags=pump 7.卡住不动 查看日志 如上 当我启动 pump server 的时候 过了一会儿 就会发生这个异常

解释

楼上描述的情况是预期的,因为 TiDB 开始 enable-binlog 参数至少需要 1 个 pump server 启动并可以提供正常服务的,这里我们设置的 enable-binlog 模式可以理解为事务强一致,所以两次卡住不动原因是:

  1. 第一次卡住不动是因为开启 enable-binlog 但是 pump server 没有启动;
  2. 第二次卡住不动,应该是因为 pump server 未注册到 PD 中,所以建议梳理一下 pump 操作,使用官方提供 binlogctl 确认 pump 和 drainer 状态,以及在 tidb log 中 pump 相关日志输出。

疑问:

leader 节点指的是什么 ?

不好意思,是我没说清楚,是PD leader 所在的那台机器,