[SERVER-31982] Shard does not call config commit chunk migration command with majority writeConcern nor checks for writeConcern errors. Created: 15/Nov/17 Updated: 30/Oct/23 Resolved: 14/Dec/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.4.11, 3.6.2, 3.7.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Dianna Hohensee (Inactive) |
| 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: |
v3.6, v3.4
|
||||
| Sprint: | Sharding 2017-12-18 | ||||
| Participants: | |||||
| Case: | (copied to CRM) | ||||
| Description |
|
From visual inspection of the code, MigrationSourceManager::commitChunkMetadataOnConfig does not check the command response for writeConcernStatus, nor does it send majority write concern in the command. On the config server, ShardingCatalogManager::commitChunkMigration does not appear to include majority write concern in its final write. This was probably because we used to take a lock twice to nest and prevent yielding, which makes yielding to wait for replication impossible, in order to enforce serialization of commits. Now, however, we use a _kChunkOpLock to serialize operations, no longer taking locks. These kind of comments should also be removed: https://github.com/mongodb/mongo/blob/e37db69674486dff9fdac2b5ee41961a8805804b/src/mongo/s/catalog/sharding_catalog_manager_chunk_operations.cpp#L223-L225 |
| Comments |
| Comment by Githook User [ 02/Jan/18 ] |
|
Author: {'name': 'Dianna Hohensee', 'username': 'DiannaHohensee', 'email': 'dianna.hohensee@10gen.com'}Message: (cherry picked from commit f4c11f679de3781ae202511fe07144e357c80e2b) |
| Comment by Githook User [ 15/Dec/17 ] |
|
Author: {'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@10gen.com', 'username': 'DiannaHohensee'}Message: (cherry picked from commit f4c11f679de3781ae202511fe07144e357c80e2b) |
| Comment by Githook User [ 14/Dec/17 ] |
|
Author: {'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@10gen.com', 'username': 'DiannaHohensee'}Message: |
| Comment by Kaloian Manassiev [ 15/Nov/17 ] |
|
You are right, this has existed since day 1. We should definitely fix it and backport to 3.4. On other note, this is not as serious bug as it sounds, because all metadata reads are done with majority read concern and "afterOpTime", so they will never read uncommitted data (including the balancer reads itself). |