I want to know if there is a way to see when a database was dropped. Is there an entry in a log file or some other way to see when this occurred

  • 2
    The answer can also be automatically migrated when we vote to close (migration to DBA is part of the close voting options), at which point a subsequent identical question will be closed as a dupe (or this one will) - cross posting can also lead to down votes, so while it's right to point out that it belongs on DBA, it might not be the best idea to ask the question there also in the interim – Adam C Oct 2 '14 at 10:47
  • @AdamComerford For the record the key word was "instead". Nice answer BTW despite the broad details. Then again I would expect as much from you to answer covering the aspects. But really trying to keep the questions in the "domain space" where the concepts have changed from StackOverflow as a general "dumping ground". And it really should be the OP who migrates rather than leaving it to voting options when there is a clear position that the question is not really suited to the site. The answer is good. The question is just in the wrong place. – Neil Lunn Oct 2 '14 at 11:06

If the drop command ran slowly, then it will be recorded in the logs (by default >100ms), otherwise the only record of it will be in the oplog (assuming you are running a replica set, even a single node replica set) and that is assuming that it did not occur so far in the past that it has "fallen out" of the oplog (which is a capped collection).

NOTE: Before running queries against your oplog, be aware that any such queries will be table scans, and that running such a query will potentially be slow, especially when run on an active replica set with a large oplog. If you have a secondary available, you may wish to use that for this type of query rather than add load to your primary.

With that said, let's show an example. We will call the database "foo", drop it and show how you would search the oplog for evidence of the drop. From the mongo shell your query would look like this:

use local;
db.oplog.rs.find({ns : "foo.$cmd",  "o" : { "dropDatabase" : 1 }})

And the result, if found, would look like this:

        "ts" : Timestamp(1412246712, 1),
        "h" : NumberLong("-6606042550253448275"),
        "v" : 2,
        "op" : "c",
        "ns" : "foo.$cmd",
        "o" : {
                "dropDatabase" : 1

After that, the only other place to gather such evidence would be the filesystem, since the files are unlinked/deleted when the DB is dropped. There are plenty of answers on how to do that (and the potential problems) - I've used this one successfully in the past.

| improve this answer | |
  • 1
    In Mongo 3.0.x the oplogs look a little different, e.g. { "ts" : ... "op" : "c", "ns" : "dbname.$cmd", "o" : { "drop" : "collname" } } where dbname is the database and collname is the collection name – Nicholas Tolley Cottrell Jun 7 '16 at 15:12
  • 1
    Thanks for the heads up - this highlights the fact that the oplog format is considered internal to MongoDB and can be changed at any time without notice, so any sort of reliance on it is dubious at best. Wiredtiger (or anything besides MMAP) will also change the filesystems semantics (and I admit, I have not investigated how it behaves) so things have changed quite a bit since I wrote this answer. – Adam C Jun 7 '16 at 16:10

If you are using MongoDB Enterprise version 2.6+, auditing will record the dropDatabase audit event in the audit log.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy