[SERVER-35756] consider dumping the full oplog in checkDBHashesForReplSet Created: 22/Jun/18 Updated: 22/Jun/18 Resolved: 22/Jun/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | 4.1.1 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | Max Hirschhorn |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Participants: | |||||
| Linked BF Score: | 68 | ||||
| Description |
|
There are numerous occasion when inspecting the oplog entry during a dbHash mismatch failure would be very useful. However, it currently only outputs the last 100 entries and would sometimes not include the most important oplog entry. |
| Comments |
| Comment by Randolph Tan [ 22/Jun/18 ] |
|
max.hirschhorn, I was able to extract the relevant oplog from the data files. You can close this ticket. |
| Comment by Max Hirschhorn [ 22/Jun/18 ] |
|
renctan, you should be able to download a tarball containing the data files of the mongod at the time of the data consistency check failed. I'd recommend examining the contents of the oplog that way instead. In your instance for this Evergreen task, there's a link in the "Files" section saying Data files jstests/concurrency/fsm_all_sharded_with_stepdowns_and_balancer.js - Execution 0 Repetition 0. |