# Follow up on database corruption **URL:** \ **Category:** Bug\ **Created:** [February 13, 2017, 12:49pm UTC](https://community.stardog.com/t/follow-up-on-database-corruption/102 "2017-02-13T12:49:42Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![hmottestad](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/hmottestad/32/19_2.png) [@hmottestad](https://community.stardog.com/u/hmottestad)\ **Post date:** [February 13, 2017, 12:49pm UTC](https://community.stardog.com/t/follow-up-on-database-corruption/102/1 "2017-02-13T12:49:42Z")
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 ---
**Author:** ![stephen](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/stephen/32/27_2.png) [@stephen](https://community.stardog.com/u/stephen)\ **Post date:** [February 13, 2017, 2:34pm UTC](https://community.stardog.com/t/follow-up-on-database-corruption/102/2 "2017-02-13T14:34:50Z")
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