请问PD 是否支持 Instance Level的Max Store Down Time

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】7.1.0
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
根据文档
https://docs.pingcap.com/tidb/stable/pd-control#config-show--set-option-value--placement-rules
max-store-down-time controls the time that PD decides the disconnected store cannot be restored if exceeded. If PD does not receive heartbeats from a store within the specified period of time, PD adds replicas in other nodes.

这应该是一个全局配置，但是假如某一台Store 目前需要被临时维护 上面有大量数据（>1 TB）移动Region 会花费大量的时间，所以我们需要改变增加 max-store-down-time （比如4-8 小时）让他足以满足Store的维护时间。但这个时候问题又来了，倘若另一台机器会临时宕机或者需要立刻移动数据有没有办法给这两台机器设置不同的 Max-Store-down-time 让那台知道会维护回来的Store保持4-8小时的Max-Store-down-time，但是另一台知道不会回来的宕机Store设置为30min

2

目前的局限性

max-store-down-time 是一个全局配置项，因此 TiDB 当前并不支持为不同的存储节点单独设置不同的 max-store-down-time 值。所有节点共享同一个设置，这导致您无法实现您想要的灵活性。

可能的解决方案

尽管当前 TiDB 不支持为每个存储节点单独配置 max-store-down-time，但您可以考虑以下几种策略：

  1. 临时降低全局 max-store-down-time：
  • 在计划进行临时维护时，您可以临时降低全局的 max-store-down-time，在维护完成后再将其恢复到较高的值。这种方法需要在维护窗口内确保不会有其他节点临时宕机。
  1. 手动迁移 Region：
  • 在对需要维护的存储节点进行操作之前，您可以手动将其上的 Region 迁移到其他节点。这样可以确保在维护期间不会影响 Region 的可用性。
  1. 使用 PD 的 pd-ctl 工具：
  • 您可以利用 pd-ctl 工具监控和手动调整 Region 的副本和调度。通过监控节点状态并手动干预，可以避免因自动配置造成的影响。
  1. 计划维护窗口：
  • 制定详细的维护计划，确保在较低负载时进行维护，并与团队沟通以减少意外停机的可能性。
  1. 利用 TiDB 的监控与告警：
  • 配置监控系统，在节点状态发生变化时及时告警，以便快速响应，防止因为错误的配置导致数据丢失。
2 个赞
3

除非你设置5副本，这样分开设置可能会有意义，否则3副本的情况下，一台维护不可用了，另一台tikv一旦临时挂了，立刻集群也不可用了。3副本坏2个已经不满足多数可用的原则了。