[SERVER-19472] count() incorrect after recovery with WiredTiger Created: 17/Jul/15 Updated: 01/Jun/20 Resolved: 17/Jul/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | WiredTiger |
| Affects Version/s: | 3.0.3, 3.0.4, 3.1.5 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Ronan Bohan | Assignee: | Max Hirschhorn |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||
| Steps To Reproduce: | Insert documents on standalone/primary:
Wait for a while (maybe 100k inserts) and 'kill -9' the mongod. Restart process and check the stats:
|
||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
When mongod is restarted after a hard crash (and a successful recovery) the values returned by 'db.stats.objects', 'db.<coll>.stats.count', 'db.<coll>.count()' are invalid. Note this is not the issue of count in a sharded clusters - it applies to standalone hosts and replica sets too (though only when using WiredTiger) It looks like the count can be reset to the correct value using for example a 'db.<coll>.validate(true)' command. The problem appears to involve the recovery phase when the log/journal is replayed on top of the data from the last successful checkpoint. Note: This is not an issue with data integrity. The data is recovered successfully, it's just the statistics reported by 'db.stats' and relatives which are incorrect following a hard crash/kill. |
| Comments |
| Comment by Ronan Bohan [ 17/Jul/15 ] |
|
Thanks for the quick response Max. I hadn't see the DOCS ticket but it does look like this was a conscious decision ( |
| Comment by Max Hirschhorn [ 17/Jul/15 ] |
|
I think this is "works as designed." Previously with the wiredTiger storage engine, all collections with fewer than 10000 documents would be scanned at start-up in order to compute the accurate count and storage size information. This special case was removed as part of |