如何用playground模拟tikv下线?

【 TiDB 使用环境】生产环境 /测试/ Poc
测试, 单机playground
【 TiDB 版本】

8.1.1
tiup --version
1.16.1 tiup

【复现路径】做过哪些操作出现的问题

  1. 用tiup playground 设置一个3 pd, 3 tikv的环境
    sudo tiup plyaground v8.1.1 --tag firsttest --db 2 --pd 3 --kv 3
  2. 使用pfctl 创建filter rule去阻止tikv-1给pd-0发heartbeat

【遇到的问题:问题现象及影响】

  1. tikv-1仍然能给pd发送heartbeat

【细节】

  1. pd-0 是 leader
  "leader": {
    "name": "pd-0",
    "member_id": 3474484975246189105,
    "peer_urls": [
      "http://127.0.0.1:2380"
    ],
    "client_urls": [
      "http://127.0.0.1:2379"
    ],
    "binary_version": "v8.1.1",
  },
  "etcd_leader": {
    "name": "pd-0",
    "member_id": 3474484975246189105,
    "peer_urls": [
      "http://127.0.0.1:2380"
    ],
    "client_urls": [
      "http://127.0.0.1:2379"
    ],
    "binary_version": "v8.1.1",
  }
  1. tikv-1 细节
  "store": {
    "id": 1,
    "address": "127.0.0.1:20161",
    "version": "8.1.1",
    "peer_address": "127.0.0.1:20161",
    "status_address": "127.0.0.1:20181",
    "start_timestamp": 1736194461,
    "last_heartbeat": 1736320282740911000,
    "node_state": 1,
    "state_name": "Up"
  },
  1. ps aux找到process id 并用 lsof 找到所有的connection
ps aux | grep tikv-1
user           33428   0.4  0.3 412985600  92144 s009  S+   Mon12PM  30:04.88 /.tiup/components/tikv/v8.1.1/tikv-server --addr=127.0.0.1:20161 --advertise-addr=127.0.0.1:20161 --status-addr=127.0.0.1:20181 --pd-endpoints=http://127.0.0.1:2379,http://127.0.0.1:2382,http://127.0.0.1:2384 --config=/.tiup/data/firsttest/tikv-1/tikv.toml ... (省去部分output)
lsof -i -n -P | grep 33428
tikv-serv 33428 user   18u  IPv4 0x629a0579e5999c86      0t0  TCP 127.0.0.1:20181->127.0.0.1:49222 (ESTABLISHED)
tikv-serv 33428 user   55u  IPv6 0xc9b1c270dedb1bec      0t0  TCP 127.0.0.1:20161 (LISTEN)
tikv-serv 33428 user   56u  IPv6 0x452e11a7665d5336      0t0  TCP 127.0.0.1:20161 (LISTEN)
tikv-serv 33428 user   57u  IPv6 0x48f1bfb5c9155498      0t0  TCP 127.0.0.1:20161 (LISTEN)
tikv-serv 33428 user   58u  IPv6 0x376bbcbb10ebeca8      0t0  TCP 127.0.0.1:20161 (LISTEN)
tikv-serv 33428 user   59u  IPv6 0xeeab296337f6f7fd      0t0  TCP 127.0.0.1:20161 (LISTEN)
tikv-serv 33428 user   64u  IPv4 0x91c8d6e2d83f2dea      0t0  TCP 127.0.0.1:20181 (LISTEN)
tikv-serv 33428 user   69u  IPv6 0xeeb0f9a688bd19e0      0t0  TCP 127.0.0.1:20161->127.0.0.1:51040 (ESTABLISHED)
tikv-serv 33428 user   70u  IPv6 0x4498c360963fc658      0t0  TCP 127.0.0.1:20161->127.0.0.1:51011 (ESTABLISHED)
tikv-serv 33428 user   71u  IPv6 0x3f857b732fd2d83a      0t0  TCP 127.0.0.1:20161->127.0.0.1:51044 (ESTABLISHED)
tikv-serv 33428 user   72u  IPv6 0xc4ebeabfe8984179      0t0  TCP 127.0.0.1:20161->127.0.0.1:51042 (ESTABLISHED)
tikv-serv 33428 user   73u  IPv6 0x1e34342da2a27806      0t0  TCP 127.0.0.1:20161->127.0.0.1:51073 (ESTABLISHED)
tikv-serv 33428 user   74u  IPv6 0xbda78c9566cad99d      0t0  TCP 127.0.0.1:51074->127.0.0.1:20162 (ESTABLISHED)
tikv-serv 33428 user   75u  IPv6 0x54ffb107eabfdb11      0t0  TCP 127.0.0.1:20161->127.0.0.1:51047 (ESTABLISHED)
tikv-serv 33428 user   76u  IPv6 0x69c9fa27d1819051      0t0  TCP 127.0.0.1:20161->127.0.0.1:51048 (ESTABLISHED)
tikv-serv 33428 user   77u  IPv6 0xd8b93c8691c59183      0t0  TCP 127.0.0.1:51004->127.0.0.1:20162 (ESTABLISHED)
tikv-serv 33428 user   78u  IPv6 0x4b2902bac3ed041b      0t0  TCP 127.0.0.1:51075->127.0.0.1:20160 (ESTABLISHED)
tikv-serv 33428 user   79u  IPv6 0xb93bb62a7bd84782      0t0  TCP 127.0.0.1:20161->127.0.0.1:58136 (ESTABLISHED)
tikv-serv 33428 user   80u  IPv6 0x97b4f9c124e3c08d      0t0  TCP 127.0.0.1:20161->127.0.0.1:58137 (ESTABLISHED)
tikv-serv 33428 user   81u  IPv6 0x9ce90a5d190d55be      0t0  TCP 127.0.0.1:20161->127.0.0.1:51013 (ESTABLISHED)
tikv-serv 33428 user   82u  IPv6 0x3d06e64321070d6e      0t0  TCP 127.0.0.1:20161->127.0.0.1:51035 (ESTABLISHED)
tikv-serv 33428 user   83u  IPv6 0xc6da2051c9b5676f      0t0  TCP 127.0.0.1:51000->127.0.0.1:20160 (ESTABLISHED)
tikv-serv 33428 user   84u  IPv6 0xf3b8d024c4578210      0t0  TCP 127.0.0.1:20161->127.0.0.1:51076 (ESTABLISHED)
tikv-serv 33428 user   85u  IPv6 0x884a2e0e9d5e6bc1      0t0  TCP 127.0.0.1:20161->127.0.0.1:50998 (ESTABLISHED)
tikv-serv 33428 user   86u  IPv4 0xe4888f09ea030252      0t0  TCP 127.0.0.1:20181->127.0.0.1:65178 (ESTABLISHED)
tikv-serv 33428 user   87u  IPv6 0x3e240794137fe7f1      0t0  TCP 127.0.0.1:63606->127.0.0.1:2379 (ESTABLISHED)
tikv-serv 33428 user   88u  IPv6 0xfc76d549b5e98997      0t0  TCP 127.0.0.1:20161->127.0.0.1:50999 (ESTABLISHED)
  1. 暴力地对所有的ESTABLISHED connection都加了filter rules,比如
