-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: 3.2.12
-
Component/s: WiredTiger
-
None
-
Environment:amazon linux 2016.03
-
ALL
We're encountering some odd behaviour with an unsharded replica set. The primary is running 3.2.10, the secondary was originally also running 3.2.10, but is now running 3.2.12 (I upgraded to see if the issue went away).
Our usage pattern is that every day we create a smallish number of collections (~13), each containing a few million documents. When we've finished inserting the data for a collection, we drop the correspondind collection from 2 days ago (in theory we could drop all collections except for the ones just created, but we like to have the ability to rollback to the old data). Apart from one small collection with some bookkeeping data, all the collections in this database have this lifecycle of 2-3 days
Occasionally some of these collection drops don't free up disk space on the secondary. Logically the data is the same on the primary and the secondary (ie show collections shows the same output, db.stats() shows very similar numbers), however there the free space on the secondary does not increase and I can observe more files in the mongodb data directory compared to the primary.
Stopping mongodb consistently fixes the issue - the extra files are removed and disk space returns to the same level as the primary. This happens sporadically (sometimes not at all for several weeks, although it seems to be happening a lot at the moment), I have not yet identified what triggers this behaviour. It has never occurred on the primary.
Assuming this isn't a known issue, what data can I provide to assist tracking down this issue. There is nothing that relevant looking in the mongodb log at the point of the mongod stop. I've attached the last few minutes immediately before I stopped mongod - you can see it dropping two collections
- duplicates
-
SERVER-26870 Sometimes collection data file is not removed even though collection is dropped
- Closed