从5.1.1原地升级到6.1.1后bug-11217未解决

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
5.7.25-TiDB-v6.1.1 TiDB Server (Apache License 2.0) Community Edition, MySQL 5.7 compatible

【概述】 场景 + 问题概述

【背景】 做过哪些操作
analyze table test
【现象】 业务和数据库现象

【问题】 当前遇到的问题
健康度85,表实际行数大概是3700万,看了下和https://asktug.com/t/topic/932932/3一致,为了解决这个问题集群从5.1.1升级到6.1.1,但是目前看原地升级的集群似乎还是存在这个问题。

±-------------------------±---------------±---------------±--------+
| Db_name | Table_name | Partition_name | Healthy |
±-------------------------±---------------±---------------±--------+
| testdb | test | | 85 |
±-------------------------±---------------±---------------±--------+

mysql> show stats_meta where table_name like ‘test’;
±-------------------------±---------------±---------------±--------------------±-------------±----------+
| Db_name | Table_name | Partition_name | Update_time | Modify_count | Row_count |
±-------------------------±---------------±---------------±--------------------±-------------±----------+
| testdb | test | | 2022-10-24 11:42:27 | 5392072 | 36269116 |
±-------------------------±---------------±---------------±--------------------±-------------±----------+

| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
±--------------------------±--------±---------±----------±------------------------------------------------------------------------±-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------±------------------------------------------------±--------±-----+
| StreamAgg_12 | 1.00 | 1 | root | | time:6.59s, loops:2 | funcs:count(1)->Column#82 | 8.38 KB | N/A |
| └─IndexReader_22 | 0.00 | 31162911 | root | | time:5.69s, loops:30601, cop_task: {num: 97, max: 2.95s, min: 67.5ms, avg: 885.8ms, p95: 2.4s, max_proc_keys: 1259990, p95_proc_keys: 1092213, tot_proc: 1m10s, tot_wait: 11.8s, rpc_num: 97, rpc_time: 1m25.9s, copr_cache_hit_ratio: 0.08} | index:IndexRangeScan_21 | 23.8 MB | N/A |
| └─IndexRangeScan_21 | 0.00 | 31162911 | cop[tikv] | table:t_hotel_source, index:ix_source_timestamp_12(source_timestamp_12) | tikv_task:{proc max:1.44s, min:223ms, p80:722ms, p95:1.1s, iters:30660, tasks:97}, scan_detail: {total_process_keys: 28869904, total_process_keys_size: 1328015584, total_keys: 72875098, rocksdb: {delete_skipped_count: 299421, key_skipped_count: 73168688, block: {cache_hit_count: 15074, read_count: 29515, read_byte: 757.1 MB}}} | range:(1666407599,1666580400), keep order:false | N/A | N/A |

【业务影响】

【TiDB 版本】
6.1.1
【应用软件及版本】

【附件】 相关日志及配置信息

  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息

监控(https://metricstool.pingcap.com/)

  • TiDB-Overview Grafana监控
  • TiDB Grafana 监控
  • TiKV Grafana 监控
  • PD Grafana 监控
  • 对应模块日志(包含问题前后 1 小时日志)

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

升级后, GC 也不工作么?

GC是一直work的,目前设置了gc life time =60m,并且safe point也正常推进,但是1小时内表上的修改量肯定没有那么大的。

在观察下看看~