tikv 缩容操作不当导致目前集群状态信息不一致

[是我的海]

tidb-v5.0.2
问题描述:
想要模拟单个tikv 节点故障后数据不可修复的整个操作流程。
操作流程可能不符合正常规范导致目前tikv 中能看到异常日志

集群部署信息:(5副本配置)

pd 中看到的信息为

» store --jq=".stores[].store | { id, address, state_name,labels}"
{"id":1,"address":"172.29.238.197:20160","state_name":"Up","labels":[{"key":"host","value":"tikv1-1"},{"key":"dc","value":"bjtx"},{"key":"zone","value":"z1"}]}
{"id":2,"address":"172.29.238.238:20160","state_name":"Offline","labels":[{"key":"host","value":"tikv2-1"},{"key":"dc","value":"bjtx"},{"key":"zone","value":"z2"}]}
{"id":3,"address":"172.29.238.146:20160","state_name":"Up","labels":[{"key":"host","value":"tikv1-2"},{"key":"dc","value":"bjtx"},{"key":"zone","value":"z1"}]}
{"id":35267,"address":"192.168.149.156:20160","state_name":"Up","labels":[{"key":"host","value":"tikv3-1"},{"key":"dc","value":"bjbd"},{"key":"zone","value":"z3"}]}
{"id":35268,"address":"192.168.149.155:20160","state_name":"Up","labels":[{"key":"host","value":"tikv4-1"},{"key":"dc","value":"bjbd"},{"key":"zone","value":"z4"}]}
{"id":35269,"address":"10.33.33.247:20160","state_name":"Up","labels":[{"key":"host","value":"tikv5-1"},{"key":"dc","value":"bjali"},{"key":"zone","value":"z5"}]}

模拟故障的操作步骤为:(172.29.238.238:20160 节点)
1.删除tikv数据目录&部署目录
2.手动kill 掉tikv 进程
3.在pd ctl中执行: store delete 2
已经过了一天后故障的tikv 节点一直是处于offline 的状态

» store 2
{
  "store": {
    "id": 2,
    "address": "172.29.238.238:20160",
    "state": 1,
    "labels": [
      {
        "key": "host",
        "value": "tikv2-1"
      },
      {
        "key": "dc",
        "value": "bjtx"
      },
      {
        "key": "zone",
        "value": "z2"
      }
    ],
    "version": "5.0.1",
    "status_address": "172.29.238.238:20180",
    "git_hash": "e26389a278116b2f61addfa9f15ca25ecf38bc80",
    "start_timestamp": 1625036503,
    "deploy_path": "/data/tidb/deploy/tikv-20160/bin",
    "last_heartbeat": 1625144514928999215,
    "state_name": "Offline"
  },
  "status": {
    "capacity": "0B",
    "available": "0B",
    "used_size": "0B",
    "leader_count": 0,
    "leader_weight": 1,
    "leader_score": 0,
    "leader_size": 0,
    "region_count": 2726,
    "region_weight": 1,
    "region_score": 190072,
    "region_size": 190072,
    "start_ts": "2021-06-30T15:01:43+08:00",
    "last_heartbeat_ts": "2021-07-01T21:01:54.928999215+08:00",
    "uptime": "30h0m11.928999215s"
  }
}

4.第二天发现状态未变成tombstone 。于是使用scale-in --force 删除了节点
目前集群状态display 显示正常，监控如下图
(目前只剩下scale-in 之后的监控大盘数据了。之前未观察被删除的tikv 的region count 是否在下降，不知道是因为副本调度太慢还是什么原因导致的tikv 一直处于offline 状态)

请问现在应该如何处理现在的状态，让pd 中不再显示store 2的状态

[spc_monkey (carry@pingcap.com)]

1、首先现在的状态其实并不影响集群使用，但 影响下次 同样 IP：PORT 的节点扩容（scale-in --force 后就好了）
2、由于未自动变成 tombstone 状态前，就手动关闭了 进程，所以无法走正常流程变成 tombstome 状态，可以用 scale-in --force 解决
3、至于 down peer 的问题，建议 用pd-ctl 中的 region check 命令，查看 down-peer 的 region 有哪些，并找到一个 region，查看 down peer 所在的 节点 是哪个（这个应该不是 store 2）

[是我的海]

我发帖子的时候已经是执行了scale-in --force 了 ，之后还是现实store 2 offline 的状态,并且region count 的数量并没有减少

我前几天扩容了一个tiflash 节点, 突然就好了。

查看对应时间点 pd 以及tikv 中的日志如下：
pd 中出现了移除store 2 上region 的operator

tikv 中的日志如下，之前error 的store 也被移除了

[spc_monkey (carry@pingcap.com)]

上面文字让我有点歧义，所以我先说一下我的理解吧：
1、你是指 使用 scale in --force 之后，仍看到 store 2 是 offline 的状态？
2、采用了 scale in --force 之后，pd 日志 仍有 store 2 相关的信息？

[是我的海]

1.是的。–force 之后还有store 2 的信息，>> store 2 命令还可以看到store 2有两千多的region
(好像并未生成operator 对down-peer 进行增加)
2.pd 里出现调度store 2 的信息是我前天 在增加了tiflash 节点后开始调度的。
在监控大盘看到是前天下午操作扩容节点后，down-peer 的数量才开始突然下降的 。

