tidb升级3.0.12后,leader迁移明显,有大量notleader报错,写入也很慢

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】:3.0.12
  • 【问题描述】: tidb升级3.0.12后,leader数量迁移明显,有大量notleader报错。

{‘tidb_log_dir’: ‘{{ deploy_dir }}/log’, ‘dummy’: None, ‘tidb_port’: 4000, ‘tidb_status_port’: 10080, ‘tidb_cert_dir’: ‘{{ deploy_dir }}/conf/ssl’}

系统信息
+---------------------+-----------------------+
|         Host        |        Release        |
+---------------------+-----------------------+
|    tidb-online-pd   | 3.10.0-862.el7.x86_64 |
| tidb-online-tidb-01 | 3.10.0-862.el7.x86_64 |
| tidb-online-tidb-02 | 3.10.0-862.el7.x86_64 |
| tidb-online-tikv-01 | 3.10.0-862.el7.x86_64 |
| tidb-online-tikv-02 | 3.10.0-862.el7.x86_64 |
| tidb-online-tikv-03 | 3.10.0-862.el7.x86_64 |
|      i-1luxw7bi     | 3.10.0-862.el7.x86_64 |
|      i-dvw3wqe7     | 3.10.0-862.el7.x86_64 |
|      i-now7d8gg     | 3.10.0-862.el7.x86_64 |
+---------------------+-----------------------+
TiDB 集群信息
+---------------------+--------------+------+----+------+
|     TiDB_version    | Clu_replicas | TiDB | PD | TiKV |
+---------------------+--------------+------+----+------+
| 5.7.25-TiDB-v3.0.12 |      3       |  3   | 3  |  3   |
+---------------------+--------------+------+----+------+
集群节点信息
+------------+-------------+
|  Node_IP   | Server_info |
+------------+-------------+
| instance_6 |      pd     |
| instance_7 |      pd     |
| instance_0 |     tikv    |
| instance_1 |     tidb    |
| instance_2 |     tidb    |
| instance_3 |     tidb    |
| instance_8 |      pd     |
| instance_4 |     tikv    |
| instance_5 |     tikv    |
+------------+-------------+
容量 & region 数量
+---------------------+-----------------+--------------+
| Storage_capacity_GB | Storage_uesd_GB | Region_count |
+---------------------+-----------------+--------------+
|       6899.65       |     4231.30     |    445917    |
+---------------------+-----------------+--------------+
QPS
+---------+----------------+-----------------+
| Clu_QPS | Duration_99_MS | Duration_999_MS |
+---------+----------------+-----------------+
|  338.24 |    47131.31    |    283028.14    |
+---------+----------------+-----------------+
热点 region 信息
+---------+----------+-----------+
|  Store  | Hot_read | Hot_write |
+---------+----------+-----------+
| store-1 |    0     |     7     |
| store-5 |    0     |     5     |
| store-4 |    0     |     7     |
+---------+----------+-----------+
磁盘延迟信息
+--------+------------+-------------+--------------+
| Device |  Instance  | Read_lat_MS | Write_lat_MS |
+--------+------------+-------------+--------------+
|  dm-0  | instance_3 |     nan     |     1.58     |
|  dm-0  | instance_2 |     nan     |     7.23     |
|  dm-0  | instance_1 |     nan     |     nan      |
|  dm-0  | instance_0 |     0.43    |     0.76     |
|  dm-0  | instance_5 |     0.46    |     3.59     |
|  dm-0  | instance_4 |     0.97    |     0.64     |
|  dm-0  | instance_6 |     nan     |     0.28     |
|  dm-0  | instance_7 |     nan     |     0.31     |
|  dm-0  | instance_8 |     nan     |     0.40     |
|  vda   | instance_3 |     nan     |     0.28     |
|  vda   | instance_2 |     nan     |     nan      |
|  vda   | instance_1 |     nan     |     nan      |
|  vda   | instance_0 |     nan     |     nan      |
|  vda   | instance_5 |     nan     |     nan      |
|  vda   | instance_4 |     nan     |     nan      |
|  vda   | instance_6 |     nan     |     nan      |
|  vda   | instance_7 |     nan     |     nan      |
|  vda   | instance_8 |     nan     |     nan      |
|  vdb   | instance_3 |     nan     |     nan      |
|  vdb   | instance_2 |     nan     |     nan      |
|  vdb   | instance_1 |     nan     |     nan      |
|  vdb   | instance_0 |     nan     |     nan      |
|  vdb   | instance_5 |     nan     |     nan      |
|  vdb   | instance_4 |     nan     |     nan      |
|  vdb   | instance_6 |     nan     |     nan      |
|  vdb   | instance_7 |     nan     |     nan      |
|  vdb   | instance_8 |     nan     |     nan      |
|  vdc   | instance_3 |     nan     |     1.58     |
|  vdc   | instance_2 |     nan     |     nan      |
|  vdc   | instance_1 |     nan     |     nan      |
|  vdc   | instance_0 |     0.39    |     0.13     |
|  vdc   | instance_5 |     0.36    |     0.13     |
|  vdc   | instance_4 |     0.39    |     0.20     |
|  vdc   | instance_6 |     nan     |     0.26     |
|  vdc   | instance_7 |     nan     |     0.29     |
|  vdc   | instance_8 |     nan     |     0.42     |
|  vdd   | instance_2 |     nan     |     7.23     |
|  vdd   | instance_0 |     0.30    |     0.19     |
|  vdd   | instance_5 |     0.34    |     0.19     |
|  vdd   | instance_4 |     1.35    |     0.14     |
|  vde   | instance_0 |     0.44    |     0.09     |
|  vde   | instance_5 |     0.44    |     0.09     |
|  vde   | instance_4 |     0.86    |     0.22     |
|  vdf   | instance_0 |     0.39    |     0.19     |
|  vdf   | instance_5 |     0.36    |     0.19     |
|  vdf   | instance_4 |     0.99    |     0.10     |
|  vdg   | instance_0 |     0.52    |     0.64     |
|  vdg   | instance_5 |     0.58    |     3.64     |
|  vdg   | instance_4 |     0.94    |     0.49     |
+--------+------------+-------------+--------------+

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

