[SERVER-25297] mongorestore: oplog + capped collection problem Created: 27/Jul/16 Updated: 31/May/17 Resolved: 02/May/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | 3.2.8 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Anton | Assignee: | Kelsey Schubert |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Participants: |
| Description |
|
When I try restore databases from dump, mongorestore gives an error:
dump created by: mongodump with --oplog --gzip options |
| Comments |
| Comment by Kelsey Schubert [ 02/May/17 ] | ||||||||||||
|
Hi Hett, We have manually inspected the files you have uploaded and created a custom build to help us debug this issue. Unfortunately, we are unable to reproduce this behavior. If you're able to provide a script that readily reproduces this issue across environments, please let us know and we will continue to investigate. Thank you, | ||||||||||||
| Comment by Anton [ 18/Oct/16 ] | ||||||||||||
|
that's how I did dump:
| ||||||||||||
| Comment by Anton [ 05/Oct/16 ] | ||||||||||||
|
Hi,
| ||||||||||||
| Comment by Kelsey Schubert [ 03/Oct/16 ] | ||||||||||||
|
Hi Hett, Thanks for the additional information. Unfortunately, the use of the Timestamp data type would not explain this issue. To help our investigation, I have few follow up questions:
Thank you, | ||||||||||||
| Comment by Anton [ 20/Sep/16 ] | ||||||||||||
|
Hello! Just I found in our application usage Timestamp datatype instead of ISODate. >The BSON timestamp type is for internal MongoDB use. For most cases, in application development, you will want to use the BSON date type. See Date for more information. Maybe this was the reason for the failure? | ||||||||||||
| Comment by Anton [ 12/Aug/16 ] | ||||||||||||
|
Hi, >Please answer the following questions so we can continue to investigate:
Sorry for my english. | ||||||||||||
| Comment by Kelsey Schubert [ 09/Aug/16 ] | ||||||||||||
|
Hi Hett, Thank you for uploading the oplog of the dump, however, to continue to debug this issue we will the complete dump, which will contain the objects in their initial size and create the collections with the appropriate settings. My understanding is that the data was dumped from a 3.2.8 node and was attempted to be restored into a 3.2.8 node as well. If that is not the case, what you are observing may be expected. In MongoDB 3.2, if an update changes the document size, the operation will fail. In MongoDB 3.0, with MMAPv1 only if the update operation causes a document to grow beyond the document’s original size would the update operation would fail, and with WiredTiger there was no restriction on objects in capped collections ( Please answer the following questions so we can continue to investigate:
Thanks again, | ||||||||||||
| Comment by Anton [ 27/Jul/16 ] | ||||||||||||
|
Ramon Fernandez,
I uploaded oplog on secure portal. | ||||||||||||
| Comment by Ramon Fernandez Marina [ 27/Jul/16 ] | ||||||||||||
|
Hett, what versions of mongod and mongodump did you use to dump the data? If this is all 3.2.8, it could be helpful for use to have access to the data dump itself; I've created a secure upload portal where you can upload the file(s) created by mongodump – please let us know if you can upload your oplog so we can investigate further. Thanks, | ||||||||||||
| Comment by Anton [ 27/Jul/16 ] | ||||||||||||
|