tidb-server异常

[zhanglei]

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

• 【TiDB 版本】：v4.0.7
• 【问题描述】：
  
  
  
  
  
  
  集群中有一个tidb-server异常（10.120.25.2:4000节点是已经下线掉的），目前会引起无法执行ddl 操作，怎么才清除掉这个异常节点

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

[zhenjiaogao]

1、我们先梳理下信息：

1）用 tiup 工具缩容了 tidb server 10.120.25.2:4000
2）缩容后，做了集群升级从 v3.0.11 升级到 v4.0.7
3）缩容后使用 tiup cluster display 不显示被缩容的 tidb server 10.120.25.2:4000 节点，但是使用 information_schema.cluster_info 仍然可以看到被缩容的 tidb server 的信息

2、上面提到的因为这个 tidb server 缩容后仍然显示的问题导致 DDL 无法执行，建议先收集下下面的信息：

1）查看当前 ddl owner (其中 10080 端口为 tidb server status 端口)

https://github.com/pingcap/tidb/blob/master/docs/tidb_http_api.md

2）具体的 DDL 操作无法执行的表现是什么？请上传相应的 tidb server ddl owner 的日志，tidb server grafana 监控中 DDL 整版监控信息，时间段为 ddl 执行异常前后各 1 小时。

[zhanglei]

操作不是这样的，v3.0.11版本是几个月之前的，最近版本是从v4.0.6升级到v4.0.7的，是在扩缩容之前做的版本升级
{
“servers_num”: 4,
“owner_id”: “2c1200d0-665f-4428-8392-7558116ce31d”,
“all_servers_diff_versions”: [
{
“version”: “5.7.25-TiDB-v4.0.7”,
“git_hash”: “ed939f3f11599b5a38352c5c160c917df3ebf3eb”
},
{
“version”: “5.7.25-TiDB-v3.0.11”,
“git_hash”: “f51cdef1cb1927624b154f07192431ffc37b2c5f”
}
],
“all_servers_info”: {
“1764da85-bb42-43e9-86b6-35e76d77afce”: {
“version”: “5.7.25-TiDB-v4.0.7”,
“git_hash”: “ed939f3f11599b5a38352c5c160c917df3ebf3eb”,
“ddl_id”: “1764da85-bb42-43e9-86b6-35e76d77afce”,
“ip”: “10.124.46.61”,
“listening_port”: 4800,
“status_port”: 10080,
“lease”: “45s”,
“binlog_status”: “On”,
“start_timestamp”: 1602494770
},
“2c1200d0-665f-4428-8392-7558116ce31d”: {
“version”: “5.7.25-TiDB-v3.0.11”,
“git_hash”: “f51cdef1cb1927624b154f07192431ffc37b2c5f”,
“ddl_id”: “2c1200d0-665f-4428-8392-7558116ce31d”,
“ip”: “10.120.25.2”,
“listening_port”: 4000,
“status_port”: 10080,
“lease”: “45s”,
“binlog_status”: “On”,
“start_timestamp”: 0
},
“eb794d2e-1c93-4f81-8761-604a744c4fad”: {
“version”: “5.7.25-TiDB-v4.0.7”,
“git_hash”: “ed939f3f11599b5a38352c5c160c917df3ebf3eb”,
“ddl_id”: “eb794d2e-1c93-4f81-8761-604a744c4fad”,
“ip”: “10.124.46.60”,
“listening_port”: 4800,
“status_port”: 10080,
“lease”: “45s”,
“binlog_status”: “On”,
“start_timestamp”: 1602494768
},
“ef4cd59f-7d3b-4984-8891-590b0f79ef22”: {
“version”: “5.7.25-TiDB-v4.0.7”,
“git_hash”: “ed939f3f11599b5a38352c5c160c917df3ebf3eb”,
“ddl_id”: “ef4cd59f-7d3b-4984-8891-590b0f79ef22”,
“ip”: “10.124.46.62”,
“listening_port”: 4800,
“status_port”: 10080,
“lease”: “45s”,
“binlog_status”: “On”,
“start_timestamp”: 1602494773
}
}
}

[zhanglei]

目前owner是已下线的节点，执行ddl是一定不成功的，需要把这个异常owner切走

