[SERVER-31990] Rollback can abort on long collection names. Created: 15/Nov/17  Updated: 30/Oct/23  Resolved: 29/Nov/17

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 3.6.0-rc4
Fix Version/s: 3.6.1, 3.7.1

Type: Bug Priority: Minor - P4
Reporter: Robert Guo (Inactive) Assignee: Judah Schvimer
Resolution: Fixed Votes: 0
Labels: rbfz
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v3.6
Sprint: Repl 2018-01-01
Participants:
Linked BF Score: 0

 Description   

Here's a sequence of operations that seems to cause rollback to abort:
1. Create a collection with a long name; (long = 64 or so characters)
2. Rename it to one with a shorter name;
3. Create an index with a long name.

Rollback seems to do the rename without dropping indexes, causing the rename back to the long name to fail when the index is present.

2017-11-15T19:53:32.521+0000 I ROLLBACK [rsBackgroundSync] Attempting to rename collection with UUID: ec2f6bdc-d71b-410c-a294-62556ad94185, from: db_1.system.drop.1510775596i24t10.two, to: db_1.verylongnamespaceverylongnamespaceverylongnamespaceverylongnamespaceverylongnamespaceverylongnamespaceverylongnam
2017-11-15T19:53:32.521+0000 F ROLLBACK [rsBackgroundSync] Unable to roll back renameCollection command: InvalidLength: collection name length of 118 exceeds maximum length of 116, allowing for index names
2017-11-15T19:53:32.521+0000 I ROLLBACK [rsBackgroundSync] Rollback finished. The final minValid is: { ts: Timestamp 1510775610000|106, t: 11 }
2017-11-15T19:53:32.522+0000 F ROLLBACK [rsBackgroundSync] Unable to complete rollback. A full resync may be needed: UnrecoverableRollbackError: Unable to rollback renameCollection command
2017-11-15T19:53:32.522+0000 F -        [rsBackgroundSync] Fatal Assertion 40507 at src/mongo/db/repl/rs_rollback.cpp 1475
2017-11-15T19:53:32.522+0000 F -        [rsBackgroundSync]
 
***aborting after fassert() failure



 Comments   
Comment by Githook User [ 05/Dec/17 ]

Author:

{'username': 'judahschvimer', 'email': 'judah@mongodb.com', 'name': 'Judah Schvimer'}

Message: SERVER-31990 drop indexes before renaming collections in rollback via refetch

(cherry picked from commit d923a5575bf277bfc49073597ca0c4d156b93492)
Branch: v3.6
https://github.com/mongodb/mongo/commit/18851f31bbee892d558680536894968efa72feb7

Comment by Githook User [ 29/Nov/17 ]

Author:

{'name': 'Judah Schvimer', 'username': 'judahschvimer', 'email': 'judah@mongodb.com'}

Message: SERVER-31990 drop indexes before renaming collections in rollback via refetch
Branch: master
https://github.com/mongodb/mongo/commit/d923a5575bf277bfc49073597ca0c4d156b93492

Comment by Robert Guo (Inactive) [ 15/Nov/17 ]

Spencer This is indeed on WT, but we check the NS length as part of the renameCollection command, independent of the storage engine.

Comment by Spencer Brody (Inactive) [ 15/Nov/17 ]

Is this on wiredTiger? My understanding was that WT doesn't have a character limit on collection or index names?

Comment by Judah Schvimer [ 15/Nov/17 ]

If we hadn't fasserted we would have dropped the index shortly after. It should be safe to drop indexes by UUID first during rollback to fix this.

Generated at Thu Feb 08 04:28:49 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.