Cyb/metadata table#18127
Conversation
…lity of table metadata operation procedure
…ager, add the scheduled task to check the status of metadata
# Conflicts: # iotdb-core/confignode/src/main/i18n/zh/org/apache/iotdb/confignode/i18n/ProcedureMessages.java # iotdb-core/confignode/src/main/java/org/apache/iotdb/confignode/procedure/env/ConfigNodeProcedureEnv.java # iotdb-core/datanode/src/main/i18n/zh/org/apache/iotdb/db/i18n/DataNodePipeMessages.java # iotdb-core/datanode/src/main/i18n/zh/org/apache/iotdb/db/i18n/DataNodeSchemaMessages.java
…m CommonConfig to the IoTDBConfig
| MetricService.getInstance(), | ||
| NodeUrlUtils.convertTEndPointUrl(dataNodeLocation.getClientRpcEndPoint())); | ||
| // Drop the removed DataNode's metadata-lease contact/capability state so it is not retained, | ||
| // and a future DataNode reusing the id cannot inherit stale fencing history. |
There was a problem hiding this comment.
id will always increase, no new DN will reuse removed DN's id
| } | ||
|
|
||
| // only care about the AbstractAlterOrDropTableProcedure(except the drop table/view) | ||
| // and the DeleteDatabaseProcedure |
There was a problem hiding this comment.
explain why we need to exclude the drop table/view procedure
| // DDL: a fenced DataNode fails closed on its now-stale table cache and resyncs on lease | ||
| // recovery, so it cannot serve dirty schema. Only fail if an unacked DataNode is not provably | ||
| // fenced (it may still be serving clients). | ||
| final TUpdateTableReq req = SchemaUtils.BuildPreUpdateTableReq(database, table, oldName); |
There was a problem hiding this comment.
| final TUpdateTableReq req = SchemaUtils.BuildPreUpdateTableReq(database, table, oldName); | |
| final TUpdateTableReq req = SchemaUtils.buildPreUpdateTableReq(database, table, oldName); |
| database, | ||
| table.getTableName(), | ||
| failedResults); | ||
| "an unreachable DataNode is not provably fenced"); |
There was a problem hiding this comment.
follow the i18n standarn, define a constant in both zh and en.
| database, | ||
| table.getTableName(), | ||
| failedResults); | ||
| "an unreachable DataNode is not provably fenced"); |
| ProcedureMessages.INVALIDATE_VIEW_SCHEMAENGINE_CACHE_FAILED))); | ||
| return; | ||
| } | ||
| LOGGER.error( |
| new MetadataException(ProcedureMessages.INVALIDATE_SCHEMAENGINE_CACHE_FAILED))); | ||
| return; | ||
| } | ||
| LOGGER.error( |
| ProcedureMessages.INVALIDATE_VIEW_SCHEMAENGINE_CACHE_FAILED))); | ||
| return; | ||
| } | ||
| LOGGER.error( |
| new MetadataException(ProcedureMessages.INVALIDATE_SCHEMAENGINE_CACHE_FAILED))); | ||
| return; | ||
| } | ||
| LOGGER.error( |
| import java.io.OutputStream; | ||
|
|
||
| public class PreDeleteTsTable extends TsTable { | ||
| public static final int PRE_DELETE_MARKER = -2; |
There was a problem hiding this comment.
| public static final int PRE_DELETE_MARKER = -2; | |
| public static final int PRE_DELETE_MARKER = -3; |
put it as an enum, add comments that -2 is reserved and don't use.
|
I reviewed this PR against the HA requirement/design docs. The direction looks good, but I found several issues that should be addressed before merge:
The design says the ConfigNode should track whether each DataNode supports self-fencing, with default
For example, Overall, the main concept is sound, but the above issues affect the safety and compatibility of the lease-based HA mechanism. |
This PR introduces a lease-based self-fencing framework to enable high
availability for table metadata operations. It prevents DataNodes from
serving stale schema during network partitions.
Problem
Currently, in a cluster deployment (e.g., 1 ConfigNode, 3 DataNodes),
metadata operations lack true high availability. If a single DataNode (DN)
crashes or experiences a network partition, execution of DDL procedures
(such as Create/Alter/Drop Table, View management, TTL adjustments, and
Drop Database) will directly fail and trigger a rollback.
Solution
Lease Mechanism
Uses monotonic clock. Self-fences (clears cache, blocks reads/writes) if no
heartbeat received within metadata_lease_fence_ms (T_fence).
fenced DataNode.
Broadcast Coordination
heartbeat response per DataNode. Separately maintained from load-balancing
samples to ensure correctness.
DataNodes have been silent for T_proceed = T_fence + margin, WAIT
otherwise, FAIL when retry budget exhausted.
waiting up to T_proceed for unresponsive DataNodes to prove self-fenced.
Schema Change Integration
ClusterCachePropagator before proceeding.
transitions.
changes.
Configuration
iotdb-system.properties.template).
Testing
MetadataBroadcastVerdict, ClusterCachePropagator
ClusterAuthorityFetcher
Key Components Added
self-fencing upon expiration.
timestamp for each DataNode.
a fencing-aware retry mechanism.
DataNodes are logically safe to skip.
thrown on a fenced DataNode.
ensure safe schema deletion.