deardeng opened a new pull request, #66680:
URL: https://github.com/apache/doris/pull/66680

   Add a cluster-level FE config `cross_az_succ_quorum` (format `az1:2,az2:1`, 
empty by default) requiring, per tablet, a minimum number of successfully 
written replicas in each availability zone before a load transaction may 
commit. It only tightens the existing commit condition, never relaxes it; the 
default empty value keeps today's behavior unchanged and costs nothing on the 
commit path.
   
   The requirement of each AZ is clamped to the replicas the tablet actually 
has there:
   
       required_in_az = min(configured, replica_num_in_az)
   
   A tablet with no replica in a configured AZ (single-AZ tables, backends 
without a location tag) is therefore skipped, and a table whose replica 
distribution cannot reach the configured value degrades instead of becoming 
permanently unloadable. This mirrors how `min_load_replica_num` is clamped in 
OlapTable#getLoadRequiredReplicaNum.
   
   FE enforces it in DatabaseTransactionMgr#checkCommitStatus, the single choke 
point shared by the 2PC pre-commit, ordinary commit and sub-transaction commit 
paths.
   
   BE's quorum success write is made AZ aware as well. Without that, a merely 
slow replica is dropped from the reported success set once the ordinary 
majority is reached; in a cross-AZ deployment the systematically slowest 
replica is the remote-AZ one, so the FE check would reject healthy loads. Two 
optional thrift fields carry what BE needs -- `TNodeInfo.location` and 
`TOlapTableSink.cross_az_succ_quorum` -- both sent only when the config is 
non-empty, so an old BE simply ignores them and falls back to the FE-only 
check. BE applies the identical clamp in
   DorisNodesInfo#is_cross_az_quorum_success, shared by the v1 and v2 tablet 
writers. Replicas with a version gap are excluded from the success count on 
both sides.
   
   Applies to the integrated storage-compute mode only; cloud mode commits 
through CloudGlobalTransactionMgr and never reaches this check.
   
   ### 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]

Reply via email to