Tikv节点负载问题

为提高效率,提问时请尽量提供详细背景信息,问题描述清晰可优先响应。以下信息点请尽量提供:

  • 系统版本 & kernel 版本
  • TiDB 版本
  • 磁盘型号
  • 集群节点分布
  • 数据量 & region 数量 & 副本数
  • 问题描述(我做了什么)
  • 关键词】 操作系统:centos7.3 内核Linux 3.10.0-514.26.2.el7.x86_64 阿里云ECS 8核+16G内存+ 300G固态硬盘,网络10Gb tidb版本: v2.1.0 磁盘 ssd固态硬盘 tidb customer 2tidb+3PD+3tikv
    副本数据默认 问题描述: 当出现大量慢日志,tikv部分节点负载跑满,剩余节点负载都很正常,连接tidb数据库的程序就会出现异常和超时timeout的情况; 请问: 为什么这种情况下,tikv服务的负载不均匀呢? 另外我测试环境和准生产环境下的tidb数据库是通过docker部署的,也经常遇到过这种情况。

如果 tikv 部分节点跑满,其他 tikv 节点正常,说明存在热点问题。可以具体看下慢日志的 SQL。具体分析。

怎么查是不是热点问题,网络和防火墙肯定是没问题,都是配置好的. 规避热点问题,我在官网上看了一下,也看明白.

1)读热点排查,通过看 QPS 监控中的 kv_get 和 kv_coprocessor 对比下这三台机器,另外通过 hot read region 看下分布

2)写热点排查:通过看QPS 监控中的 kv_commit 和 kv_prewrite 对比下这三台机器,另外通过 hot write region 看下分布

QQ%E6%88%AA%E5%9B%BE20191031001321

为什么tidb数据库重启后,pd follower节点没有数据呢?另外我一共三个pd节点,grafana监控平台看到只有两个节点?如果说一个是容灾,那岂不是pd服务其实就是一个在leader节点在工作?

pd follower监控显示无数据,这个可能是监控的问题,PD 通过 Raft 协议保证数据的安全性。Raft 的 leader server 负责处理所有操作,其余的 PD server 仅用于保证高可用。

关于TiKV负载的问题,需要到TiKV-Detail面板中查看几个TiKV节点的负载情况,判断是否有热点问题

通过tikv QPS面部看到,其中一个节点的kv_get打动300 ops, 另外两个节点在1-10 ops之间,这段时间特别短,大概是2分钟,这样正常吗?

这个可能存在热点问题,可以参考热点问题定位与解决链接: