Uh oh!
There was an error while loading. Please reload this page.
[opt](rowset) Remote fetch rowsets to avoid -230 error when capturing rowsets - #52995
Conversation
hello-stephen
commented
Jul 9, 2025
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
cc13028 to
da91298CompareHastyshell
commented
Oct 13, 2025
run buildall |
doris-robot
commented
Oct 13, 2025
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Oct 13, 2025
FE UT Coverage ReportIncrement line coverage `` 🎉 |
4dc6d94 to
840053eCompareHastyshell
commented
Oct 15, 2025
run buildall |
840053e to
715070aCompareHastyshell
commented
Oct 15, 2025
run buildall |
hello-stephen
commented
Oct 15, 2025
FE Regression Coverage ReportIncrement line coverage |
715070a to
f0054cdCompareHastyshell
commented
Oct 17, 2025
run buildall |
hello-stephen
commented
Oct 17, 2025
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
f0054cd to
38759bbCompareHastyshell
commented
Oct 17, 2025
run buildall |
doris-robot
commented
Oct 17, 2025
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Oct 17, 2025
FE Regression Coverage ReportIncrement line coverage |
Hastyshell
commented
Oct 17, 2025
run beut |
38759bb to
c30231fCompareHastyshell
commented
Oct 20, 2025
run buildall |
1 similar comment
Hastyshell
commented
Oct 20, 2025
run buildall |
doris-robot
commented
Oct 22, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Oct 22, 2025
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
df02c39 to
f22b220CompareHastyshell
commented
Oct 22, 2025
run buildall |
doris-robot
commented
Oct 22, 2025
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
doris-robot
commented
Oct 22, 2025
TPC-H: Total hot run time: 36123 ms |
doris-robot
commented
Oct 22, 2025
ClickBench: Total hot run time: 29.84 s |
hello-stephen
commented
Oct 22, 2025
FE UT Coverage ReportIncrement line coverage |
doris-robot
commented
Oct 22, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Oct 22, 2025
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Oct 22, 2025
FE Regression Coverage ReportIncrement line coverage |
Hastyshell
commented
Oct 23, 2025
run cloud_p0 |
hello-stephen
commented
Oct 23, 2025
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Oct 23, 2025
FE Regression Coverage ReportIncrement line coverage |
PR approved by at least one committer and no changes requested. |
Uh oh!
There was an error while loading. Please reload this page.
… rowsets (apache#52995) Related PR: apache#52440 In read-write splitting scenarios, some BE (Backend) nodes may have already merged certain rowset versions, while another BE still attempts to capture or access those rowsets. When this happens, the BE reports error E-230 (versions already merged), causing data access or synchronization to fail. This PR introduces a remote rowset fetching mechanism, allowing a BE that lacks the required rowset to fetch it from other BE nodes, instead of failing with E-230. - Added a remote fetch mechanism in the rowset management layer: When a BE detects that a rowset is missing locally but has already been merged, it will try to fetch the rowset from other BE nodes. - Updated version and state checking logic to correctly identify the “merged but missing” condition. - Adjusted the rowset access path to trigger remote fetch rather than throwing an immediate error. - Added tests (unit/integration) to cover the new logic where applicable. - Ensured backward compatibility: If the BE already has the rowset locally or read-write splitting is not enabled, the behavior remains unchanged. Introduce a remote rowset fetching mechanism to prevent E-230 (“versions already merged”) errors in read-write splitting scenarios. This improves BE fault tolerance when some nodes have merged versions that others have not yet synchronized.
… rowsets (#52995) (#57271) Related PR: #52995 In read-write splitting scenarios, some BE (Backend) nodes may have already merged certain rowset versions, while another BE still attempts to capture or access those rowsets. When this happens, the BE reports error E-230 (versions already merged), causing data access or synchronization to fail. This PR introduces a remote rowset fetching mechanism, allowing a BE that lacks the required rowset to fetch it from other BE nodes, instead of failing with E-230. - Added a remote fetch mechanism in the rowset management layer: When a BE detects that a rowset is missing locally but has already been merged, it will try to fetch the rowset from other BE nodes. - Updated version and state checking logic to correctly identify the “merged but missing” condition. - Adjusted the rowset access path to trigger remote fetch rather than throwing an immediate error. - Added tests (unit/integration) to cover the new logic where applicable. - Ensured backward compatibility: If the BE already has the rowset locally or read-write splitting is not enabled, the behavior remains unchanged. Introduce a remote rowset fetching mechanism to prevent E-230 (“versions already merged”) errors in read-write splitting scenarios. This improves BE fault tolerance when some nodes have merged versions that others have not yet synchronized. ### What problem does this PR solve? Issue Number: close #xxx Related PR: #xxx Problem Summary: ### Release note None ### Check List (For Author) - Test <!-- At least one of them must be included. --> - [x] Regression test - [ ] Unit Test - [ ] Manual test (add detailed scripts or steps below) - [ ] No need to test or manual test. Explain why: - [ ] This is a refactor/code format and no logic has been changed. - [ ] Previous test can cover this change. - [ ] No code files have been changed. - [ ] Other reason <!-- Add your reason? --> - Behavior changed: - [x] No. - [ ] Yes. <!-- Explain the behavior change --> - Does this need documentation? - [ ] No. - [x] Yes. <!-- Add document PR link here. eg: apache/doris-website#1214 --> ### Check List (For Reviewer who merge this PR) - [ ] Confirm the release note - [ ] Confirm test cases - [ ] Confirm document - [ ] Add branch pick label <!-- Add branch pick label that this PR should merge into -->
… rowsets (apache#52995) Related PR: apache#52440 In read-write splitting scenarios, some BE (Backend) nodes may have already merged certain rowset versions, while another BE still attempts to capture or access those rowsets. When this happens, the BE reports error E-230 (versions already merged), causing data access or synchronization to fail. This PR introduces a remote rowset fetching mechanism, allowing a BE that lacks the required rowset to fetch it from other BE nodes, instead of failing with E-230. - Added a remote fetch mechanism in the rowset management layer: When a BE detects that a rowset is missing locally but has already been merged, it will try to fetch the rowset from other BE nodes. - Updated version and state checking logic to correctly identify the “merged but missing” condition. - Adjusted the rowset access path to trigger remote fetch rather than throwing an immediate error. - Added tests (unit/integration) to cover the new logic where applicable. - Ensured backward compatibility: If the BE already has the rowset locally or read-write splitting is not enabled, the behavior remains unchanged. ### Release note Introduce a remote rowset fetching mechanism to prevent E-230 (“versions already merged”) errors in read-write splitting scenarios. This improves BE fault tolerance when some nodes have merged versions that others have not yet synchronized.
What problem does this PR solve?
Related PR: #52440
Problem Summary:
In read-write splitting scenarios, some BE (Backend) nodes may have already merged certain rowset versions, while another BE still attempts to capture or access those rowsets.
When this happens, the BE reports error E-230 (versions already merged), causing data access or synchronization to fail.
This PR introduces a remote rowset fetching mechanism, allowing a BE that lacks the required rowset to fetch it from other BE nodes, instead of failing with E-230.
When a BE detects that a rowset is missing locally but has already been merged, it will try to fetch the rowset from other BE nodes.
Release note
Introduce a remote rowset fetching mechanism to prevent E-230 (“versions already merged”) errors in read-write splitting scenarios.
This improves BE fault tolerance when some nodes have merged versions that others have not yet synchronized.
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)