[SERVER-22717] Sudden (huge) spike in Oplog GB/hour on primary member Created: 18/Feb/16  Updated: 18/Feb/16  Resolved: 18/Feb/16

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

Type: Bug Priority: Critical - P2
Reporter: Amanpreet Singh Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Amazon Linux


Attachments: PNG File mms.png    
Issue Links:
Duplicate
duplicates SERVER-22634 Data size change for oplog deletes ca... Closed
Operating System: Linux
Participants:

 Description   

Sudden (huge) spike in Oplog GB/hour on primary member rendered secondaries in "RECOVERY" state. There was no spike in Opcounters, so no idea what went wrong there. Since it's a production db, I wasn't able to wait to collect more information about the issue.

I have added the relevant MMS graphs. Notice the "Oplog GB/hour". First one is primary member, others are secondaries - all running v3.0.9 WiredTiger.



 Comments   
Comment by Ramon Fernandez Marina [ 18/Feb/16 ]

amanpreet@codigami.com, sorry this happened in your production environment, and I understand your not waiting to collect further information.

Looks like you may be hitting SERVER-22634, which hasn't yet ben fixed in a 3.0 release unfortunately. As noted in that ticket MongoDB 3.2 is not impacted, so if this is a critical issue for you you may want to consider upgrading to MongoDB 3.2.3 (released yesterday).

Please note that without the ability to troubleshoot this in more detail there may not be much more we can do and this ticket will be closed. However the symptoms you describe correlate with those observed in SERVER-22634, so I'm tentatively marking this ticket as a duplicate of SERVER-22634.

Regards,
Ramón.

Generated at Thu Feb 08 04:01:14 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.