[SERVER-26210] mongodump from SECONDARY Created: 21/Sep/16  Updated: 21/Sep/16  Resolved: 21/Sep/16

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

Type: Question Priority: Minor - P4
Reporter: Anton Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

Hello,
i tried to create dump from SECONDARY server:

> mongodump --oplog --host 127.0.0.1
...
...
2016-09-20T19:44:06.464+0000    [########################]  .oplog  38149065/14594363  (261.4%)
2016-09-20T19:44:09.464+0000    [########################]  .oplog  38149065/14594363  (261.4%)
2016-09-20T19:44:12.464+0000    [########################]  .oplog  38184108/14594363  (261.6%)
2016-09-20T19:44:15.464+0000    [########################]  .oplog  38288534/14594363  (262.4%)
2016-09-20T19:44:18.464+0000    [########################]  .oplog  38394542/14594363  (263.1%)
2016-09-20T19:44:21.464+0000    [########################]  .oplog  38502959/14594363  (263.8%)
2016-09-20T19:44:22.545+0000    [########################]  .oplog  38545805/14594363  (264.1%)
2016-09-20T19:44:22.546+0000            dumped 38545805 oplog entries
2016-09-20T19:44:22.554+0000    Failed: oplog overflow: mongodump was unable to capture all new oplog entries during execution

this is normal behavior?



 Comments   
Comment by Kelsey Schubert [ 21/Sep/16 ]

Hi Hett,

Thanks for reporting this behavior. This is an expected issue when the oplog rolls over while executing mongodump.

The problem is that the first op that occurs after the dump starts is no longer in the oplog after dump finishes. so the section of oplog that needs to be dumped cannot be since it's not all there.

My recommendation would be to increase the size of your oplog to ensure that's big enough so that it takes longer for the ops to be discarded then it takes for the dump to complete.

Kind regards,
Thomas

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