Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-19633

Fatal Assertion 16360 during initial sync

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 2.6.9, 2.6.10
    • Component/s: Replication
    • None
    • ALL

      After provisioning a new database server, and adding it to our existing replica set, we got this error during the initial sync. A large portion of the data transferred successfully before we got the error.

      The duplicate key error mentioned in the logs does not exist on the primary. The index in question (on Primary) is:

      	{
      		"v" : 0,
      		"unique" : true,
      		"key" : {
      			"linkedin_ids" : 1
      		},
      		"name" : "linkedin_ids_1",
      		"ns" : "datafox.mappings",
      		"sparse" : true,
      		"background" : true,
      		"safe" : null
      	}
      

      The pre-existing Primary and Secondary hosts are running 2.6.9, but the new server (on which the error occurs) is running 2.6.10.

      We've tried to bring this new host up twice, and got the same error both times. (Though on different objects)

      2015-07-27T20:48:29.379-0700 [initandlisten] connection accepted from 172.31.16.82:37930 #825633 (318 connections now open)
      2015-07-27T20:48:29.488-0700 [initandlisten] connection accepted from 172.31.10.102:60198 #825634 (319 connections now open)
      2015-07-27T20:48:29.531-0700 [repl writer worker 2] ERROR: writer worker caught exception:  :: caused by :: 11000 E11000 duplicate key error index: datafox.mappings.$linkedin_ids_1  dup key: { : undefined } on: { ts: Timestamp 1438054759000|1, h: -7888321465560204017, v: 2, op: "u", ns: "datafox.mappings", o2: { _id: ObjectId('54fdb9c9998e85da06001fd7') }, o: { $set: { mtime: new Date(1438054759071), urls.1: { url: "www.boosharticles.com/", url_domain: "boosharticles.com", _id: ObjectId('55b6f96701c3755e3800f0c4') }, __v: 1 } } }
      2015-07-27T20:48:29.531-0700 [repl writer worker 2] Fatal Assertion 16360
      2015-07-27T20:48:29.531-0700 [repl writer worker 2] 
      
      ***aborting after fassert() failure
      

            Assignee:
            ramon.fernandez@mongodb.com Ramon Fernandez Marina
            Reporter:
            jr@datafox.co John Fisher
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: