[SERVER-77309] An interleaving might cause a migration to continue when it shouldn't Created: 19/May/23 Updated: 29/Oct/23 Resolved: 26/May/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 6.0.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.3.0, 7.0 Required, 6.0.5, 6.0.6, 6.3.1 |
| Fix Version/s: | 7.1.0-rc0, 6.0.7, 7.0.0-rc3 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Marcos José Grillo Ramirez | Assignee: | Marcos José Grillo Ramirez |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Backport Requested: |
v7.0, v6.0
|
||||||||
| Sprint: | Sharding EMEA 2023-05-29 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 135 | ||||||||
| Description |
|
Currently we have an exclusive CSR lock at the beginning of the migration that is used to atomically check the allowMigrations metadata flag and then set the ScopedRegisterer for the migration. Additionally in the refresh code, we have a shared CSR lock used to abort any ongoing migration registered in the migration's decoration. However, that lock goes out of scope, before taking it again in exclusive mode to install the new metadata, making the following interleaving possible: Suppose we have two threads thread1 and thread2. thread1 starts executing a migration command, and thread2 a refresh triggered as part of the setAllowMigrations code (which could be the result of a DDL that used the stopMigration helper). 1. thread1 executes the migration's refresh, but does not see the setAllowMigration's commit The condition described by 4 could cause a migration acquiring the critical section while a DDL requires it (for example, a rename participant might try to acquire the critical section when the migration already held it). We could leave the initial migration check in the refresh as an optimistic verification, but we need to re-check for migrations while holding the exclusive lock and before installing the new metadata. |
| Comments |
| Comment by Githook User [ 06/Jun/23 ] |
|
Author: {'name': 'Marcos José Grillo Ramirez', 'email': 'marcos.grillo@mongodb.com', 'username': 'm4nti5'}Message: |
| Comment by Githook User [ 06/Jun/23 ] |
|
Author: {'name': 'Marcos José Grillo Ramirez', 'email': 'marcos.grillo@mongodb.com', 'username': 'm4nti5'}Message: (cherry picked from commit 533eae2e276298a287a47458ee48d4c481d01788) |
| Comment by Githook User [ 29/May/23 ] |
|
Code review: |
| Comment by Githook User [ 26/May/23 ] |
|
Author: {'name': 'Marcos José Grillo Ramirez', 'email': 'marcos.grillo@mongodb.com', 'username': 'm4nti5'}Message: (cherry picked from commit 533eae2e276298a287a47458ee48d4c481d01788) |
| Comment by Githook User [ 26/May/23 ] |
|
Author: {'name': 'Marcos José Grillo Ramirez', 'email': 'marcos.grillo@mongodb.com', 'username': 'm4nti5'}Message: |