Skip to content

branch-4.1: [fix](cloud) refresh tablet meta of continuously ingested tablets #67972 - #68044

Merged
yiguolei merged 1 commit into
apache:branch-4.1from
liaoxin01:codex/pick-67972-to-branch-4.1
Sep 16, 2026
Merged

yiguolei merged 1 commit into
apache:branch-4.1from
liaoxin01:codex/pick-67972-to-branch-4.1

Conversation

@liaoxin01

@liaoxin01 liaoxin01 commented Sep 16, 2026

Copy link
Copy Markdown
Contributor

Pick #67972

…ache#67972)

Problem Summary:

`CloudTabletMgr::sync_tablets()` selected the tablets it would work on
by `last_sync_time_s`, then did two things to each one: `sync_meta()`
followed by `sync_rowsets()`.

But that clock only tracks how stale a tablet's **rowsets** are. It is
advanced inside `sync_tablet_rowsets()`, and only when that actually
issues its RPC. A tablet under continuous ingest therefore keeps it
permanently fresh, never falls below the staleness bound, and never has
`sync_meta()` called on it at all.

Its `TabletMeta` then stays at whatever it was built with for the
lifetime of the object, so properties that only arrive through the
tablet meta are never picked up. `ttl_seconds` is the one that shows:
`CloudTablet::sync_meta()` is the only thing that refreshes it, and it
feeds the file cache expiration computed on the write path
(`CloudRowsetBuilder`, compaction output), the read path
(`TabletReader`, `OlapScanner`) and warm-up. An `ALTER TABLE ... SET
("file_cache_ttl_seconds" = ...)` on a table under load therefore has no
effect on those blocks, which keep landing in the wrong queue with an
expiration derived from the stale value.

Fixed tablet metadata never being refreshed for tablets under continuous
ingest, which left properties such as `file_cache_ttl_seconds` stale on
those tablets after an ALTER.

**1. Give meta staleness its own clock.** `last_sync_tablet_meta_time_s`
is advanced only by `sync_meta()`.

**2. Rename `last_sync_time_s` to `last_sync_rowsets_time_s`** (separate
commit, mechanical). The old name says "sync" while the clock only ever
tracked rowsets, and reading it as "when this tablet was last synced" is
exactly the mistake that let meta work be gated on it. With a second
clock alongside it the old name would be actively misleading. This also
keeps the field named the same as on branch-3.1.

**3. `sync_tablets()` decides per tablet which of the two RPCs it is due
for**, rather than sorting tablets into a single bucket:

- rowsets stale -> sync rowsets, and the meta too. Pulling rowsets
implies pulling the meta, which is the relationship the single pass had:
the rowsets are only as trustworthy as the meta they belong to.
- rowsets fresh but meta stale -> sync the meta only, one RPC instead of
the two a full sync costs. This is the case that used to be skipped
entirely.
- both fresh -> skip.

Work is still ordered by the older of the two clocks, so a mid-run stop
has already served the tablets that waited longest.

New bvars `sync_tablets_meta_num` and `sync_tablets_rowsets_num` split
what `num_sync` used to lump together, and the finish log reports both.

(cherry picked from commit fe92389)
@liaoxin01
liaoxin01 requested a review from yiguolei as a code owner September 16, 2026 02:25
@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?

@liaoxin01

Copy link
Copy Markdown
Contributor Author

run buildall

@hello-stephen

Copy link
Copy Markdown
Contributor

BE Regression && UT Coverage Report

Increment line coverage 89.80% (44/49) 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 74.47% (31464/42253)
Line Coverage 58.70% (350687/597426)
Region Coverage 55.41% (292586/528035)
Branch Coverage 56.28% (132088/234716)

@yiguolei
yiguolei merged commit 02a54fe into apache:branch-4.1 Sep 16, 2026
41 of 43 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

PR approved by anyone and no changes requested.

@github-actions github-actions Bot added the approved Indicates a PR has been approved by one committer. label Sep 16, 2026
@github-actions

Copy link
Copy Markdown
Contributor

PR approved by at least one committer and no changes requested.

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

Labels

approved Indicates a PR has been approved by one committer. reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants