You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Ryan Mohr <ry...@kumu.io> on 2014/07/11 00:20:21 UTC

Are couchdb restarts graceful?

We were running into issues with our couchdb server today and ended up
restarting couchdb after exhausting other options.

I'm curious -- are couchdb restarts graceful? Or are all current requests
immediately terminated?

Thanks
-Ryan

Re: Are couchdb restarts graceful?

Posted by Robert Samuel Newson <rn...@apache.org>.
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 <ry...@kumu.io> 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.


Re: Are couchdb restarts graceful?

Posted by Ryan Mohr <ry...@kumu.io>.
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.

Re: Are couchdb restarts graceful?

Posted by Benoit Chesneau <bc...@gmail.com>.
On Fri, Jul 11, 2014 at 12:20 AM, Ryan Mohr <ry...@kumu.io> wrote:
> We were running into issues with our couchdb server today and ended up
> restarting couchdb after exhausting other options.
>
> I'm curious -- are couchdb restarts graceful? Or are all current requests
> immediately terminated?
>
> Thanks
> -Ryan

The answer is no. Connections are immediately close and don't let any
chance to finish a request if it's what you mean by graceful.

- benoit

Re: Are couchdb restarts graceful?

Posted by Dave Cottlehuber <dc...@jsonified.com>.
> We were running into issues with our couchdb server today and ended up
> restarting couchdb after exhausting other options.
>  
> I'm curious -- are couchdb restarts graceful? Or are all current requests
> immediately terminated?
>  

Hey Ryan,  

Graceful like a shotgun, expect casualties. Due to append-only design
there’s no real difference between a kill -9 and shutting down couchdb.

BTW what issues were you experiencing and can you share any details
of the couchdb version/config you were running?

—  
Dave Cottlehuber
dch@jsonified.com
Sent from my Couch