Re: Couch stopped working (service was still alive)

2016-11-28 Thread Kiril Stankov

Hi,
thanks for the answer.
Yes, that's the Erlang version.
No, there is nothing else in the log, this error appears several times 
(actually on every access to Couch - it was actually alive, but no 
answering).
Nothing special in the calls to Couch before that. Neither on the OS 
side - regular, not very busy use.

We had much higher usage peeks and nothing like this happened for months.

So, another question - can an automatic restart of Couch be safely 
assumed as solution in this case? I can have a script trying to get a 
test doc, and if it fails, then /service couchdb restart?


/Thanks./
/

*With best regards,*
Kiril Stankov

On 11/28/2016 1:29 AM, Robert Samuel Newson wrote:

looks like a bug in a core Erlang/OTP application (disksup) rather than couchdb 
itself. What version of erlang are you using?

Ubuntu 14.04 bundles R16B03 so I'll assume that for now, so that's

terminate(_Reason, State) ->
 clear_alarms(),
 case State#state.port of
 not_used ->
 ok;
 Port ->
 port_close(Port)
 end,
 ok.

Which is to say, the reason for that process to terminate is a bug in the 
terminate callback function, and that makes no sense to me. I suspect, but 
don't know, that this is just wonky reporting. Something else must have caused 
termination, and the bug in terminate/2 is being reported erroneously as that 
reason. Perhaps there's more in your log that would explain this.

On your question of data corruption, that won't happen for any kind of process 
crash in couchdb. The worst scenario would be any un-fsynced data being lost 
and all databases rolling back to the last fsynced state. For this reason, we 
recommend setting the delayed_commits config setting to false. This defaults to 
true in versions earlier than 2.0, and defaults to true from 2.0 onward.

HTH
B.



On 27 Nov 2016, at 08:46, Kiril Stankov  wrote:

Hi,

I adore Couch, but one thing always puzzled me is the log files syntax.
I understand it is readable for Erlang people, but not being one of them, can, 
please, someone help me decipher the lines below.

Couch stopped answering queries yesterday, after 6 months of flawless operation.
There was nothing unusual on the OS, disk has plenty of space, etc. Ubuntu 14. 
Couch 1.6.

Restarting it fixed the problem.

But I am still unsure if possible data corruption may have occurred and what 
was the root cause of the problem.

Thanks!

