Re: HOw to avoid Initial sync with dropping all databases

From: Kevin Adistambha <kevinadi@xxxxxxxxxxx>
To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Date: Mon, 2 May 2016 23:19:49 -0700 (PDT)
Why ads?


Hi Metikov

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

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?

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()?

If your deployment is a GridFS storage, you can verify the md5 hash of 
every file in GridFS by using the filemd5 command 
<https://docs.mongodb.org/manual/reference/command/filemd5/> and compare it 
with a known md5 hash of that file, which is stored in the fs.files 
collection 
<https://docs.mongodb.org/manual/core/gridfs/#the-files-collection>:

db.fs.files.find()
{
  "_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 
collection 
<https://docs.mongodb.org/manual/core/gridfs/#the-chunks-collection>), 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.

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 
<https://docs.mongodb.org/manual/tutorial/restore-replica-set-from-backup/
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).

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?

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 
<https://docs.mongodb.org/v2.6/core/replica-set-architectures/#consider-fault-tolerance
page, where this situation is described in detail.

Best regards,
Kevin


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

For other MongoDB technical support options, see: https://docs.mongodb.org/manual/support/
--- 
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 https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/6398962c-e464-4031-a013-7ed3f91368d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Why ads?