Closed matthewdarwin closed 2 years ago
This has happened a few times.
It has only happened to me when I've stopped the systemd service. I've been wanting to create backups. But to create a consistent backup need to shutdown the systemd service, which then runs the risk of triggering this issue after it the backup completes and systemd service is started again.
And if have no backups, then I have to re-sync everything from start again. Kinda makes it unusable.
This one comes from a a few elements/conditions not playing nicely, when:
To answer your two questions:
To prevent this behavior, here is what we suggest for producing historical blocks (it's actually what we do when indexing a new chain)
Once you caught up with live, you will not have these issues anymore, because the mindreaders will not try to produce merged files by themselves, so taking backups is easier.
Does that (removal of continuity check and approach to producing historical blocks) solve your issue ?
Lots of improvements happened since then, let's close and track in other issue if reproducible.
Ran into a problem:
error: failed storing block in archiver, shutting down. You will need to reprocess over this range to get this block (mindreader/mindreader.go:275){"error": "blocks non contiguous, expectedBlock: 5573454, got block: 5573455"...
2 issues here:
1) why does mindreader fail to read the correct block,
2) why does the entire process not just exit? Instead we just left with a partially working system. no firehose blocks are generated.
Other than reading logs, what is the correct way to detect this problem?
And how to recover? Restarting mindreader just gets stuck again at the same spot. I don't care about the hole in merged blocks. Another mindreader (running on another server) will fill it in eventually.