Truncate a collection












47















How do I truncate a collection in MongoDB or is there such a thing?



Right now I have to delete 6 large collections all at once and I'm stopping the server, deleting the database files and then recreating the database and the collections in it. Is there a way to delete the data and leave the collection as it is? The delete operation takes very long time. I have millions of entries in the collections.










share|improve this question























  • How are you doing the delete operation (when it is taking a very long time)?

    – Stennie
    May 11 '13 at 7:47








  • 8





    db.collection.remove({ });

    – iefpw
    May 11 '13 at 18:14








  • 4





    Ah! The remove() command will be much slower than drop() for a large collection because it does the extra housekeeping of updating indexes as documents are deleted. If you are deleting all documents in a collection then drop() is generally the best approach. The caveat with dropping & recreating the same collection is that you will also need to re-ensure any secondary indexes.

    – Stennie
    May 11 '13 at 22:02
















47















How do I truncate a collection in MongoDB or is there such a thing?



Right now I have to delete 6 large collections all at once and I'm stopping the server, deleting the database files and then recreating the database and the collections in it. Is there a way to delete the data and leave the collection as it is? The delete operation takes very long time. I have millions of entries in the collections.










share|improve this question























  • How are you doing the delete operation (when it is taking a very long time)?

    – Stennie
    May 11 '13 at 7:47








  • 8





    db.collection.remove({ });

    – iefpw
    May 11 '13 at 18:14








  • 4





    Ah! The remove() command will be much slower than drop() for a large collection because it does the extra housekeeping of updating indexes as documents are deleted. If you are deleting all documents in a collection then drop() is generally the best approach. The caveat with dropping & recreating the same collection is that you will also need to re-ensure any secondary indexes.

    – Stennie
    May 11 '13 at 22:02














47












47








47


11






How do I truncate a collection in MongoDB or is there such a thing?



Right now I have to delete 6 large collections all at once and I'm stopping the server, deleting the database files and then recreating the database and the collections in it. Is there a way to delete the data and leave the collection as it is? The delete operation takes very long time. I have millions of entries in the collections.










share|improve this question














How do I truncate a collection in MongoDB or is there such a thing?



Right now I have to delete 6 large collections all at once and I'm stopping the server, deleting the database files and then recreating the database and the collections in it. Is there a way to delete the data and leave the collection as it is? The delete operation takes very long time. I have millions of entries in the collections.







mongodb mongodb-.net-driver






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked May 11 '13 at 4:58









iefpwiefpw

3,353143869




3,353143869













  • How are you doing the delete operation (when it is taking a very long time)?

    – Stennie
    May 11 '13 at 7:47








  • 8





    db.collection.remove({ });

    – iefpw
    May 11 '13 at 18:14








  • 4





    Ah! The remove() command will be much slower than drop() for a large collection because it does the extra housekeeping of updating indexes as documents are deleted. If you are deleting all documents in a collection then drop() is generally the best approach. The caveat with dropping & recreating the same collection is that you will also need to re-ensure any secondary indexes.

    – Stennie
    May 11 '13 at 22:02



















  • How are you doing the delete operation (when it is taking a very long time)?

    – Stennie
    May 11 '13 at 7:47








  • 8





    db.collection.remove({ });

    – iefpw
    May 11 '13 at 18:14








  • 4





    Ah! The remove() command will be much slower than drop() for a large collection because it does the extra housekeeping of updating indexes as documents are deleted. If you are deleting all documents in a collection then drop() is generally the best approach. The caveat with dropping & recreating the same collection is that you will also need to re-ensure any secondary indexes.

    – Stennie
    May 11 '13 at 22:02

















How are you doing the delete operation (when it is taking a very long time)?

– Stennie
May 11 '13 at 7:47







How are you doing the delete operation (when it is taking a very long time)?

– Stennie
May 11 '13 at 7:47






8




8





db.collection.remove({ });

– iefpw
May 11 '13 at 18:14







db.collection.remove({ });

– iefpw
May 11 '13 at 18:14






4




4





Ah! The remove() command will be much slower than drop() for a large collection because it does the extra housekeeping of updating indexes as documents are deleted. If you are deleting all documents in a collection then drop() is generally the best approach. The caveat with dropping & recreating the same collection is that you will also need to re-ensure any secondary indexes.

– Stennie
May 11 '13 at 22:02





Ah! The remove() command will be much slower than drop() for a large collection because it does the extra housekeeping of updating indexes as documents are deleted. If you are deleting all documents in a collection then drop() is generally the best approach. The caveat with dropping & recreating the same collection is that you will also need to re-ensure any secondary indexes.

– Stennie
May 11 '13 at 22:02












6 Answers
6






active

oldest

votes


















33














You can efficiently drop all data and indexes for a collection with db.collection.drop(). Dropping a collection with a large number of documents and/or indexes will be significantly more efficient than deleting all documents using db.collection.remove({}). The remove() method does the extra housekeeping of updating indexes as documents are deleted, and would be even slower in a replica set environment where the oplog would include entries for each document removed rather than a single collection drop command.



