Re: HOw to avoid Initial sync with dropping all databases

From: Kevin Adistambha <kevinadi@xxxxxxxxxxx>
To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Date: Sun, 8 May 2016 18:58:44 -0700 (PDT)
Why ads?


Hi Metikov,

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

Unfortunately no. The first step in initial sync is always dropping all 
databases. A Secondary is supposed to mirror the data content of the 
Primary, and there is no setting in MongoDB that can avoid this drop 
databases step when a server is attached to an existing replica set.

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. 

Could you elaborate on the steps you performed in your desharding procedure?

Also, I’m a little unclear about the current state of your deployment. My 
understanding is that currently it is a sharded cluster, where each shard 
is a replica set with Primary-Secondary-Arbiter configuration. Could you 
elaborate on:

   - how many shards are there currently 
   - how many config servers 
   - how many mongos 

Additional information that may be helpful:

   - the output of db.serverCmdLineOpts() in the mongo shell from each 
   mongod in your deployment 
   - the output of rs.status() from your replica set (you can connect 
   directly to the replica set’s Primary using the mongo shell to execute 
   this command) 
   - the output of sh.status() from any mongos process 

Regarding data corruption issues: Unfortunately there is little anyone can 
do if you are having data corruption issues due to hardware failures, power 
outages, etc. There are a couple of things you could try, but both of them 
involve some downtime:

   - Restore from a known good backup 
   - Dump the content of your database with mongodump --repair 
   <https://docs.mongodb.com/v2.6/reference/program/mongodump/#cmdoption--repair
   to dump all known good data, and restore to a new deployment 

I would also like to clarify a statement you made in your earlier post:

Ititial sync on new member breaks on 12th datafile and new member promoted 
to state SECONDARY without data (having only 12/3500 files)

It is entirely possible (and perfectly normal) for a Secondary to have 
fewer number of files compared to the Primary. Once a node reach a 
Secondary state <https://docs.mongodb.com/v2.6/reference/replica-states/>, 
it has successfully performed an initial sync, and contains the same data 
as the Primary. For a list of reasons, please see Why are the files in my 
data directory larger than the data in my database 
<https://docs.mongodb.com/v2.6/faq/storage/#why-are-the-files-in-my-data-directory-larger-than-the-data-in-my-database>. 
If you deleted a large amount of data, the section labeled Empty records 
<https://docs.mongodb.com/v2.6/faq/storage/#empty-records> is especially 
relevant.

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/c279fe5f-699e-4ed9-a217-e35e82859f0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Why ads?