修改参数后重启集群,tidb节点启动失败，提示StoreNotMatch

🪐 TiDB 技术问题
1

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：

【TiDB 版本】
v4.0.10
【问题描述】
通过｀tiup cluster edit-config cluster_name修改配置参数后，执行了tiup cluster reload cluster_name`命令，tikv和pd节点，以及其他两个tidb节点都启动成功，只有一个tidb节点一直处于down状态,节点状态如下：

ID              Role          Host      Ports        OS/Arch       Status  Data Dir                      Deploy Dir
--              ----          ----      -----        -------       ------  --------                      ----------
tidbpt41:9093   alertmanager  tidbpt41  9093/9094    linux/x86_64  Up      /tidb/tikv/alertmanager-9093  /tidb/tidb-deploy/alertmanager-9093
tidbpt41:3000   grafana       tidbpt41  3000         linux/x86_64  Up      -                             /tidb/tidb-deploy/grafana-3000
tidbpt40:2379   pd            tidbpt40  2379/2380    linux/x86_64  Up      /tidb/tikv/pd-2379            /tidb/tidb-deploy/pd-2379
tidbpt41:2379   pd            tidbpt41  2379/2380    linux/x86_64  Up|UI   /tidb/tikv/pd-2379            /tidb/tidb-deploy/pd-2379
tidbpt42:2379   pd            tidbpt42  2379/2380    linux/x86_64  Up|L    /tidb/tikv/pd-2379            /tidb/tidb-deploy/pd-2379
tidbpt41:9090   prometheus    tidbpt41  9090         linux/x86_64  Up      /tidb/tikv/prometheus-9090    /tidb/tidb-deploy/prometheus-9090
tidbpt40:4000   tidb          tidbpt40  4000/10080   linux/x86_64  Up      -                             /tidb/tidb-deploy/tidb-4000
tidbpt41:4000   tidb          tidbpt41  4000/10080   linux/x86_64  Up      -                             /tidb/tidb-deploy/tidb-4000
tidbpt42:4001   tidb          tidbpt42  4001/10081   linux/x86_64  Down    -                             /tidb/tidb-deploy/tidb-4001
tidbpt40:20160  tikv          tidbpt40  20160/20180  linux/x86_64  Up      /tidb/tikv/tikv-20160         /tidb/tidb-deploy/tikv-20160
tidbpt41:20160  tikv          tidbpt41  20160/20180  linux/x86_64  Up      /tidb/tikv/tikv-20160         /tidb/tidb-deploy/tikv-20160
tidbpt42:20160  tikv          tidbpt42  20160/20180  linux/x86_64  Up      /tidb/tikv/tikv-20160         /tidb/tidb-deploy/tikv-20160

启动提示的错误日志如下：

Error: failed to restart: tidb tidbpt42:4001, please check the instance's log(/tidb/tidb-deploy/tidb-4001/log) for more detail.: timed out waiting for port 4001 to be started after 2m0s

到对应节点查看错误日志，一直在不停提示StoreNotMatch

[2021/02/20 18:51:44.571 +08:00] [WARN] [region_request.go:578] ["tikv reports `StoreNotMatch` retry later"] [storeNotMatch="request_store_id:34210 actual_store_id:34434 "] [ctx="region ID: 16, meta: id:16 start_key:\"t\\200\\000\\000\\000\\000\\000\\000\\017\" end_key:\"t\\200\\000\\000\\000\\000\\000\\000\\021\" region_epoch:<conf_ver:8 version:8 > peers:<id:35572 store_id:34482 > peers:<id:37865 store_id:34210 > peers:<id:92442 store_id:34434 > , peer: id:37865 store_id:34210 , addr: tidbpt41:20160, idx: 1, reqStoreType: TiKvOnly, runStoreType: tikv"]
[2021/02/20 18:51:44.571 +08:00] [WARN] [region_request.go:578] ["tikv reports `StoreNotMatch` retry later"] [storeNotMatch="request_store_id:34210 actual_store_id:34434 "] [ctx="region ID: 16, meta: id:16 start_key:\"t\\200\\000\\000\\000\\000\\000\\000\\017\" end_key:\"t\\200\\000\\000\\000\\000\\000\\000\\021\" region_epoch:<conf_ver:8 version:8 > peers:<id:35572 store_id:34482 > peers:<id:37865 store_id:34210 > peers:<id:92442 store_id:34434 > , peer: id:37865 store_id:34210 , addr: tidbpt41:20160, idx: 1, reqStoreType: TiKvOnly, runStoreType: tikv"]

另外执行 info_collecting.py脚本失败，提示inventory.ini不存在，请问这个文件应该从哪里获取．

Traceback (most recent call last):
  File "info_collecting.py", line 18, in <module>
    with open('./inventory.ini', 'r') as f:
IOError: [Errno 2] No such file or directory: './inventory.ini'

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

2
  1. 修改了什么参数？除了修改参数还有什么操作？
  2. 查看下其他两个tidb日志是否有报错
  3. 查看 tikv 日志报错信息
3

修改的参数是tikv的日志级别;修改前没有做其他操作，但是几个小时模拟了过断电重启，因sync-log设置为false，所以部分数据出现异常，使用tikv-ctl修复了数据。 另外此环境一直在用dm同步生产数据。

tikv:
   log-level: warn

其他两个tidb节点的日志信息都挺正常，tikv的日志tikv-2020-20.16.log (47.3 KB)

4

另外看了下pd leader的日志，发现有如下错误信息

[2021/02/21 19:04:02.010 +08:00] [WARN] [proxy.go:181] ["fail to recv activity from remote, stay inactive and wait to next checking round"] [remote=tidbpt42:4000] [interval=2s] [error="dial tcp 172.18.102.86:4000: connect: connection refused"]
[2021/02/21 19:04:02.010 +08:00] [WARN] [proxy.go:181] ["fail to recv activity from remote, stay inactive and wait to next checking round"] [remote=tidbpt42:10081] [interval=2s] [error="dial tcp 172.18.102.86:10081: connect: connection refused"]
[2021/02/21 19:04:03.009 +08:00] [WARN] [proxy.go:181] ["fail to recv activity from remote, stay inactive and wait to next checking round"] [remote=tidbpt31:4000] [interval=2s] [error="dial tcp 172.18.102.83:4000: i/o timeout"]
[2021/02/21 19:04:03.009 +08:00] [WARN] [proxy.go:181] ["fail to recv activity from remote, stay inactive and wait to next checking round"] [remote=tidbpt31:10080] [interval=2s] [error="dial tcp 172.18.102.83:10080: i/o timeout"]

172.18.102.86这台机器的tidb节点先做过scale-in缩容操作，然后再用scale-out做了扩容，但是端口改成了4001和10081,这里pd好像还在连接4000端口;
另外172.18.102.83这台机器已经通过强制关机，scale-in --force下线了，但是这里pd节点还在尝试连接。

5
  1. tidbpt42 的 4001 端口是放通的吗？
  2. pd-ctl 检查下当前的 store 和 member 信息
6

是的，重启之前各个节点都是正常工作的，执行reload之后才发现ttidbpt42的tidb节点处于Down状态了. 之前用pd-ctl看过member的的状态是正常的，状态都是正常的，tidbpt31没在列表中，其他状态都是healthy，store的信息暂时看不到了，用的抢占式实例，节点被意外释放了:joy:．等后面复现了这个问题再补充．

7

好的，多谢。