Clojurians Log v2
datalevin
I'm encountering occasional db corruption(?) in my production deploy set up, likely due to something I'm doing wrong. I would like some advice.
How my deploy works:
• v0 clojure application running, with (d/get-conn ...) store to an atom, with continuous updates to the db
• v1 clojure application started, also with (d/get-conn ...)` , (attempts to) start reading/writing to db
• v0 killed soon after
Questions:
• Does datalevin need a clean shutdown? (ie. add a shutdown hook to close the connection?)
• If a second clojure process connects, should I expect it to error (because of lock files)? Or, will it just connect, but, cause problems?
◦ If I use an out-of-process version of datalevin, will that solve things?
As an update, I think the issue may have been due to schema changes with insufficient migrations (ex. changing the type of a field). Last several deploys without schema changes have been fine.
I wouldn’t expect the use you described to be problematic, though we don’t currently test for such cases: multiple processes accessing the db on and off. We probably should. However, if you could isolate a reproducible case, that would be great. Or write such tests, even better. PR welcome.
For the time being though, you can always cleanly close the connection before kill the app.
So that you know all txs actually persisted prior to the killing
Prior to 0.9, abrupt killing may corrupt the db, post 0.9, corruption is avoided, but the last tx may be lost when app is killed, resulting in inconsistency if another app is concurrently accessing it. So advice is to close the connection before killing.
Of course, we can change the default setting to the safest write option.
Maybe we should 😀
We already have jvm shutdown hooks to close db, but it may not get called if you kill jvm abruptly, also depending on you os
So, as far as you know, what I'm doing should be ok. I'll try to dig into it further when/if it happens again. I just didn't want to isolate it if it's not a supported use case. Thanks for the replies.
Yes, your use case is what we intend to support.