有几个问题需要确认一下:

  1. 从哪个版本升级上来的? 前后的集群配置一致么 ?
  2. 看一下监控的 region count 监控,确认一下 region 情况?

根据目前的情况看,如果是从 v2.1 或者 v2.0 升级到 v3.0 可能 region 在开始一段时间,会进行大量的 region merge 操作(v3.0 版本为提高 region 的读取性能,会将小 region 和 空 region 进行一定的 merge 操作,前期工作量会很大),这个操作会导致部分 noleader 报错。这个会随着 region count 的减少,region 的空 region 和 小 region 的数量减少, noleader 报错会减少至不报警。

风险提示:该告警对业务影响影响较低,建议持续关注一下。

从3.0.0-beta.1升上来的,配置都一样。 region各个节点都是一致的,并且是稳步增长。

  1. 那这个应该是预期的 split region 导致的 noleader。
  2. 按照现有的容量和 region count 换算,avg_region_size 大概 9.7 MB,这个非常低,说明有有大量的 空 region 和 小 region 存在。这个会影响到你的查询效率,可以等PD 的 region merge 执行一段时间再观察一下 region count 是否减少,读性能有所改善。。

现在是写入很慢,但是系统资源使用率都不高

请问我怎么从key找到表?

现在提供的监控无法定位到写入慢的瓶颈,你可以尝试提供完成的 TiDB 监控让我们进行分析。导出监控为 pdf 的方式:

1)使用 chrome 浏览器,安装“Full Page Screen Capture”插件: https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl

2)展开grafana 监控的 “cluster-name-overview” 的所有 dashboard (先按 d 再按 E 可将所有 Rows 的 Panels 打开,需等待一段时间待页面加载完成)

3)使用插件导出 pdf

需要通过 TiDB API 来查询 Get MVCC Information of the key with a specified handle ID https://github.com/pingcap/tidb/lob/v3.0.12/docs/tidb_http_api.md

tidb日志里有大量的invalidate current region, because others failed on same store报错; tikv日志里有大量的locked primary_lock报错; 请问这种情况一般是什么引起的呢?

业务事务的读写冲突导致的,可以看一下 tidb-map 和 tidb-in-action 中介绍 。

TiDB-Map https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-map.md#72-tikv

