Vacuum databases in a ramdisk to reduce downtime

[anon27637763]

DB discussions can get contentious quickly…

However, sqlite has the following in its Vacuum page:

However, using auto_vacuum can lead to extra database file fragmentation. And auto_vacuum does not compact partially filled pages of the database as VACUUM does.

https://www.sqlite.org/lang_vacuum.html

The vacuum issues were mostly focused around the orders.db database. And that database has been redesigned as a flat file:

https://forum.storj.io/t/changelog-v1-11-1/8773

@littleskunk

Order DB
Some storage nodes had problems with a locked order DB. To avoid this problem we replaced the order DB with flat files. The storage node creates one file per hour per satellite and appends all incoming orders. One hour later the storage node will submit these orders to the satellite and move the file into an archive folder. By creating a new file every hour we avoid defragmentation and with that also DB locks.
Note: The storage node will check the unsent orders every 5 minutes. For 55 minutes it will notice that there is nothing to submit. That is intentional and not a bug.

So…

@shoofar should have no issues going forward. I didn’t see a post on which version was currently being vacuumed. It’s possible that the orders.db file was no longer being used… just left behind after the update to V1.11.1 … in that case, the file is smaller, but wasn’t being used anyway.

However, it’s not a good idea to delete files that you are unsure about needing.