You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Martin Hewitt <ma...@thenoi.se> on 2012/03/20 13:59:21 UTC
CouchDB, linux & clean shutdowns
Hi all,
We've just had a problem with one of our CouchDB servers - it was repeatedly crashing with gen_server timeouts - so I restarted CouchDB using /etc/init.d/couchdb restart
Our applications send HEAD requests to our main database views to ensure they remain up to date and responsive as our write volume vastly outweighs our read volume, but when CouchDB restarted, all the views began rebuilding from scratch when first accessed.
Is this a CouchDB "thing" or is the init.d script shutting down CouchDB in a non-clean fashion that's causing a cautionary rebuild when CouchDB comes back up?
Obviously, we hope not to have to restart frequently, but the rebuild process takes a while on our larger databases, so it's quite a barrier to our availability to have these views being recreated from scratch.
It may be that I need to upgrade my CouchDB install, but if there's any light that can be shed on this without that being necessary, that would be good.
Many thanks,
Martin
Re: CouchDB, linux & clean shutdowns
Posted by Martin Hewitt <ma...@thenoi.se>.
Hi Matthew,
On 20 Mar 2012, at 13:06, Matthew Woodward wrote:
> On Tue, Mar 20, 2012 at 5:59 AM, Martin Hewitt <ma...@thenoi.se> wrote:
>
>> Is this a CouchDB "thing" or is the init.d script shutting down CouchDB in
>> a non-clean fashion that's causing a cautionary rebuild when CouchDB comes
>> back up?
>>
>
> I believe given the way writes in CouchDB work that shutting it down
> gracefully or even doing a kill -9 would have no impact as far as this goes.
>
> Is this always the behavior for you when you do a restart? Is this a single
> server or are you doing any replication?
I'm not sure - we don't restart very often. I can try a restart later today once all the views have rebuilt and see if the issue persists.
It's a single server, no replication - it's our beta database, so one step removed from production.
>
>
>> Obviously, we hope not to have to restart frequently, but the rebuild
>> process takes a while on our larger databases, so it's quite a barrier to
>> our availability to have these views being recreated from scratch.
>>
>
> If you add stale=ok to your query does anything come up or is it as if the
> view doesn't exist at all after you do a restart?
Adding stale=ok gives the expected response, but the views have been rebuilding for a little while now, I'll try this when I do the above restart later today.
>
>
>>
>> It may be that I need to upgrade my CouchDB install, but if there's any
>> light that can be shed on this without that being necessary, that would be
>> good.
>>
>
> What version are you running?
Running 1.2.0a-1160734, compiled from source some time back.
> --
> Matthew Woodward
> matt@mattwoodward.com
> http://blog.mattwoodward.com
> identi.ca / Twitter: @mpwoodward
>
> Please do not send me proprietary file formats such as Word, PowerPoint,
> etc. as attachments.
> http://www.gnu.org/philosophy/no-word-attachments.html
Re: CouchDB, linux & clean shutdowns
Posted by Matthew Woodward <ma...@mattwoodward.com>.
On Tue, Mar 20, 2012 at 5:59 AM, Martin Hewitt <ma...@thenoi.se> wrote:
> Is this a CouchDB "thing" or is the init.d script shutting down CouchDB in
> a non-clean fashion that's causing a cautionary rebuild when CouchDB comes
> back up?
>
I believe given the way writes in CouchDB work that shutting it down
gracefully or even doing a kill -9 would have no impact as far as this goes.
Is this always the behavior for you when you do a restart? Is this a single
server or are you doing any replication?
> Obviously, we hope not to have to restart frequently, but the rebuild
> process takes a while on our larger databases, so it's quite a barrier to
> our availability to have these views being recreated from scratch.
>
If you add stale=ok to your query does anything come up or is it as if the
view doesn't exist at all after you do a restart?
>
> It may be that I need to upgrade my CouchDB install, but if there's any
> light that can be shed on this without that being necessary, that would be
> good.
>
What version are you running?
--
Matthew Woodward
matt@mattwoodward.com
http://blog.mattwoodward.com
identi.ca / Twitter: @mpwoodward
Please do not send me proprietary file formats such as Word, PowerPoint,
etc. as attachments.
http://www.gnu.org/philosophy/no-word-attachments.html
Re: CouchDB, linux & clean shutdowns
Posted by Jason Smith <jh...@iriscouch.com>.
On Tue, Mar 20, 2012 at 1:07 PM, Jo-Erlend Schinstad
<jo...@gmail.com> wrote:
> Den 20. mars 2012 13:59, skrev Martin Hewitt:
>
>> Is this a CouchDB "thing" or is the init.d script shutting down CouchDB in
>> a non-clean fashion that's causing a cautionary rebuild when CouchDB comes
>> back up?
>
>
> As far as I'm aware, there's no clean way to shutdown CouchDB. It's designed
> that way. You just kill it.
There is no **unclean** way to shut down CouchDB.
However CouchDB is not responsible for the bits hitting the metal (or
the SSD). Many layers lurk between CouchDB and the disk; so generally
speaking the cleaner the shutdown the better.
--
Iris Couch
Re: CouchDB, linux & clean shutdowns
Posted by Martin Hewitt <ma...@thenoi.se>.
Not sure if it is - at least there don't appear to be many similarities in the stack trace (but then again, I'm not very good at interpreting Erlang stack traces!)
I've got to the logfile and extracted the last failure before I restarted the server, and have uploaded it to Pastebin: http://pastebin.com/ykn7wAFX
My views are (still) rebuilding so I've not had a chance to test the restart/view/stale=ok cycle yet.
Martin
On 20 Mar 2012, at 23:36, Jason Smith wrote:
> On Tue, Mar 20, 2012 at 8:51 PM, Jason Smith <jh...@iriscouch.com> wrote:
>> Hi, Martin. I wonder if it is related to this issue?
>
> Sorry, I forgot to post a link:
> https://issues.apache.org/jira/browse/COUCHDB-1445
>
> --
> Iris Couch
Re: CouchDB, linux & clean shutdowns
Posted by Jason Smith <jh...@iriscouch.com>.
On Tue, Mar 20, 2012 at 8:51 PM, Jason Smith <jh...@iriscouch.com> wrote:
> Hi, Martin. I wonder if it is related to this issue?
Sorry, I forgot to post a link:
https://issues.apache.org/jira/browse/COUCHDB-1445
--
Iris Couch
Re: CouchDB, linux & clean shutdowns
Posted by Martin Hewitt <ma...@thenoi.se>.
Hi Robert,
Yes, I simply ran:
tar xvfz apache-couchdb-1.2.0.tar.gz
And then changed into the `apache-couchdb-1.2.0` directory. I then ran the configure command as detailed previously.
The gist I linked to previously is the content of make.log given the command:
make > make.log 2>&1
And my config.log file is here: https://gist.github.com/2229743
Martin
On 28 Mar 2012, at 17:56, Robert Newson wrote:
> Ok, assuming you unzipped the release tarball into an empty dir, can
> you include the full log (and config.log)?
>
> B.
>
> On 28 March 2012 17:30, Martin Hewitt <ma...@thenoi.se> wrote:
>> Not that I can see, I've got version 1.8.5 installed, I compiled it from source. My ./configure command is:
>>
>> ./configure --with-erlang=/usr/local/lib/erlang/usr/include --with-js-lib=/usr/local/lib/ --with-js-include=/usr/local/include/js/
>>
>> Martin
>>
>> On 28 Mar 2012, at 17:17, Robert Newson wrote:
>>
>>> Do you have more than one version of spidermonkey on your path?
>>>
>>> On 28 March 2012 17:09, Martin Hewitt <ma...@thenoi.se> wrote:
>>>> Hi Robert,
>>>>
>>>> I've downloaded that tarball, extracted it, and ./configure runs fine, however, I get errors when I run `make`.
>>>>
>>>> I've put the output from the `make` command here: https://gist.github.com/2227816 as I'm not sure where the problem lies.
>>>>
>>>> I've managed to compile, make and make install the 1.3.0a-394a08a-git version without error.
>>>>
>>>> Martin
>>>>
>>>> On 25 Mar 2012, at 17:48, Robert Newson wrote:
>>>>
>>>>> http://people.apache.org/~nslater/dist/1.2.0/
>>>>
>>
Re: CouchDB, linux & clean shutdowns
Posted by Robert Newson <rn...@apache.org>.
Ok, assuming you unzipped the release tarball into an empty dir, can
you include the full log (and config.log)?
B.
On 28 March 2012 17:30, Martin Hewitt <ma...@thenoi.se> wrote:
> Not that I can see, I've got version 1.8.5 installed, I compiled it from source. My ./configure command is:
>
> ./configure --with-erlang=/usr/local/lib/erlang/usr/include --with-js-lib=/usr/local/lib/ --with-js-include=/usr/local/include/js/
>
> Martin
>
> On 28 Mar 2012, at 17:17, Robert Newson wrote:
>
>> Do you have more than one version of spidermonkey on your path?
>>
>> On 28 March 2012 17:09, Martin Hewitt <ma...@thenoi.se> wrote:
>>> Hi Robert,
>>>
>>> I've downloaded that tarball, extracted it, and ./configure runs fine, however, I get errors when I run `make`.
>>>
>>> I've put the output from the `make` command here: https://gist.github.com/2227816 as I'm not sure where the problem lies.
>>>
>>> I've managed to compile, make and make install the 1.3.0a-394a08a-git version without error.
>>>
>>> Martin
>>>
>>> On 25 Mar 2012, at 17:48, Robert Newson wrote:
>>>
>>>> http://people.apache.org/~nslater/dist/1.2.0/
>>>
>
Re: CouchDB, linux & clean shutdowns
Posted by Martin Hewitt <ma...@thenoi.se>.
Not that I can see, I've got version 1.8.5 installed, I compiled it from source. My ./configure command is:
./configure --with-erlang=/usr/local/lib/erlang/usr/include --with-js-lib=/usr/local/lib/ --with-js-include=/usr/local/include/js/
Martin
On 28 Mar 2012, at 17:17, Robert Newson wrote:
> Do you have more than one version of spidermonkey on your path?
>
> On 28 March 2012 17:09, Martin Hewitt <ma...@thenoi.se> wrote:
>> Hi Robert,
>>
>> I've downloaded that tarball, extracted it, and ./configure runs fine, however, I get errors when I run `make`.
>>
>> I've put the output from the `make` command here: https://gist.github.com/2227816 as I'm not sure where the problem lies.
>>
>> I've managed to compile, make and make install the 1.3.0a-394a08a-git version without error.
>>
>> Martin
>>
>> On 25 Mar 2012, at 17:48, Robert Newson wrote:
>>
>>> http://people.apache.org/~nslater/dist/1.2.0/
>>
Re: CouchDB, linux & clean shutdowns
Posted by Robert Newson <rn...@apache.org>.
Do you have more than one version of spidermonkey on your path?
On 28 March 2012 17:09, Martin Hewitt <ma...@thenoi.se> wrote:
> Hi Robert,
>
> I've downloaded that tarball, extracted it, and ./configure runs fine, however, I get errors when I run `make`.
>
> I've put the output from the `make` command here: https://gist.github.com/2227816 as I'm not sure where the problem lies.
>
> I've managed to compile, make and make install the 1.3.0a-394a08a-git version without error.
>
> Martin
>
> On 25 Mar 2012, at 17:48, Robert Newson wrote:
>
>> http://people.apache.org/~nslater/dist/1.2.0/
>
Re: CouchDB, linux & clean shutdowns
Posted by Martin Hewitt <ma...@thenoi.se>.
Hi Robert,
I've downloaded that tarball, extracted it, and ./configure runs fine, however, I get errors when I run `make`.
I've put the output from the `make` command here: https://gist.github.com/2227816 as I'm not sure where the problem lies.
I've managed to compile, make and make install the 1.3.0a-394a08a-git version without error.
Martin
On 25 Mar 2012, at 17:48, Robert Newson wrote:
> http://people.apache.org/~nslater/dist/1.2.0/
Re: CouchDB, linux & clean shutdowns
Posted by Robert Newson <rn...@apache.org>.
However, I would use the tarball from
http://people.apache.org/~nslater/dist/1.2.0/
B.
On 25 March 2012 17:48, Robert Newson <rn...@apache.org> wrote:
> master is (will be) 1.3. If you build from the 1.2.x branch couchdb
> will report '1.2.0', so I suspect you didn't build what you thought
> you did. Make sure you ./bootstrap && ./configure before you make.
>
> B.
>
> On 25 March 2012 17:41, Martin Hewitt <ma...@thenoi.se> wrote:
>> Hi Robert,
>>
>> I've just built the 1.2.x branch of the CouchDB git repo, and I'm getting the following version line:
>>
>> {"couchdb":"Welcome","version":"1.3.0a-394a08a-git","vendor":{"version":"1.3.0a-394a08a-git","name":"The Apache Software Foundation"}}
>>
>> Should I be building from master?
>>
>> Martin
>>
>> On 25 Mar 2012, at 17:30, Robert Newson wrote:
>>
>>> Since you're following 1.2.x already, I suggest building the latest
>>> 1.2.0 artifact that we're currently voting on. It at least will not
>>> delete views if it encounters an error, and it also logs those errors,
>>> so we'll have something more to go on if it recurs.
>>>
>>> B.
>>>
>>> On 25 March 2012 16:32, Martin Hewitt <ma...@thenoi.se> wrote:
>>>> Ooh, didn't spot that there was a fix, so that'd be without the fix.
>>>>
>>>> Martin
>>>>
>>>> On 25 Mar 2012, at 16:26, Robert Newson wrote:
>>>>
>>>>> Martin,
>>>>>
>>>>> Is that with or without the fix for COUCHDB-1445?
>>>>>
>>>>> B.
>>>>>
>>>>> On 25 March 2012 16:06, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>> I've just restarted our CouchDB instance and, as before, all the views have started to rebuild from scratch.
>>>>>>
>>>>>> I've loaded a rebuilding view with ?stale=ok, and it appears to load the view as it would be before the server was restarted, i.e. the view still exists as calculated before the server was restarted and the rebuild began, but the _utils/status.html page shows all views as rebuilding from scratch.
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>> On 20 Mar 2012, at 16:49, Robert Newson wrote:
>>>>>>
>>>>>>> Very curious, would love to know more.
>>>>>>>
>>>>>>> On 20 March 2012 16:33, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>>>> Hi Robert,
>>>>>>>>
>>>>>>>> For one view, whenever we loaded it, but every time we loaded it, would produce a stack trace and not the view. Restarting the CouchDB instance restored the view to working order.
>>>>>>>>
>>>>>>>> I'll try and dig out the stack trace, but it was the perpetual, continual problem with this view that led us to take the "nuclear option" and restart.
>>>>>>>>
>>>>>>>> Martin
>>>>>>>>
>>>>>>>> On 20 Mar 2012, at 14:24, Robert Newson wrote:
>>>>>>>>
>>>>>>>>> Can you describe "it was repeatedly crashing with gen_server timeouts"
>>>>>>>>> in more detail? This sounds non-fatal to me but can look alarming if
>>>>>>>>> you're not used to the erlang approach to error handling. It might be
>>>>>>>>> that you're restarting for no good reason.
>>>>>>>>>
>>>>>>>>> B.
>>>>>>>>>
>>>>>>>>> On 20 March 2012 14:20, Robert Newson <rn...@apache.org> wrote:
>>>>>>>>>> Also we don't fsync views at all, so if you built the view and then
>>>>>>>>>> killed couchdb very quickly, the data didn't reach the platters.
>>>>>>>>>>
>>>>>>>>>> I'll note that you really, *really*, want to set delayed_commits to
>>>>>>>>>> false if using couchdb in production. This strongly guarantees that
>>>>>>>>>> your database updates are preserved in the event of a crash.
>>>>>>>>>>
>>>>>>>>>> B.
>>>>>>>>>>
>>>>>>>>>> On 20 March 2012 13:51, Jason Smith <jh...@iriscouch.com> wrote:
>>>>>>>>>>> On Tue, Mar 20, 2012 at 1:38 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>>>>>>>> Hi Alexander,
>>>>>>>>>>>>
>>>>>>>>>>>> On 20 Mar 2012, at 13:23, Alexander Shorin wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Mar 20, 2012 at 5:07 PM, Jo-Erlend Schinstad
>>>>>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>>>>>> As far as I'm aware, there's no clean way to shutdown CouchDB. It's designed
>>>>>>>>>>>>>> that way. You just kill it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> With _admin permissions:
>>>>>>>>>>>>> curl -X POST http://localhost:5984/_restart -H "Content-Type: application/json"
>>>>>>>>>>>>
>>>>>>>>>>>> Excellent, thanks, I'll give this a try.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Mar 20, 2012 at 5:12 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>>>>>>>>>>> What version are you running?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Running 1.2.0a-1160734, compiled from source some time back.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looks like subversion revision number and a little out of dated. By
>>>>>>>>>>>>> the way, CouchDB repository had been moved to git not so far a long
>>>>>>>>>>>>> ago. Have you tried to update to latest head of 1.2.x branch?
>>>>>>>>>>>>
>>>>>>>>>>>> Yeah, i know it's an old version, I was just curious as to whether there was something I could try before rebuilding the server.
>>>>>>>>>>>
>>>>>>>>>>> Hi, Martin. I wonder if it is related to this issue?
>>>>>>>>>>>
>>>>>>>>>>> CouchDB was deleting .view files if some kinds of errors happened.
>>>>>>>>>>> This will be fixed in the upcoming version 1.2.0. (But I'm not 100%
>>>>>>>>>>> sure that that is your issue.)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Iris Couch
>>>>>>>>
>>>>>>
>>>>
>>
Re: CouchDB, linux & clean shutdowns
Posted by Robert Newson <rn...@apache.org>.
master is (will be) 1.3. If you build from the 1.2.x branch couchdb
will report '1.2.0', so I suspect you didn't build what you thought
you did. Make sure you ./bootstrap && ./configure before you make.
B.
On 25 March 2012 17:41, Martin Hewitt <ma...@thenoi.se> wrote:
> Hi Robert,
>
> I've just built the 1.2.x branch of the CouchDB git repo, and I'm getting the following version line:
>
> {"couchdb":"Welcome","version":"1.3.0a-394a08a-git","vendor":{"version":"1.3.0a-394a08a-git","name":"The Apache Software Foundation"}}
>
> Should I be building from master?
>
> Martin
>
> On 25 Mar 2012, at 17:30, Robert Newson wrote:
>
>> Since you're following 1.2.x already, I suggest building the latest
>> 1.2.0 artifact that we're currently voting on. It at least will not
>> delete views if it encounters an error, and it also logs those errors,
>> so we'll have something more to go on if it recurs.
>>
>> B.
>>
>> On 25 March 2012 16:32, Martin Hewitt <ma...@thenoi.se> wrote:
>>> Ooh, didn't spot that there was a fix, so that'd be without the fix.
>>>
>>> Martin
>>>
>>> On 25 Mar 2012, at 16:26, Robert Newson wrote:
>>>
>>>> Martin,
>>>>
>>>> Is that with or without the fix for COUCHDB-1445?
>>>>
>>>> B.
>>>>
>>>> On 25 March 2012 16:06, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>> I've just restarted our CouchDB instance and, as before, all the views have started to rebuild from scratch.
>>>>>
>>>>> I've loaded a rebuilding view with ?stale=ok, and it appears to load the view as it would be before the server was restarted, i.e. the view still exists as calculated before the server was restarted and the rebuild began, but the _utils/status.html page shows all views as rebuilding from scratch.
>>>>>
>>>>> Martin
>>>>>
>>>>> On 20 Mar 2012, at 16:49, Robert Newson wrote:
>>>>>
>>>>>> Very curious, would love to know more.
>>>>>>
>>>>>> On 20 March 2012 16:33, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>>> Hi Robert,
>>>>>>>
>>>>>>> For one view, whenever we loaded it, but every time we loaded it, would produce a stack trace and not the view. Restarting the CouchDB instance restored the view to working order.
>>>>>>>
>>>>>>> I'll try and dig out the stack trace, but it was the perpetual, continual problem with this view that led us to take the "nuclear option" and restart.
>>>>>>>
>>>>>>> Martin
>>>>>>>
>>>>>>> On 20 Mar 2012, at 14:24, Robert Newson wrote:
>>>>>>>
>>>>>>>> Can you describe "it was repeatedly crashing with gen_server timeouts"
>>>>>>>> in more detail? This sounds non-fatal to me but can look alarming if
>>>>>>>> you're not used to the erlang approach to error handling. It might be
>>>>>>>> that you're restarting for no good reason.
>>>>>>>>
>>>>>>>> B.
>>>>>>>>
>>>>>>>> On 20 March 2012 14:20, Robert Newson <rn...@apache.org> wrote:
>>>>>>>>> Also we don't fsync views at all, so if you built the view and then
>>>>>>>>> killed couchdb very quickly, the data didn't reach the platters.
>>>>>>>>>
>>>>>>>>> I'll note that you really, *really*, want to set delayed_commits to
>>>>>>>>> false if using couchdb in production. This strongly guarantees that
>>>>>>>>> your database updates are preserved in the event of a crash.
>>>>>>>>>
>>>>>>>>> B.
>>>>>>>>>
>>>>>>>>> On 20 March 2012 13:51, Jason Smith <jh...@iriscouch.com> wrote:
>>>>>>>>>> On Tue, Mar 20, 2012 at 1:38 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>>>>>>> Hi Alexander,
>>>>>>>>>>>
>>>>>>>>>>> On 20 Mar 2012, at 13:23, Alexander Shorin wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Mar 20, 2012 at 5:07 PM, Jo-Erlend Schinstad
>>>>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>>>>> As far as I'm aware, there's no clean way to shutdown CouchDB. It's designed
>>>>>>>>>>>>> that way. You just kill it.
>>>>>>>>>>>>
>>>>>>>>>>>> With _admin permissions:
>>>>>>>>>>>> curl -X POST http://localhost:5984/_restart -H "Content-Type: application/json"
>>>>>>>>>>>
>>>>>>>>>>> Excellent, thanks, I'll give this a try.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Mar 20, 2012 at 5:12 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>>>>>>>>>> What version are you running?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Running 1.2.0a-1160734, compiled from source some time back.
>>>>>>>>>>>>
>>>>>>>>>>>> Looks like subversion revision number and a little out of dated. By
>>>>>>>>>>>> the way, CouchDB repository had been moved to git not so far a long
>>>>>>>>>>>> ago. Have you tried to update to latest head of 1.2.x branch?
>>>>>>>>>>>
>>>>>>>>>>> Yeah, i know it's an old version, I was just curious as to whether there was something I could try before rebuilding the server.
>>>>>>>>>>
>>>>>>>>>> Hi, Martin. I wonder if it is related to this issue?
>>>>>>>>>>
>>>>>>>>>> CouchDB was deleting .view files if some kinds of errors happened.
>>>>>>>>>> This will be fixed in the upcoming version 1.2.0. (But I'm not 100%
>>>>>>>>>> sure that that is your issue.)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Iris Couch
>>>>>>>
>>>>>
>>>
>
Re: CouchDB, linux & clean shutdowns
Posted by Martin Hewitt <ma...@thenoi.se>.
Hi Robert,
I've just built the 1.2.x branch of the CouchDB git repo, and I'm getting the following version line:
{"couchdb":"Welcome","version":"1.3.0a-394a08a-git","vendor":{"version":"1.3.0a-394a08a-git","name":"The Apache Software Foundation"}}
Should I be building from master?
Martin
On 25 Mar 2012, at 17:30, Robert Newson wrote:
> Since you're following 1.2.x already, I suggest building the latest
> 1.2.0 artifact that we're currently voting on. It at least will not
> delete views if it encounters an error, and it also logs those errors,
> so we'll have something more to go on if it recurs.
>
> B.
>
> On 25 March 2012 16:32, Martin Hewitt <ma...@thenoi.se> wrote:
>> Ooh, didn't spot that there was a fix, so that'd be without the fix.
>>
>> Martin
>>
>> On 25 Mar 2012, at 16:26, Robert Newson wrote:
>>
>>> Martin,
>>>
>>> Is that with or without the fix for COUCHDB-1445?
>>>
>>> B.
>>>
>>> On 25 March 2012 16:06, Martin Hewitt <ma...@thenoi.se> wrote:
>>>> I've just restarted our CouchDB instance and, as before, all the views have started to rebuild from scratch.
>>>>
>>>> I've loaded a rebuilding view with ?stale=ok, and it appears to load the view as it would be before the server was restarted, i.e. the view still exists as calculated before the server was restarted and the rebuild began, but the _utils/status.html page shows all views as rebuilding from scratch.
>>>>
>>>> Martin
>>>>
>>>> On 20 Mar 2012, at 16:49, Robert Newson wrote:
>>>>
>>>>> Very curious, would love to know more.
>>>>>
>>>>> On 20 March 2012 16:33, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>> Hi Robert,
>>>>>>
>>>>>> For one view, whenever we loaded it, but every time we loaded it, would produce a stack trace and not the view. Restarting the CouchDB instance restored the view to working order.
>>>>>>
>>>>>> I'll try and dig out the stack trace, but it was the perpetual, continual problem with this view that led us to take the "nuclear option" and restart.
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>> On 20 Mar 2012, at 14:24, Robert Newson wrote:
>>>>>>
>>>>>>> Can you describe "it was repeatedly crashing with gen_server timeouts"
>>>>>>> in more detail? This sounds non-fatal to me but can look alarming if
>>>>>>> you're not used to the erlang approach to error handling. It might be
>>>>>>> that you're restarting for no good reason.
>>>>>>>
>>>>>>> B.
>>>>>>>
>>>>>>> On 20 March 2012 14:20, Robert Newson <rn...@apache.org> wrote:
>>>>>>>> Also we don't fsync views at all, so if you built the view and then
>>>>>>>> killed couchdb very quickly, the data didn't reach the platters.
>>>>>>>>
>>>>>>>> I'll note that you really, *really*, want to set delayed_commits to
>>>>>>>> false if using couchdb in production. This strongly guarantees that
>>>>>>>> your database updates are preserved in the event of a crash.
>>>>>>>>
>>>>>>>> B.
>>>>>>>>
>>>>>>>> On 20 March 2012 13:51, Jason Smith <jh...@iriscouch.com> wrote:
>>>>>>>>> On Tue, Mar 20, 2012 at 1:38 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>>>>>> Hi Alexander,
>>>>>>>>>>
>>>>>>>>>> On 20 Mar 2012, at 13:23, Alexander Shorin wrote:
>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 20, 2012 at 5:07 PM, Jo-Erlend Schinstad
>>>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>>>> As far as I'm aware, there's no clean way to shutdown CouchDB. It's designed
>>>>>>>>>>>> that way. You just kill it.
>>>>>>>>>>>
>>>>>>>>>>> With _admin permissions:
>>>>>>>>>>> curl -X POST http://localhost:5984/_restart -H "Content-Type: application/json"
>>>>>>>>>>
>>>>>>>>>> Excellent, thanks, I'll give this a try.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 20, 2012 at 5:12 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>>>>>>>>> What version are you running?
>>>>>>>>>>>>
>>>>>>>>>>>> Running 1.2.0a-1160734, compiled from source some time back.
>>>>>>>>>>>
>>>>>>>>>>> Looks like subversion revision number and a little out of dated. By
>>>>>>>>>>> the way, CouchDB repository had been moved to git not so far a long
>>>>>>>>>>> ago. Have you tried to update to latest head of 1.2.x branch?
>>>>>>>>>>
>>>>>>>>>> Yeah, i know it's an old version, I was just curious as to whether there was something I could try before rebuilding the server.
>>>>>>>>>
>>>>>>>>> Hi, Martin. I wonder if it is related to this issue?
>>>>>>>>>
>>>>>>>>> CouchDB was deleting .view files if some kinds of errors happened.
>>>>>>>>> This will be fixed in the upcoming version 1.2.0. (But I'm not 100%
>>>>>>>>> sure that that is your issue.)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Iris Couch
>>>>>>
>>>>
>>
Re: CouchDB, linux & clean shutdowns
Posted by Robert Newson <rn...@apache.org>.
Since you're following 1.2.x already, I suggest building the latest
1.2.0 artifact that we're currently voting on. It at least will not
delete views if it encounters an error, and it also logs those errors,
so we'll have something more to go on if it recurs.
B.
On 25 March 2012 16:32, Martin Hewitt <ma...@thenoi.se> wrote:
> Ooh, didn't spot that there was a fix, so that'd be without the fix.
>
> Martin
>
> On 25 Mar 2012, at 16:26, Robert Newson wrote:
>
>> Martin,
>>
>> Is that with or without the fix for COUCHDB-1445?
>>
>> B.
>>
>> On 25 March 2012 16:06, Martin Hewitt <ma...@thenoi.se> wrote:
>>> I've just restarted our CouchDB instance and, as before, all the views have started to rebuild from scratch.
>>>
>>> I've loaded a rebuilding view with ?stale=ok, and it appears to load the view as it would be before the server was restarted, i.e. the view still exists as calculated before the server was restarted and the rebuild began, but the _utils/status.html page shows all views as rebuilding from scratch.
>>>
>>> Martin
>>>
>>> On 20 Mar 2012, at 16:49, Robert Newson wrote:
>>>
>>>> Very curious, would love to know more.
>>>>
>>>> On 20 March 2012 16:33, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>> Hi Robert,
>>>>>
>>>>> For one view, whenever we loaded it, but every time we loaded it, would produce a stack trace and not the view. Restarting the CouchDB instance restored the view to working order.
>>>>>
>>>>> I'll try and dig out the stack trace, but it was the perpetual, continual problem with this view that led us to take the "nuclear option" and restart.
>>>>>
>>>>> Martin
>>>>>
>>>>> On 20 Mar 2012, at 14:24, Robert Newson wrote:
>>>>>
>>>>>> Can you describe "it was repeatedly crashing with gen_server timeouts"
>>>>>> in more detail? This sounds non-fatal to me but can look alarming if
>>>>>> you're not used to the erlang approach to error handling. It might be
>>>>>> that you're restarting for no good reason.
>>>>>>
>>>>>> B.
>>>>>>
>>>>>> On 20 March 2012 14:20, Robert Newson <rn...@apache.org> wrote:
>>>>>>> Also we don't fsync views at all, so if you built the view and then
>>>>>>> killed couchdb very quickly, the data didn't reach the platters.
>>>>>>>
>>>>>>> I'll note that you really, *really*, want to set delayed_commits to
>>>>>>> false if using couchdb in production. This strongly guarantees that
>>>>>>> your database updates are preserved in the event of a crash.
>>>>>>>
>>>>>>> B.
>>>>>>>
>>>>>>> On 20 March 2012 13:51, Jason Smith <jh...@iriscouch.com> wrote:
>>>>>>>> On Tue, Mar 20, 2012 at 1:38 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>>>>> Hi Alexander,
>>>>>>>>>
>>>>>>>>> On 20 Mar 2012, at 13:23, Alexander Shorin wrote:
>>>>>>>>>
>>>>>>>>>> On Tue, Mar 20, 2012 at 5:07 PM, Jo-Erlend Schinstad
>>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>>> As far as I'm aware, there's no clean way to shutdown CouchDB. It's designed
>>>>>>>>>>> that way. You just kill it.
>>>>>>>>>>
>>>>>>>>>> With _admin permissions:
>>>>>>>>>> curl -X POST http://localhost:5984/_restart -H "Content-Type: application/json"
>>>>>>>>>
>>>>>>>>> Excellent, thanks, I'll give this a try.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Mar 20, 2012 at 5:12 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>>>>>>>> What version are you running?
>>>>>>>>>>>
>>>>>>>>>>> Running 1.2.0a-1160734, compiled from source some time back.
>>>>>>>>>>
>>>>>>>>>> Looks like subversion revision number and a little out of dated. By
>>>>>>>>>> the way, CouchDB repository had been moved to git not so far a long
>>>>>>>>>> ago. Have you tried to update to latest head of 1.2.x branch?
>>>>>>>>>
>>>>>>>>> Yeah, i know it's an old version, I was just curious as to whether there was something I could try before rebuilding the server.
>>>>>>>>
>>>>>>>> Hi, Martin. I wonder if it is related to this issue?
>>>>>>>>
>>>>>>>> CouchDB was deleting .view files if some kinds of errors happened.
>>>>>>>> This will be fixed in the upcoming version 1.2.0. (But I'm not 100%
>>>>>>>> sure that that is your issue.)
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Iris Couch
>>>>>
>>>
>
Re: CouchDB, linux & clean shutdowns
Posted by Martin Hewitt <ma...@thenoi.se>.
Ooh, didn't spot that there was a fix, so that'd be without the fix.
Martin
On 25 Mar 2012, at 16:26, Robert Newson wrote:
> Martin,
>
> Is that with or without the fix for COUCHDB-1445?
>
> B.
>
> On 25 March 2012 16:06, Martin Hewitt <ma...@thenoi.se> wrote:
>> I've just restarted our CouchDB instance and, as before, all the views have started to rebuild from scratch.
>>
>> I've loaded a rebuilding view with ?stale=ok, and it appears to load the view as it would be before the server was restarted, i.e. the view still exists as calculated before the server was restarted and the rebuild began, but the _utils/status.html page shows all views as rebuilding from scratch.
>>
>> Martin
>>
>> On 20 Mar 2012, at 16:49, Robert Newson wrote:
>>
>>> Very curious, would love to know more.
>>>
>>> On 20 March 2012 16:33, Martin Hewitt <ma...@thenoi.se> wrote:
>>>> Hi Robert,
>>>>
>>>> For one view, whenever we loaded it, but every time we loaded it, would produce a stack trace and not the view. Restarting the CouchDB instance restored the view to working order.
>>>>
>>>> I'll try and dig out the stack trace, but it was the perpetual, continual problem with this view that led us to take the "nuclear option" and restart.
>>>>
>>>> Martin
>>>>
>>>> On 20 Mar 2012, at 14:24, Robert Newson wrote:
>>>>
>>>>> Can you describe "it was repeatedly crashing with gen_server timeouts"
>>>>> in more detail? This sounds non-fatal to me but can look alarming if
>>>>> you're not used to the erlang approach to error handling. It might be
>>>>> that you're restarting for no good reason.
>>>>>
>>>>> B.
>>>>>
>>>>> On 20 March 2012 14:20, Robert Newson <rn...@apache.org> wrote:
>>>>>> Also we don't fsync views at all, so if you built the view and then
>>>>>> killed couchdb very quickly, the data didn't reach the platters.
>>>>>>
>>>>>> I'll note that you really, *really*, want to set delayed_commits to
>>>>>> false if using couchdb in production. This strongly guarantees that
>>>>>> your database updates are preserved in the event of a crash.
>>>>>>
>>>>>> B.
>>>>>>
>>>>>> On 20 March 2012 13:51, Jason Smith <jh...@iriscouch.com> wrote:
>>>>>>> On Tue, Mar 20, 2012 at 1:38 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>>>> Hi Alexander,
>>>>>>>>
>>>>>>>> On 20 Mar 2012, at 13:23, Alexander Shorin wrote:
>>>>>>>>
>>>>>>>>> On Tue, Mar 20, 2012 at 5:07 PM, Jo-Erlend Schinstad
>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>> As far as I'm aware, there's no clean way to shutdown CouchDB. It's designed
>>>>>>>>>> that way. You just kill it.
>>>>>>>>>
>>>>>>>>> With _admin permissions:
>>>>>>>>> curl -X POST http://localhost:5984/_restart -H "Content-Type: application/json"
>>>>>>>>
>>>>>>>> Excellent, thanks, I'll give this a try.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Mar 20, 2012 at 5:12 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>>>>>>> What version are you running?
>>>>>>>>>>
>>>>>>>>>> Running 1.2.0a-1160734, compiled from source some time back.
>>>>>>>>>
>>>>>>>>> Looks like subversion revision number and a little out of dated. By
>>>>>>>>> the way, CouchDB repository had been moved to git not so far a long
>>>>>>>>> ago. Have you tried to update to latest head of 1.2.x branch?
>>>>>>>>
>>>>>>>> Yeah, i know it's an old version, I was just curious as to whether there was something I could try before rebuilding the server.
>>>>>>>
>>>>>>> Hi, Martin. I wonder if it is related to this issue?
>>>>>>>
>>>>>>> CouchDB was deleting .view files if some kinds of errors happened.
>>>>>>> This will be fixed in the upcoming version 1.2.0. (But I'm not 100%
>>>>>>> sure that that is your issue.)
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Iris Couch
>>>>
>>
Re: CouchDB, linux & clean shutdowns
Posted by Robert Newson <rn...@apache.org>.
Martin,
Is that with or without the fix for COUCHDB-1445?
B.
On 25 March 2012 16:06, Martin Hewitt <ma...@thenoi.se> wrote:
> I've just restarted our CouchDB instance and, as before, all the views have started to rebuild from scratch.
>
> I've loaded a rebuilding view with ?stale=ok, and it appears to load the view as it would be before the server was restarted, i.e. the view still exists as calculated before the server was restarted and the rebuild began, but the _utils/status.html page shows all views as rebuilding from scratch.
>
> Martin
>
> On 20 Mar 2012, at 16:49, Robert Newson wrote:
>
>> Very curious, would love to know more.
>>
>> On 20 March 2012 16:33, Martin Hewitt <ma...@thenoi.se> wrote:
>>> Hi Robert,
>>>
>>> For one view, whenever we loaded it, but every time we loaded it, would produce a stack trace and not the view. Restarting the CouchDB instance restored the view to working order.
>>>
>>> I'll try and dig out the stack trace, but it was the perpetual, continual problem with this view that led us to take the "nuclear option" and restart.
>>>
>>> Martin
>>>
>>> On 20 Mar 2012, at 14:24, Robert Newson wrote:
>>>
>>>> Can you describe "it was repeatedly crashing with gen_server timeouts"
>>>> in more detail? This sounds non-fatal to me but can look alarming if
>>>> you're not used to the erlang approach to error handling. It might be
>>>> that you're restarting for no good reason.
>>>>
>>>> B.
>>>>
>>>> On 20 March 2012 14:20, Robert Newson <rn...@apache.org> wrote:
>>>>> Also we don't fsync views at all, so if you built the view and then
>>>>> killed couchdb very quickly, the data didn't reach the platters.
>>>>>
>>>>> I'll note that you really, *really*, want to set delayed_commits to
>>>>> false if using couchdb in production. This strongly guarantees that
>>>>> your database updates are preserved in the event of a crash.
>>>>>
>>>>> B.
>>>>>
>>>>> On 20 March 2012 13:51, Jason Smith <jh...@iriscouch.com> wrote:
>>>>>> On Tue, Mar 20, 2012 at 1:38 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>>> Hi Alexander,
>>>>>>>
>>>>>>> On 20 Mar 2012, at 13:23, Alexander Shorin wrote:
>>>>>>>
>>>>>>>> On Tue, Mar 20, 2012 at 5:07 PM, Jo-Erlend Schinstad
>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>> As far as I'm aware, there's no clean way to shutdown CouchDB. It's designed
>>>>>>>>> that way. You just kill it.
>>>>>>>>
>>>>>>>> With _admin permissions:
>>>>>>>> curl -X POST http://localhost:5984/_restart -H "Content-Type: application/json"
>>>>>>>
>>>>>>> Excellent, thanks, I'll give this a try.
>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Mar 20, 2012 at 5:12 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>>>>>> What version are you running?
>>>>>>>>>
>>>>>>>>> Running 1.2.0a-1160734, compiled from source some time back.
>>>>>>>>
>>>>>>>> Looks like subversion revision number and a little out of dated. By
>>>>>>>> the way, CouchDB repository had been moved to git not so far a long
>>>>>>>> ago. Have you tried to update to latest head of 1.2.x branch?
>>>>>>>
>>>>>>> Yeah, i know it's an old version, I was just curious as to whether there was something I could try before rebuilding the server.
>>>>>>
>>>>>> Hi, Martin. I wonder if it is related to this issue?
>>>>>>
>>>>>> CouchDB was deleting .view files if some kinds of errors happened.
>>>>>> This will be fixed in the upcoming version 1.2.0. (But I'm not 100%
>>>>>> sure that that is your issue.)
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Iris Couch
>>>
>
Re: CouchDB, linux & clean shutdowns
Posted by Martin Hewitt <ma...@thenoi.se>.
I've just restarted our CouchDB instance and, as before, all the views have started to rebuild from scratch.
I've loaded a rebuilding view with ?stale=ok, and it appears to load the view as it would be before the server was restarted, i.e. the view still exists as calculated before the server was restarted and the rebuild began, but the _utils/status.html page shows all views as rebuilding from scratch.
Martin
On 20 Mar 2012, at 16:49, Robert Newson wrote:
> Very curious, would love to know more.
>
> On 20 March 2012 16:33, Martin Hewitt <ma...@thenoi.se> wrote:
>> Hi Robert,
>>
>> For one view, whenever we loaded it, but every time we loaded it, would produce a stack trace and not the view. Restarting the CouchDB instance restored the view to working order.
>>
>> I'll try and dig out the stack trace, but it was the perpetual, continual problem with this view that led us to take the "nuclear option" and restart.
>>
>> Martin
>>
>> On 20 Mar 2012, at 14:24, Robert Newson wrote:
>>
>>> Can you describe "it was repeatedly crashing with gen_server timeouts"
>>> in more detail? This sounds non-fatal to me but can look alarming if
>>> you're not used to the erlang approach to error handling. It might be
>>> that you're restarting for no good reason.
>>>
>>> B.
>>>
>>> On 20 March 2012 14:20, Robert Newson <rn...@apache.org> wrote:
>>>> Also we don't fsync views at all, so if you built the view and then
>>>> killed couchdb very quickly, the data didn't reach the platters.
>>>>
>>>> I'll note that you really, *really*, want to set delayed_commits to
>>>> false if using couchdb in production. This strongly guarantees that
>>>> your database updates are preserved in the event of a crash.
>>>>
>>>> B.
>>>>
>>>> On 20 March 2012 13:51, Jason Smith <jh...@iriscouch.com> wrote:
>>>>> On Tue, Mar 20, 2012 at 1:38 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>> Hi Alexander,
>>>>>>
>>>>>> On 20 Mar 2012, at 13:23, Alexander Shorin wrote:
>>>>>>
>>>>>>> On Tue, Mar 20, 2012 at 5:07 PM, Jo-Erlend Schinstad
>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>> As far as I'm aware, there's no clean way to shutdown CouchDB. It's designed
>>>>>>>> that way. You just kill it.
>>>>>>>
>>>>>>> With _admin permissions:
>>>>>>> curl -X POST http://localhost:5984/_restart -H "Content-Type: application/json"
>>>>>>
>>>>>> Excellent, thanks, I'll give this a try.
>>>>>>
>>>>>>>
>>>>>>> On Tue, Mar 20, 2012 at 5:12 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>>>>> What version are you running?
>>>>>>>>
>>>>>>>> Running 1.2.0a-1160734, compiled from source some time back.
>>>>>>>
>>>>>>> Looks like subversion revision number and a little out of dated. By
>>>>>>> the way, CouchDB repository had been moved to git not so far a long
>>>>>>> ago. Have you tried to update to latest head of 1.2.x branch?
>>>>>>
>>>>>> Yeah, i know it's an old version, I was just curious as to whether there was something I could try before rebuilding the server.
>>>>>
>>>>> Hi, Martin. I wonder if it is related to this issue?
>>>>>
>>>>> CouchDB was deleting .view files if some kinds of errors happened.
>>>>> This will be fixed in the upcoming version 1.2.0. (But I'm not 100%
>>>>> sure that that is your issue.)
>>>>>
>>>>>
>>>>> --
>>>>> Iris Couch
>>
Re: CouchDB, linux & clean shutdowns
Posted by Robert Newson <rn...@apache.org>.
Very curious, would love to know more.
On 20 March 2012 16:33, Martin Hewitt <ma...@thenoi.se> wrote:
> Hi Robert,
>
> For one view, whenever we loaded it, but every time we loaded it, would produce a stack trace and not the view. Restarting the CouchDB instance restored the view to working order.
>
> I'll try and dig out the stack trace, but it was the perpetual, continual problem with this view that led us to take the "nuclear option" and restart.
>
> Martin
>
> On 20 Mar 2012, at 14:24, Robert Newson wrote:
>
>> Can you describe "it was repeatedly crashing with gen_server timeouts"
>> in more detail? This sounds non-fatal to me but can look alarming if
>> you're not used to the erlang approach to error handling. It might be
>> that you're restarting for no good reason.
>>
>> B.
>>
>> On 20 March 2012 14:20, Robert Newson <rn...@apache.org> wrote:
>>> Also we don't fsync views at all, so if you built the view and then
>>> killed couchdb very quickly, the data didn't reach the platters.
>>>
>>> I'll note that you really, *really*, want to set delayed_commits to
>>> false if using couchdb in production. This strongly guarantees that
>>> your database updates are preserved in the event of a crash.
>>>
>>> B.
>>>
>>> On 20 March 2012 13:51, Jason Smith <jh...@iriscouch.com> wrote:
>>>> On Tue, Mar 20, 2012 at 1:38 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>> Hi Alexander,
>>>>>
>>>>> On 20 Mar 2012, at 13:23, Alexander Shorin wrote:
>>>>>
>>>>>> On Tue, Mar 20, 2012 at 5:07 PM, Jo-Erlend Schinstad
>>>>>> <jo...@gmail.com> wrote:
>>>>>>> As far as I'm aware, there's no clean way to shutdown CouchDB. It's designed
>>>>>>> that way. You just kill it.
>>>>>>
>>>>>> With _admin permissions:
>>>>>> curl -X POST http://localhost:5984/_restart -H "Content-Type: application/json"
>>>>>
>>>>> Excellent, thanks, I'll give this a try.
>>>>>
>>>>>>
>>>>>> On Tue, Mar 20, 2012 at 5:12 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>>>> What version are you running?
>>>>>>>
>>>>>>> Running 1.2.0a-1160734, compiled from source some time back.
>>>>>>
>>>>>> Looks like subversion revision number and a little out of dated. By
>>>>>> the way, CouchDB repository had been moved to git not so far a long
>>>>>> ago. Have you tried to update to latest head of 1.2.x branch?
>>>>>
>>>>> Yeah, i know it's an old version, I was just curious as to whether there was something I could try before rebuilding the server.
>>>>
>>>> Hi, Martin. I wonder if it is related to this issue?
>>>>
>>>> CouchDB was deleting .view files if some kinds of errors happened.
>>>> This will be fixed in the upcoming version 1.2.0. (But I'm not 100%
>>>> sure that that is your issue.)
>>>>
>>>>
>>>> --
>>>> Iris Couch
>
Re: CouchDB, linux & clean shutdowns
Posted by Martin Hewitt <ma...@thenoi.se>.
Hi Robert,
For one view, whenever we loaded it, but every time we loaded it, would produce a stack trace and not the view. Restarting the CouchDB instance restored the view to working order.
I'll try and dig out the stack trace, but it was the perpetual, continual problem with this view that led us to take the "nuclear option" and restart.
Martin
On 20 Mar 2012, at 14:24, Robert Newson wrote:
> Can you describe "it was repeatedly crashing with gen_server timeouts"
> in more detail? This sounds non-fatal to me but can look alarming if
> you're not used to the erlang approach to error handling. It might be
> that you're restarting for no good reason.
>
> B.
>
> On 20 March 2012 14:20, Robert Newson <rn...@apache.org> wrote:
>> Also we don't fsync views at all, so if you built the view and then
>> killed couchdb very quickly, the data didn't reach the platters.
>>
>> I'll note that you really, *really*, want to set delayed_commits to
>> false if using couchdb in production. This strongly guarantees that
>> your database updates are preserved in the event of a crash.
>>
>> B.
>>
>> On 20 March 2012 13:51, Jason Smith <jh...@iriscouch.com> wrote:
>>> On Tue, Mar 20, 2012 at 1:38 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>> Hi Alexander,
>>>>
>>>> On 20 Mar 2012, at 13:23, Alexander Shorin wrote:
>>>>
>>>>> On Tue, Mar 20, 2012 at 5:07 PM, Jo-Erlend Schinstad
>>>>> <jo...@gmail.com> wrote:
>>>>>> As far as I'm aware, there's no clean way to shutdown CouchDB. It's designed
>>>>>> that way. You just kill it.
>>>>>
>>>>> With _admin permissions:
>>>>> curl -X POST http://localhost:5984/_restart -H "Content-Type: application/json"
>>>>
>>>> Excellent, thanks, I'll give this a try.
>>>>
>>>>>
>>>>> On Tue, Mar 20, 2012 at 5:12 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>>> What version are you running?
>>>>>>
>>>>>> Running 1.2.0a-1160734, compiled from source some time back.
>>>>>
>>>>> Looks like subversion revision number and a little out of dated. By
>>>>> the way, CouchDB repository had been moved to git not so far a long
>>>>> ago. Have you tried to update to latest head of 1.2.x branch?
>>>>
>>>> Yeah, i know it's an old version, I was just curious as to whether there was something I could try before rebuilding the server.
>>>
>>> Hi, Martin. I wonder if it is related to this issue?
>>>
>>> CouchDB was deleting .view files if some kinds of errors happened.
>>> This will be fixed in the upcoming version 1.2.0. (But I'm not 100%
>>> sure that that is your issue.)
>>>
>>>
>>> --
>>> Iris Couch
Re: CouchDB, linux & clean shutdowns
Posted by Robert Newson <rn...@apache.org>.
Can you describe "it was repeatedly crashing with gen_server timeouts"
in more detail? This sounds non-fatal to me but can look alarming if
you're not used to the erlang approach to error handling. It might be
that you're restarting for no good reason.
B.
On 20 March 2012 14:20, Robert Newson <rn...@apache.org> wrote:
> Also we don't fsync views at all, so if you built the view and then
> killed couchdb very quickly, the data didn't reach the platters.
>
> I'll note that you really, *really*, want to set delayed_commits to
> false if using couchdb in production. This strongly guarantees that
> your database updates are preserved in the event of a crash.
>
> B.
>
> On 20 March 2012 13:51, Jason Smith <jh...@iriscouch.com> wrote:
>> On Tue, Mar 20, 2012 at 1:38 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>> Hi Alexander,
>>>
>>> On 20 Mar 2012, at 13:23, Alexander Shorin wrote:
>>>
>>>> On Tue, Mar 20, 2012 at 5:07 PM, Jo-Erlend Schinstad
>>>> <jo...@gmail.com> wrote:
>>>>> As far as I'm aware, there's no clean way to shutdown CouchDB. It's designed
>>>>> that way. You just kill it.
>>>>
>>>> With _admin permissions:
>>>> curl -X POST http://localhost:5984/_restart -H "Content-Type: application/json"
>>>
>>> Excellent, thanks, I'll give this a try.
>>>
>>>>
>>>> On Tue, Mar 20, 2012 at 5:12 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>>> What version are you running?
>>>>>
>>>>> Running 1.2.0a-1160734, compiled from source some time back.
>>>>
>>>> Looks like subversion revision number and a little out of dated. By
>>>> the way, CouchDB repository had been moved to git not so far a long
>>>> ago. Have you tried to update to latest head of 1.2.x branch?
>>>
>>> Yeah, i know it's an old version, I was just curious as to whether there was something I could try before rebuilding the server.
>>
>> Hi, Martin. I wonder if it is related to this issue?
>>
>> CouchDB was deleting .view files if some kinds of errors happened.
>> This will be fixed in the upcoming version 1.2.0. (But I'm not 100%
>> sure that that is your issue.)
>>
>>
>> --
>> Iris Couch
Re: CouchDB, linux & clean shutdowns
Posted by Robert Newson <rn...@apache.org>.
Also we don't fsync views at all, so if you built the view and then
killed couchdb very quickly, the data didn't reach the platters.
I'll note that you really, *really*, want to set delayed_commits to
false if using couchdb in production. This strongly guarantees that
your database updates are preserved in the event of a crash.
B.
On 20 March 2012 13:51, Jason Smith <jh...@iriscouch.com> wrote:
> On Tue, Mar 20, 2012 at 1:38 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>> Hi Alexander,
>>
>> On 20 Mar 2012, at 13:23, Alexander Shorin wrote:
>>
>>> On Tue, Mar 20, 2012 at 5:07 PM, Jo-Erlend Schinstad
>>> <jo...@gmail.com> wrote:
>>>> As far as I'm aware, there's no clean way to shutdown CouchDB. It's designed
>>>> that way. You just kill it.
>>>
>>> With _admin permissions:
>>> curl -X POST http://localhost:5984/_restart -H "Content-Type: application/json"
>>
>> Excellent, thanks, I'll give this a try.
>>
>>>
>>> On Tue, Mar 20, 2012 at 5:12 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>>> What version are you running?
>>>>
>>>> Running 1.2.0a-1160734, compiled from source some time back.
>>>
>>> Looks like subversion revision number and a little out of dated. By
>>> the way, CouchDB repository had been moved to git not so far a long
>>> ago. Have you tried to update to latest head of 1.2.x branch?
>>
>> Yeah, i know it's an old version, I was just curious as to whether there was something I could try before rebuilding the server.
>
> Hi, Martin. I wonder if it is related to this issue?
>
> CouchDB was deleting .view files if some kinds of errors happened.
> This will be fixed in the upcoming version 1.2.0. (But I'm not 100%
> sure that that is your issue.)
>
>
> --
> Iris Couch
Re: CouchDB, linux & clean shutdowns
Posted by Jason Smith <jh...@iriscouch.com>.
On Tue, Mar 20, 2012 at 1:38 PM, Martin Hewitt <ma...@thenoi.se> wrote:
> Hi Alexander,
>
> On 20 Mar 2012, at 13:23, Alexander Shorin wrote:
>
>> On Tue, Mar 20, 2012 at 5:07 PM, Jo-Erlend Schinstad
>> <jo...@gmail.com> wrote:
>>> As far as I'm aware, there's no clean way to shutdown CouchDB. It's designed
>>> that way. You just kill it.
>>
>> With _admin permissions:
>> curl -X POST http://localhost:5984/_restart -H "Content-Type: application/json"
>
> Excellent, thanks, I'll give this a try.
>
>>
>> On Tue, Mar 20, 2012 at 5:12 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>>> What version are you running?
>>>
>>> Running 1.2.0a-1160734, compiled from source some time back.
>>
>> Looks like subversion revision number and a little out of dated. By
>> the way, CouchDB repository had been moved to git not so far a long
>> ago. Have you tried to update to latest head of 1.2.x branch?
>
> Yeah, i know it's an old version, I was just curious as to whether there was something I could try before rebuilding the server.
Hi, Martin. I wonder if it is related to this issue?
CouchDB was deleting .view files if some kinds of errors happened.
This will be fixed in the upcoming version 1.2.0. (But I'm not 100%
sure that that is your issue.)
--
Iris Couch
Re: CouchDB, linux & clean shutdowns
Posted by Martin Hewitt <ma...@thenoi.se>.
Hi Alexander,
On 20 Mar 2012, at 13:23, Alexander Shorin wrote:
> On Tue, Mar 20, 2012 at 5:07 PM, Jo-Erlend Schinstad
> <jo...@gmail.com> wrote:
>> As far as I'm aware, there's no clean way to shutdown CouchDB. It's designed
>> that way. You just kill it.
>
> With _admin permissions:
> curl -X POST http://localhost:5984/_restart -H "Content-Type: application/json"
Excellent, thanks, I'll give this a try.
>
> On Tue, Mar 20, 2012 at 5:12 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>>> What version are you running?
>>
>> Running 1.2.0a-1160734, compiled from source some time back.
>
> Looks like subversion revision number and a little out of dated. By
> the way, CouchDB repository had been moved to git not so far a long
> ago. Have you tried to update to latest head of 1.2.x branch?
Yeah, i know it's an old version, I was just curious as to whether there was something I could try before rebuilding the server.
>
> --
> ,,,^..^,,,
Re: CouchDB, linux & clean shutdowns
Posted by Alexander Shorin <kx...@gmail.com>.
On Tue, Mar 20, 2012 at 5:07 PM, Jo-Erlend Schinstad
<jo...@gmail.com> wrote:
> As far as I'm aware, there's no clean way to shutdown CouchDB. It's designed
> that way. You just kill it.
With _admin permissions:
curl -X POST http://localhost:5984/_restart -H "Content-Type: application/json"
On Tue, Mar 20, 2012 at 5:12 PM, Martin Hewitt <ma...@thenoi.se> wrote:
>> What version are you running?
>
> Running 1.2.0a-1160734, compiled from source some time back.
Looks like subversion revision number and a little out of dated. By
the way, CouchDB repository had been moved to git not so far a long
ago. Have you tried to update to latest head of 1.2.x branch?
--
,,,^..^,,,
Re: CouchDB, linux & clean shutdowns
Posted by Jo-Erlend Schinstad <jo...@gmail.com>.
Den 20. mars 2012 13:59, skrev Martin Hewitt:
> Is this a CouchDB "thing" or is the init.d script shutting down CouchDB in a non-clean fashion that's causing a cautionary rebuild when CouchDB comes back up?
As far as I'm aware, there's no clean way to shutdown CouchDB. It's
designed that way. You just kill it.
--
Jo-Erlend Schinstad