[SERVER-37728] Disabling majority reads negates some goals of filesystem backups Created: 24/Oct/18 Updated: 14/Nov/18 Resolved: 14/Nov/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication, Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Daniel Gottlieb (Inactive) | Assignee: | William Schultz (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Sprint: | Repl 2018-11-19 | ||||||||
| Participants: | |||||||||
| Description |
|
The mechanism for reducing history (enableMajorityReads=false) was forward ported from 3.6. In 3.6, MongoDB didn't fully timestamp all writes and thus relied on logging all table writes and performing rollback via refetch. The forward port to 4.0 and master also ported the functionality of enabling logging of all tables. This impacts the goal of filesystem backups to be able to 1) copy majority committed data and 2) the ability to control, via replication recovery, playing data to a specific time T in the oplog. This ticket is a placeholder to make sure we understand the limitations this introduces and discuss, with the backup team/product, what we can do as a whole to reduce the limitations for the least amount of effort. |
| Comments |
| Comment by William Schultz (Inactive) [ 08/Nov/18 ] |
|
daniel.gottlieb Going to close this since |
| Comment by Gregory McKeon (Inactive) [ 29/Oct/18 ] |
|
alyson.cabral so she's aware. william.schultz to follow up with backup/storage and product. |