我这两天我再操作一个节点试一下(6个tikv 5副本 3机房，然后挂掉一个tikv 节点)
后续的操作步骤和结果我在这里追加一下。

[spc_monkey (carry@pingcap.com)]

，这个问题，可能最有用的是 pd 的日志和 tikv 的日志，这个最好提供一下

[chenwh]

我也重现了问题。

[是我的海]

@chenwh 今天重新测试了下tikv 故障的场景

1.节点信息：3个tikv 节点, 删除其中一个节点的tikv 数据(store 7)

» store --jq=".stores[].store | { id, address, state_name,labels}"
{"id":1,"address":"172.29.238.238:20192","state_name":"Up","labels":[{"key":"host","value":"tikv1"}]}
{"id":2,"address":"172.29.238.146:20192","state_name":"Up","labels":[{"key":"host","value":"tikv2"}]}
{"id":7,"address":"192.168.134.144:20192","state_name":"up","labels":[{"key":"host","value":"tikv3"}]}

2.查看pd-leader 的日志如下: 节点挂掉之后很快会进行leader 的重新选举

[2021/07/06 16:32:17.627 +08:00] [ERROR] [heartbeat_streams.go:122] ["send keepalive message fail"] [target-store-id=94] [error=EOF]
[2021/07/06 16:32:19.502 +08:00] [INFO] [cluster.go:563] ["leader changed"] [region-id=32] [from=94] [to=1]
[2021/07/06 16:32:20.503 +08:00] [INFO] [cluster.go:563] ["leader changed"] [region-id=90] [from=94] [to=1]

3.经过max-store-down-time 时间后，节点状态变成了down。但是region count 不会减少
– 此处需要注意: 如果3个tikv 节点挂掉了一个，剩下的两个tikv 节点，不能满足3副本的隔离需求，因此在tikv 节点变成down 的状态后并不会在其他节点进行副本补充。因此此时需要先进行tikv 的扩容

4.使用api 将store 状态变成tombstone( 因为 down 的节点并不会自动变成tombstone)

curl -X POST http://192.168.134.145:2409/pd/api/v1/store/94/state?state=Tombstone
pd 中日志如下
[2021/07/06 16:55:01.636 +08:00] [WARN] [cluster.go:1093] ["store update state"] [store-id=94] [new-state=Tombstone]

根据第三点的描述，此时依然不会为缺失的region 增加副本.(在监控大盘overview-pd 下也能看到相关信息)

5.扩容tikv 节点并清理Tombstone的信息.并使用–force 强制下线tikv 节点

curl -X DELETE http://192.168.134.145:2409/pd/api/v1/stores/remove-tombstone
display 还是会显示N/A 节点信息,进行强制缩容--force
tiup cluster  scale-in  tidb-oooom -N 192.168.134.144:20192  --force
强制删除后新节点的监控才显示出来。。。。。

tikv 故障场景总结：
1.当对线上tikv 节点 进行scale-in 操作时, 如果tikv 剩余节点数不能满足副本的标签隔离级别，则不会进行副本的调度，节点会一直处于offline 的状态
2.当一个tikv 节点故障时, 经过max-store-down-time 后，节点变成down 的状态。
– 如果tikv 节点数不足，则不会进行region 的副本增加
– 如果tikv 节点数足够，则会进行region 副本的增加
3.对于down 的tikv 需要使用api 将tikv 节点的状态从down 改成tombstone 并使用–force 强制下线

---

此处有个问题：
在其他帖子中看到如下描述如何删除已下线实例在information_schema中信息 - #11，来自 GangShen

请问在5.x 版本中tikv 节点异常的处理流程应该是怎样的 ？
建议能在官方文档中将tikv 节点异常的几种情况增加更多详细的说明和操作文档

[是我的海]

第一次发帖子的问题我清楚了。我在删除一个tikv 之后，剩下的tikv 节点不能满足副本的隔离需求。因此不会有增加副本的动作。
在我增加了一个新的tiflash 节点后相当于增加了一个副本，因此pd 里的故障节点信息就正常显示了。

[spc_monkey (carry@pingcap.com)]

1、上面的实验及结论是对的
2、这个结论：“在我增加了一个新的tiflash 节点后相当于增加了一个副本，因此pd 里的故障节点信息就正常显示了” ，应该是有问题的，tiflash 的角色 是 learner，这个会增加 region 但不会因为这个 导致 down peer 不下降，建议你验证一下

[是我的海]

好的。我再验证一下

[spc_monkey (carry@pingcap.com)]

好的

[Lawrence (None)]

我也遇到了这个问题，V5的tikv下线流程，官方文档写的绝对有问题

[Lawrence (None)]

我们现在扩了5个tikv，这个–force强制下线的region根本不会动，也不会被迁移，一直是卡死在offline状态，死翘翘的，这个数值从–force之后就没变过

[spc_monkey (carry@pingcap.com)]

这个肯定不符合预期的，建议找一个 具体的region，看一下 tikv 和 pd 的日志，看看为什么不能正常迁移