Re: HOw to avoid Initial sync with dropping all databases

From: Metikov Vadim <metikov.vadim@xxxxxxxxx>
To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Date: Tue, 10 May 2016 23:21:03 -0700 (PDT)
Why ads?
Hello!

2016-05-09 6:58 GMT+05:00 Kevin Adistambha <kevinadi@xxxxxxxxxxx>:

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?

I used next command:
db.runCommand( { removeShard: "unistore-2" } ) 

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

now it is two shards but second is in draining stage 


   - how many config servers

it is three config servers 


   - how many mongos

we have six mongos (one on each client) 

Additional information that may be helpful:

   - the output of db.serverCmdLineOpts() in the mongo shell from each 
   mongod in your deployment

Here is output:
unistore-1:SECONDARY> db.serverCmdLineOpts()
{
        "argv" : [
                "/usr/bin/mongod",
                "--config",
                "/etc/mongod.conf"
        ],
        "parsed" : {
                "config" : "/etc/mongod.conf",
                "replication" : {
                        "replSet" : "unistore-1"
                },
                "storage" : {
                        "dbPath" : "/var/lib/mongodb"
                },
                "systemLog" : {
                        "destination" : "file",
                        "logAppend" : true,
                        "path" : "/var/log/mongodb/mongod.log"
                }
        },
        "ok" : 1
}
unistore-1:SECONDARY>
 


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

Here is output on SECONDARY:
 
unistore-1:SECONDARY> rs.status()
{
        "set" : "unistore-1",
        "date" : ISODate("2016-05-11T06:02:00Z"),
        "myState" : 2,
        "syncingTo" : "79.110.251.109:27017",
        "members" : [
                {
                        "_id" : 3,
                        "name" : "79.172.49.11:27017",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",
                        "uptime" : 477144,
                        "optime" : Timestamp(1462946517, 8),
                        "optimeDate" : ISODate("2016-05-11T06:01:57Z"),
                        "self" : true
                },
                {
                        "_id" : 18,
                        "name" : "79.172.49.73:30000",
                        "health" : 1,
                        "state" : 7,
                        "stateStr" : "ARBITER",
                        "uptime" : 429531,
                        "lastHeartbeat" : ISODate("2016-05-11T06:01:59Z"),
                        "lastHeartbeatRecv" : 
ISODate("2016-05-11T06:01:59Z"),
                        "pingMs" : 0
                },
                {
                        "_id" : 22,
                        "name" : "79.110.251.109:27017",
                        "health" : 1,
                        "state" : 1,
                        "stateStr" : "PRIMARY",
                        "uptime" : 429156,
                        "optime" : Timestamp(1462946517, 8),
                        "optimeDate" : ISODate("2016-05-11T06:01:57Z"),
                        "lastHeartbeat" : ISODate("2016-05-11T06:01:59Z"),
                        "lastHeartbeatRecv" : 
ISODate("2016-05-11T06:01:58Z"),
                        "pingMs" : 109,
                        "electionTime" : Timestamp(1462517538, 1),
                        "electionDate" : ISODate("2016-05-06T06:52:18Z")
                }
        ],
        "ok" : 1
}
unistore-1:SECONDARY>
 


   - the output of sh.status() from any mongos process

Here is it:
mongos> sh.status()
--- Sharding Status ---
  sharding version: {
        "_id" : 1,
        "minCompatibleVersion" : 5,
        "currentVersion" : 6,
        "clusterId" : ObjectId("54dada532e13265e4a8c9568")
}
  shards:
        {  "_id" : "unistore-1",  "host" : "unistore-1/79.110.251.109:27017,
79.172.49.11:27017" }
        {  "_id" : "unistore-2",  "host" : "unistore-2/79.172.49.11:37017,
79.172.49.114:27017",  "draining" : true }
  databases:
        {  "_id" : "admin",  "partitioned" : false,  "primary" : "config" }
        {  "_id" : "grid_fs_test6",  "partitioned" : false,  "primary" : 
"unistore-1" }
        {  "_id" : "grid_fs_test3",  "partitioned" : false,  "primary" : 
"unistore-1" }
        {  "_id" : "grid_fs",  "partitioned" : true,  "primary" : 
"unistore-1" }
                grid_fs.fs.chunks
                        shard key: { "files_id" : 1, "n" : 1 }
                        chunks:
                                unistore-1      222966
                                unistore-2      150871
                        too many chunks to print, use verbose if you want 
to force print
        {  "_id" : "kombu_default",  "partitioned" : false,  "primary" : 
"unistore-1" }
        {  "_id" : "grid_fs_test",  "partitioned" : false,  "primary" : 
"unistore-1" }
        {  "_id" : "test",  "partitioned" : false,  "primary" : 
"unistore-1" }
        {  "_id" : "gridfs",  "partitioned" : false,  "primary" : 
"unistore-1" }

mongos>
 

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

It is too slow. Making one backup took more than 36 hours. May be it is 
because of disk I/O. I will try dump/restore procedure without file 
creation in future.


   - 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

Yes i used mongodump with --repair option. Without repair mongodump 
stopped with error(data corruption: Assertion: 10334:BSONObj size: 0 
(0x00000000) is invalid. Size must be between 0 and 16793600(16MB) First 
element: EOO)

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.

Yes , i deleted many records but not more than a half. II have 7 TB of data 
in 8TB datafiles minimum.
 

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 a topic in the 
Google Groups "mongodb-user" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/mongodb-user/O0Z4t17N2wI/unsubscribe.
To unsubscribe from this group and all its topics, 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 ;
<https://groups.google.com/d/msgid/mongodb-user/c279fe5f-699e-4ed9-a217-e35e82859f0e%40googlegroups.com?utm_medium=email&utm_source=footer>
.

For more options, visit https://groups.google.com/d/optout.


Thank you for cooperation, Kevin.

-- 
Regards, Vadim

-- 
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/a7979b84-0d79-4e7e-a26e-b56c7ad1138f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Why ads?