Hi everyone!
I'd like to share a refactoring of the metadata_lease_fence_ms configuration and propose the approach for discussion. 【pr: https://github.com/apache/iotdb/pull/18228】 Background Previously, metadata_lease_fence_ms lived in CommonConfig / CommonDescriptor, meaning both ConfigNode and DataNode read it from their own local configuration files. This created two problems: 1. Duplicated configuration — the same value had to be set on every node. 2. Risk of inconsistency — if a DataNode was misconfigured with a different value, its fencing behavior would diverge from what the ConfigNode expected. What Changed The configuration has been moved exclusively to ConfigNodeConfig / ConfigNodeDescriptor. The DataNode no longer reads metadata_lease_fence_ms from its local config. Instead, the ConfigNode delivers the value to each DataNode through three protocol paths: 1. Registration / Restart — The value is carried in TRuntimeConfiguration.fenceThresholdMs (an optional field). When present, the DataNode updates its local threshold via MetadataLeaseManager.updateFenceThresholdMs(). Before the first ConfigNode contact, the DataNode uses a default of 20,000 ms. 2. Heartbeat — The value is carried in TDataNodeHeartbeatReq.fenceThresholdMs. To avoid redundant transmission, DataNodeContactTracker on the ConfigNode side tracks which value was last delivered to each DataNode (using value comparison). A new value is only sent when it differs from what was previously delivered. This design also enables future hot-reload of the threshold without restarting nodes. 3. Lease recovery (network partition recovery) — No explicit delivery is needed in TDataNodeLeaseRecoveryResp. When a DataNode recovers from a network partition, it has NOT crashed, so its in-memory threshold value is still intact. If the ConfigNode changed the threshold during the partition window, the updated value arrives naturally through the heartbeat path as soon as connectivity is restored. Compatibility The change is wire-compatible for rolling upgrades. A new ConfigNode talking to an old DataNode works correctly — the old DataNode silently ignores the new Thrift fields it doesn't recognize. An old ConfigNode talking to a new DataNode is also safe: since fenceThresholdMs is optional in TRuntimeConfiguration, the DataNode simply keeps its 20,000 ms default when the field is absent. - 向大家介绍一项关于 metadata_lease_fence_ms（元数据租约隔离阈值）配置的重构，供讨论。 背景 此前，metadata_lease_fence_ms 位于 CommonConfig / CommonDescriptor 中，意味着 ConfigNode 和 DataNode 都从各自的本地配置文件读取该值。这带来两个问题： 1. 配置重复 —— 每个节点都需要设置相同的值。 2. 不一致风险 —— 如果某个 DataNode 配置了不同的阈值，其隔离行为将与 ConfigNode 的预期产生偏差。 改动内容 该配置已迁移至 ConfigNodeConfig / ConfigNodeDescriptor（仅 ConfigNode 侧）。DataNode 不再从本地配置读取 metadata_lease_fence_ms。ConfigNode 通过以下三条协议路径将值传递给每个 DataNode： 1. 注册 / 重启 — 值通过 TRuntimeConfiguration.fenceThresholdMs（optional 字段）传递。当字段存在时，DataNode 通过 MetadataLeaseManager.updateFenceThresholdMs() 更新本地阈值。在与 ConfigNode 首次建立联系之前，DataNode 使用默认值 20,000 毫秒。 2. 心跳 — 值通过 TDataNodeHeartbeatReq.fenceThresholdMs 传递。为避免重复发送，ConfigNode 侧的 DataNodeContactTracker 追踪上次发给每个 DataNode 的值（通过值比较），仅当值与上次不同时才发送。此设计也为未来无需重启的热加载阈值提供了支持。 3. 租约恢复（网络分区恢复） — 无需在 TDataNodeLeaseRecoveryResp 中显式传递。DataNode 从网络分区恢复时并未宕机，内存中的阈值依然有效。如果 ConfigNode 在分区期间修改了阈值，连接恢复后新值会通过心跳路径自然到达。 兼容性 此改动在滚动升级中保持线兼容。新 ConfigNode 与旧 DataNode 通信时正常工作, 由于 TRuntimeConfiguration.fenceThresholdMs 是 optional 字段，字段缺失时 DataNode 保持 20,000 毫秒的默认值。 Best wishes, Yaobin Chen
