[SERVER-11763] Support online compaction of a database Created: 18/Nov/13 Updated: 06/Dec/22 Resolved: 04/Mar/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Jeffrey Yemin | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Done | Votes: | 8 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Storage Execution
|
||||||||
| Participants: | |||||||||
| Description |
|
The compact command is per collection, does not reclaim space on the file system, and blocks use of the database The repairDatabase is per database, does reclaim space, and blocks use of the server. Neither run automatically, and therefore must be scheduled externally. This is a request for compaction of an entire database that can be done without blocking use of the server or even the database, similar to the VACUUM command in Postgres. Note that compact/repairDatabase is roughly equivalent to a VACUUM FULL. |
| Comments |
| Comment by Sara Williamson [ 04/Mar/19 ] |
|
WiredTiger, unlike MMAPv1, doesn't need online compact so we are closing this ticket as gone away. |
| Comment by Kevin J. Rice [ 04/Mar/14 ] |
|
1. IMHO, and please correct me if I'm wrong: the above 'power of 2' allocation CANNOT fix this case entirely. Even if the data is made contiguous (and I'm doubtful this feature will entirely enable contiguous placement), it does not solve the VERY large issue of disk space usage. 2. Given a collection with records of widely varying sizes, compaction has to be an active process. Presume a collection wherein records change size regularly (and drastically) as fields are removed / updated / added-to. The only thing that can change (for a single record) the amount of padding is the compaction process. This compaction, as now, will relocate records to be contiguous with specified padding factor. So, there are 2 issues - Contiguous Records (filling empty spaces) and Disk Space Reclamation (returning disk space to the OS). This feature should encompass BOTH issues (as Postgres does with autovacuum, and other databases do in their own way). |
| Comment by Eliot Horowitz (Inactive) [ 22/Nov/13 ] |
|
Terry - have you tried using power of 2 allocation, which should eliminate fragmentation? |