Re: HOw to avoid Initial sync with dropping all databases

From: Metikov Vadim <metikov.vadim@xxxxxxxxx>
To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Date: Thu, 5 May 2016 12:17:37 -0700 (PDT)
Why ads?
I'm sorry for previous answer. Nothing was saved :(

вторник, 3 мая 2016 г., 11:19:50 UTC+5 пользователь Kevin Adistambha 

Hi Metikov

What is the current state of your deployment? Are you still having 
corruption issues?

 No after chunk migration was stopped i see no errors.

Once apon a time we have noticed data corruption

Could you provide some context on the nature of the corruption, e.g. log 
messages, errors, was it due to hardware failure, etc?

Yes. That was due to server power loss. Log messages listed here 

after restoring new member by mongorestore tool

Did I understand correctly that you created a new server, used 
mongorestore to restore a previous dump (which was created using mongodump 
--repair on an existing Secondary), and added this new server to the 
replica set using rs.add()?

Yes. Absolutely.

If your deployment is a GridFS storage, you can verify the md5 hash of 
every file in GridFS by using the filemd5 command 
<> and compare 
it with a known md5 hash of that file, which is stored in the fs.files

  "_id": ObjectId("57282bb698e914b1a826601d"),
  "chunkSize": 261120,
  "uploadDate": ISODate("2016-05-03T04:40:22.837Z"),
  "length": 25,
  "md5": "6395d98c719565ee540354e5f971383a",
  "filename": "test.txt"

If there is corruption on the data in GridFS (i.e. in the fs.chunks
the md5 value will be different:

db.runCommand({filemd5: ObjectId("57282bb698e914b1a826601d"), root: "fs"})
  "numChunks": 1,
  "md5": "db3d76e3cd3bf3a5819efd1316e68657",
  "ok": 1

In the example above, the md5 values between the fs.files collection and 
the result of the filemd5 command differs for file test.txt identified in 
GridFS by ObjectId("57282bb698e914b1a826601d"), which indicates that 
there is a corruption in the GridFS storage of that file.

Thanks to the solution. But when i try to delete corrupted documents i get 
same erros like above. 

it wants to make initial sync with dropping all datafiles.
How to avoid this behavior?

The default behaviour for a Secondary’s initial sync step is to drop all 
databases first. This is because a Secondary is supposed to act as a 
high-availability failover server that could be called on at any time to 
replace the function of the Primary. Therefore, it should be as similar to 
the Primary as possible.

If I understand correctly, your replica set crashed due to data 
corruption, and you would like to restore the replica set using a good 
dump. In this case, you wanted to follow the instructions in the Restore 
a Replica Set from MongoDB Backups 
<> page 
(i.e. create a new replica set using the dumped data). If you restore the 
data into a new server and then attach that restored server into an 
existing replica set, the first thing it will do is to perform initial sync 
with the set’s Primary (which you are seeing).

Can i add new member with low-priority / zero votes / something else to 
avoid initial sync (with dropping datafiles)?

Mongod version is 2.6.11 and now it is a part of sharded cluster

I’m not sure I fully understand your statement here. Could you please 
elaborate on how exactly did you convert this replica set into part of a 
sharded cluster, and for what purpose?

In some point of time we need to use sharding due to big data. All data was 
more than one server storage(11TB). We added a new shard. After that we get 
more spave for new data. Some time after we deleted much documents and all 
data fits to one shard. We have decided to use "desharding" procedure(just 
remove second shard). Some time later chunk migration was stopped due to 
data corruption errors.  

Shard number 1 (unistore-1) consist of Primary , two arbiters and one 
secondary that has been restored from dump.

If your replica set consists of a Primary, a Secondary, and two Arbiters, 
I would recommend you to remove one of the Arbiters, since there is no 
benefit for having two Arbiters vs. only one Arbiter in this configuration. 
Please see Consider Fault Tolerance 
<> page, 
where this situation is described in detail. 

That was temporarily situation. We have three members in each 
shard(primary, secondary and arbiter) now.


Best regards,

You received this message because you are subscribed to the Google Groups "mongodb-user"

For other MongoDB technical support options, see:
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxx.
To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxx.
Visit this group at
To view this discussion on the web visit
For more options, visit
Why ads?