TIDB集群断网测试问题


昨晚又重新打补丁一直提示这个,上次打补丁的时候很顺利,这个报错能指导一下吗

  1. 如果是为了测试,可以用那个地址的原代码,手动 build 个 binary 跑(安装个 rust 环境, make 一下);
  2. 我看了下那个链接中没有 tikv-server 的 binary,报出来这个问题是预期行为(不报反而不正常),可以手动将 build 出来的 tikv-server 替换到 {/path/deploy-path/bin/tikv-server} 中,验证是这个问题后,再找 Kongdom 老师,向 PingCAP 提个商业交付物申请吧,或者我看交流群里有人有现成的 hotfix ,如果可以直接私下要一下:rofl:

是这个流程么?将之前连接里的替换进去就可以了么?

1 个赞
tiup cluster patch {cluster-name} tikv-server.tar.gz -R tikv --overwrite

收到。我其实是想问的那个补丁包怎么打,刚才已经在群里获取到现成的了。感谢~

昨晚打完补丁后,今天中午又重新进行了断网测试,这是提取的日志https://clinic.pingcap.com.cn/portal/#/orgs/64/clusters/6846941113233660477
还是会报Region is unavailable的错误;具体:
202节点断开,连接201,203查不出数据,有报错;
201节点断开,连接202,203查不出数据,有报错;
203节点断开,连接201,202查出数据,有报错;

目前就看 kill 一个 node 的情况(13:54~13:59):

  1. 是怎么模拟的断网测试,应该不是真正的拔网线吧(下面第一张图跟以前又不同,以前的能感知到这个 tikv 根本就没有往 prometheus 里写数据的能力了),看这个时间点 tikv 的监控数据还能写到 prometheus,且网络流量还陆续的有进进出出:laughing:。 不过 pd 确实是接不到新 pd leader 的信息了。




  2. 第二个奇怪的点,真的有全部开到 debug log level 吗?在 tiflash 确实看到了 debug 的日志,但其他组件还是没有,像 kill pd 的这种情况 不可能不打 info 日志的啊:rofl: 。 这个是 clinic 的问题吗? 真实 log 文件中应该也没有吧?

  3. 看了下能查到的测试记录,相似的几乎没有🤔,要不把测试方案发我模拟下(包括怎么模拟的断网)?(不方便可以私信发)

测试方案就是上面说的:
202节点服务器拔网线,连接201,203查不出数据,有报错;
201节点服务器拔网线,连接202,203查不出数据,有报错;
203节点服务器拔网线,连接201,202查出数据,有报错;

不过需要注意的是,每个节点上都有一套tidb、pd、tikv组件。
另外,操作不是我们在机房操作的,是机房值班人员操作的,所以具体怎么操作的不知道,要求是拔网线。断开第一个节点的时候,我也在看监控,当时监控根本看不出节点断开了,也很奇怪,但是查询数据确实是报错了。

借了几台机器,模拟了下,确实有问题,能稳定复现;
步骤如下,开启防火墙能模拟出来,稍等 内部交流下 给反馈;
我看了半天,暂时没发现啥~,感觉 PD 傻了:rofl:

tiup cluster deploy jan-szp-cluster v5.2.4 topology.toml -u root -p
tiup cluster start jan-szp-cluster

