3

Hey guys, I have a question.

If you ever had to deal with parity (Ethereum node software) and ever ran archive node, you perfectly know how long this bastard synchronizes. For our server it took almost month. Well, today or yesterday parity decided to spontaniously blow up (or crash) corruptiong database manifest file which greatly undercut us.

Anyone knows any viable way to rebuild manifest file withoud doing full sync from a scratfch?

If anyone has any suggestions other than what 95% of internet say "well, delete your database and sync from scratch" Im happy to test if it will solve our burning burning issue.

I am sure there is some way to rebuild database, especially where it's manifest file that's corrupt (Ive checked it, for wtf reason parity decided to truncate the file when it crashed).

Database backend is written in rust, and is called rocks db.

EDIT: if helps, its archive fat database (fat db means it should be easier to recover?)

Comments
  • 2
    Oh the horror. Maybe do backups in the future?
  • 1
    @Conrad

    We had one backup due the big storage requirements and this project is bearly starting...

    it ovewritten good backup with dead db ;-;

    I tried https://github.com/facebook/...

    ldb repair - nope :(

    Ive contacted devs and they say that so far we can go w/o archive node but will need it in future....

    Gotta love spontanious crashed
    And spontanious database corruptions ;-;
  • 0
    @DubbaThony That sounds more like replica/slave/mirror, not backup. Backups are usually write-once, read-many.
  • 0
    @arraysstartat1

    Nightly cron job:

    1. create backup, name it backup_tmp
    2. rm -r backup
    3. mv backup_tmp backup

    EDIT:
    I know 1 day backup isn't much but currently this project isn't high on finances and client didn't want to pay for 4 TB of storage
Your Job Suck?
Get a Better Job
Add Comment