Primary Shard Server is down, is this normal behavior?Mongo sharding issue with chunk split and Data...

How strictly should I take "Candidates must be local"?

What was the Kree's motivation in Captain Marvel?

When traveling to Europe from North America, do I need to purchase a different power strip?

Accepted offer letter, position changed

How does NOW work?

finite abelian groups tensor product.

Should I take out a loan for a friend to invest on my behalf?

Why was Goose renamed from Chewie for the Captain Marvel film?

PTIJ: wiping amalek’s memory?

Database Backup for data and log files

Why does liquid water form when we exhale on a mirror?

What Happens when Passenger Refuses to Fly Boeing 737 Max?

Does this video of collapsing warehouse shelves show a real incident?

List elements digit difference sort

What is the magic ball of every day?

How do I express some one as a black person?

Is it work or heat?

When a wind turbine does not produce enough electricity how does the power company compensate for the loss?

Is it "Vierergruppe" or "Viergruppe", or is there a distinction?

Was Luke Skywalker the leader of the Rebel forces on Hoth?

What's the "normal" opposite of flautando?

Child Theme Path Being Ignored With wp_enqueue_scripts

How to secure an aircraft at a transient parking space?

What are the practical Opportunty Attack values for a bugbear, holding a reach weapon, with Polearm Mastery?



Primary Shard Server is down, is this normal behavior?


Mongo sharding issue with chunk split and Data transfermongodb shard chunk migration 500GB takes 13 days - Is this slow or normal?MongoDB - Change primary shard only for a certain databaseChunk Size is shown as 1 KB in mongo db logs even it is set to 300 MBMongos version 3.0.1 Split Chunk Error with ShardingWhat will happen if the primary shard for a mongodb database is down?Mongo DB sharded cluster fails when one shard is downReplica Set Question - one primary instance with two secondary instancesMongodb rs.add() new member in STARTUP statewhat if mongos server goes down in shard cluster setup













0















I have two sharded Replica set



RS0
RS1


The balancer is doing chunk migration between primary at RS0 to the primary at RS1.



Once the primary server at RS1 goes down, then the secondary is elected as primary but I can see a strange thing. The migration of chunks stopped and the number of chunks stay the same and all the data inserted to the primary at RS1 in one chunk.



The balancer status is running but no new chunks have been added until I start again the original primary node then the migration is back to work again and the chunks have been added to the RS1.



Is this normal?



sh.status():



    mongos> sh.status()