tiup cluster display jan-szp-cluster
tiup is checking updates for component cluster ...
Starting component `cluster`: /home/tidb/.tiup/components/cluster/v1.11.0/tiup-cluster display jan-szp-cluster
Cluster type:       tidb
Cluster name:       jan-szp-cluster
Cluster version:    v5.2.4
Deploy user:        tidb
SSH type:           builtin
Dashboard URL:      http://172.16.6.196:2379/dashboard
Grafana URL:        http://172.16.6.196:3000
ID                  Role          Host          Ports                            OS/Arch       Status  Data Dir                                                Deploy Dir
--                  ----          ----          -----                            -------       ------  --------                                                ----------
172.16.6.196:9093   alertmanager  172.16.6.196  9093/9094                        linux/x86_64  Up      /home/szp_tidb_cluster/jan/tidb-data/alertmanager-9093  /home/szp_tidb_cluster/jan/tidb-deploy/alertmanager-9093
172.16.6.196:3000   grafana       172.16.6.196  3000                             linux/x86_64  Up      -                                                       /home/szp_tidb_cluster/jan/tidb-deploy/grafana-3000
172.16.6.155:2379   pd            172.16.6.155  2379/2380                        linux/x86_64  Up|L    /home/szp_tidb_cluster/jan/tidb-data/pd-2379            /home/szp_tidb_cluster/jan/tidb-deploy/pd-2379
172.16.6.194:2379   pd            172.16.6.194  2379/2380                        linux/x86_64  Up      /home/szp_tidb_cluster/jan/tidb-data/pd-2379            /home/szp_tidb_cluster/jan/tidb-deploy/pd-2379
172.16.6.196:2379   pd            172.16.6.196  2379/2380                        linux/x86_64  Up|UI   /home/szp_tidb_cluster/jan/tidb-data/pd-2379            /home/szp_tidb_cluster/jan/tidb-deploy/pd-2379
172.16.6.196:9090   prometheus    172.16.6.196  9090                             linux/x86_64  Up      /home/szp_tidb_cluster/jan/tidb-data/prometheus-9090    /home/szp_tidb_cluster/jan/tidb-deploy/prometheus-9090
172.16.6.155:4000   tidb          172.16.6.155  4000/10080                       linux/x86_64  Up      -                                                       /home/szp_tidb_cluster/jan/tidb-deploy/tidb-4000
172.16.6.194:4000   tidb          172.16.6.194  4000/10080                       linux/x86_64  Up      -                                                       /home/szp_tidb_cluster/jan/tidb-deploy/tidb-4000
172.16.6.196:4000   tidb          172.16.6.196  4000/10080                       linux/x86_64  Up      -                                                       /home/szp_tidb_cluster/jan/tidb-deploy/tidb-4000
172.16.6.155:9000   tiflash       172.16.6.155  9000/8123/3930/20170/20292/8234  linux/x86_64  Up      /home/szp_tidb_cluster/jan/tidb-data/tiflash-9000       /home/szp_tidb_cluster/jan/tidb-deploy/tiflash-9000
172.16.6.194:9000   tiflash       172.16.6.194  9000/8123/3930/20170/20292/8234  linux/x86_64  Up      /home/szp_tidb_cluster/jan/tidb-data/tiflash-9000       /home/szp_tidb_cluster/jan/tidb-deploy/tiflash-9000
172.16.6.196:9000   tiflash       172.16.6.196  9000/8123/3930/20170/20292/8234  linux/x86_64  Up      /home/szp_tidb_cluster/jan/tidb-data/tiflash-9000       /home/szp_tidb_cluster/jan/tidb-deploy/tiflash-9000
172.16.6.155:20160  tikv          172.16.6.155  20160/20180                      linux/x86_64  Up      /home/szp_tidb_cluster/jan/tidb-data/tikv-20160         /home/szp_tidb_cluster/jan/tidb-deploy/tikv-20160
172.16.6.194:20160  tikv          172.16.6.194  20160/20180                      linux/x86_64  Up      /home/szp_tidb_cluster/jan/tidb-data/tikv-20160         /home/szp_tidb_cluster/jan/tidb-deploy/tikv-20160
172.16.6.196:20160  tikv          172.16.6.196  20160/20180                      linux/x86_64  Up      /home/szp_tidb_cluster/jan/tidb-data/tikv-20160         /home/szp_tidb_cluster/jan/tidb-deploy/tikv-20160

alter table test.sbtest1 set TIFLASH REPLICA 1;
alter table test.sbtest2 set TIFLASH REPLICA 1;
alter table test.sbtest3 set TIFLASH REPLICA 1;
alter table test.sbtest4 set TIFLASH REPLICA 1;
alter table test.sbtest5 set TIFLASH REPLICA 1;
alter table test.sbtest6 set TIFLASH REPLICA 1;
alter table test.sbtest7 set TIFLASH REPLICA 1;
alter table test.sbtest8 set TIFLASH REPLICA 1;
alter table test.sbtest9 set TIFLASH REPLICA 1;
alter table test.sbtest10 set TIFLASH REPLICA 1;


