Tikv节点使用容量忽大忽小，无法控制

[ddmasato]

Tidb版本：2.0.rc4
背景：主要目的是开启region merge功能，所以从2.0.RC1—> RC4，然后缩减region后升级到更高版本3.0-4.0，

已经合并结束，所以关闭了合并（是否需要一直开启merge?策略设置的是合并空的region），以下是pd的配置

» config show
{
  "max-snapshot-count": 3,
  "max-pending-peer-count": 0,
  "max-merge-region-size": 0,
  "max-store-down-time": "30m0s",
  "leader-schedule-limit": 32,
  "region-schedule-limit": 6,
  "replica-schedule-limit": 4,
  "merge-schedule-limit": 0,
  "tolerant-size-ratio": 2.5,
  "schedulers-v2": [
    {
      "type": "balance-region",
      "args": null
    },
    {
      "type": "balance-leader",
      "args": null
    },
    {
      "type": "hot-region",
      "args": null
    },
    {
      "type": "label",
      "args": null
    }
  ]
}

目前发现的问题：

tikv节点的容量，不稳定，升级前容量是平滑得，空间稳定，没有变动，想知道怎么去排查定位问题？

以下是截图，需要日志或者别的信息可以补充，麻烦啦~~

PD截图：

Tikv的截图：
这个能看到单个节点的大小，，波动太厉害了

下面是整体12个节点

补充：

这张图包含升级前与后tikv的走向，28号中午12点升级，1点开启merge region

[yilong (yi888long)]

1. 目前 tidb 具体小版本是多少？
2. pd-ctl 反馈下 store 信息，多谢。
3. 在8/10 12：00 时候，是否开启了 region merge？ 当时有其他节点出现问题吗？
   麻烦反馈，相同时间段 pd 和 detail-tikv 的监控。多谢。

[ddmasato]

1. Tidb的小版本，就是2.0 RC4，，，

2. 上传文件，store信息 (9.1 KB)

3. 8月10号，12点没有开启region merge，region merge在 8月9号21：00已经关闭了
   tikv的波动（12个节点中，11个节点有波动，1个平稳），是从7月28号升级以后出现的，最开始是比较小的波动，磁盘使用率可能在5%-10%的范围波动，但是最近波动的特别明显，在数据量没有增大的情况下，能有40-50%的波动

请问您说的是 8月10号12点，还是 升级当天（7月28号）12点的监控？

[yilong (yi888long)]

1. 波动猜测可能是有其他节点出问题，导致region迁移到此节点
2. 建议升级到 3.0 或者 4.0 的新版本再来一起查看问题吧， 2.0版本有些太老了。

[ddmasato]

最近涉及到数据中心的搬迁，所以打算等搬迁完成后再升级到3.0

这两天查询资料，参阅帖子与这个类似，业务无读写情况下，tikv负载仍然很高，磁盘IO也几乎达到瓶颈 - #2，来自 Kay-PingCAP
初步判断是因为region的调度导致。开启了region merge后，才出现的这个情况，但是上面的帖子是region到一定的程度后就恢复了，我的案例设置的如下参数

"max-merge-region-size": 50
"merge-schedule-limit": 6
"max-merge-region-keys":2000

目前也已经关闭。将"max-merge-region-size": 设置为0
但是region还在持续调度。。。。持续TIKV的磁盘高I/O，硬盘出问题的概率也很大，这个要怎么去优化，调整pd的设置？
目前的配置：

» config show
{
  "max-snapshot-count": 3,
  "max-pending-peer-count": 0,
  "max-merge-region-size": 0,
  "max-store-down-time": "30m0s",
  "leader-schedule-limit": 6,
  "region-schedule-limit": 6,
  "replica-schedule-limit": 4,
  "merge-schedule-limit": 6,
  "tolerant-size-ratio": 2.5,
  "schedulers-v2": [
    {
      "type": "balance-region",
      "args": null
    },
    {
      "type": "balance-leader",
      "args": null
    },
    {
      "type": "hot-region",
      "args": null
    },
    {
      "type": "label",
      "args": null
    }
  ]
}

[ddmasato]

补充一个高I/O的系统状态：

[yilong (yi888long)]

1. 从监控截图看是有些 balance leader 的调度。 反馈的 pd-ctl 中的 store 信息可以看出 leader 和 region 的数量都是基本均衡的。
   
   

2. IO 高从 top 里没有看出来，您能否查看下 iostat 的信息或者 iotop 看下具体io 情况

[ddmasato]

请问一下。。我执行了scheduler remove balance-region-scheduler 后，怎么把调度器添加回来?
add不支持这个参数。。。

[ddmasato]

按照官方的文档，本意是禁用后观察效果，再添加回来，，结果无法添加了。。

[yilong (yi888long)]

添加具体命令是什么？报什么错

[ddmasato]

以下的信息，没有这个参数

» scheduler show
[
  "balance-hot-region-scheduler",
  "label-scheduler"
]

» scheduler add balance-region-scheduler
add a scheduler

Usage:
  add [command]

Available Commands:
  evict-leader-scheduler   add a scheduler to evict leader from a store
  grant-leader-scheduler   add a scheduler to grant leader to a store
  shuffle-leader-scheduler add a scheduler to shuffle leaders between stores
  shuffle-region-scheduler add a scheduler to shuffle regions between stores

Additional help topics:

Use "help add [command] " for more information about a command.
»  

使用的版本：

[tidb@localhost ~]$ ./tidb-deploy/resources/bin/pd-ctl -V
Release Version: v2.0.0-rc.4
Git Commit Hash: e221ffb59f7b3433ee2e0a617f616dc92b02d007
Git Branch: release-2.0
UTC Build Time:  2018-03-31 06:49:39

是不是因为pd-ctl版本比较老？ 看到官方资料。pd-ctl ，3.0的版本支持add，能否用3.0的pd-ctl连接到现有集群进行操作，是否有风险。。。。

[小王同学]

@ddmasato

是不是因为pd-ctl版本比较老？ 看到官方资料。pd-ctl ，3.0的版本支持add，能否用3.0的pd-ctl连接到现有集群进行操作，是否有风险。。。。

不建议跨版本使用，版本太老了，还是建议升级吧。

[ddmasato]

嗯，等物理环境稳定了，会逐步升级，然后测试过使用pd-ctl，v3.0.16成功将删除的scheduler添加回来

[yilong (yi888long)]