[DOCS-600] Best practices for mongooplog tool Created: 12/Oct/12 Updated: 30/Oct/23 Resolved: 07/Nov/12 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual |
| Affects Version/s: | mongodb-2.2 |
| Fix Version/s: | Server_Docs_20231030 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Thomas Rueckstiess | Assignee: | Sam Kleinman (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Participants: | |||||
| Days since reply: | 11 years, 15 weeks ago | ||||
| Description |
|
Customer asking for best practices on mongooplog usage. The docs on mongooplog show some examples but no detailed use cases in the form of Backup and Restoration strategies. |
| Comments |
| Comment by Sam Kleinman (Inactive) [ 07/Nov/12 ] |
|
I think we should discourage people from using mongooplog as a general purpose backup tool, given the narrowness of its use case and the fact that other strategies (like mongodump --oplog) provide better strategy for more users. If you need true asynchronous replication, the better solution is probably to work in the server itself (i.e. feature request) rather than in an offline solution the tool, which will probably provide better results (particularly given the high likelihood of replication-lag type situations with mongooplog). If I misunderstand the request, or you have a specific best practice that you'd like to add to the mongooplog page itself, feel free to reopen this ticket with that suggestion. |