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

[Dbam (ein)]

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

• 【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     |
+--------+------------+-------------+--------------+

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

[Lucien-卢西恩 (路西恩)]

@ein

tidb升级3.0.12后，leader数量迁移明显，有大量notleader报错。

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

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 报错会减少至不报警。

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

[Dbam (ein)]

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

[Dbam (ein)]

[Lucien-卢西恩 (路西恩)]

@ein

region各个节点都是一致的，并且是稳步增长。

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

[Dbam (ein)]

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

[Dbam (ein)]

请问我怎么从key找到表？

[Lucien-卢西恩 (路西恩)]

@ein

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

现在提供的监控无法定位到写入慢的瓶颈，你可以尝试提供完成的 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

@ein

请问我怎么从key找到表？

需要通过 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

[Dbam (ein)]

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

[Lucien-卢西恩 (路西恩)]

@ein

tikv日志里有大量的locked primary_lock报错

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

TiDB-Map

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

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

[Dbam (ein)]

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

[yilong (yi888long)]

您好：

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

[Dbam (ein)]

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

[yilong (yi888long)]

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 插件进行截屏保存

[Dbam (ein)]

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

[yilong (yi888long)]

[问题澄清]

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

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

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

[Dbam (ein)]

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

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

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

[yilong (yi888long)]

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

https://pingcap.com/docs-cn/stable/reference/best-practices/massive-regions/#方法五开启-region-merge

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