[server] Support altering table.log.ttl table option

[Kaixuan-Duan]

Purpose

Linked issue: close #3231

Brief change log

• Add ConfigOptions.TABLE_LOG_TTL.key() to FlussConfigUtils.ALTERABLE_TABLE_OPTIONS so the validator no longer rejects ALTER on this option.
• Change RemoteLogTablet#ttlMs from final to volatile and add getTtlMs() / updateTtlMs(long) so the remote-log expiration check can observe the new value without recreating the tablet.
• Add Replica#updateLogTtlMs(long) which looks up the corresponding RemoteLogTablet via RemoteLogManager and applies the new TTL, guarded by an IllegalStateException fallback for the case where the tablet has not been registered yet.
• Extend ReplicaManager#updateReplicaTableConfig to collect a tableIdToLogTtlMs map from the metadata diff and dispatch updateLogTtlMs to each affected replica, mirroring how table.log.tiered.local-segments is already handled.

Tests

./mvnw -pl fluss-client,fluss-server -am test \
-Dtest='FlussAdminITCase#testAlterTableLogTtl,'\
'RemoteLogTabletTest,'\
'RemoteLogManagerTest,'\
'RemoteLogTTLTest' \
-DfailIfNoTests=false

API and Format

Documentation

[Copilot]

Pull request overview

Enables ALTER TABLE ... SET ('table.log.ttl' = ...) by allowing the option through config validation and propagating updated TTL values into the server-side remote-log expiration logic without requiring tablet recreation.

Changes:

• Allow table.log.ttl to be altered by adding it to FlussConfigUtils.ALTERABLE_TABLE_OPTIONS.
• Make RemoteLogTablet TTL mutable/visible across threads and add update/access methods; wire TTL updates through Replica and ReplicaManager.
• Add/extend tests to validate TTL alteration persistence and runtime effect on remote-log expiration.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
fluss-common/src/main/java/org/apache/fluss/config/FlussConfigUtils.java	Allows table.log.ttl to pass ALTER-table option validation.
fluss-server/src/main/java/org/apache/fluss/server/log/remote/RemoteLogTablet.java	Makes TTL mutable (volatile) and adds TTL getter/updater for runtime expiration decisions.
fluss-server/src/main/java/org/apache/fluss/server/replica/Replica.java	Adds updateLogTtlMs to apply TTL changes to the associated RemoteLogTablet.
fluss-server/src/main/java/org/apache/fluss/server/replica/ReplicaManager.java	Propagates TTL values from metadata updates to online replicas.
fluss-server/src/test/java/org/apache/fluss/server/log/remote/RemoteLogTabletTest.java	Adds unit coverage for TTL update behavior affecting expiration results.
fluss-server/src/test/java/org/apache/fluss/server/log/remote/RemoteLogManagerTest.java	Adds integration-style test ensuring replica-driven TTL updates reach RemoteLogTablet.
fluss-client/src/test/java/org/apache/fluss/client/admin/FlussAdminITCase.java	Adds IT coverage verifying ALTER persists TTL into TableInfo and reset reverts to default.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This calls remoteLogManager.remoteLogTablet(tableBucket), which is currently a @VisibleForTesting method and throws IllegalStateException when absent. For production code paths, it would be cleaner to add a non-test API on RemoteLogManager (e.g., returning @Nullable/Optional) or a dedicated updateLogTtlMs(tableBucket, ttl) method, instead of relying on an exception-driven control flow.

Suggested change

	final RemoteLogTablet remoteLogTablet;
	try {
	remoteLogTablet = remoteLogManager.remoteLogTablet(tableBucket);
	} catch (IllegalStateException e) {
	// RemoteLogTablet may not be registered yet during the early stage of replica
	// creation. In that case, the alter is a no-op here because the Replica will read the
	// up-to-date ttl from the persisted TableInfo when constructing the RemoteLogTablet.
	LOG.warn(
	"RemoteLogTablet for {} is not registered yet, skip applying new logTtlMs={}.",
	tableBucket,
	newTtlMs);
	return;
	}
	final RemoteLogTablet remoteLogTablet = remoteLogManager.remoteLogTablet(tableBucket);

[Copilot]

Logging this as WARN on every TTL update can be noisy in normal scenarios (e.g., remote-log tiering disabled globally or replica still initializing), and the message implies “not registered yet” even when remote logging is disabled. Consider downgrading to DEBUG (or gating on remote-log enabled) and/or refining the message so operators can distinguish disabled vs. not-yet-registered cases.

Suggested change

	// RemoteLogTablet may not be registered yet during the early stage of replica
	// creation. In that case, the alter is a no-op here because the Replica will read the
	// up-to-date ttl from the persisted TableInfo when constructing the RemoteLogTablet.
	LOG.warn(
	"RemoteLogTablet for {} is not registered yet, skip applying new logTtlMs={}.",
	// RemoteLogTablet may be unavailable when remote logging is disabled or during the
	// early stage of replica creation. In those cases, the alter is a no-op here because
	// the Replica will read the up-to-date ttl from the persisted TableInfo when
	// constructing the RemoteLogTablet.
	LOG.debug(
	"RemoteLogTablet for {} is unavailable; skip applying new logTtlMs={} "
	+ "(remote logging may be disabled or the replica is still initializing).",

[Kaixuan-Duan]

@luoyuxia I have addressed the feedback. PTAL