--- Sharding Status ---
sharding version: {
"_id" : 1,
"minCompatibleVersion" : 5,
"currentVersion" : 6,
"clusterId" : ObjectId("5649d9f147a1deaf459cd461")
}
shards:
{ "_id" : "rs0", "host" : "rs0/PrimaryShardA:27017,SecondaryShardA:270
17" }
{ "_id" : "rs1", "host" : "rs1/PrimaryShardB:27017,SecondaryShardA:250
17" }
balancer:
Currently enabled: yes
Currently running: no
Collections with active migrations:
mohe.alg started at Wed Nov 18 2015 05:35:19 GMT-0800 (Pacific S
tandard Time)
Failed balancer rounds in last 5 attempts: 0
Migration Results for the last 24 hours:
1170 : Success

databases:
{ "_id" : "admin", "partitioned" : false, "primary" : "config" }
{ "_id" : "moe", "partitioned" : false, "primary" : "rs1" }
{ "_id" : "mohe", "partitioned" : true, "primary" : "rs0" }

mohe.alg
shard key: { "dept" : 1, "id" : 1 }
chunks:
rs0 7
rs1 8
{ "dept" : { "$minKey" : 1 }, "id" : { "$minKey" : 1 } }
-->> { "dept" : "C10", "id" : 10 } on : rs1 Timestamp(6, 1)
{ "dept" : "C10", "id" : 10 } -->> { "dept" : "C6", "id"
: 6 } on : rs0 Timestamp(7, 1)
{ "dept" : "C6", "id" : 6 } -->> { "dept" : "H10280", "i
d" : 10280 } on : rs0 Timestamp(2, 2)
{ "dept" : "H10280", "id" : 10280 } -->> { "dept" : "H18
119", "id" : 18119 } on : rs0 Timestamp(2, 3)
{ "dept" : "H18119", "id" : 18119 } -->> { "dept" : "M22
843", "id" : 22843 } on : rs1 Timestamp(3, 2)
{ "dept" : "M22843", "id" : 22843 } -->> { "dept" : "M29
224", "id" : 29224 } on : rs1 Timestamp(3, 3)
{ "dept" : "M29224", "id" : 29224 } -->> { "dept" : "X33
948", "id" : 33948 } on : rs0 Timestamp(4, 2)
{ "dept" : "X33948", "id" : 33948 } -->> { "dept" : "X38
974", "id" : 38974 } on : rs0 Timestamp(4, 3)
{ "dept" : "X38974", "id" : 38974 } -->> { "dept" : "X43
697", "id" : 43697 } on : rs1 Timestamp(5, 2)
{ "dept" : "X43697", "id" : 43697 } -->> { "dept" : "X49
726", "id" : 49726 } on : rs1 Timestamp(5, 3)
{ "dept" : "X49726", "id" : 49726 } -->> { "dept" : "X54
449", "id" : 54449 } on : rs0 Timestamp(6, 2)
{ "dept" : "X54449", "id" : 54449 } -->> { "dept" : "X61
987", "id" : 61987 } on : rs0 Timestamp(6, 3)
{ "dept" : "X61987", "id" : 61987 } -->> { "dept" : "X66
710", "id" : 66710 } on : rs1 Timestamp(7, 2)
{ "dept" : "X66710", "id" : 66710 } -->> { "dept" : "u74
489", "id" : 74489 } on : rs1 Timestamp(7, 3)
{ "dept" : "u74489", "id" : 74489 } -->> { "dept" : { "$
maxKey" : 1 }, "id" : { "$maxKey" : 1 } } on : rs1 Timestamp(7, 4)

{ "_id" : "stds", "partitioned" : false, "primary" : "rs1" }
{ "_id" : "users", "partitioned" : false, "primary" : "rs1" }
{ "_id" : "mongos", "partitioned" : false, "primary" : "rs1" }
{ "_id" : "test", "partitioned" : false, "primary" : "rs0" }

mongos>


rs0.status:



rs1:PRIMARY> rs.status()
{
"set" : "rs1",
"date" : ISODate("2015-11-19T05:24:53.577Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "PrimaryShardB:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 79578,
"optime" : Timestamp(1447910579, 262),
"optimeDate" : ISODate("2015-11-19T05:22:59Z"),
"electionTime" : Timestamp(1447831123, 1),
"electionDate" : ISODate("2015-11-18T07:18:43Z"),
"configVersion" : 8,
"self" : true
},
{
"_id" : 2,
"name" : "Config2Arbiter2:30000",
"health" : 1,
"state" : 7,
"stateStr" : "ARBITER",
"uptime" : 79578,
"lastHeartbeat" : ISODate("2015-11-19T05:24:51.768Z"),
"lastHeartbeatRecv" : ISODate("2015-11-19T05:24:52Z"),
"pingMs" : 0,
"configVersion" : 8
},
{
"_id" : 3,
"name" : "SecondaryShardB:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 52802,
"optime" : Timestamp(1447910579, 262),
"optimeDate" : ISODate("2015-11-19T05:22:59Z"),
"lastHeartbeat" : ISODate("2015-11-19T05:24:52.988Z"),
"lastHeartbeatRecv" : ISODate("2015-11-19T05:24:51.650Z"
),
"pingMs" : 0,
"syncingTo" : "PrimaryShardB:27017",
"configVersion" : 8
}
],
"ok" : 1,
"$gleStats" : {
"lastOpTime" : Timestamp(1447857889, 1),
"electionId" : ObjectId("564c26530b899b6501a068b5")
}
}
rs1:PRIMARY>


rs1.status:



> rs.status()
{
"set" : "rs0",
"date" : ISODate("2015-11-19T05:22:45.355Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "PrimaryShardA:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 74,
"optime" : Timestamp(1447910558, 129),
"optimeDate" : ISODate("2015-11-19T05:22:38Z"),
"electionTime" : Timestamp(1447910499, 1),
"electionDate" : ISODate("2015-11-19T05:21:39Z"),
"configVersion" : 5,
"self" : true
},
{
"_id" : 1,
"name" : "SecondaryShardA:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 73,
"optime" : Timestamp(1447910558, 129),
"optimeDate" : ISODate("2015-11-19T05:22:38Z"),
"lastHeartbeat" : ISODate("2015-11-19T05:22:43.661Z"),
"lastHeartbeatRecv" : ISODate("2015-11-19T05:22:44.703Z"
),
"pingMs" : 0,
"syncingTo" : "PrimaryShardA:27017",
"configVersion" : 5
},
{
"_id" : 2,
"name" : "config1arb1:30000",
"health" : 1,
"state" : 7,
"stateStr" : "ARBITER",
"uptime" : 73,
"lastHeartbeat" : ISODate("2015-11-19T05:22:43.670Z"),
"lastHeartbeatRecv" : ISODate("2015-11-19T05:22:43.648Z"
),
"pingMs" : 0,
"configVersion" : 5
}
],
"ok" : 1,
"$gleStats" : {
"lastOpTime" : Timestamp(0, 0),
"electionId" : ObjectId("564d5c6369be81b02ca1eb55")
}
}
>


mongos db.stats()



 mongos> db.stats()
{
"raw" : {
"rs0/PrimaryShardA:27017,SecondaryShardA:27017" : {
"db" : "mohe",
"collections" : 1,
"objects" : 1121765,
"avgObjSize" : 243.47020900099398,
"dataSize" : 273116359,
"storageSize" : 283131904,
"numExtents" : 0,
"indexes" : 2,
"indexSize" : 490663936,
"ok" : 1,
"$gleStats" : {
"lastOpTime" : Timestamp(0, 0),
"electionId" : ObjectId("564dcd0b1999c29e17f28f5
5")
}
},
"rs1/PrimaryShardB:27017,SecondaryShardB:27017" : {
"db" : "mohe",
"collections" : 1,
"objects" : 878232,
"avgObjSize" : 243.5902791062043,
"dataSize" : 213928778,
"storageSize" : 433602560,
"numExtents" : 0,
"indexes" : 2,
"indexSize" : 389627904,
"ok" : 1
}
},
"objects" : 1999997,
"avgObjSize" : 243,
"dataSize" : 487045137,
"storageSize" : 716734464,
"numExtents" : 0,
"indexes" : 4,
"indexSize" : 880291840,
"fileSize" : 0,
"extentFreeList" : {
"num" : 0,
"totalSize" : 0
},
"ok" : 1
}









share|improve this question
















bumped to the homepage by Community 4 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.











  • 1





    Can you please correct your question (correct spelling and punctuation make it much easier to understand) and add the anonymized output of sh.status()? The output of rs.status() of both shards could be helpful, too.

    – Markus W Mahlberg
    Nov 18 '15 at 9:50













  • Done my friend , please check now

    – Ahmad Abu-Hamideh
    Nov 18 '15 at 14:04











  • Furthermore: "{ "_id" : "rs1", "host" : "rs1/PrimaryShardB:27017,SecondaryShardA:25017" }" This is a mistake coming from anonymization, I assume?

    – Markus W Mahlberg
    Nov 18 '15 at 14:35













  • And your secondary isn't reachable as per rs.status(): stateStr" : "(not reachable/healthy)". Please add the output of rs.status() for "rs1", too. I have the feeling that this might be the same there, which would explain the behavior you are experiencing.

    – Markus W Mahlberg
    Nov 18 '15 at 14:39











  • thanks for your reply , i did that in purpose , as i need to have one server as secondary for both replica set RS0 and RS1.. anyway i removed it and added a new server to the RS1 as SecondaryShardB and re-did the scenario... but still the same , as the data goes to only one shard RS1 until i re-start the second shard rs0 primary server

    – Ahmad Abu-Hamideh
    Nov 18 '15 at 15:03


















0















I have two sharded Replica set



RS0
RS1


The balancer is doing chunk migration between primary at RS0 to the primary at RS1.



Once the primary server at RS1 goes down, then the secondary is elected as primary but I can see a strange thing. The migration of chunks stopped and the number of chunks stay the same and all the data inserted to the primary at RS1 in one chunk.



The balancer status is running but no new chunks have been added until I start again the original primary node then the migration is back to work again and the chunks have been added to the RS1.



Is this normal?



sh.status():



    mongos> sh.status()
--- Sharding Status ---
sharding version: {
"_id" : 1,
"minCompatibleVersion" : 5,
"currentVersion" : 6,
"clusterId" : ObjectId("5649d9f147a1deaf459cd461")
}
shards:
{ "_id" : "rs0", "host" : "rs0/PrimaryShardA:27017,SecondaryShardA:270
17" }
{ "_id" : "rs1", "host" : "rs1/PrimaryShardB:27017,SecondaryShardA:250
17" }
balancer:
Currently enabled: yes
Currently running: no
Collections with active migrations:
mohe.alg started at Wed Nov 18 2015 05:35:19 GMT-0800 (Pacific S
tandard Time)
Failed balancer rounds in last 5 attempts: 0
Migration Results for the last 24 hours:
1170 : Success

databases:
{ "_id" : "admin", "partitioned" : false, "primary" : "config" }
{ "_id" : "moe", "partitioned" : false, "primary" : "rs1" }
{ "_id" : "mohe", "partitioned" : true, "primary" : "rs0" }

mohe.alg
shard key: { "dept" : 1, "id" : 1 }
chunks:
rs0 7
rs1 8
{ "dept" : { "$minKey" : 1 }, "id" : { "$minKey" : 1 } }
-->> { "dept" : "C10", "id" : 10 } on : rs1 Timestamp(6, 1)
{ "dept" : "C10", "id" : 10 } -->> { "dept" : "C6", "id"
: 6 } on : rs0 Timestamp(7, 1)
{ "dept" : "C6", "id" : 6 } -->> { "dept" : "H10280", "i
d" : 10280 } on : rs0 Timestamp(2, 2)
{ "dept" : "H10280", "id" : 10280 } -->> { "dept" : "H18
119", "id" : 18119 } on : rs0 Timestamp(2, 3)
{ "dept" : "H18119", "id" : 18119 } -->> { "dept" : "M22
843", "id" : 22843 } on : rs1 Timestamp(3, 2)
{ "dept" : "M22843", "id" : 22843 } -->> { "dept" : "M29
224", "id" : 29224 } on : rs1 Timestamp(3, 3)
{ "dept" : "M29224", "id" : 29224 } -->> { "dept" : "X33
948", "id" : 33948 } on : rs0 Timestamp(4, 2)
{ "dept" : "X33948", "id" : 33948 } -->> { "dept" : "X38
974", "id" : 38974 } on : rs0 Timestamp(4, 3)
{ "dept" : "X38974", "id" : 38974 } -->> { "dept" : "X43
697", "id" : 43697 } on : rs1 Timestamp(5, 2)
{ "dept" : "X43697", "id" : 43697 } -->> { "dept" : "X49
726", "id" : 49726 } on : rs1 Timestamp(5, 3)
{ "dept" : "X49726", "id" : 49726 } -->> { "dept" : "X54
449", "id" : 54449 } on : rs0 Timestamp(6, 2)
{ "dept" : "X54449", "id" : 54449 } -->> { "dept" : "X61
987", "id" : 61987 } on : rs0 Timestamp(6, 3)
{ "dept" : "X61987", "id" : 61987 } -->> { "dept" : "X66
710", "id" : 66710 } on : rs1 Timestamp(7, 2)
{ "dept" : "X66710", "id" : 66710 } -->> { "dept" : "u74
489", "id" : 74489 } on : rs1 Timestamp(7, 3)
{ "dept" : "u74489", "id" : 74489 } -->> { "dept" : { "$
maxKey" : 1 }, "id" : { "$maxKey" : 1 } } on : rs1 Timestamp(7, 4)

{ "_id" : "stds", "partitioned" : false, "primary" : "rs1" }
{ "_id" : "users", "partitioned" : false, "primary" : "rs1" }
{ "_id" : "mongos", "partitioned" : false, "primary" : "rs1" }
{ "_id" : "test", "partitioned" : false, "primary" : "rs0" }

mongos>


rs0.status:



rs1:PRIMARY> rs.status()
{
"set" : "rs1",
"date" : ISODate("2015-11-19T05:24:53.577Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "PrimaryShardB:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 79578,
"optime" : Timestamp(1447910579, 262),
"optimeDate" : ISODate("2015-11-19T05:22:59Z"),
"electionTime" : Timestamp(1447831123, 1),
"electionDate" : ISODate("2015-11-18T07:18:43Z"),
"configVersion" : 8,
"self" : true
},
{
"_id" : 2,
"name" : "Config2Arbiter2:30000",
"health" : 1,
"state" : 7,
"stateStr" : "ARBITER",
"uptime" : 79578,
"lastHeartbeat" : ISODate("2015-11-19T05:24:51.768Z"),
"lastHeartbeatRecv" : ISODate("2015-11-19T05:24:52Z"),
"pingMs" : 0,
"configVersion" : 8
},
{
"_id" : 3,
"name" : "SecondaryShardB:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 52802,
"optime" : Timestamp(1447910579, 262),
"optimeDate" : ISODate("2015-11-19T05:22:59Z"),
"lastHeartbeat" : ISODate("2015-11-19T05:24:52.988Z"),
"lastHeartbeatRecv" : ISODate("2015-11-19T05:24:51.650Z"
),
"pingMs" : 0,
"syncingTo" : "PrimaryShardB:27017",
"configVersion" : 8
}
],
"ok" : 1,
"$gleStats" : {
"lastOpTime" : Timestamp(1447857889, 1),
"electionId" : ObjectId("564c26530b899b6501a068b5")
}
}
rs1:PRIMARY>


rs1.status:



> rs.status()
{
"set" : "rs0",
"date" : ISODate("2015-11-19T05:22:45.355Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "PrimaryShardA:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 74,
"optime" : Timestamp(1447910558, 129),
"optimeDate" : ISODate("2015-11-19T05:22:38Z"),
"electionTime" : Timestamp(1447910499, 1),
"electionDate" : ISODate("2015-11-19T05:21:39Z"),
"configVersion" : 5,
"self" : true
},
{
"_id" : 1,
"name" : "SecondaryShardA:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 73,
"optime" : Timestamp(1447910558, 129),
"optimeDate" : ISODate("2015-11-19T05:22:38Z"),
"lastHeartbeat" : ISODate("2015-11-19T05:22:43.661Z"),
"lastHeartbeatRecv" : ISODate("2015-11-19T05:22:44.703Z"
),
"pingMs" : 0,
"syncingTo" : "PrimaryShardA:27017",
"configVersion" : 5
},
{
"_id" : 2,
"name" : "config1arb1:30000",
"health" : 1,
"state" : 7,
"stateStr" : "ARBITER",
"uptime" : 73,
"lastHeartbeat" : ISODate("2015-11-19T05:22:43.670Z"),
"lastHeartbeatRecv" : ISODate("2015-11-19T05:22:43.648Z"
),
"pingMs" : 0,
"configVersion" : 5
}
],
"ok" : 1,
"$gleStats" : {
"lastOpTime" : Timestamp(0, 0),
"electionId" : ObjectId("564d5c6369be81b02ca1eb55")
}
}
>


mongos db.stats()



 mongos> db.stats()
{
"raw" : {
"rs0/PrimaryShardA:27017,SecondaryShardA:27017" : {
"db" : "mohe",
"collections" : 1,
"objects" : 1121765,
"avgObjSize" : 243.47020900099398,
"dataSize" : 273116359,
"storageSize" : 283131904,
"numExtents" : 0,
"indexes" : 2,
"indexSize" : 490663936,
"ok" : 1,
"$gleStats" : {
"lastOpTime" : Timestamp(0, 0),
"electionId" : ObjectId("564dcd0b1999c29e17f28f5
5")
}
},
"rs1/PrimaryShardB:27017,SecondaryShardB:27017" : {
"db" : "mohe",
"collections" : 1,
"objects" : 878232,
"avgObjSize" : 243.5902791062043,
"dataSize" : 213928778,
"storageSize" : 433602560,
"numExtents" : 0,
"indexes" : 2,
"indexSize" : 389627904,
"ok" : 1
}
},
"objects" : 1999997,
"avgObjSize" : 243,
"dataSize" : 487045137,
"storageSize" : 716734464,
"numExtents" : 0,
"indexes" : 4,
"indexSize" : 880291840,
"fileSize" : 0,
"extentFreeList" : {
"num" : 0,
"totalSize" : 0
},
"ok" : 1
}









share|improve this question
















bumped to the homepage by Community 4 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.











  • 1





    Can you please correct your question (correct spelling and punctuation make it much easier to understand) and add the anonymized output of sh.status()? The output of rs.status() of both shards could be helpful, too.

    – Markus W Mahlberg
    Nov 18 '15 at 9:50













  • Done my friend , please check now

    – Ahmad Abu-Hamideh
    Nov 18 '15 at 14:04











  • Furthermore: "{ "_id" : "rs1", "host" : "rs1/PrimaryShardB:27017,SecondaryShardA:25017" }" This is a mistake coming from anonymization, I assume?

    – Markus W Mahlberg
    Nov 18 '15 at 14:35













  • And your secondary isn't reachable as per rs.status(): stateStr" : "(not reachable/healthy)". Please add the output of rs.status() for "rs1", too. I have the feeling that this might be the same there, which would explain the behavior you are experiencing.

    – Markus W Mahlberg
    Nov 18 '15 at 14:39











  • thanks for your reply , i did that in purpose , as i need to have one server as secondary for both replica set RS0 and RS1.. anyway i removed it and added a new server to the RS1 as SecondaryShardB and re-did the scenario... but still the same , as the data goes to only one shard RS1 until i re-start the second shard rs0 primary server

    – Ahmad Abu-Hamideh
    Nov 18 '15 at 15:03
















0












0








0








I have two sharded Replica set



RS0
RS1


The balancer is doing chunk migration between primary at RS0 to the primary at RS1.



Once the primary server at RS1 goes down, then the secondary is elected as primary but I can see a strange thing. The migration of chunks stopped and the number of chunks stay the same and all the data inserted to the primary at RS1 in one chunk.



The balancer status is running but no new chunks have been added until I start again the original primary node then the migration is back to work again and the chunks have been added to the RS1.



Is this normal?



sh.status():



    mongos> sh.status()
--- Sharding Status ---
sharding version: {
"_id" : 1,
"minCompatibleVersion" : 5,
"currentVersion" : 6,
"clusterId" : ObjectId("5649d9f147a1deaf459cd461")
}
shards:
{ "_id" : "rs0", "host" : "rs0/PrimaryShardA:27017,SecondaryShardA:270
17" }
{ "_id" : "rs1", "host" : "rs1/PrimaryShardB:27017,SecondaryShardA:250
17" }
balancer:
Currently enabled: yes
Currently running: no
Collections with active migrations:
mohe.alg started at Wed Nov 18 2015 05:35:19 GMT-0800 (Pacific S
tandard Time)
Failed balancer rounds in last 5 attempts: 0
Migration Results for the last 24 hours:
1170 : Success

databases:
{ "_id" : "admin", "partitioned" : false, "primary" : "config" }
{ "_id" : "moe", "partitioned" : false, "primary" : "rs1" }
{ "_id" : "mohe", "partitioned" : true, "primary" : "rs0" }

mohe.alg
shard key: { "dept" : 1, "id" : 1 }
chunks:
rs0 7
rs1 8
{ "dept" : { "$minKey" : 1 }, "id" : { "$minKey" : 1 } }
-->> { "dept" : "C10", "id" : 10 } on : rs1 Timestamp(6, 1)
{ "dept" : "C10", "id" : 10 } -->> { "dept" : "C6", "id"
: 6 } on : rs0 Timestamp(7, 1)
{ "dept" : "C6", "id" : 6 } -->> { "dept" : "H10280", "i
d" : 10280 } on : rs0 Timestamp(2, 2)
{ "dept" : "H10280", "id" : 10280 } -->> { "dept" : "H18
119", "id" : 18119 } on : rs0 Timestamp(2, 3)
{ "dept" : "H18119", "id" : 18119 } -->> { "dept" : "M22
843", "id" : 22843 } on : rs1 Timestamp(3, 2)
{ "dept" : "M22843", "id" : 22843 } -->> { "dept" : "M29
224", "id" : 29224 } on : rs1 Timestamp(3, 3)
{ "dept" : "M29224", "id" : 29224 } -->> { "dept" : "X33
948", "id" : 33948 } on : rs0 Timestamp(4, 2)
{ "dept" : "X33948", "id" : 33948 } -->> { "dept" : "X38
974", "id" : 38974 } on : rs0 Timestamp(4, 3)
{ "dept" : "X38974", "id" : 38974 } -->> { "dept" : "X43
697", "id" : 43697 } on : rs1 Timestamp(5, 2)
{ "dept" : "X43697", "id" : 43697 } -->> { "dept" : "X49
726", "id" : 49726 } on : rs1 Timestamp(5, 3)
{ "dept" : "X49726", "id" : 49726 } -->> { "dept" : "X54
449", "id" : 54449 } on : rs0 Timestamp(6, 2)
{ "dept" : "X54449", "id" : 54449 } -->> { "dept" : "X61
987", "id" : 61987 } on : rs0 Timestamp(6, 3)
{ "dept" : "X61987", "id" : 61987 } -->> { "dept" : "X66
710", "id" : 66710 } on : rs1 Timestamp(7, 2)
{ "dept" : "X66710", "id" : 66710 } -->> { "dept" : "u74
489", "id" : 74489 } on : rs1 Timestamp(7, 3)
{ "dept" : "u74489", "id" : 74489 } -->> { "dept" : { "$
maxKey" : 1 }, "id" : { "$maxKey" : 1 } } on : rs1 Timestamp(7, 4)

{ "_id" : "stds", "partitioned" : false, "primary" : "rs1" }
{ "_id" : "users", "partitioned" : false, "primary" : "rs1" }
{ "_id" : "mongos", "partitioned" : false, "primary" : "rs1" }
{ "_id" : "test", "partitioned" : false, "primary" : "rs0" }

mongos>


rs0.status:



rs1:PRIMARY> rs.status()
{
"set" : "rs1",
"date" : ISODate("2015-11-19T05:24:53.577Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "PrimaryShardB:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 79578,
"optime" : Timestamp(1447910579, 262),
"optimeDate" : ISODate("2015-11-19T05:22:59Z"),
"electionTime" : Timestamp(1447831123, 1),
"electionDate" : ISODate("2015-11-18T07:18:43Z"),
"configVersion" : 8,
"self" : true
},
{
"_id" : 2,
"name" : "Config2Arbiter2:30000",
"health" : 1,
"state" : 7,
"stateStr" : "ARBITER",
"uptime" : 79578,
"lastHeartbeat" : ISODate("2015-11-19T05:24:51.768Z"),
"lastHeartbeatRecv" : ISODate("2015-11-19T05:24:52Z"),
"pingMs" : 0,
"configVersion" : 8
},
{
"_id" : 3,
"name" : "SecondaryShardB:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 52802,
"optime" : Timestamp(1447910579, 262),
"optimeDate" : ISODate("2015-11-19T05:22:59Z"),
"lastHeartbeat" : ISODate("2015-11-19T05:24:52.988Z"),
"lastHeartbeatRecv" : ISODate("2015-11-19T05:24:51.650Z"
),
"pingMs" : 0,
"syncingTo" : "PrimaryShardB:27017",
"configVersion" : 8
}
],
"ok" : 1,
"$gleStats" : {
"lastOpTime" : Timestamp(1447857889, 1),
"electionId" : ObjectId("564c26530b899b6501a068b5")
}
}
rs1:PRIMARY>


rs1.status:



> rs.status()
{
"set" : "rs0",
"date" : ISODate("2015-11-19T05:22:45.355Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "PrimaryShardA:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 74,
"optime" : Timestamp(1447910558, 129),
"optimeDate" : ISODate("2015-11-19T05:22:38Z"),
"electionTime" : Timestamp(1447910499, 1),
"electionDate" : ISODate("2015-11-19T05:21:39Z"),
"configVersion" : 5,
"self" : true
},
{
"_id" : 1,
"name" : "SecondaryShardA:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 73,
"optime" : Timestamp(1447910558, 129),
"optimeDate" : ISODate("2015-11-19T05:22:38Z"),
"lastHeartbeat" : ISODate("2015-11-19T05:22:43.661Z"),
"lastHeartbeatRecv" : ISODate("2015-11-19T05:22:44.703Z"
),
"pingMs" : 0,
"syncingTo" : "PrimaryShardA:27017",
"configVersion" : 5
},
{
"_id" : 2,
"name" : "config1arb1:30000",
"health" : 1,
"state" : 7,
"stateStr" : "ARBITER",
"uptime" : 73,
"lastHeartbeat" : ISODate("2015-11-19T05:22:43.670Z"),
"lastHeartbeatRecv" : ISODate("2015-11-19T05:22:43.648Z"
),
"pingMs" : 0,
"configVersion" : 5
}
],
"ok" : 1,
"$gleStats" : {
"lastOpTime" : Timestamp(0, 0),
"electionId" : ObjectId("564d5c6369be81b02ca1eb55")
}
}
>


mongos db.stats()



 mongos> db.stats()
{
"raw" : {
"rs0/PrimaryShardA:27017,SecondaryShardA:27017" : {
"db" : "mohe",
"collections" : 1,
"objects" : 1121765,
"avgObjSize" : 243.47020900099398,
"dataSize" : 273116359,
"storageSize" : 283131904,
"numExtents" : 0,
"indexes" : 2,
"indexSize" : 490663936,
"ok" : 1,
"$gleStats" : {
"lastOpTime" : Timestamp(0, 0),
"electionId" : ObjectId("564dcd0b1999c29e17f28f5
5")
}
},
"rs1/PrimaryShardB:27017,SecondaryShardB:27017" : {
"db" : "mohe",
"collections" : 1,
"objects" : 878232,
"avgObjSize" : 243.5902791062043,
"dataSize" : 213928778,
"storageSize" : 433602560,
"numExtents" : 0,
"indexes" : 2,
"indexSize" : 389627904,
"ok" : 1
}
},
"objects" : 1999997,
"avgObjSize" : 243,
"dataSize" : 487045137,
"storageSize" : 716734464,
"numExtents" : 0,
"indexes" : 4,
"indexSize" : 880291840,
"fileSize" : 0,
"extentFreeList" : {
"num" : 0,
"totalSize" : 0
},
"ok" : 1
}









share|improve this question
















I have two sharded Replica set



RS0
RS1


The balancer is doing chunk migration between primary at RS0 to the primary at RS1.



Once the primary server at RS1 goes down, then the secondary is elected as primary but I can see a strange thing. The migration of chunks stopped and the number of chunks stay the same and all the data inserted to the primary at RS1 in one chunk.



The balancer status is running but no new chunks have been added until I start again the original primary node then the migration is back to work again and the chunks have been added to the RS1.



Is this normal?



sh.status():



    mongos> sh.status()
--- Sharding Status ---
sharding version: {
"_id" : 1,
"minCompatibleVersion" : 5,
"currentVersion" : 6,
"clusterId" : ObjectId("5649d9f147a1deaf459cd461")
}
shards:
{ "_id" : "rs0", "host" : "rs0/PrimaryShardA:27017,SecondaryShardA:270
17" }
{ "_id" : "rs1", "host" : "rs1/PrimaryShardB:27017,SecondaryShardA:250
17" }
balancer:
Currently enabled: yes
Currently running: no
Collections with active migrations:
mohe.alg started at Wed Nov 18 2015 05:35:19 GMT-0800 (Pacific S
tandard Time)
Failed balancer rounds in last 5 attempts: 0
Migration Results for the last 24 hours:
1170 : Success

databases:
{ "_id" : "admin", "partitioned" : false, "primary" : "config" }
{ "_id" : "moe", "partitioned" : false, "primary" : "rs1" }
{ "_id" : "mohe", "partitioned" : true, "primary" : "rs0" }

mohe.alg
shard key: { "dept" : 1, "id" : 1 }
chunks:
rs0 7
rs1 8
{ "dept" : { "$minKey" : 1 }, "id" : { "$minKey" : 1 } }
-->> { "dept" : "C10", "id" : 10 } on : rs1 Timestamp(6, 1)
{ "dept" : "C10", "id" : 10 } -->> { "dept" : "C6", "id"
: 6 } on : rs0 Timestamp(7, 1)
{ "dept" : "C6", "id" : 6 } -->> { "dept" : "H10280", "i
d" : 10280 } on : rs0 Timestamp(2, 2)
{ "dept" : "H10280", "id" : 10280 } -->> { "dept" : "H18
119", "id" : 18119 } on : rs0 Timestamp(2, 3)
{ "dept" : "H18119", "id" : 18119 } -->> { "dept" : "M22
843", "id" : 22843 } on : rs1 Timestamp(3, 2)
{ "dept" : "M22843", "id" : 22843 } -->> { "dept" : "M29
224", "id" : 29224 } on : rs1 Timestamp(3, 3)
{ "dept" : "M29224", "id" : 29224 } -->> { "dept" : "X33
948", "id" : 33948 } on : rs0 Timestamp(4, 2)
{ "dept" : "X33948", "id" : 33948 } -->> { "dept" : "X38
974", "id" : 38974 } on : rs0 Timestamp(4, 3)
{ "dept" : "X38974", "id" : 38974 } -->> { "dept" : "X43
697", "id" : 43697 } on : rs1 Timestamp(5, 2)
{ "dept" : "X43697", "id" : 43697 } -->> { "dept" : "X49
726", "id" : 49726 } on : rs1 Timestamp(5, 3)
{ "dept" : "X49726", "id" : 49726 } -->> { "dept" : "X54
449", "id" : 54449 } on : rs0 Timestamp(6, 2)
{ "dept" : "X54449", "id" : 54449 } -->> { "dept" : "X61
987", "id" : 61987 } on : rs0 Timestamp(6, 3)
{ "dept" : "X61987", "id" : 61987 } -->> { "dept" : "X66
710", "id" : 66710 } on : rs1 Timestamp(7, 2)
{ "dept" : "X66710", "id" : 66710 } -->> { "dept" : "u74
489", "id" : 74489 } on : rs1 Timestamp(7, 3)
{ "dept" : "u74489", "id" : 74489 } -->> { "dept" : { "$
maxKey" : 1 }, "id" : { "$maxKey" : 1 } } on : rs1 Timestamp(7, 4)

{ "_id" : "stds", "partitioned" : false, "primary" : "rs1" }
{ "_id" : "users", "partitioned" : false, "primary" : "rs1" }
{ "_id" : "mongos", "partitioned" : false, "primary" : "rs1" }
{ "_id" : "test", "partitioned" : false, "primary" : "rs0" }

mongos>


rs0.status:



rs1:PRIMARY> rs.status()
{
"set" : "rs1",
"date" : ISODate("2015-11-19T05:24:53.577Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "PrimaryShardB:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 79578,
"optime" : Timestamp(1447910579, 262),
"optimeDate" : ISODate("2015-11-19T05:22:59Z"),
"electionTime" : Timestamp(1447831123, 1),
"electionDate" : ISODate("2015-11-18T07:18:43Z"),
"configVersion" : 8,
"self" : true
},
{
"_id" : 2,
"name" : "Config2Arbiter2:30000",
"health" : 1,
"state" : 7,
"stateStr" : "ARBITER",
"uptime" : 79578,
"lastHeartbeat" : ISODate("2015-11-19T05:24:51.768Z"),
"lastHeartbeatRecv" : ISODate("2015-11-19T05:24:52Z"),
"pingMs" : 0,
"configVersion" : 8
},
{
"_id" : 3,
"name" : "SecondaryShardB:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 52802,
"optime" : Timestamp(1447910579, 262),
"optimeDate" : ISODate("2015-11-19T05:22:59Z"),
"lastHeartbeat" : ISODate("2015-11-19T05:24:52.988Z"),
"lastHeartbeatRecv" : ISODate("2015-11-19T05:24:51.650Z"
),
"pingMs" : 0,
"syncingTo" : "PrimaryShardB:27017",
"configVersion" : 8
}
],
"ok" : 1,
"$gleStats" : {
"lastOpTime" : Timestamp(1447857889, 1),
"electionId" : ObjectId("564c26530b899b6501a068b5")
}
}
rs1:PRIMARY>


rs1.status:



> rs.status()
{
"set" : "rs0",
"date" : ISODate("2015-11-19T05:22:45.355Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "PrimaryShardA:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 74,
"optime" : Timestamp(1447910558, 129),
"optimeDate" : ISODate("2015-11-19T05:22:38Z"),
"electionTime" : Timestamp(1447910499, 1),
"electionDate" : ISODate("2015-11-19T05:21:39Z"),
"configVersion" : 5,
"self" : true
},
{
"_id" : 1,
"name" : "SecondaryShardA:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 73,
"optime" : Timestamp(1447910558, 129),
"optimeDate" : ISODate("2015-11-19T05:22:38Z"),
"lastHeartbeat" : ISODate("2015-11-19T05:22:43.661Z"),
"lastHeartbeatRecv" : ISODate("2015-11-19T05:22:44.703Z"
),
"pingMs" : 0,
"syncingTo" : "PrimaryShardA:27017",
"configVersion" : 5
},
{
"_id" : 2,
"name" : "config1arb1:30000",
"health" : 1,
"state" : 7,
"stateStr" : "ARBITER",
"uptime" : 73,
"lastHeartbeat" : ISODate("2015-11-19T05:22:43.670Z"),
"lastHeartbeatRecv" : ISODate("2015-11-19T05:22:43.648Z"
),
"pingMs" : 0,
"configVersion" : 5
}
],
"ok" : 1,
"$gleStats" : {
"lastOpTime" : Timestamp(0, 0),
"electionId" : ObjectId("564d5c6369be81b02ca1eb55")
}
}
>


mongos db.stats()



 mongos> db.stats()
{
"raw" : {
"rs0/PrimaryShardA:27017,SecondaryShardA:27017" : {
"db" : "mohe",
"collections" : 1,
"objects" : 1121765,
"avgObjSize" : 243.47020900099398,
"dataSize" : 273116359,
"storageSize" : 283131904,
"numExtents" : 0,
"indexes" : 2,
"indexSize" : 490663936,
"ok" : 1,
"$gleStats" : {
"lastOpTime" : Timestamp(0, 0),
"electionId" : ObjectId("564dcd0b1999c29e17f28f5
5")
}
},
"rs1/PrimaryShardB:27017,SecondaryShardB:27017" : {
"db" : "mohe",
"collections" : 1,
"objects" : 878232,
"avgObjSize" : 243.5902791062043,
"dataSize" : 213928778,
"storageSize" : 433602560,
"numExtents" : 0,
"indexes" : 2,
"indexSize" : 389627904,
"ok" : 1
}
},
"objects" : 1999997,
"avgObjSize" : 243,
"dataSize" : 487045137,
"storageSize" : 716734464,
"numExtents" : 0,
"indexes" : 4,
"indexSize" : 880291840,
"fileSize" : 0,
"extentFreeList" : {
"num" : 0,
"totalSize" : 0
},
"ok" : 1
}






mongodb






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 23 '15 at 5:28







Ahmad Abu-Hamideh

















asked Nov 18 '15 at 7:52









Ahmad Abu-HamidehAhmad Abu-Hamideh

154




154





bumped to the homepage by Community 4 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.







bumped to the homepage by Community 4 mins ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.










  • 1





    Can you please correct your question (correct spelling and punctuation make it much easier to understand) and add the anonymized output of sh.status()? The output of rs.status() of both shards could be helpful, too.

    – Markus W Mahlberg
    Nov 18 '15 at 9:50













  • Done my friend , please check now

    – Ahmad Abu-Hamideh
    Nov 18 '15 at 14:04











  • Furthermore: "{ "_id" : "rs1", "host" : "rs1/PrimaryShardB:27017,SecondaryShardA:25017" }" This is a mistake coming from anonymization, I assume?

    – Markus W Mahlberg
    Nov 18 '15 at 14:35













  • And your secondary isn't reachable as per rs.status(): stateStr" : "(not reachable/healthy)". Please add the output of rs.status() for "rs1", too. I have the feeling that this might be the same there, which would explain the behavior you are experiencing.

    – Markus W Mahlberg
    Nov 18 '15 at 14:39











  • thanks for your reply , i did that in purpose , as i need to have one server as secondary for both replica set RS0 and RS1.. anyway i removed it and added a new server to the RS1 as SecondaryShardB and re-did the scenario... but still the same , as the data goes to only one shard RS1 until i re-start the second shard rs0 primary server

    – Ahmad Abu-Hamideh
    Nov 18 '15 at 15:03
















  • 1





    Can you please correct your question (correct spelling and punctuation make it much easier to understand) and add the anonymized output of sh.status()? The output of rs.status() of both shards could be helpful, too.

    – Markus W Mahlberg
    Nov 18 '15 at 9:50













  • Done my friend , please check now

    – Ahmad Abu-Hamideh
    Nov 18 '15 at 14:04











  • Furthermore: "{ "_id" : "rs1", "host" : "rs1/PrimaryShardB:27017,SecondaryShardA:25017" }" This is a mistake coming from anonymization, I assume?

    – Markus W Mahlberg
    Nov 18 '15 at 14:35













  • And your secondary isn't reachable as per rs.status(): stateStr" : "(not reachable/healthy)". Please add the output of rs.status() for "rs1", too. I have the feeling that this might be the same there, which would explain the behavior you are experiencing.

    – Markus W Mahlberg
    Nov 18 '15 at 14:39











  • thanks for your reply , i did that in purpose , as i need to have one server as secondary for both replica set RS0 and RS1.. anyway i removed it and added a new server to the RS1 as SecondaryShardB and re-did the scenario... but still the same , as the data goes to only one shard RS1 until i re-start the second shard rs0 primary server

    – Ahmad Abu-Hamideh
    Nov 18 '15 at 15:03










1




1





Can you please correct your question (correct spelling and punctuation make it much easier to understand) and add the anonymized output of sh.status()? The output of rs.status() of both shards could be helpful, too.

– Markus W Mahlberg
Nov 18 '15 at 9:50







Can you please correct your question (correct spelling and punctuation make it much easier to understand) and add the anonymized output of sh.status()? The output of rs.status() of both shards could be helpful, too.

– Markus W Mahlberg
Nov 18 '15 at 9:50















Done my friend , please check now

– Ahmad Abu-Hamideh
Nov 18 '15 at 14:04





Done my friend , please check now

– Ahmad Abu-Hamideh
Nov 18 '15 at 14:04













Furthermore: "{ "_id" : "rs1", "host" : "rs1/PrimaryShardB:27017,SecondaryShardA:25017" }" This is a mistake coming from anonymization, I assume?

– Markus W Mahlberg
Nov 18 '15 at 14:35







Furthermore: "{ "_id" : "rs1", "host" : "rs1/PrimaryShardB:27017,SecondaryShardA:25017" }" This is a mistake coming from anonymization, I assume?

– Markus W Mahlberg
Nov 18 '15 at 14:35















And your secondary isn't reachable as per rs.status(): stateStr" : "(not reachable/healthy)". Please add the output of rs.status() for "rs1", too. I have the feeling that this might be the same there, which would explain the behavior you are experiencing.

– Markus W Mahlberg
Nov 18 '15 at 14:39





And your secondary isn't reachable as per rs.status(): stateStr" : "(not reachable/healthy)". Please add the output of rs.status() for "rs1", too. I have the feeling that this might be the same there, which would explain the behavior you are experiencing.

– Markus W Mahlberg
Nov 18 '15 at 14:39













thanks for your reply , i did that in purpose , as i need to have one server as secondary for both replica set RS0 and RS1.. anyway i removed it and added a new server to the RS1 as SecondaryShardB and re-did the scenario... but still the same , as the data goes to only one shard RS1 until i re-start the second shard rs0 primary server

– Ahmad Abu-Hamideh
Nov 18 '15 at 15:03







thanks for your reply , i did that in purpose , as i need to have one server as secondary for both replica set RS0 and RS1.. anyway i removed it and added a new server to the RS1 as SecondaryShardB and re-did the scenario... but still the same , as the data goes to only one shard RS1 until i re-start the second shard rs0 primary server

– Ahmad Abu-Hamideh
Nov 18 '15 at 15:03












1 Answer
1






active

oldest

votes


















0














Can you paste the output of db.chunk.count() and db.chunk().find().pretty() commands?
It will be on config servers.






share|improve this answer























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "182"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f121432%2fprimary-shard-server-is-down-is-this-normal-behavior%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    Can you paste the output of db.chunk.count() and db.chunk().find().pretty() commands?
    It will be on config servers.






    share|improve this answer




























      0














      Can you paste the output of db.chunk.count() and db.chunk().find().pretty() commands?
      It will be on config servers.






      share|improve this answer


























        0












        0








        0







        Can you paste the output of db.chunk.count() and db.chunk().find().pretty() commands?
        It will be on config servers.






        share|improve this answer













        Can you paste the output of db.chunk.count() and db.chunk().find().pretty() commands?
        It will be on config servers.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 23 '15 at 18:21









        harshavmbharshavmb

        18519




        18519






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Database Administrators Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f121432%2fprimary-shard-server-is-down-is-this-normal-behavior%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Parapolítica Índice Antecedentes El escándalo Proceso judicial Consecuencias Véase...

            How to remove border from elements in the last row?Targeting flex items on the last rowHow to vertically wrap...

            Tecnologías entrañables Índice Antecedentes Desarrollo Tecnologías Entrañables en la...