[SERVER-40783] For a transaction that requires two-phase commit due to multiple write shards, omit read-only shards from having to do prepare Created: 23/Apr/19 Updated: 12/Dec/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Backlog - Cluster Scalability |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | ShardedTxn:FutureOptimizations, pm-564, sharding-common-backlog | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Cluster Scalability
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Participants: | |||||||||
| Description |
|
For a transaction that requires two-phase commit due to multiple write shards, omit read-only shards from having to do prepare. (Also, the following should also be done as part of this ticket, from previous Currently, the first participant is chosen as the two-phase commit coordinator. This means that if that participant ends up being read-only, the two-phase commit will not have the benefit of any of the participants being local. This would only improve the tail latency of two-phase commit. It is slightly complicated because in order to choose a write shard, the router has to first know whether the participant has done a write, which means the router cannot piggyback "coordinator: true" on the request to the participant. |