block drop quick on lo0 inet proto tcp from 127.0.0.1 port = 63606 to 127.0.0.1 port = 2379
block drop quick on lo0 inet proto tcp from 127.0.0.1 port = 2379 to 127.0.0.1 port = 63606
block drop quick on lo0 inet6 proto tcp from ::1 port = 63606 to ::1 port = 2379
block drop quick on lo0 inet6 proto tcp from ::1 port = 2379 to ::1 port = 63606

(限于篇幅,不复制所有内容)

【描述】
我通过其他帖子学习到了tikv的状态变化,所以想在local环境下,通过模拟tikv断线,来深入学习disconnected, down,rejoin cluster这类的行为,但不知道为什么pf rule并不起作用,dashboard里面store仍然是up。我猜测要么是pf rule在这个情况下完全不起作用,要么是一些我还不了解的tikv/pd grpc 行为会自动recover,所以感知不到. 请问这里是我什么地方搞错了?
我本想看看grpc是怎么配置的,但由于对代码还不够熟悉,一时半会找不到相关的源码,如果有建议阅读的代码,也请告知

"peer_address": "127.0.0.1:20161",
"status_address": "127.0.0.1:20181",

屏蔽20161和20181这两个端口的访问就行了。

你屏蔽的是2379到一个特定端口的双向访问,到2379是对pd的请求,63606 端口不能访问2379了,换一个端口还是能访问2379的pd的。等于没影响。

1 个赞

:call_me_hand:楼上说的开启防火墙是个好办法。最好还是搭个虚拟机,实际tiup部署看一下。

1 个赞

用虚拟机吧,playground不是用来测高可用的。

1 个赞

用虚拟机试试,或许可以

2 个赞

可以尝试通过切断特定 TiKV 节点与其余集群成员之间的通信来模拟节点下线

1 个赞

你设置了 pfctlfilter rule 来阻止 tikv-1pd-0heartbeat ,但 tikv-1 仍然能够发送 heartbeat ,这可能是因为防火墙规则没有正确生效或者存在其他绕过规则的通信路径
确保你设置的 pfctl 规则语法正确,并且规则的顺序合理。有时候,规则的顺序可能会影响其生效的结果。例如,如果存在其他允许相关通信的规则在阻止规则之前,那么阻止规则可能不会生效。你可以使用 pfctl -s rules 命令来查看当前生效的规则列表,检查规则的顺序是否符合预期

1 个赞

换一个端口还是能访问2379的pd的。等于没影响

我测试了一下,你这个说法是对的。当我屏蔽63606的时候,tikv会用一个新的port去发送heartbeat。(不知道这个recovery逻辑属于tiup,还是tikv,还是grpc)。很难通过pfctl来屏蔽这类情况。

屏蔽20161和20181之后,region heartbeat没有了,但是store heartbeat仍然还在,所以就是这个dynamic port的问题导致在单机环境下,没有办法去测试这种行为。

我打算还是按照大家的建议,用vm或者docker这类去做测试吧😂 感谢🙏

1 个赞

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。