[SERVER-66972] Database critical section does not serialize with ongoing refreshes Created: 02/Jun/22 Updated: 29/Oct/23 Resolved: 29/Aug/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 5.0.9, 6.0.0-rc8 |
| Fix Version/s: | 6.1.1, 5.0.14, 6.0.3, 6.2.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Tommaso Tocci | Assignee: | Antonio Fuschetto |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | PM-2144-Milestone-0 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||
| Backport Requested: |
v6.1, v6.0, v5.0
|
||||||||||||||||||||||||||||||||||||
| Sprint: | Sharding EMEA 2022-07-11, Sharding EMEA 2022-07-25, Sharding EMEA 2022-08-08, Sharding EMEA 2022-08-22, Sharding EMEA 2022-09-05 | ||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 20 | ||||||||||||||||||||||||||||||||||||
| Description |
|
Consider the following scenario:
To guarantee correctness of the critical section we must ensure that all the refreshes started before the critical section acquisition (3.) will be invalidated and no new refreshes could start before (5.) |
| Comments |
| Comment by Githook User [ 05/Oct/22 ] |
|
Author: {'name': 'Antonio Fuschetto', 'email': 'antonio.fuschetto@mongodb.com', 'username': 'afuschetto'}Message: |
| Comment by Githook User [ 03/Oct/22 ] |
|
Author: {'name': 'Antonio Fuschetto', 'email': 'antonio.fuschetto@mongodb.com', 'username': 'afuschetto'}Message: |
| Comment by Githook User [ 03/Oct/22 ] |
|
Author: {'name': 'Antonio Fuschetto', 'email': 'antonio.fuschetto@mongodb.com', 'username': 'afuschetto'}Message: |
| Comment by Githook User [ 29/Aug/22 ] |
|
Author: {'name': 'Antonio Fuschetto', 'email': 'antonio.fuschetto@mongodb.com', 'username': 'afuschetto'}Message: |
| Comment by Antonio Fuschetto [ 25/Jul/22 ] |
|
The solution that I am implementing is designed to be backported, since this race condition affects old branches as well. With the Sharding-first Catalog project the logic of how the database version is managed at shard level will change, which probably allows us to get rid of the current logic to refresh the DB version in case of mismatch with the one provided by the router. This will included, presumably, in version 7.0. The fix will provide the following properties to the current onDbVersionMismatch implementation:
|
| Comment by Antonio Fuschetto [ 14/Jun/22 ] |
|
Whatever will be the strategy to resolve this problem, the procedure that checks and possibly recovers the database version must satisfy the following conditions:
|