Bandwith.db repair extremly slow what to do?

Hi,

I just did a health check on my bandwidth db (~1GB size) and spotted a few index issues.
Trying to repair via dump to sql and then read into a new db.
This read takes ages OK a few days :frowning: so I moved it to my fastest machine Ryzen 59 with nvme raid 0 setup but even there it is now running since hours and and disk utlization is ~40%.

the node is handling ~20TB data and was running more than 3 years.

  1. Is there any way to speed this up?
  2. Any plans to move to a proper DB :frowning: ?
  3. Can I let the storage node running and replace the bandwith.db later (with a version that then will be ~1 day old)? what might be consequences?
  4. What will happen if I jsut remove bandwidth.db?

thanks in advance for tipps and tricks

for 1.:
First idea put everything into a ram disk. Should even be faster then raid0 nvme.
I just find it strange that this kind of mini db read takes ages and loading disk like hell.
Note: running it in RAM will still take hours - currently running

for 4.:
Answqering myself on starting wo bandwith db:
Starting fresh see here https://support.storj.io/hc/en-us/articles/4403032417044-How-to-fix-database-file-is-not-a-database-error

what about 3. ?
thinking of let the node run,

  1. repair the defect dbs
  2. and if done stop node
  3. replace dbs with repaired ones
  4. and restart.

Would the effect be just loosing few days of historical data or any serious issues possible?

You will loose some history, and there would be a discrepancy between accounted on the node’s side and on the satellite’s side. The satellite’s information is collected from orders sent by your node, so you will be paid for what is submitted. So usage from the satellite’s point of view will be greater than from storagenode’s point of view.

1 Like