[zhenjiaogao]

1、现在看到的 DDL owner 仍然是被缩容的 10.120.25.2:4000，建议先尝试使用下面的命令，观察下能否触发下 ddl owner 新一轮的选举，然后再使用上面的命令看下选举后的 ddl owner 的信息。其中的 tidb server 为 ddl owner：

如果上述命令无法执行，那么可能需要将 etcd 中该节点的信息删除，具体命令稍等下。

2、ddl 无法执行的问题是在 10.120.25.2:4000 缩容后出现的，不是从 v4.0.6 升级到 v4.0.7 出现的吧？

3、如果是，那么 10.120.25.2:4000 缩容的操作步骤是怎样的？如果还有相应的日志，请收集下缩容的操作步骤信息，以及缩容后剩余 tidb server 的 log 信息，以及 pd log 信息。

[zhanglei]

1. curl -X POST http://10.124.46.60:10080/ddl/owner/resign
   返回"This node is not a ddl owner, can’t be resigned."
   是否需要把10.120.25.2节点加回来，才能执行该操作

2. 是缩容后出现的，缩容前没出问题，也没去关注这里的版本号不对

3. 缩容操作是正常的tiup下线节点流程（我同一个集群另外2个tidb-server，3个pd，3个tikv节点下线都没问题的）

[zhanglei]

这个是执行tiup缩容前后的命令

[zhenjiaogao]

1、当前情况将残留的 tidb server 的信息从 pd 的 etcd 清除，清除后，触发选举，使 ddl 能够恢复正常，参考命令如下：

1) 获取当前的 ddl owner 信息：
    curl http://{tidb_server_ip}:{tidb_server_status_port}/info/all

2) 使用确认当前 ddl owner 在 etcd 中的 key
     tiup ctl tidb --pdhost= --pdport= etcd ddlinfo

3）从 etcd 中删除 10.120.25.2:4000 的 key
    tiup ctl tidb --pdhost= --pdport= etcd delkey {10.120.25.2:4000 的 key}

4）确认删除状态以及查看是否选举出 ddl 新 owner
     curl http://{tidb_server_ip}:{tidb_server_status_port}/info/all
     tiup ctl tidb --pdhost= --pdport= etcd ddlinfo

https://docs.pingcap.com/zh/tidb/stable/tidb-control#etcd-命令

2、上述操作完成后，执行测试 ddl 语句，验证 ddl 执行效果。

3、出现上述问题可能是 tiup 下线 tidb server 的过程中出现了异常，该问题目前在单独查看和定位~~

[zhanglei]

感谢PingCAP小伙伴的帮助，问题顺利解决，现整理下解决思路，以供其他人参考

问题现象：
近期因业务需要，从A机房切到某云平台， 通过tiup执行扩容缩容操作，一切都很顺利，今天团队小伙伴反馈操作ddl加字段操作卡住

解决思路：

1. 通过ADMIN SHOW DDL;看到执行ddl 的owner为下线的机器ip
2. 执行"select * from information_schema.cluster_info;"看到集群中出现多个tidb-server的版本信息
3. 执行curl http://10.124.46.60:10080/info/all，确认owner是异常节点
4. 执行./tidb-ctl --pdhost=10.124.46.70 --pdport=2379 etcd delkey /tidb/ddl/fg/owner/1b8374b49c4ef8d4把异常节点切走
5. 在异常节点25.2机器查看tidb-server进程，发现tidb-server进程启动时间为3月15号，从这里得到信息：之前升级tidb版本该节点可能一直就没有成功过，该进程为僵死进程
6. 手动kill -9 杀掉有问题的异常节点tidb-server，又出现新的tidb-server被拉起，"select * from information_schema.cluster_info"查看集群信息，25.2异常节点版本号这时与其他节点保持一直为4.0.7
7. 在异常节点25.2上手动sudo systemctl stop tidb-4000.service && systemctl daemon-reload，下线成功

总结：
问题出现原因大概是之前升级tidb-server版本是有一台tidb-server没有成功，kill进程时卡死，引发owner切到问题节点，无法执行ddl操作
为避免出现类似问题，后续升级集群后通过命令查看集群各组件版本信息是否正常，若有异常手动解决

[zhenjiaogao]

感谢分享