[SERVER-62700] The rename DDL violates some ShardServerCatalogCacheLoader constraints when the cached metadata collections are UUID-based Created: 18/Jan/22 Updated: 17/Jun/22 Resolved: 24/Jan/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Sergi Mateo Bellido | Assignee: | Antonio Fuschetto |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | SSCCL-BUG | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Sprint: | Sharding EMEA 2022-01-24 |
| Participants: |
| Description |
|
When we enable the long names support, all config.cache.chunks.* collections are UUID-based. This is problematic for the rename DDL operation, let me try to describe the problem:
I spotted this problem some time ago ( rui.liu found this problem in this execution. |
| Comments |
| Comment by Sergi Mateo Bellido [ 24/Jan/22 ] |
|
Pierlauro and myself discussed about the approach above but wasn't complete. A solution that would work would be to name the config.cache.chunks.* collections with a hash of the namespace instead of the UUID. We would probably want to persist also this hash in config.cache.collections for post-mortem analysis though. |
| Comment by Pierlauro Sciarelli [ 21/Jan/22 ] |
|
Would it be an acceptable trick to update the uuid field for the document representing A in the config.cache.collections at some point during the rename? E.g. set it to UUID(0) so that the async drop tries to delete config.cache.chunks.0. Note that this would not affect the rename operation because:
It seems an easy way to get rid of the race condition with no side effects. I believe it could be done by the DDL coordinator after renaming the metadata on the CSRS and before unblocking CRUDs (around here). |