[SERVER-17543]  WT secondary fall to “recovery” when MMAP secondary keep going under insert only workload Created: 11/Mar/15  Updated: 08/Apr/15  Resolved: 08/Apr/15

Status: Closed
Project: Core Server
Component/s: Replication, Storage
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Eitan Klein Assignee: Eitan Klein
Resolution: Incomplete Votes: 0
Labels: 28qa
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File MMAPSecondery.txt     Text File WTSecondery.txt     Text File rs3primary.txt    
Operating System: ALL
Participants:

 Description   

Version - RC11

Environment:
3 members replica set with the setting below:

  • Primary WT (compression enabled 1GB cache)
  • Secondary WT no compression (journal and block)
  • Secondary MMAP

Machine – Dedicated 6 core machine for WT and 4 core for MMAP

 Used hammer.mongo to do insert only workload , 6 threads
 OS: Windows

MongoDB shell version: 3.0.0-rc11
connecting to: 127.0.0.1:5002/test
EitanRs3a:PRIMARY> rs.status()
{
        "set" : "EitanRs3a",
        "date" : ISODate("2015-03-11T15:23:10.223Z"),
        "myState" : 1,
        "members" : [
                {
                        "_id" : 0,
                        "name" : "eitan5:5002",
                        "health" : 1,
                        "state" : 1,
                        "stateStr" : "PRIMARY",
                        "uptime" : 10657,
                        "optime" : Timestamp(1426087390, 2870),
                        "optimeDate" : ISODate("2015-03-11T15:23:10Z"),
                        "electionTime" : Timestamp(1426076744, 2),
                        "electionDate" : ISODate("2015-03-11T12:25:44Z"),
                        "configVersion" : 3,
                        "self" : true
                },
                {
                        "_id" : 1,
                        "name" : "eitan1:5002",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",
                        "uptime" : 10572,
                        "optime" : Timestamp(1426087297, 6834),
                        "optimeDate" : ISODate("2015-03-11T15:21:37Z"),
                        "lastHeartbeat" : ISODate("2015-03-11T15:23:09.143Z"),
                        "lastHeartbeatRecv" : ISODate("2015-03-11T15:23:10.112Z"
),
                        "pingMs" : 0,
                        "syncingTo" : "eitan5:5002",
                        "configVersion" : 3
                },
                {
                        "_id" : 2,
                        "name" : "eitan6:5001",
                        "health" : 1,
                        "state" : 3,
                        "stateStr" : "RECOVERING",
                        "uptime" : 10555,
                        "optime" : Timestamp(1426079421, 2354),
                        "optimeDate" : ISODate("2015-03-11T13:10:21Z"),
                        "lastHeartbeat" : ISODate("2015-03-11T15:23:08.363Z"),
                        "lastHeartbeatRecv" : ISODate("2015-03-11T15:23:08.628Z"
),
                        "pingMs" : 1,
                        "configVersion" : 3
                }
        ],
        "ok" : 1
}

I will work with michael.grundy@10gen.com to understand the why happen before the replica set fall beyond



 Comments   
Comment by Eitan Klein [ 08/Apr/15 ]

michael.grundy@10gen.com Did you had a chance to look into this? did you learned something?

Generated at Thu Feb 08 03:44:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.