CouchDB deliberately has no graceful shutdown code, the server process is simply killed. We plan for this by ensuring all data is durably on disk before responding to http writes. By only having one way to fail, we are always executing the 'recovery' path, it’s never an afterthought. CouchDB’s disk structures do not require a validation on startup after regular or irregular server shutdown.
In 2.0, it will be possible to put each node of the cluster into maintenance mode, which is pretty close to 'graceful restart' (notably, though, the nodes in maintenance mode will continue to perform internal housekeeping tasks, which includes disk writes). B. On 11 Jul 2014, at 19:47, Ryan Mohr <[email protected]> wrote: > In the end the errors ended up (ironically) being caused by a bad call to > our error monitoring service. We run couchdb behind a rails proxy and we > were randomly seeing 500 errors on some proxy requests with no backtrace so > it was hard to track down. > > Benoit, by graceful I mean something like unicorn's USR2 signal. The > original process would immediately stop accepting new requests, fire up a > new instance, finish handling any existing requests, and then terminate. > > Is there a strong argument against graceful restarts? Couchdb restarts so > quickly it's a shame to have it result in failed requests.
