[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: |
|
||||||||
| Issue Links: |
|
||||||||
| 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 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 Regards, |