fix: fix potential data loss for shared source

xxchan commented 3 days ago

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

Set up: Create a shared kafka source, and 1 MV on the source.

Data loss happens when:

alter source set rate limit to 0
push some new data to the kafka topic
resume the source. Then we can find the MV don't get the data. If we push more data to the topic, only new data comes.

Reason: In #16626 we introduced an optimization to let shared SourceExecutor start from latest, but the implementation is problematic. Specifically, hack_seek_to_latest will not only take effect at the beginning, but will also when rebuilding the source reader (which happens when rate limit is applied).

The new implementation in this PR:

Remove implicit hack_seek_to_latest flag, which is error prone.
Replaced with an explicit seek_to_latest call. At the same time, we also get the latest offsets. To make sure SplitImpl and SourceReader is consistent.
Make sure the splits are written to state store even if no messages come.
Do not pause the SourceExecutor. (#16348) It seems not very useful, but just confusion. Seeking to latest should be good enough.

Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)
[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

xxchan commented 3 days ago

#19466
#19445
#19443 👈 (View in Graphite)
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

tabVersion commented 3 days ago

Specifically, hack_seek_to_latest will not only take effect at the beginning, but will also when rebuilding the source reader (which happens when rate limit is applied).

So when receiving a new mutation on rate_limit, the source exec refreshes the high watermark to hw_1 but the source backfill exec keeps the original high watermark hw_0 as the end position of backfill. Is my understanding correct?

xxchan commented 3 days ago

It's not related with backfill's position. We may assume backfill already finished, and it's just forwarding messages now.

Rebuilding will make source exec jump from hw_0 to hw_1.

xxchan commented 2 days ago

Want to wait a while for more reviews. Just in case.

xxchan commented 2 days ago

Merge activity

Nov 20, 3:57 PM GMT+8: A user started a stack merge that includes this pull request via Graphite.
Nov 20, 3:58 PM GMT+8: Graphite couldn't merge this PR because it failed for an unknown reason (This repository has GitHub's merge queue enabled, which is currently incompatible with Graphite).

xxchan commented 2 days ago

will cherry pick the whole stack together

risingwavelabs / risingwave