deardeng commented on code in PR #65836:
URL: https://github.com/apache/doris/pull/65836#discussion_r3629225846
##########
fe/fe-core/src/main/java/org/apache/doris/catalog/TableProperty.java:
##########
@@ -678,10 +682,23 @@ public TableProperty
buildInvertedIndexFileStorageFormat() {
}
public void modifyTableProperties(Map<String, String> modifyProperties) {
+ // Compatibility note: ModifyTablePropertyOperationLog persists only
properties to set, not keys removed
+ // here. Keep its payload unchanged for this legacy repair. During a
rolling FE upgrade, alter these
+ // properties on a table that already contains both legacy keys only
after all FEs have been upgraded;
+ // otherwise old and new FEs may apply different effective replica
settings.
+ removeConflictingDefaultReplicaProperty(modifyProperties);
Review Comment:
> Thanks for pointing this out. We intentionally do not extend the
persistence protocol for this corner case in this PR.
>
> The issue requires several conditions to occur together:
>
> 1. The table contains both conflicting replica properties from
historical metadata.
> 2. The relevant replica property is altered during the short
mixed-version FE upgrade window.
> 3. An incompatible leader/follower combination or failover occurs before
the FE upgrade completes.
>
> Doris’ supported rolling-upgrade procedure requires upgrading non-Master
FEs first and the Master last. For affected legacy tables, the relevant ALTER
should be executed after all FEs have completed the upgrade. This restriction
is now documented next to the mutation
> logic.
>
> Making the removal understandable to pre-change FEs would require
journal protocol evolution, capability/version gating, or a staged
multi-release migration. That would significantly increase the scope and risk
of this focused bug fix for a very low-probability upgrade
> corner case.
>
> This PR therefore deliberately keeps the persisted log format unchanged,
fixes the behavior for homogeneous upgraded clusters, and documents the
mixed-version operational restriction. We consider this an accepted upgrade
limitation rather than a blocker for this PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
