[DOCS-6458] MongoOplog Deprecated in 3.2 Created: 26/Oct/15 Updated: 11/Jul/16 Resolved: 18/Apr/16 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Osmar Olivo | Assignee: | Allison Reinheimer Moore |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: | |
| Days since reply: | 7 years, 39 weeks, 1 day ago |
| Description |
|
the mongooplog tool is being deprecated as part of the 3.2.0 release. All documentation regarding mongooplog should reflect this and label it as a deprecated tool that will potentially be removed at some point in the future. |
| Comments |
| Comment by CenZheng [ 18/May/16 ] |
|
Hi Osmar Olivo, |
| Comment by Osmar Olivo [ 17/May/16 ] |
|
Hi zhcn381, Yes, mongooplog was simply deprecated in 3.2, but not removed. Though it is important to keep in mind that the deprecated label means it will likely be removed in a future release. There are many users who have modified mongooplog in different ways to achieve what they have needed, which is a testament to our needing to either improve or replace it with something that has this functionality out of the box. There are no problems in functionality with this tool in single nodes. But we find that as users scale their clusters, if they find that features and tools that they used to use on single nodes or replicas no longer work sharded, it can lead to a bad overall experience. You should be able to perform a similar real time migration in 3.2 by performing a mongodump with the --oplog flag and streaming it's output directly into a mongorestore on another single node. Performance may be degraded somewhat by the mongodump causing some memory churn, but overall this is a cleaner solution for fully migrating data and the changes that occur during a migration . |
| Comment by CenZheng [ 17/May/16 ] |
|
Hi Osmar Olivo, |
| Comment by Osmar Olivo [ 16/May/16 ] |
|
Hi zhcn381, We deprecated mongooplog in order to simplify our offering and reduce the number of products we support with duplicate capabilities. As of 3.2, mongodump/restore supports streaming over named pipes, archiving, and compression. The combination of these capabilities with the pre-existing --oplog and --oplogReplay capabilities allow you to perform most of the tasks you would have ever used mongooplog for. You can now stream operations as well as the data itself to other nodes or clusters directly and leverage point in time restore capabilities both locally and remotely, Another reason for deprecating mongooplog is that it has relatively undefined behavior in sharded environments, from a consistency perspective. Mongodump/restore has similar issues from a consistency perspective, as both tools focus on single nodes and not the cluster as a whole. The main difference is that there is a workaround for mongodump/restore in that it is consistent if writes stop to the sharded cluster while the dump is performed. There is no workaround for mongooplog at all. Neither tool is suited for having a cluster tail another cluster and keeping the data consistent regardless of topology. This feature will likely be included in a future release as a new tool or offering. Anyone using mongooplog for these purposes is likely not fully aware of the risks and shortcoming, whereas it is much more obvious in mongodump/restore what the risks are. I hope that answers your question. Please reach out if you have any other questions or comments. |
| Comment by CenZheng [ 12/May/16 ] |
|
hi |
| Comment by Githook User [ 18/Apr/16 ] |
|
Author: {u'username': u'schmalliso', u'name': u'Allison Moore', u'email': u'allison.moore@10gen.com'}Message: |