Hi,
I’m following up on the database corruption issue where I created a reproducible test case.
How is the bug hunt going?
Cheers,
Håvard M. Ottestad
Hi Håvard,
We were able to recreate your issue, and are looking into a more permanent fix in the upcoming 5.x release cycle.
For now, Here are my suggestions for avoiding this problem:
-
Don’t have your threads all trying to create the same db simultaneously. Create the DB outside of the threads running and only have them performing modifications
-
When shutting down the Stardog server, only do so via a
server stopcommand (or API equivalent), and wait for the server to process it. If Docker is sending a SIGINT or SIGTERM, Stardog should process that similarly, but if it sends a SIGKILL then there is no guarantee -
After a SIGKILL / power outage / unplanned interruption, the
db repairstep during startup will do what it can to fix the dbs in a non-ideal state. This may cause the server to come up less quickly than usual, so waiting until it’s finished before attempting to create / recreate / modify the db again is advised