[SERVER-10262] mongos assertion triggers "Assertion: 16634:field names of bound { yearMonthDay: MinKey } do not match those of keyPattern { _id: 1.0 }" Created: 19/Jul/13  Updated: 19/Jul/13  Resolved: 19/Jul/13

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 2.4.5
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Chad Tindel Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-6357 Add tag based sharding commands Closed
Operating System: ALL
Participants:

 Description   

I'm playing with shard tagging. I'm pretty sure I did something incorrectly, but the shell gave no error and I don't think I should be able to make mongos trigger an assertion by misconfiguring something using shell commands. Here's the details:

Assertion: 16634:field names of bound

{ yearMonthDay: MinKey }

do not match those of keyPattern

{ _id: 1.0 }

> sh.status()
Fri Jul 19 11:33:29.390 trying reconnect to 127.0.0.1:27017
Fri Jul 19 11:33:29.390 reconnect 127.0.0.1:27017 ok
— Sharding Status —
sharding version: {
"_id" : 1,
"version" : 3,
"minCompatibleVersion" : 3,
"currentVersion" : 4,
"clusterId" : ObjectId("51e863e9a9dbd997b14cf9b6")
}
shards:

{ "_id" : "fast1", "host" : "fast1/localhost:37017,localhost:37018,localhost:37019", "tags" : [ "fast" ] } { "_id" : "fast2", "host" : "fast2/localhost:37020,localhost:37021,localhost:37022", "tags" : [ "fast" ] } { "_id" : "slow1", "host" : "slow1/localhost:47017,localhost:47018,localhost:47019", "tags" : [ "slow" ] } { "_id" : "slow2", "host" : "slow2/localhost:47020,localhost:47021,localhost:47022", "tags" : [ "slow" ] }

databases:

{ "_id" : "admin", "partitioned" : false, "primary" : "config" } { "_id" : "uhg", "partitioned" : true, "primary" : "fast1" }

uhg.claims
shard key:

{ "_id" : 1 }

chunks:
fast1 1
{ "_id" :

{ "$minKey" : 1 }

} -->> { "_id" :

{ "$maxKey" : 1 }

} on : fast1

{ "t" : 1, "i" : 0 }

tag: slow { "yearMonthDay" :

{ "$minKey" : 1 }

} -->>

{ "yearMonthDay" : "20110719" }

tag: fast

{ "yearMonthDay" : "20110720" }

-->> { "yearMonthDay" :

{ "$maxKey" : 1 }

}

I'm guessing the bug is "the shell should not have let me do this configuration which resulted in a later assertion triggering". Let me know if you need more info.

Fri Jul 19 11:41:56.161 [Balancer] Assertion: 16634:field names of bound

{ yearMonthDay: MinKey }

do not match those of keyPattern

{ _id: 1.0 }

0x1002a106b 0x10027d71e 0x10027d7dd 0x1000f256e 0x10016216e 0x10015fae6 0x10027edb5 0x10027f4ea 0x10027f5b6 0x10027f676 0x1002d39e5 0x7fff8e2e67a2 0x7fff8e2d31e1
0 mongos 0x00000001002a106b _ZN5mongo15printStackTraceERSo + 43
1 mongos 0x000000010027d71e _ZN5mongo11msgassertedEiPKc + 174
2 mongos 0x000000010027d7dd _ZN5mongo11msgassertedEiRKSs + 29
3 mongos 0x00000001000f256e _ZNK5mongo10KeyPattern16extendRangeBoundERKNS_7BSONObjEb + 1230
4 mongos 0x000000010016216e _ZN5mongo8Balancer15_doBalanceRoundERNS_12DBClientBaseEPSt6vectorIN5boost10shared_ptrINS_11MigrateInfoEEESaIS7_EE + 7872
5 mongos 0x000000010015fae6 _ZN5mongo8Balancer3runEv + 1772
6 mongos 0x000000010027edb5 _ZN5mongo13BackgroundJob7jobBodyEN5boost10shared_ptrINS0_9JobStatusEEE + 653
7 mongos 0x000000010027f4ea ZNK5boost4_mfi3mf1IvN5mongo13BackgroundJobENS_10shared_ptrINS3_9JobStatusEEEEclEPS3_S6 + 68
8 mongos 0x000000010027f5b6 _ZN5boost3_bi5list2INS0_5valueIPN5mongo13BackgroundJobEEENS2_INS_10shared_ptrINS4_9JobStatusEEEEEEclINS_4_mfi3mf1IvS4_S9_EENS0_5list0EEEvNS0_4typeIvEERT_RT0_i + 54
9 mongos 0x000000010027f676 _ZN5boost6detail11thread_dataINS_3_bi6bind_tIvNS_4_mfi3mf1IvN5mongo13BackgroundJobENS_10shared_ptrINS7_9JobStatusEEEEENS2_5list2INS2_5valueIPS7_EENSD_ISA_EEEEEEE3runEv + 42
10 mongos 0x00000001002d39e5 thread_proxy + 229
11 libsystem_c.dylib 0x00007fff8e2e67a2 _pthread_start + 327
12 libsystem_c.dylib 0x00007fff8e2d31e1 thread_start + 13



 Comments   
Comment by Scott Hernandez (Inactive) [ 19/Jul/13 ]

This is the current design but we are planning to address some of this, but the short of it is that validation is currently only done at runtime.

see SERVER-6357

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