TiDB-in-Action 有一些案例可以参考一下 https://book.tidb.io/session4/chapter6/avoid-optimistic-lock-conflicts.html

Asktug 相关案例 https://asktug.com/t/topic/33205/4

这个和本身的事务处理有关,可以考虑将多个自动提交的事务放在一个事务处理,减少两阶段提交带来的影响。

为什么leader会发生迁移,是因为热点吗?能不能不让leader迁移?

您好:

    1. leader不均衡为了平摊压力要均衡是合理的操作
    2. 我们先聚焦在你写入慢的问题上,请按照上面的要求上传一段时间,你觉得慢的监控信息over-view,tidb, tikv 和disk-performance。 另外,正常的写入时间是多少?
    3. 请问你的机器配置是什么?是在物理机还是虚拟机上
    4. 上传下inventory.ini文件,方便查看拓扑信息

问题是leader已经达到每个节点一样之后,还是会出现大量的leader迁移,这是怎么回事呀? 机器配置pd是虚拟机 8核8g,tikv是物理机32核256g,机器资源是没有瓶颈的。 inventory.ini (2.0 KB)

  1. leader迁移是因为在不断的写入数据,你的数据量在增加,leader数也在变化,所以会不断动态变化
  2. 现在要解决写入慢的问题不是吗? 重点来看为什么写入慢,所以请反馈下需要的监控信息? over-view , tidb,detail-tikv,disk-performance (1)、chrome 安装这个插件https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl

(2)、鼠标焦点置于 Dashboard 上,按 ?可显示所有快捷键,先按 d 再按 E 可将所有 Rows 的 Panels 打开,需等待一段时间待页面加载完成。

(3)、使用这个 full-page-screen-capture 插件进行截屏保存

这是over-view , tidb,detail-tikv,disk-performance 的监控,谢谢。

[问题澄清]

TiDB集群版本: 3.0.12

问题描述: leader数量迁移明显,有大量not leader报错。 写入慢。

[问题分析]

  1. 查看overview 监控的duration,时长接近10几分钟
  2. 查看tikv grpc duration信息,时长在4分钟
  3. 查看写入流程duration
  4. 从上面可以看出append log 和apply log 不算非常慢,这里的时间都在proposal wait,所以是raft store的问题,查看raft store cpu信息,可以看到都达到了180%,打满了
  5. 查看region 信息,每个store有15万的region,这个数量已经非常多了
  6. 查看cpu使用情况

[下步计划]

  1. 修改store-pool-size
  • 处理 raft 的线程池线程数。
  • 默认值:2
  • 最小值:大于 0

[raftstore]的 store-pool-size 由2改成4

2 开启静默region 完成

用于减少 raftstore CPU 的消耗

将 raftstore.hibernate-regions 配置为 true

  1. 1和2 参数修改在中控机/conf目录的tikv.yaml文件中修改后,滚动重启tikv,在业务低峰期操作。 ansible-playbook rolling_update.yml -t tikv

  2. 上报not leader可能也是由于raftstore太繁忙,导致通信出现问题. 出现not leader的情况.

1赞

非常感谢您的回复,我会去做相应的修改!

我还有个两个疑惑: 第一个是当前的region虽然多,但一个region的平均数据量却很小,只有7MB多一点,是不是把region数量减少会减轻系统的负载?有什么方法可以合并region呢?我之前把 max-merge-region-size改成64好像也没什么作用。

第二个是我听一同事说,好像一个tikv实例能管理的数据量是有一个上限的,超过了就会出现瓶颈。我的理解是不是本质上还是和tikv实例的具体配置有关,如果数据量让一个实例的处理出现了瓶颈,可以通过增加tikv实例节点去减少每个实例的数据量来解决,也可以通过修改配置去增加实例对系统资源的利用来解决(前提是硬件资源本身是够的),比如上面的store-pool-size。不知道我的理解对不对? 期望您能解答我的疑惑,非常感谢。

  1. 你可以参考文档看下是否开启了region merge, 注意:如果namespace-classifier = table,是不会合并的. 具体参考这个文章,以及提及的文章。

  1. 是的单台tikv上的region数量不宜过多。可以扩容tikv实例。 修改参数不一定每种情况都有用。
1赞