Follow up on database corruption


I’m following up on the database corruption issue where I created a reproducible test case.

How is the bug hunt going?

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 stop command (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 repair step 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