sysbench oltp_read_write --mysql-host=127.0.0.1 --mysql-port=4000 --mysql-db=test --mysql-user=root --mysql-password= --table_size=5000 --tables=50 prepare

mysql>SELECT * FROM information_schema.tiflash_replica;
+--------------+------------+----------+---------------+-----------------+-----------+----------+
| TABLE_SCHEMA | TABLE_NAME | TABLE_ID | REPLICA_COUNT | LOCATION_LABELS | AVAILABLE | PROGRESS |
+--------------+------------+----------+---------------+-----------------+-----------+----------+
| test         | sbtest8    |       74 |             1 |                 |         1 |        1 |
| test         | sbtest4    |       62 |             1 |                 |         1 |        1 |
| test         | sbtest7    |       71 |             1 |                 |         1 |        1 |
| test         | sbtest1    |       53 |             1 |                 |         1 |        1 |
| test         | sbtest2    |       56 |             1 |                 |         1 |        1 |
| test         | sbtest5    |       65 |             1 |                 |         1 |        1 |
| test         | sbtest3    |       59 |             1 |                 |         1 |        1 |
| test         | sbtest6    |       68 |             1 |                 |         1 |        1 |
| test         | sbtest10   |       80 |             1 |                 |         1 |        1 |
| test         | sbtest9    |       77 |             1 |                 |         1 |        1 |
+--------------+------------+----------+---------------+-----------------+-----------+----------+

