调整max-store-down-time不生效

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:

【概述】
通过pd-ctl修改max-store-down-time为24小时
» config set max-store-down-time 24h
Success!

» config show max-store-down-time
{
“replication”: {
“enable-placement-rules”: “true”,
“location-labels”: “dc,host”,
“max-replicas”: 3,
“strictly-match-label”: “false”
},
“schedule”: {
“enable-cross-table-merge”: “false”,
“enable-debug-metrics”: “false”,
“enable-location-replacement”: “true”,
“enable-make-up-replica”: “true”,
“enable-one-way-merge”: “false”,
“enable-remove-down-replica”: “true”,
“enable-remove-extra-replica”: “true”,
“enable-replace-offline-replica”: “true”,
“high-space-ratio”: 0.7,
“hot-region-cache-hits-threshold”: 3,
“hot-region-schedule-limit”: 4,
“leader-schedule-limit”: 25,
“leader-schedule-policy”: “count”,
“low-space-ratio”: 0.8,
“max-merge-region-keys”: 200000,
“max-merge-region-size”: 20,
“max-pending-peer-count”: 16,
“max-snapshot-count”: 3,
"max-store-down-time": “24h0m0s”,
“merge-schedule-limit”: 8,
“patrol-region-interval”: “100ms”,
“region-schedule-limit”: 25,
“replica-schedule-limit”: 64,
“scheduler-max-waiting-operator”: 5,
“split-merge-interval”: “1h0m0s”,
“store-limit-mode”: “manual”,
“tolerant-size-ratio”: 0
}
}

查看修改后的参数,为24小时
mysql> show config where name=‘schedule.max-store-down-time’;
±-----±-----------------±-----------------------------±--------+
| Type | Instance | Name | Value |
±-----±-----------------±-----------------------------±--------+
| pd | xx.xx.xx.xx:2379 | schedule.max-store-down-time | 24h0m0s |
| pd | xx.xx.xx.xx:2379 | schedule.max-store-down-time | 24h0m0s |
| pd | xx.xx.xx.xx:2379 | schedule.max-store-down-time | 24h0m0s |
±-----±-----------------±-----------------------------±--------+
3 rows in set, 24 warnings (0.00 sec)

但是edit-config里面,没有发现该参数
pd:
replication.enable-placement-rules: true
replication.location-labels:
- dc
- host
schedule.leader-schedule-limit: 4
schedule.region-schedule-limit: 2048
schedule.replica-schedule-limit: 64
tiflash: {}
tiflash-learner: {}

并且pd.log里面还是默认的30分钟(集群已经重启过了)
“max-store-down-time”:"30m0s

请问这个参数到底修改成功了吗?

【背景】做过哪些操作

【现象】业务和数据库现象

【业务影响】

【TiDB 版本】

【附件】

  1. TiUP Cluster Display 信息

  2. TiUP Cluster Edit Config 信息

  3. TiDB- Overview 监控

  • 对应模块日志(包含问题前后1小时日志)

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

1 个赞

尝试使用这种方式修改配置试试
https://docs.pingcap.com/zh/tidb/stable/maintain-tidb-using-tiup#修改配置参数

这种方式,直接修改配置文件需要重启集群吗?还是重启pd-server节点?

为什么通过set config命令或者pd-ctl修改后不能生效呢?

我通过edit-config修改了,然后把pd server重启了,现在edit-config里面是能看到了,但是查看参数值,发现如下问题:
如果我edit-config修改为25个小时,重启pd以后,通过pd-ctl或者show config where name='schedule.max-store-down-time’命令查看,还是原来我通过config set设置的24小时。

修改之后进行reload了么? tiup修改的应该是中控机的toml,如果想修改某个pd的,可以在pd节点上修改toml然后重启这个节点,就会读取节点配置,而不使用中控机的集群配置。

重新reload了。
我在中控机上执行的是tiup cluster edit-config cluster_name命令,这个修改的不是集群的配置吗?我没有手工修改toml文件。

我查看pd节点服务器上的pd.toml文件是25h。我看pd.log里面的welcome信息里面也是25h。
但是通过pd-ctl和show config看到的还是我原来的24h

是的,这个修改的是集群的配置

:thinking:还真没遇到这种情况,是否是有延迟~

不知道啊。这是啥情况呢。而且我看官网上,这个参数还是在线可配置的。

请问这个问题应该怎么处理呢?

通过tiup修改并reload之后,就是修改成功了。可以晚点再验证一下在show config中有没有生效

我是不是把pd-server节点进行reload就可以了。不需要把这个tidb集群都reload,我理解的没错吧?

是的。刚沟通了一下,pd-ctl是修改的内存配置,edit-config修改的是启动配置。这两者还是有区别的

1、那就是通过pd-ctl修改后,那这个 max-store-down-time参数对集群来说是不是也就是生效了,比如我一个tikv节点服务器维护,只要不超过max-store-down-time配置的数值,就不会发生region的补齐动作?

2、edit-config修改是为了参数的永久生效。

我如上理解没问题吧?

没问题。
另外确认了一下,由于pd 的参数很多初始化已经写入到 pd 里面了, 如果再修改只能通过 pd-ctl ,不能通过 edit config,所以还是建议通过pd-ctl进行设置,pd-ctl修改是持久化的,重启集群不会重置。

有点晕了,就拿我这个 max-store-down-time参数来说,我是通过edit-config来修改呢还是通过pd-ctl修改呢?

使用pd-ctl修改就可以,config看的是启动配置文件,pd-ctl修改的内存配置(存储在etcd)。

但是我通过pd-ctl修改后,为啥edit-confing里面没有呢?而且我在pd.log的welcome信息里面也没有看到新调整的参数,还都是默认的30m。

config看的是启动配置文件,pd-ctl修改的内存配置(存储在etcd)。