[Fri, 25 Nov 2016 14:53:01 GMT] [error] [<0.2510.0>] {error_report,<0.78.0>,
  {<0.2510.0>,crash_report,
[[{initial_call,{disksup,init,['Argument__1']}},
 {pid,<0.2510.0>},
 {registered_name,disksup},
 {error_info,
  {exit,
   {badarg,
[{erlang,port_close,[#Port<0.3152>],[]},
 {disksup,terminate,2,
  [{file,"disksup.erl"},{line,164}]},
 {gen_server,terminate,6,
  [{file,"gen_server.erl"},{line,719}]},
 {proc_lib,init_p_do_apply,3,
  [{file,"proc_lib.erl"},{line,239}]}]},
   [{gen_server,terminate,6,
 [{file,"gen_server.erl"},{line,722}]},
{proc_lib,init_p_do_apply,3,
 [{file,"proc_lib.erl"},{line,239}]}]}},
 {ancestors,[os_mon_sup,<0.79.0>]},
 {messages,[]},
 {links,[<0.80.0>]},
 {dictionary,[]},
 {trap_exit,true},
 {status,running},
 {heap_size,610},
 {stack_size,27},
 {reductions,350}],
[]]}}

[Fri, 25 Nov 2016 14:53:01 GMT] [error] [<0.80.0>] {error_report,<0.78.0>,
   {<0.80.0>,supervisor_report,
[{supervisor,{local,os_mon_sup}},
 {errorContext,child_terminated},
 {reason,
 {badarg,
[{erlang,port_close,[#Port<0.3157>],[]},
  {disksup,terminate,2,
[{file,"disksup.erl"},{line,164}]},
  {gen_server,terminate,6,
[{file,"gen_server.erl"},{line,719}]},
  {proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,239}]}]}},
 {offender,
 [{pid,<0.2514.0>},
  {name,disksup},
  {mfargs,{disksup,start_link,[]}},
  {restart_type,permanent},
  {shutdown,2000},
  {child_type,worker}]}]}}



apt-get package for CouchDB 2.0

2016-11-28 Thread Stefan du Fresne
Hi,

Is there an intention to update Ubuntu et al’s apt-get package from 1.6 to 2.0? 
If so, is there an ETA for this? While it is possible to compile from source, 
I’d like to be able to run integration tests against CouchDB2.0 in Travis, and 
so an official package would make that a lot easier (and faster).

While I’m here, is the brew package also being actively worked on?

Cheers,
Stefan

Re: [CouchDB 1.6] Use symlinks for database files?

2016-11-28 Thread Kevin Qiu
Thanks. I've replied inline.

On Mon, Nov 28, 2016 at 1:19 PM, Joel Wallis Jucá 
wrote:

> Just curious: when you say your app will use the db A', do you app uses the
> CouchDB "way" to access data (aka the HTTP interface)? If it does, what's
> the point on using symlinks in the case you've just described?
>
>
Yes, we're using HTTP api to access couchdb. The point here is that we
don't have to change the configuration for individual services to point to
A'.



> FYI: this step (moving valid documents to a new db and discard
> deleted/invalid ones) is common with devs using CouchDB, but take note that
> if you're on a distributed environment it might not be a good idea (you
> need to have a deleted document being propagated to have proper eventual
> consistence).
>
>
We're not using couchdb in a distributed setup. We run 2 db instances, one
active and the other standby with haproxy in front.



> 2016-11-28 15:04 GMT-03:00 Kevin Qiu :
>
> > Hi all,
> >
> > I have a question regarding using symbolic links for {db}.couch file and
> > .{db}_design folder. First off, this is my usecase: we use couchdb 1.6.1,
> > and our data size has been growing rapidly to the point we have to
> archive
> > old data. We chose to use the filtered replication approach. We setup a
> > replication task from db A to db A' with a filter function that weeds out
> > documents older than X months (we have a metadata field that records the
> > document create date).
> >
> > We would also like to seamlessly having our application start using the
> > filtered database (A') without having to change our application db
> > configuration to point to A'. Here's the question, is it possible to use
> > symbolic links to achieve this? i.e., have a symbolic link L ( (both
> .couch
> > file and _design folder) to point to A initially, and after the filtered
> > replication is done, re-point L to A'.
> >
> > From my own experiments, it looks like this is possible, not without
> > caveats however. E.g., when L already exists, it works when I unlink L
> and
> > then do `ln -s A' L`. Everything seems to be fine. However, if I do `ln
> -s
> > A' L_tmp && mv -Tf L_tmp L` (atomic switch), it appears that couchdb
> fails
> > to recognize L being a pointer to another couchdb file, and shows that
> the
> > db contains 0 documents.
> >
> > Any input is appreciated!
> >
> > -Kevin
> >
>
>
>
> --
> Joel Wallis Jucá
> joelwallis.com
>


Re: [CouchDB 1.6] Use symlinks for database files?

2016-11-28 Thread Joel Wallis Jucá
Just curious: when you say your app will use the db A', do you app uses the
CouchDB "way" to access data (aka the HTTP interface)? If it does, what's
the point on using symlinks in the case you've just described?

FYI: this step (moving valid documents to a new db and discard
deleted/invalid ones) is common with devs using CouchDB, but take note that
if you're on a distributed environment it might not be a good idea (you
need to have a deleted document being propagated to have proper eventual
consistence).

2016-11-28 15:04 GMT-03:00 Kevin Qiu :

> Hi all,
>
> I have a question regarding using symbolic links for {db}.couch file and
> .{db}_design folder. First off, this is my usecase: we use couchdb 1.6.1,
> and our data size has been growing rapidly to the point we have to archive
> old data. We chose to use the filtered replication approach. We setup a
> replication task from db A to db A' with a filter function that weeds out
> documents older than X months (we have a metadata field that records the
> document create date).
>
> We would also like to seamlessly having our application start using the
> filtered database (A') without having to change our application db
> configuration to point to A'. Here's the question, is it possible to use
> symbolic links to achieve this? i.e., have a symbolic link L ( (both .couch
> file and _design folder) to point to A initially, and after the filtered
> replication is done, re-point L to A'.
>
> From my own experiments, it looks like this is possible, not without
> caveats however. E.g., when L already exists, it works when I unlink L and
> then do `ln -s A' L`. Everything seems to be fine. However, if I do `ln -s
> A' L_tmp && mv -Tf L_tmp L` (atomic switch), it appears that couchdb fails
> to recognize L being a pointer to another couchdb file, and shows that the
> db contains 0 documents.
>
> Any input is appreciated!
>
> -Kevin
>



-- 
Joel Wallis Jucá
joelwallis.com


[CouchDB 1.6] Use symlinks for database files?

2016-11-28 Thread Kevin Qiu
Hi all,

I have a question regarding using symbolic links for {db}.couch file and
.{db}_design folder. First off, this is my usecase: we use couchdb 1.6.1,
and our data size has been growing rapidly to the point we have to archive
old data. We chose to use the filtered replication approach. We setup a
replication task from db A to db A' with a filter function that weeds out
documents older than X months (we have a metadata field that records the
document create date).

We would also like to seamlessly having our application start using the
filtered database (A') without having to change our application db
configuration to point to A'. Here's the question, is it possible to use
symbolic links to achieve this? i.e., have a symbolic link L ( (both .couch
file and _design folder) to point to A initially, and after the filtered
replication is done, re-point L to A'.

>From my own experiments, it looks like this is possible, not without
caveats however. E.g., when L already exists, it works when I unlink L and
then do `ln -s A' L`. Everything seems to be fine. However, if I do `ln -s
A' L_tmp && mv -Tf L_tmp L` (atomic switch), it appears that couchdb fails
to recognize L being a pointer to another couchdb file, and shows that the
db contains 0 documents.

Any input is appreciated!

-Kevin