It seems a similar issue was discussed at Startup Failure - #7 by msj242, but over there it was made to sound like that v1.24 has improved the integrity of the files and if the file was created with v1.24+, then this shouldn’t really be happening.
Well, this file was created with v1.24.6 (it was created yesterday) and today after a reboot/crash it is causing the above issue at startup and prevents Weaviate from starting up.
What is the recovery here?
Manually dropping the corrupted .db file and rebuilding it from zero?
I have moved the folder of this offending class into a subfolder within the Weaviate data library - then Weaviate has recreated the original class folder (with 1Mb of data) and things has suddenly started to work - including the given class is now accessible with all its data.
I did not expect that. I thought I have lost this class.
Hi @DudaNogueira ,
Yes, this is a multi node setup (2 nodes) with object numbers in the 15-30 range (variable, as most objects gets rebuilt daily).
For the larger ones we do additional sharding (additional - above of what the multi-node setup would mean).
It is possible.
But if that is the case, then shouldn’t there be a better method to inform us about the machines reaching their individual limits then bricking the system?