englefly opened a new pull request, #66964:
URL: https://github.com/apache/doris/pull/66964
### What problem does this PR solve?
Problem Summary:
A backend that is alive but not query available (query-disabled or shutting
down) can still enter the scan candidate set built by
OlapScanNode.addScanRangeLocations(), which only requires isAlive() and
isMixNode(). When a tablet ends up with a single such candidate (single replica
table, or fixed/cooldown replica narrowing), the LoadBalanceScanWorkerSelector
selects it as the actual scan worker without any availability check (the
replicaLocations.size()==1 branch). Meanwhile the MaterializationNode snapshots
the query-available backend set when the physical plan is translated
(NereidsPlanner.splitFragments), i.e. earlier and with a stricter filter. The
assigned scan worker then writes its own backend_id into every rowid; when the
materialization operator parses the rowid and looks the backend_id up in its
rpc_struct_map built from the earlier snapshot, the id is missing and the query
fails with "MaterializationSinkOperatorX failed to find rpc_struct".
This change makes both places require the same predicate
Backend.isQueryAvailable() when selecting a scan replica host:
- OlapScanNode.addScanRangeLocations() requires isQueryAvailable() when
building the scan candidate set (fixed replica fallback, cooldown replica
narrowing and the replica loop), so a query-disabled but alive backend no
longer enters the candidates; a tablet with no query-available replica now
fails immediately with "has no queryable replicas".
- LoadBalanceScanWorkerSelector.selectScanReplicaAndMinWorkloadWorker()
checks isQueryAvailable() in the single-replica branch and throws "No available
workers" if the only replica is not query available; the multi-replica branch
uses the same predicate.
### Release note
None
### Check List (For Author)
- Test: Unit Test (updated LoadBalanceScanWorkerSelectorBackendSelectionTest
and OlapScanNodeBackendSelectionConfigTest)
- Behavior changed: Yes (a query whose only scan candidate is on a
query-disabled backend now fails fast with a clear error instead of failing
deep in materialization; with fallback/cooldown enabled it recovers by falling
back to another replica)
- Does this need documentation: No
### 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. -->
- [ ] 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:
- [ ] No.
- [ ] Yes. <!-- Explain the behavior change -->
- Does this need documentation?
- [ ] No.
- [ ] Yes. <!-- Add document PR link here. eg:
https://github.com/apache/doris-website/pull/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 -->
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