Example using the mongo shell:



var dbName = 'nukeme';
db.getSiblingDB(dbName).getCollectionNames().forEach(function(collName) {
// Drop all collections except system ones (indexes/profile)
if (!collName.startsWith("system.")) {
// Safety hat
print("WARNING: going to drop ["+dbName+"."+collName+"] in 5s .. hit Ctrl-C if you've changed your mind!");
sleep(5000);
db[collName].drop();
}
})


It is worth noting that dropping a collection has different outcomes on storage usage depending on the configured storage engine:




  • WiredTiger (default storage engine in MongoDB 3.2 or newer) will free the space used by a dropped collection (and any associated indexes) once the drop completes.

  • MMAPv1 (default storage engine in MongoDB 3.0 and older) will
    not free up preallocated disk space. This may be fine for your use case; the free space is available for reuse when new data is inserted.


If you are instead dropping the database, you generally don't need to explicitly create the collections as they will be created as documents are inserted.



However, here is an example of dropping and recreating the database with the same collection names in the mongo shell:



var dbName = 'nukeme';

// Save the old collection names before dropping the DB
var oldNames = db.getSiblingDB(dbName).getCollectionNames();

// Safety hat
print("WARNING: going to drop ["+dbName+"] in 5s .. hit Ctrl-C if you've changed your mind!")
sleep(5000)

db.getSiblingDB(dbName).dropDatabase();

// Recreate database with the same collection names
oldNames.forEach(function(collName) {
db.getSiblingDB(dbName).createCollection(collName);
})





share|improve this answer





















  • 1





    I forgot to note that if you drop & recreate the collection you will also need to add any secondary indexes. You can list the existing index definitions with db.system.indexes.find().

    – Stennie
    May 11 '13 at 21:57











  • Won't this wreak havoc when performed on a partitioned/sharded collection?

    – zamnuts
    Sep 23 '15 at 20:33











  • @zamnuts Thanks for commenting! There was a subsequent issue found with dropping & reusing namespaces in a sharded cluster: SERVER-17397 - dropping a Database or Collection in a Sharded Cluster may not fully succeed. This was reported against MongoDB 2.6+ (unconfirmed if earlier versions have the same issue). There is a workaround noted on that issue which involves some extra steps to ensure the config server has been updated and the mongos cache is cleared before the namespaces are recreated.

    – Stennie
    Sep 23 '15 at 20:48











  • In practice, this is a bad idea. The problem is that dropping a collection also drops its indexes, including _id. If you attempt to drop and re-use a collection immediately, mongodb seems to background the index destruction and you can get the obscure error message 'Operation aborted because: all indexes on collection dropped'. It is safer to use remove().

    – Wheezil
    Feb 16 '18 at 0:54













  • @Wheezil Your issue sounds like something separate; perhaps dropping a collection when it is actively being used (which invalidates open cursors that might be reading from an index). Dropping and reusing collections in a sharded cluster is not a great idea until SERVER-17937 has been resolved. Dropping & reusing a collection in a replica set or standalone deployment is safe and faster than removing documents and index entries. If you do have a specific case to investigate, can you post a new question with relevant details on DBA StackExchange? Much has changed since this was posted in 2013.

    – Stennie
    Feb 16 '18 at 5:09



















55














To truncate a collection and keep the indexes use



 db.<collection>.remove({})





share|improve this answer
























  • This works, but index sizes stay the same. Is there a way to truncate the indexes as well, but keep them anyway?

    – logic
    Nov 10 '16 at 10:13











  • notice, however, tha remove() is much slower than drop().

    – rlib
    Nov 30 '16 at 22:27











  • @rlib yes it should be :)

    – astroanu
    Dec 1 '16 at 6:09













  • @astroanu Yes, surely. Last time I deleted 15 billion docs with remove() and it took very long time... Actually, inacceptably long. So drop() , createCollection() and createIndex() is the only way for truncate operation.

    – rlib
    Dec 1 '16 at 14:02



















7














the below query will delete all records in a collections and will keep the collection as is,



db.collectionname.remove({})





