[SERVER-17703] dropDatabase not removing folders with wiredTiger Created: 23/Mar/15  Updated: 15/Jun/20  Resolved: 01/Jul/15

Status: Closed
Project: Core Server
Component/s: WiredTiger
Affects Version/s: 3.0.0
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Chad Kreimendahl Assignee: Unassigned
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-22985 Allow dropDatabase to accept flags to... Closed
is related to SERVER-48882 If directoryperdb is active, remove e... Closed
is related to SERVER-1379 dropdb with directoryperdb should rem... Closed
Operating System: ALL
Participants:

 Description   

When doing a dropDatabase() using MMAPv1 on versions from 2.4 -> 3.0.1, the relevant folders which contain the data when using directoryPerDB: true are also removed.

However, when performing the same dropDatabase using the wiredTiger engine and directoryPerDB: true, the directories are left in-tact, and only the related files are removed.

(note, only tested with directoryForIndexes: true in 3.0.1)



 Comments   
Comment by Michael Brenden [ 20/Oct/19 ]

ditto

"Feature request / Improvement request:
"Please implement a serverparameter "remove database directory when database is dropped" YES | NO | NO_LINKS_ONLY

Comment by Johannes Richter [ 07/Mar/16 ]

Dear team,
We create and drop databases on the fly leading to several thousand empty folders on the filesystem after a week.

Feature request / Improvement request:
Please implement a serverparameter "remove database directory when database is dropped" YES | NO | NO_LINKS_ONLY

Best regards,
Johannes

Comment by Daniel Pasette (Inactive) [ 01/Jul/15 ]

Have decided to not fix and instead change MMAP to be consistent with what WiredTiger already does.

Comment by Chad Kreimendahl [ 30/Jun/15 ]

Works for me. I was just looking for consistency more than anything.

Comment by Daniel Pasette (Inactive) [ 30/Jun/15 ]

sallgeud, I found this related issue from the archives: SERVER-1379. I think the desired behavior is actually to remove the contents of the database directory for a couple reasons. If users have a mount point for one of the db directories, it will not be removed when you dropDatabase, so this would lead to inconsistent behavior depending on how you've configured your system. We could ignore the error message, but that seems like a error prone approach.

Furthermore, if you have a symlink pointing to a directory within a separate volume, calling dropDatabase only deletes the symlink, it doesn't actually delete the data files – which I think is a bug. If you then recreate the symlink without deleting the data files, mongodb with mmap will happily allow you to continue using the old datafiles.

Comment by Michael Cahill (Inactive) [ 24/Mar/15 ]

One issue with this change is if the "directory" is in fact a symbolic link to another volume – if the link is removed by a drop then a subsequent create would make a directory on the wrong volume. I'll check exactly what happens with mmap_v1 – I agree that it would be good to match those semantics.

Comment by Chad Kreimendahl [ 23/Mar/15 ]

I think this is entirely about maintenance for us. Other than the potential of having to check thousands of directories unnecessarily in the future, I don't imagine it's a bad issue. Of course, consistency is good.... as is cleanliness. Given that the directory has no purpose following a drop, it would make sense to remove it. In the event you've created a partition for it, the delete would return fine, but the mount would still appear, so no harm in that scenario would be caused.

Comment by Ramon Fernandez Marina [ 23/Mar/15 ]

Thanks for the report sallgeud, I can reproduce with --directoryperdb as well, so we're investigating.

Note that I couldn't see any ill-effects related to this behavior: I ran a quick test and I could re-create the database, create new collections, and add indexes as expected.

While I can see the difference in behavior between storage engines, I wonder whether this behavior is a better choice than removing the directory since directoryperdb is commonly used to host different databases in different filesystems.

Generated at Thu Feb 08 03:45:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.