[SERVER-7720] Building an index with a too-long name should always fail Created: 20/Nov/12  Updated: 12/Jul/17  Resolved: 24/Jun/13

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 2.2.1
Fix Version/s: 2.5.1

Type: Bug Priority: Major - P3
Reporter: Derek Buttineau Assignee: Matt Dannenberg
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu Server


Issue Links:
Related
related to SERVER-29373 Two Phase Drops: Relax index namespac... Closed
Backwards Compatibility: Minor Change
Operating System: ALL
Participants:

 Description   

We found (by accident) that if a command that generates an error (in this case a create index that had too long of a name) is shipped to a replica, the replica dies a horrible death.

Tue Nov 20 07:48:50 [repl writer worker 2] build index gshiftlabs.blekko_backlink_daily_metrics

{ presence_id: 1, web_site_id: 1, competitor_id: 1, web_page_id: 1, external_page_id: 1, recorded_on: 1 }

background
Tue Nov 20 07:48:51 [repl writer worker 2] ERROR: exception: ns name too long, max size is 128 on: { ts: Timestamp 1353357103000|4, h: 4767433707090496134, v: 2, op: "i", ns: "gshiftlabs.system.indexes", o: { unique: true, background: tru
e, dropDups: true, ns: "gshiftlabs.blekko_backlink_daily_metrics", key:

{ presence_id: 1, web_site_id: 1, competitor_id: 1, web_page_id: 1, external_page_id: 1, recorded_on: 1 }

, name: "presence_id_1_web_site_id_1_competitor_id_1_web_page
_id_1_external_page_id_1_recorded_on_1" } }
Tue Nov 20 07:48:51 [repl writer worker 2] Fatal Assertion 16361
0xaf8c41 0xabe223 0x99c807 0xacc4cd 0xb3ec79 0x7fabe36d6e9a 0x7fabe29ec4bd
/usr/bin/mongod(_ZN5mongo15printStackTraceERSo+0x21) [0xaf8c41]
/usr/bin/mongod(_ZN5mongo13fassertFailedEi+0xa3) [0xabe223]
/usr/bin/mongod(_ZN5mongo7replset21multiInitialSyncApplyERKSt6vectorINS_7BSONObjESaIS2_EEPNS0_8SyncTailE+0x197) [0x99c807]
/usr/bin/mongod(_ZN5mongo10threadpool6Worker4loopEv+0x26d) [0xacc4cd]
/usr/bin/mongod() [0xb3ec79]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x7fabe36d6e9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fabe29ec4bd]
Tue Nov 20 07:48:51 [repl writer worker 2]

***aborting after fassert() failure

Tue Nov 20 07:48:51 Got signal: 6 (Aborted).

Tue Nov 20 07:48:51 Backtrace:
0xaf8c41 0x5586c9 0x7fabe29304c0 0x7fabe2930445 0x7fabe2933bab 0xabe25e 0x99c807 0xacc4cd 0xb3ec79 0x7fabe36d6e9a 0x7fabe29ec4bd
/usr/bin/mongod(_ZN5mongo15printStackTraceERSo+0x21) [0xaf8c41]
/usr/bin/mongod(_ZN5mongo10abruptQuitEi+0x399) [0x5586c9]
/lib/x86_64-linux-gnu/libc.so.6(+0x364c0) [0x7fabe29304c0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7fabe2930445]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x7fabe2933bab]
/usr/bin/mongod(_ZN5mongo13fassertFailedEi+0xde) [0xabe25e]
/usr/bin/mongod(_ZN5mongo7replset21multiInitialSyncApplyERKSt6vectorINS_7BSONObjESaIS2_EEPNS0_8SyncTailE+0x197) [0x99c807]
/usr/bin/mongod(_ZN5mongo10threadpool6Worker4loopEv+0x26d) [0xacc4cd]
/usr/bin/mongod() [0xb3ec79]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x7fabe36d6e9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fabe29ec4bd]

          • SERVER RESTARTED *****


 Comments   
Comment by auto [ 28/May/13 ]

Author:

{u'username': u'dannenberg', u'name': u'Matt Dannenberg', u'email': u'matt.dannenberg@10gen.com'}

Message: SERVER-7720 fail on createIndex with a too-long name even if it already exists by another name
Branch: master
https://github.com/mongodb/mongo/commit/60f86587e5f528fc0f5685ce7f9fb25fa415ca2a

Comment by Derek Buttineau [ 21/Nov/12 ]

In this case, the index was already applied to the primary (but with a supplied shortened name).

ensureIndex() was ran again on the primary (but without the name), but since the index already existed on the primary the "too long" error wasn't raised on the primary. The index command was then propagated to the secondaries (which were still recovering so didn't yet have the index) resulting in the error and then the Fatal Assertion.

Comment by Daniel Pasette (Inactive) [ 21/Nov/12 ]

What do you mean by "a command that gets shipped to a replica?" If the command errors out on the primary, it should not get propagated to the secondary.

Generated at Thu Feb 08 03:15:24 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.