[SERVER-76830] Compact does not free space Created: 04/May/23  Updated: 20/Jun/23  Resolved: 20/Jun/23

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

Type: Bug Priority: Major - P3
Reporter: Yanfei Wu Assignee: Yuan Fang
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-41596 Compact doesn't work on all cases Backlog
related to SERVER-37812 Compact doesn't free space Closed
Operating System: ALL
Participants:

 Description   

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
} 



 Comments   
Comment by Yuan Fang [ 20/Jun/23 ]

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.

Comment by Yuan Fang [ 31/May/23 ]

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

Comment by Yuan Fang [ 10/May/23 ]

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
 

Comment by Yanfei Wu [ 05/May/23 ]

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.

Generated at Thu Feb 08 06:33:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.