Skip to content

branch-4.1: [enhance](cloud) proactively sync tablet meta after alter #61585 - #66798

Open
github-actions[bot] wants to merge 1 commit into
branch-4.1from
auto-pick-61585-branch-4.1
Open

branch-4.1: [enhance](cloud) proactively sync tablet meta after alter #61585#66798
github-actions[bot] wants to merge 1 commit into
branch-4.1from
auto-pick-61585-branch-4.1

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

Cherry-picked from #61585

FE now sends a sync_tablet_meta RPC to all alive cloud backends after
alter updates tablet meta in meta service. The request carries affected
tablet ids and is dispatched as a best-effort notification, so alter
success still depends on meta service update instead of backend
acknowledgements.

BE handles the RPC by refreshing meta only for tablets that are already
cached locally. Uncached tablets are skipped, which avoids polluting
tablet cache while still fixing stale compaction policy and related
tablet meta on active compute clusters. The RPC also returns
synced/skipped/failed counts and exposes bvar counters for
observability.

This change adds FE and BE unit tests and a cloud regression suite. The
regression covers cached and uncached multi-cluster behavior, the
negative path with proactive notify disabled, and the version-limit
scenario where a size_based table hits too many versions, is altered to
time_series, and can accept new writes immediately after alter.
@github-actions
github-actions Bot requested a review from yiguolei as a code owner August 15, 2026 14:02
@hello-stephen

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@hello-stephen

Copy link
Copy Markdown
Contributor

run buildall

@hello-stephen

Copy link
Copy Markdown
Contributor

Cloud UT Coverage Report

Increment line coverage 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 77.48% (1909/2464)
Line Coverage 64.30% (34169/53141)
Region Coverage 64.44% (17300/26845)
Branch Coverage 53.97% (9264/17166)

@hello-stephen

Copy link
Copy Markdown
Contributor

BE UT Coverage Report

Increment line coverage 92.98% (106/114) 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 58.87% (25190/42792)
Line Coverage 43.31% (256521/592340)
Region Coverage 39.34% (203095/516255)
Branch Coverage 40.82% (93632/229396)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants