Info

MongoDB three-node replica set, version v4.4.5. I removed some data in the collection on the PRIMARY node, and then I executed the compact command on the SECONDARY node, but the freeStorageSize was not released after execution, why? local-mongodb-one:SECONDARY> db.test_catch.stats() { "ns" : "mdworkflow.test_catch", "size" : NumberLong("5555713675259"), "count" : 18994123, "avgObjSize" : 292496, "storageSize" : 811467612160, "freeStorageSize" : 30761287680, "capped" : false } local-mongodb-one:SECONDARY> db.runCommand({ compact:"test_catch" } ) { "bytesFreed" : 0, "ok" : 1 } local-mongodb-one:SECONDARY> db.test_catch.stats() { "ns" : "mdworkflow.test_catch", "size" : NumberLong("5555714175181"), "count" : 18994126, "avgObjSize" : 292496, "storageSize" : 811467612160, "freeStorageSize" : 30761205760, "capped" : false }

Top User Comments

JIRAUSER1270794 commented on Tue, 20 Jun 2023 16:26:24 +0000: We haven’t heard back from you for some time, so I’m going to close this ticket. If this is still an issue for you, please provide additional information and we will reopen the ticket. JIRAUSER1270794 commented on Wed, 31 May 2023 15:10:15 +0000: Hi wuyanfeiwork@gmail.com, We still need additional information to diagnose the problem. If this is still an issue for you, could you provide the diagnostic data spanning the steps from "removing data on the primary node" to "running the compact command on the secondary node" to this secure upload portal ? Files uploaded to this portal are hosted on Box, are visible only to MongoDB employees, and are routinely deleted after some time. For each node in the replica set spanning a time period that includes the incident, would you please archive (tar or zip) and upload to that link: the mongod logs the $dbpath/diagnostic.data directory (the contents are described here) Regards, Yuan JIRAUSER1270794 commented on Wed, 10 May 2023 15:32:16 +0000: Hi wuyanfeiwork@gmail.com, Thank you for reporting this issue. It is unexpected that the compact command did not release disk space after removing a large amount of data. In order to further investigate this matter, we kindly request your assistance in providing the diagnostic data spanning the steps from "removing data on the primary node" to "running the compact command on the secondary node" I've created a secure upload portal for you. Files uploaded to this portal are hosted on Box, are visible only to MongoDB employees, and are routinely deleted after some time. For each node in the replica set spanning a time period that includes the incident, would you please archive (tar or zip) and upload to that link: the mongod logs the $dbpath/diagnostic.data directory (the contents are described here) Regards, Yuan JIRAUSER1273658 commented on Fri, 5 May 2023 02:52:17 +0000: I have deployed a replica set of MongoDB with the same version, and it has been verified that executing “compact” releases disk space in the new environment. The data in this environment was originally migrated from v3.4.24 to v4.4.5. I am not sure if this has any impact on the issue. Resyncing the replica node data does release space, but it is too time-consuming. My intention is to solve the problem of why “compact” does not release disk space in this environment.

Steps to Reproduce