share|improve this answer

































    2














    Create the database and the collections and then backup the database to bson files using mongodump:



    mongodump --db database-to-use


    Then, when you need to drop the database and recreate the previous environment, just use mongorestore:



    mongorestore --drop


    The backup will be saved in the current working directory, in a folder named dump, when you use the command mongodump.






    share|improve this answer
























    • this will delete everything including indexes

      – astroanu
      Apr 29 '15 at 5:17



















    2














    There is no equivalent to the "truncate" operation in MongoDB. You can either remove all documents, but it will have a complexity of O(n), or drop the collection, then the complexity will be O(1) but you will loose your indexes.






    share|improve this answer































      0














      The db.drop() method obtains a write lock on the affected database and will block other operations until it has completed.



      I think using the db.remove({}) method is better than db.drop().






      share|improve this answer

























        Your Answer






        StackExchange.ifUsing("editor", function () {
        StackExchange.using("externalEditor", function () {
        StackExchange.using("snippets", function () {
        StackExchange.snippets.init();
        });
        });
        }, "code-snippets");

        StackExchange.ready(function() {
        var channelOptions = {
        tags: "".split(" "),
        id: "1"
        };
        initTagRenderer("".split(" "), "".split(" "), channelOptions);

        StackExchange.using("externalEditor", function() {
        // Have to fire editor after snippets, if snippets enabled
        if (StackExchange.settings.snippets.snippetsEnabled) {
        StackExchange.using("snippets", function() {
        createEditor();
        });
        }
        else {
        createEditor();
        }
        });

        function createEditor() {
        StackExchange.prepareEditor({
        heartbeatType: 'answer',
        autoActivateHeartbeat: false,
        convertImagesToLinks: true,
        noModals: true,
        showLowRepImageUploadWarning: true,
        reputationToPostImages: 10,
        bindNavPrevention: true,
        postfix: "",
        imageUploader: {
        brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
        contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
        allowUrls: true
        },
        onDemand: true,
        discardSelector: ".discard-answer"
        ,immediatelyShowMarkdownHelp:true
        });


        }
        });














        draft saved

        draft discarded


















        StackExchange.ready(
        function () {
        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f16493902%2ftruncate-a-collection%23new-answer', 'question_page');
        }
        );

        Post as a guest















        Required, but never shown

























        6 Answers
        6






        active

        oldest

        votes








        6 Answers
        6






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes









        33














        You can efficiently drop all data and indexes for a collection with db.collection.drop(). Dropping a collection with a large number of documents and/or indexes will be significantly more efficient than deleting all documents using db.collection.remove({}). The remove() method does the extra housekeeping of updating indexes as documents are deleted, and would be even slower in a replica set environment where the oplog would include entries for each document removed rather than a single collection drop command.



        Example using the mongo shell:



        var dbName = 'nukeme';
        db.getSiblingDB(dbName).getCollectionNames().forEach(function(collName) {
        // Drop all collections except system ones (indexes/profile)
        if (!collName.startsWith("system.")) {
        // Safety hat
        print("WARNING: going to drop ["+dbName+"."+collName+"] in 5s .. hit Ctrl-C if you've changed your mind!");
        sleep(5000);
        db[collName].drop();
        }
        })


        It is worth noting that dropping a collection has different outcomes on storage usage depending on the configured storage engine:




        • WiredTiger (default storage engine in MongoDB 3.2 or newer) will free the space used by a dropped collection (and any associated indexes) once the drop completes.

        • MMAPv1 (default storage engine in MongoDB 3.0 and older) will
          not free up preallocated disk space. This may be fine for your use case; the free space is available for reuse when new data is inserted.


        If you are instead dropping the database, you generally don't need to explicitly create the collections as they will be created as documents are inserted.



        However, here is an example of dropping and recreating the database with the same collection names in the mongo shell:



        var dbName = 'nukeme';

        // Save the old collection names before dropping the DB
        var oldNames = db.getSiblingDB(dbName).getCollectionNames();

        // Safety hat
        print("WARNING: going to drop ["+dbName+"] in 5s .. hit Ctrl-C if you've changed your mind!")
        sleep(5000)

        db.getSiblingDB(dbName).dropDatabase();

        // Recreate database with the same collection names
        oldNames.forEach(function(collName) {
        db.getSiblingDB(dbName).createCollection(collName);
        })





        share|improve this answer





















        • 1





          I forgot to note that if you drop & recreate the collection you will also need to add any secondary indexes. You can list the existing index definitions with db.system.indexes.find().

          – Stennie
          May 11 '13 at 21:57











        • Won't this wreak havoc when performed on a partitioned/sharded collection?

          – zamnuts
          Sep 23 '15 at 20:33











        • @zamnuts Thanks for commenting! There was a subsequent issue found with dropping & reusing namespaces in a sharded cluster: SERVER-17397 - dropping a Database or Collection in a Sharded Cluster may not fully succeed. This was reported against MongoDB 2.6+ (unconfirmed if earlier versions have the same issue). There is a workaround noted on that issue which involves some extra steps to ensure the config server has been updated and the mongos cache is cleared before the namespaces are recreated.

          – Stennie
          Sep 23 '15 at 20:48











        • In practice, this is a bad idea. The problem is that dropping a collection also drops its indexes, including _id. If you attempt to drop and re-use a collection immediately, mongodb seems to background the index destruction and you can get the obscure error message 'Operation aborted because: all indexes on collection dropped'. It is safer to use remove().

          – Wheezil
          Feb 16 '18 at 0:54













        • @Wheezil Your issue sounds like something separate; perhaps dropping a collection when it is actively being used (which invalidates open cursors that might be reading from an index). Dropping and reusing collections in a sharded cluster is not a great idea until SERVER-17937 has been resolved. Dropping & reusing a collection in a replica set or standalone deployment is safe and faster than removing documents and index entries. If you do have a specific case to investigate, can you post a new question with relevant details on DBA StackExchange? Much has changed since this was posted in 2013.

          – Stennie
          Feb 16 '18 at 5:09
















        33














        You can efficiently drop all data and indexes for a collection with db.collection.drop(). Dropping a collection with a large number of documents and/or indexes will be significantly more efficient than deleting all documents using db.collection.remove({}). The remove() method does the extra housekeeping of updating indexes as documents are deleted, and would be even slower in a replica set environment where the oplog would include entries for each document removed rather than a single collection drop command.



        Example using the mongo shell:



        var dbName = 'nukeme';
        db.getSiblingDB(dbName).getCollectionNames().forEach(function(collName) {
        // Drop all collections except system ones (indexes/profile)
        if (!collName.startsWith("system.")) {
        // Safety hat
        print("WARNING: going to drop ["+dbName+"."+collName+"] in 5s .. hit Ctrl-C if you've changed your mind!");
        sleep(5000);
        db[collName].drop();
        }
        })


        It is worth noting that dropping a collection has different outcomes on storage usage depending on the configured storage engine:




        • WiredTiger (default storage engine in MongoDB 3.2 or newer) will free the space used by a dropped collection (and any associated indexes) once the drop completes.

        • MMAPv1 (default storage engine in MongoDB 3.0 and older) will
          not free up preallocated disk space. This may be fine for your use case; the free space is available for reuse when new data is inserted.


        If you are instead dropping the database, you generally don't need to explicitly create the collections as they will be created as documents are inserted.



        However, here is an example of dropping and recreating the database with the same collection names in the mongo shell:



        var dbName = 'nukeme';

        // Save the old collection names before dropping the DB
        var oldNames = db.getSiblingDB(dbName).getCollectionNames();

        // Safety hat
        print("WARNING: going to drop ["+dbName+"] in 5s .. hit Ctrl-C if you've changed your mind!")
        sleep(5000)

        db.getSiblingDB(dbName).dropDatabase();

        // Recreate database with the same collection names
        oldNames.forEach(function(collName) {
        db.getSiblingDB(dbName).createCollection(collName);
        })





        share|improve this answer





















        • 1





          I forgot to note that if you drop & recreate the collection you will also need to add any secondary indexes. You can list the existing index definitions with db.system.indexes.find().

          – Stennie
          May 11 '13 at 21:57











        • Won't this wreak havoc when performed on a partitioned/sharded collection?

          – zamnuts
          Sep 23 '15 at 20:33











        • @zamnuts Thanks for commenting! There was a subsequent issue found with dropping & reusing namespaces in a sharded cluster: SERVER-17397 - dropping a Database or Collection in a Sharded Cluster may not fully succeed. This was reported against MongoDB 2.6+ (unconfirmed if earlier versions have the same issue). There is a workaround noted on that issue which involves some extra steps to ensure the config server has been updated and the mongos cache is cleared before the namespaces are recreated.

          – Stennie
          Sep 23 '15 at 20:48











        • In practice, this is a bad idea. The problem is that dropping a collection also drops its indexes, including _id. If you attempt to drop and re-use a collection immediately, mongodb seems to background the index destruction and you can get the obscure error message 'Operation aborted because: all indexes on collection dropped'. It is safer to use remove().

          – Wheezil
          Feb 16 '18 at 0:54













        • @Wheezil Your issue sounds like something separate; perhaps dropping a collection when it is actively being used (which invalidates open cursors that might be reading from an index). Dropping and reusing collections in a sharded cluster is not a great idea until SERVER-17937 has been resolved. Dropping & reusing a collection in a replica set or standalone deployment is safe and faster than removing documents and index entries. If you do have a specific case to investigate, can you post a new question with relevant details on DBA StackExchange? Much has changed since this was posted in 2013.

          – Stennie
          Feb 16 '18 at 5:09














        33












        33








        33







        You can efficiently drop all data and indexes for a collection with db.collection.drop(). Dropping a collection with a large number of documents and/or indexes will be significantly more efficient than deleting all documents using db.collection.remove({}). The remove() method does the extra housekeeping of updating indexes as documents are deleted, and would be even slower in a replica set environment where the oplog would include entries for each document removed rather than a single collection drop command.



        Example using the mongo shell:



        var dbName = 'nukeme';
        db.getSiblingDB(dbName).getCollectionNames().forEach(function(collName) {
        // Drop all collections except system ones (indexes/profile)
        if (!collName.startsWith("system.")) {
        // Safety hat
        print("WARNING: going to drop ["+dbName+"."+collName+"] in 5s .. hit Ctrl-C if you've changed your mind!");
        sleep(5000);
        db[collName].drop();
        }
        })


        It is worth noting that dropping a collection has different outcomes on storage usage depending on the configured storage engine:




        • WiredTiger (default storage engine in MongoDB 3.2 or newer) will free the space used by a dropped collection (and any associated indexes) once the drop completes.

        • MMAPv1 (default storage engine in MongoDB 3.0 and older) will
          not free up preallocated disk space. This may be fine for your use case; the free space is available for reuse when new data is inserted.


        If you are instead dropping the database, you generally don't need to explicitly create the collections as they will be created as documents are inserted.



        However, here is an example of dropping and recreating the database with the same collection names in the mongo shell:



        var dbName = 'nukeme';

        // Save the old collection names before dropping the DB
        var oldNames = db.getSiblingDB(dbName).getCollectionNames();

        // Safety hat
        print("WARNING: going to drop ["+dbName+"] in 5s .. hit Ctrl-C if you've changed your mind!")
        sleep(5000)

        db.getSiblingDB(dbName).dropDatabase();

        // Recreate database with the same collection names
        oldNames.forEach(function(collName) {
        db.getSiblingDB(dbName).createCollection(collName);
        })





        share|improve this answer















        You can efficiently drop all data and indexes for a collection with db.collection.drop(). Dropping a collection with a large number of documents and/or indexes will be significantly more efficient than deleting all documents using db.collection.remove({}). The remove() method does the extra housekeeping of updating indexes as documents are deleted, and would be even slower in a replica set environment where the oplog would include entries for each document removed rather than a single collection drop command.



        Example using the mongo shell:



        var dbName = 'nukeme';
        db.getSiblingDB(dbName).getCollectionNames().forEach(function(collName) {
        // Drop all collections except system ones (indexes/profile)
        if (!collName.startsWith("system.")) {
        // Safety hat
        print("WARNING: going to drop ["+dbName+"."+collName+"] in 5s .. hit Ctrl-C if you've changed your mind!");
        sleep(5000);
        db[collName].drop();
        }
        })


        It is worth noting that dropping a collection has different outcomes on storage usage depending on the configured storage engine:




        • WiredTiger (default storage engine in MongoDB 3.2 or newer) will free the space used by a dropped collection (and any associated indexes) once the drop completes.

        • MMAPv1 (default storage engine in MongoDB 3.0 and older) will
          not free up preallocated disk space. This may be fine for your use case; the free space is available for reuse when new data is inserted.


        If you are instead dropping the database, you generally don't need to explicitly create the collections as they will be created as documents are inserted.



        However, here is an example of dropping and recreating the database with the same collection names in the mongo shell:



        var dbName = 'nukeme';

        // Save the old collection names before dropping the DB
        var oldNames = db.getSiblingDB(dbName).getCollectionNames();

        // Safety hat
        print("WARNING: going to drop ["+dbName+"] in 5s .. hit Ctrl-C if you've changed your mind!")
        sleep(5000)

        db.getSiblingDB(dbName).dropDatabase();

        // Recreate database with the same collection names
        oldNames.forEach(function(collName) {
        db.getSiblingDB(dbName).createCollection(collName);
        })






        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Feb 16 '18 at 5:25

























        answered May 11 '13 at 7:47









        StennieStennie

        46.9k8110138




        46.9k8110138








        • 1





          I forgot to note that if you drop & recreate the collection you will also need to add any secondary indexes. You can list the existing index definitions with db.system.indexes.find().

          – Stennie
          May 11 '13 at 21:57











        • Won't this wreak havoc when performed on a partitioned/sharded collection?

          – zamnuts
          Sep 23 '15 at 20:33











        • @zamnuts Thanks for commenting! There was a subsequent issue found with dropping & reusing namespaces in a sharded cluster: SERVER-17397 - dropping a Database or Collection in a Sharded Cluster may not fully succeed. This was reported against MongoDB 2.6+ (unconfirmed if earlier versions have the same issue). There is a workaround noted on that issue which involves some extra steps to ensure the config server has been updated and the mongos cache is cleared before the namespaces are recreated.

          – Stennie
          Sep 23 '15 at 20:48











        • In practice, this is a bad idea. The problem is that dropping a collection also drops its indexes, including _id. If you attempt to drop and re-use a collection immediately, mongodb seems to background the index destruction and you can get the obscure error message 'Operation aborted because: all indexes on collection dropped'. It is safer to use remove().

          – Wheezil
          Feb 16 '18 at 0:54













        • @Wheezil Your issue sounds like something separate; perhaps dropping a collection when it is actively being used (which invalidates open cursors that might be reading from an index). Dropping and reusing collections in a sharded cluster is not a great idea until SERVER-17937 has been resolved. Dropping & reusing a collection in a replica set or standalone deployment is safe and faster than removing documents and index entries. If you do have a specific case to investigate, can you post a new question with relevant details on DBA StackExchange? Much has changed since this was posted in 2013.

          – Stennie
          Feb 16 '18 at 5:09














        • 1





          I forgot to note that if you drop & recreate the collection you will also need to add any secondary indexes. You can list the existing index definitions with db.system.indexes.find().

          – Stennie
          May 11 '13 at 21:57











        • Won't this wreak havoc when performed on a partitioned/sharded collection?

          – zamnuts
          Sep 23 '15 at 20:33











        • @zamnuts Thanks for commenting! There was a subsequent issue found with dropping & reusing namespaces in a sharded cluster: SERVER-17397 - dropping a Database or Collection in a Sharded Cluster may not fully succeed. This was reported against MongoDB 2.6+ (unconfirmed if earlier versions have the same issue). There is a workaround noted on that issue which involves some extra steps to ensure the config server has been updated and the mongos cache is cleared before the namespaces are recreated.

          – Stennie
          Sep 23 '15 at 20:48











        • In practice, this is a bad idea. The problem is that dropping a collection also drops its indexes, including _id. If you attempt to drop and re-use a collection immediately, mongodb seems to background the index destruction and you can get the obscure error message 'Operation aborted because: all indexes on collection dropped'. It is safer to use remove().

          – Wheezil
          Feb 16 '18 at 0:54













        • @Wheezil Your issue sounds like something separate; perhaps dropping a collection when it is actively being used (which invalidates open cursors that might be reading from an index). Dropping and reusing collections in a sharded cluster is not a great idea until SERVER-17937 has been resolved. Dropping & reusing a collection in a replica set or standalone deployment is safe and faster than removing documents and index entries. If you do have a specific case to investigate, can you post a new question with relevant details on DBA StackExchange? Much has changed since this was posted in 2013.

          – Stennie
          Feb 16 '18 at 5:09








        1




        1





        I forgot to note that if you drop & recreate the collection you will also need to add any secondary indexes. You can list the existing index definitions with db.system.indexes.find().

        – Stennie
        May 11 '13 at 21:57





        I forgot to note that if you drop & recreate the collection you will also need to add any secondary indexes. You can list the existing index definitions with db.system.indexes.find().

        – Stennie
        May 11 '13 at 21:57













        Won't this wreak havoc when performed on a partitioned/sharded collection?

        – zamnuts
        Sep 23 '15 at 20:33





        Won't this wreak havoc when performed on a partitioned/sharded collection?

        – zamnuts
        Sep 23 '15 at 20:33













        @zamnuts Thanks for commenting! There was a subsequent issue found with dropping & reusing namespaces in a sharded cluster: SERVER-17397 - dropping a Database or Collection in a Sharded Cluster may not fully succeed. This was reported against MongoDB 2.6+ (unconfirmed if earlier versions have the same issue). There is a workaround noted on that issue which involves some extra steps to ensure the config server has been updated and the mongos cache is cleared before the namespaces are recreated.

        – Stennie
        Sep 23 '15 at 20:48





        @zamnuts Thanks for commenting! There was a subsequent issue found with dropping & reusing namespaces in a sharded cluster: SERVER-17397 - dropping a Database or Collection in a Sharded Cluster may not fully succeed. This was reported against MongoDB 2.6+ (unconfirmed if earlier versions have the same issue). There is a workaround noted on that issue which involves some extra steps to ensure the config server has been updated and the mongos cache is cleared before the namespaces are recreated.

        – Stennie
        Sep 23 '15 at 20:48













        In practice, this is a bad idea. The problem is that dropping a collection also drops its indexes, including _id. If you attempt to drop and re-use a collection immediately, mongodb seems to background the index destruction and you can get the obscure error message 'Operation aborted because: all indexes on collection dropped'. It is safer to use remove().

        – Wheezil
        Feb 16 '18 at 0:54







        In practice, this is a bad idea. The problem is that dropping a collection also drops its indexes, including _id. If you attempt to drop and re-use a collection immediately, mongodb seems to background the index destruction and you can get the obscure error message 'Operation aborted because: all indexes on collection dropped'. It is safer to use remove().

        – Wheezil
        Feb 16 '18 at 0:54















        @Wheezil Your issue sounds like something separate; perhaps dropping a collection when it is actively being used (which invalidates open cursors that might be reading from an index). Dropping and reusing collections in a sharded cluster is not a great idea until SERVER-17937 has been resolved. Dropping & reusing a collection in a replica set or standalone deployment is safe and faster than removing documents and index entries. If you do have a specific case to investigate, can you post a new question with relevant details on DBA StackExchange? Much has changed since this was posted in 2013.

        – Stennie
        Feb 16 '18 at 5:09





        @Wheezil Your issue sounds like something separate; perhaps dropping a collection when it is actively being used (which invalidates open cursors that might be reading from an index). Dropping and reusing collections in a sharded cluster is not a great idea until SERVER-17937 has been resolved. Dropping & reusing a collection in a replica set or standalone deployment is safe and faster than removing documents and index entries. If you do have a specific case to investigate, can you post a new question with relevant details on DBA StackExchange? Much has changed since this was posted in 2013.

        – Stennie
        Feb 16 '18 at 5:09













        55














        To truncate a collection and keep the indexes use



         db.<collection>.remove({})





        share|improve this answer
























        • This works, but index sizes stay the same. Is there a way to truncate the indexes as well, but keep them anyway?

          – logic
          Nov 10 '16 at 10:13











        • notice, however, tha remove() is much slower than drop().

          – rlib
          Nov 30 '16 at 22:27











        • @rlib yes it should be :)

          – astroanu
          Dec 1 '16 at 6:09













        • @astroanu Yes, surely. Last time I deleted 15 billion docs with remove() and it took very long time... Actually, inacceptably long. So drop() , createCollection() and createIndex() is the only way for truncate operation.

          – rlib
          Dec 1 '16 at 14:02
















        55














        To truncate a collection and keep the indexes use



         db.<collection>.remove({})





        share|improve this answer
























        • This works, but index sizes stay the same. Is there a way to truncate the indexes as well, but keep them anyway?

          – logic
          Nov 10 '16 at 10:13











        • notice, however, tha remove() is much slower than drop().

          – rlib
          Nov 30 '16 at 22:27











        • @rlib yes it should be :)

          – astroanu
          Dec 1 '16 at 6:09













        • @astroanu Yes, surely. Last time I deleted 15 billion docs with remove() and it took very long time... Actually, inacceptably long. So drop() , createCollection() and createIndex() is the only way for truncate operation.

          – rlib
          Dec 1 '16 at 14:02














        55












        55








        55







        To truncate a collection and keep the indexes use



         db.<collection>.remove({})





        share|improve this answer













        To truncate a collection and keep the indexes use



         db.<collection>.remove({})






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Apr 23 '14 at 8:12









        astroanuastroanu

        2,26922739




        2,26922739













        • This works, but index sizes stay the same. Is there a way to truncate the indexes as well, but keep them anyway?

          – logic
          Nov 10 '16 at 10:13











        • notice, however, tha remove() is much slower than drop().

          – rlib
          Nov 30 '16 at 22:27











        • @rlib yes it should be :)

          – astroanu
          Dec 1 '16 at 6:09













        • @astroanu Yes, surely. Last time I deleted 15 billion docs with remove() and it took very long time... Actually, inacceptably long. So drop() , createCollection() and createIndex() is the only way for truncate operation.

          – rlib
          Dec 1 '16 at 14:02



















        • This works, but index sizes stay the same. Is there a way to truncate the indexes as well, but keep them anyway?

          – logic
          Nov 10 '16 at 10:13











        • notice, however, tha remove() is much slower than drop().

          – rlib
          Nov 30 '16 at 22:27











        • @rlib yes it should be :)

          – astroanu
          Dec 1 '16 at 6:09













        • @astroanu Yes, surely. Last time I deleted 15 billion docs with remove() and it took very long time... Actually, inacceptably long. So drop() , createCollection() and createIndex() is the only way for truncate operation.

          – rlib
          Dec 1 '16 at 14:02

















        This works, but index sizes stay the same. Is there a way to truncate the indexes as well, but keep them anyway?

        – logic
        Nov 10 '16 at 10:13





        This works, but index sizes stay the same. Is there a way to truncate the indexes as well, but keep them anyway?

        – logic
        Nov 10 '16 at 10:13













        notice, however, tha remove() is much slower than drop().

        – rlib
        Nov 30 '16 at 22:27





        notice, however, tha remove() is much slower than drop().

        – rlib
        Nov 30 '16 at 22:27













        @rlib yes it should be :)

        – astroanu
        Dec 1 '16 at 6:09







        @rlib yes it should be :)

        – astroanu
        Dec 1 '16 at 6:09















        @astroanu Yes, surely. Last time I deleted 15 billion docs with remove() and it took very long time... Actually, inacceptably long. So drop() , createCollection() and createIndex() is the only way for truncate operation.

        – rlib
        Dec 1 '16 at 14:02





        @astroanu Yes, surely. Last time I deleted 15 billion docs with remove() and it took very long time... Actually, inacceptably long. So drop() , createCollection() and createIndex() is the only way for truncate operation.

        – rlib
        Dec 1 '16 at 14:02











        7














        the below query will delete all records in a collections and will keep the collection as is,



        db.collectionname.remove({})





        share|improve this answer






























          7














          the below query will delete all records in a collections and will keep the collection as is,



          db.collectionname.remove({})





          share|improve this answer




























            7












            7








            7







            the below query will delete all records in a collections and will keep the collection as is,



            db.collectionname.remove({})





            share|improve this answer















            the below query will delete all records in a collections and will keep the collection as is,



            db.collectionname.remove({})






            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Feb 1 '17 at 16:32









            DanFromGermany

            19.6k64695




            19.6k64695










            answered Jul 22 '14 at 9:12









            IAmHomesIAmHomes

            1951618




            1951618























                2














                Create the database and the collections and then backup the database to bson files using mongodump:



                mongodump --db database-to-use


                Then, when you need to drop the database and recreate the previous environment, just use mongorestore:



                mongorestore --drop


                The backup will be saved in the current working directory, in a folder named dump, when you use the command mongodump.






                share|improve this answer
























                • this will delete everything including indexes

                  – astroanu
                  Apr 29 '15 at 5:17
















                2














                Create the database and the collections and then backup the database to bson files using mongodump:



                mongodump --db database-to-use


                Then, when you need to drop the database and recreate the previous environment, just use mongorestore:



                mongorestore --drop


                The backup will be saved in the current working directory, in a folder named dump, when you use the command mongodump.






                share|improve this answer
























                • this will delete everything including indexes

                  – astroanu
                  Apr 29 '15 at 5:17














                2












                2








                2







                Create the database and the collections and then backup the database to bson files using mongodump:



                mongodump --db database-to-use


                Then, when you need to drop the database and recreate the previous environment, just use mongorestore:



                mongorestore --drop


                The backup will be saved in the current working directory, in a folder named dump, when you use the command mongodump.






                share|improve this answer













                Create the database and the collections and then backup the database to bson files using mongodump:



                mongodump --db database-to-use


                Then, when you need to drop the database and recreate the previous environment, just use mongorestore:



                mongorestore --drop


                The backup will be saved in the current working directory, in a folder named dump, when you use the command mongodump.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered May 11 '13 at 5:23









                vinipsmakervinipsmaker

                1,2341125




                1,2341125













                • this will delete everything including indexes

                  – astroanu
                  Apr 29 '15 at 5:17



















                • this will delete everything including indexes

                  – astroanu
                  Apr 29 '15 at 5:17

















                this will delete everything including indexes

                – astroanu
                Apr 29 '15 at 5:17





                this will delete everything including indexes

                – astroanu
                Apr 29 '15 at 5:17











                2














                There is no equivalent to the "truncate" operation in MongoDB. You can either remove all documents, but it will have a complexity of O(n), or drop the collection, then the complexity will be O(1) but you will loose your indexes.






                share|improve this answer




























                  2














                  There is no equivalent to the "truncate" operation in MongoDB. You can either remove all documents, but it will have a complexity of O(n), or drop the collection, then the complexity will be O(1) but you will loose your indexes.






                  share|improve this answer


























                    2












                    2








                    2







                    There is no equivalent to the "truncate" operation in MongoDB. You can either remove all documents, but it will have a complexity of O(n), or drop the collection, then the complexity will be O(1) but you will loose your indexes.






                    share|improve this answer













                    There is no equivalent to the "truncate" operation in MongoDB. You can either remove all documents, but it will have a complexity of O(n), or drop the collection, then the complexity will be O(1) but you will loose your indexes.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Jan 12 '17 at 10:02









                    AlonAlon

                    41652662




                    41652662























                        0














                        The db.drop() method obtains a write lock on the affected database and will block other operations until it has completed.



                        I think using the db.remove({}) method is better than db.drop().






                        share|improve this answer






























                          0














                          The db.drop() method obtains a write lock on the affected database and will block other operations until it has completed.



                          I think using the db.remove({}) method is better than db.drop().






                          share|improve this answer




























                            0












                            0








                            0







                            The db.drop() method obtains a write lock on the affected database and will block other operations until it has completed.



                            I think using the db.remove({}) method is better than db.drop().






                            share|improve this answer















                            The db.drop() method obtains a write lock on the affected database and will block other operations until it has completed.



                            I think using the db.remove({}) method is better than db.drop().







                            share|improve this answer














                            share|improve this answer



                            share|improve this answer








                            edited Dec 7 '18 at 11:58









                            Adrian W

                            1,86951420




                            1,86951420










                            answered Dec 7 '18 at 9:11









                            Congwu ZhangCongwu Zhang

                            1




                            1






























                                draft saved

                                draft discarded




















































                                Thanks for contributing an answer to Stack Overflow!


                                • Please be sure to answer the question. Provide details and share your research!

                                But avoid



                                • Asking for help, clarification, or responding to other answers.

                                • Making statements based on opinion; back them up with references or personal experience.


                                To learn more, see our tips on writing great answers.




                                draft saved


                                draft discarded














                                StackExchange.ready(
                                function () {
                                StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f16493902%2ftruncate-a-collection%23new-answer', 'question_page');
                                }
                                );

                                Post as a guest















                                Required, but never shown





















































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown

































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown







                                Popular posts from this blog

                                Florida Star v. B. J. F.

                                Danny Elfman

                                Retrieve a Users Dashboard in Tumblr with R and TumblR. Oauth Issues