+------------------------------+---------+---------+-------------------+---------------+---------------------------------------------------------------------------------------------------------------------------
| id                           | estRows | actRows | task              | access object | execution info                                                                                                            
+------------------------------+---------+---------+-------------------+---------------+---------------------------------------------------------------------------------------------------------------------------
| HashAgg_23                   | 1.00    | 1       | root              |               | time:5.52ms, loops:2, partial_worker:{wall_time:5.473661ms, concurrency:5, task_num:1, tot_wait:27.163385ms, tot_exec:4.78
| └─TableReader_25             | 1.00    | 1       | root              |               | time:5.36ms, loops:2, cop_task: {num: 1, max: 0s, proc_keys: 0, copr_cache_hit_ratio: 0.00}                               
|   └─ExchangeSender_24        | 1.00    | 1       | batchCop[tiflash] |               | tiflash_task:{time:3.78ms, loops:1, threads:1}                                                                            
|     └─HashAgg_8              | 1.00    | 1       | batchCop[tiflash] |               | tiflash_task:{time:3.78ms, loops:1, threads:1}                                                                            
|       └─TableFullScan_22     | 5000.00 | 5000    | batchCop[tiflash] | table:sbtest1 | tiflash_task:{time:3.78ms, loops:1, threads:1}                                                                            
+------------------------------+---------+---------+-------------------+---------------+---------------------------------------------------------------------------------------------------------------------------



[root@bj-az1-155 ~]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:firewalld(1)

[root@bj-az1-155 ~]# systemctl start firewalld


[root@bj-az1-155 ~]# date
Sat Oct  8 00:21:35 CST 2022

[root@bj-az1-155 ~]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
   Active: active (running) since Sat 2022-10-08 00:21:26 CST; 24s ago
     Docs: man:firewalld(1)
 Main PID: 13095 (firewalld)
   CGroup: /system.slice/firewalld.service
           └─13095 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

[root@bj-az1-155 ~]# firewall-cmd --list-ports

# 空,即:没有开放的端口
[root@bj-az1-155 ~]# 

mysql> select * from test.sbtest7;
ERROR 9012 (HY000): TiFlash server timeout
mysql> select /*+ READ_FROM_STORAGE(TIKV[sbtest7]]) */ * from test.sbtest7;
ERROR 9005 (HY000): Region is unavailable


#######################################################################
## 至此复现问题

感谢老师国庆加班测试~申请给老师加个鸡腿:meat_on_bone:~

问题一

mysql> select * from test.sbtest7;ERROR 9012 (HY000): TiFlash server timeout

因为只添加了一个 tiflash 副本,因为断网的那台机器上的 tiflash region 连不上,所以 server timeout 符合预期,想要规避这种现象,可以添加两个 tiflash 副本进行验证。

问题 二

select /*+ READ_FROM_STORAGE(TIKV[sbtest7]]) */ * from test.sbtest7;ERROR 9005 (HY000): Region is unavailable

  1. 如果删除的副本所在 leader 正好在这台断网的机器上,因为 raft 要 2-10 s 之后才会重新选主,所以那一瞬间会爆 region is unavailable. 另外还有一个问题是,这台机器断网后,如果需要选主的 region 特别多,这会儿可能会卡,但是最终都会选主 region leader, 恢复正常查询。

但是在 raft 重新选主后,就可以查到结果了,在测试机器上已经复现:

mysql> select /+ READ_FROM_STORAGE(tikv[sbtest7]) / count() from sbtest7;
±---------+
| count(
) |
±---------+
| 5000 |
±---------+
1 row in set (0.01 sec)

所以是不是等待时间太短,还没来得及选主?等个几分钟看看有没有类似的错误?

另外,需要注意的一点是, 在 leader 所在节点断网后,pd 虽然会发现,但是选主的操作是 tikv 进行的。如果遇到静默 region, 选主的操作则会等待更久。

Aunt-Shirly 老师请教了下,引发 Region is unavailable 的主要原因应该是 老师说的 raft 要 2-10 s 之后才会重新选主,看了下你这边的集群数据量好像是几十 TB(region 更多),等的时间可能更长。我的数据量较少,恢复的快些。

:handshake:感谢老师的回复

那这个问题就是和数据量、硬件有关,在数据量较大,硬件不够时,表现的特别明显?
通过哪个监控视图可以确认raft重新选主完成?

其实我们做这个测试主要是为了验证高可用,期望是无感的,但现在看来还是由于硬件资源问题,导致出现空白期。之前低版本的PD Leader切换也出现过类似情况。

Hello,因为问题前面断网我看是一会断这台,恢复,断另一台,再恢复,这种情况下分析引入条件比较多,分析起来也比较复杂,而且也不是特别贴近我们的实际应用场景。所以我们这边暂不分析。

我们只说三副本情况下,能够保证剩余幅本数 >=2 的情况(即保证多数副本可用的情况),如果忽然有一台(机房)断网了,这边主要涉及两个地方重新选主:

  1. 如果切掉的正好是 pd-leader 所在机器,则 PD 需要重新选主,这个时间大概是 15 s 左右能够完成。
  2. 对于那些 leader 在断网上的 region, 剩下的两个副本会发现自己没有 leader, 重新开始选举。其中 发现自己没有 leader 的时间大概是 2-8s, 重新选举出 leader 的时间是个概率值,内部大部分测试下来体感应该是在分钟级以内。

关于我们的监控:
确保监控服务未断网的情况下,理论上监控数据是应该能够和上述结论一致,即:

  • pd 监控上能大概 20 s 内能看到 leader 切换完成。
  • tikv 监控中 leader 相关页面未断网节点在半分钟后 leader 个数开始上涨。这些数据代表着对应 region 的选主完成。

:ok_hand:收到,感谢老师。那我们再按这个方案测试一下,某一节点断网下集群可用情况。

嗯嗯,另外特别注意的是,监控节点不要部署在断网那台机器上,会导致其他实例无法上报监控信息导致监控不准确。

好的。我们的grafana、prometheus是在另外一台单独服务器上。

老师,今天有测试了一下,断网202,还是一样的情况,部分查询报错。最奇怪的就是leader一直不变,实际中间是有断网的。断网时间内查看有一条线是中断了,联网之后就变成下面这样,又变成没有中断了。


想看一下报错表的region,结果连的还是202。

现在就坐等v5.4.3发版升级验证一下了。如果还不行,我们准备重装集群,担心是历史原因,因为这个集群是从v3.0.0升级上来的。

PS:由于人不在机房,总体给我的感觉是断网了但又没有完全断。