Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 76DEADF34 for ; Wed, 7 Nov 2012 13:32:01 +0000 (UTC) Received: (qmail 73603 invoked by uid 500); 7 Nov 2012 13:32:00 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 73569 invoked by uid 500); 7 Nov 2012 13:31:59 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 73551 invoked by uid 99); 7 Nov 2012 13:31:59 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Nov 2012 13:31:59 +0000 Received: from localhost (HELO mail-vc0-f180.google.com) (127.0.0.1) (smtp-auth username rnewson, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Nov 2012 13:31:58 +0000 Received: by mail-vc0-f180.google.com with SMTP id fl13so1480446vcb.11 for ; Wed, 07 Nov 2012 05:31:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.99.103 with SMTP id ep7mr3674082vdb.17.1352295117463; Wed, 07 Nov 2012 05:31:57 -0800 (PST) Received: by 10.52.69.79 with HTTP; Wed, 7 Nov 2012 05:31:57 -0800 (PST) In-Reply-To: References: <20121107143025.30a5147d@eee-az> <9B15C42A-50B1-45E4-AAB6-A53E7D13C722@gmail.com> Date: Wed, 7 Nov 2012 13:31:57 +0000 Message-ID: Subject: Re: Remote view looks different to localhost From: Robert Newson To: "user@couchdb.apache.org" Content-Type: multipart/alternative; boundary=20cf307f38f61b9ec704cde7be5c --20cf307f38f61b9ec704cde7be5c Content-Type: text/plain; charset=ISO-8859-1 I'd be very careful here. Assuming database_dir is the same for both instance, only one of them is pointing to the same data that the filesystem is. If it's not the one you want, do not stop either instance, use the /proc//fd links to find the actual data and copy it out. Verify it by copying that data to another server before you stop either instance. On 7 November 2012 13:20, Stoo Goff wrote: > OK, that definitely is the case. I've used /etc/init.d/couchdb stop to stop > the server. ps ax shows one instance running now. If I make a request using > curl on the server it gives me the same results I've been seeing all along, > if I do it from the remote machine I get a failure to connect to host > > So there were definitely two instances running. The currently running > instance has the correct data. If I stop the remaining instance of couch > and restart which set of data will I end up with? > > > On 7 November 2012 13:11, Stoo Goff wrote: > > > I think you might have it... > > > > 16592 ? S 267:59 /usr/lib/erlang/erts-5.8/bin/beam -Bd -K true > > -- -root /usr/lib/erlang -progname erl -- -home /var/lib/couchdb -- > > -noshell -noinput -sasl errlog_type error -couch_ini > > /etc/couchdb/default.ini /etc/couchdb/local.ini /etc/couchdb/default.ini > > /etc/couchdb/local.ini -s couch -pidfile /var/run/couchdb/couchdb.pid > -heart > > 17665 ? S 202:21 /usr/lib/erlang/erts-5.8/bin/beam -Bd -K true > > -- -root /usr/lib/erlang -progname erl -- -home /var/lib/couchdb -- > > -noshell -noinput -sasl errlog_type error -couch_ini > > /etc/couchdb/default.ini /etc/couchdb/local.ini /etc/couchdb/default.ini > > /etc/couchdb/local.ini -s couch -pidfile /var/run/couchdb/couchdb.pid > -heart > > > > > > On 7 November 2012 12:58, Paul J Davis >wrote: > > > >> Forgot to add that you should also do a "ps ax | grep beam" and make > sure > >> you don't have two servers running bound to two different ports. > >> > >> On Nov 7, 2012, at 1:56 PM, Stoo Goff wrote: > >> > >> > Also, why would the sequence numbers be so different? > >> > > >> > Logged in to the server I get update_seq of 1194. Viewing the same > date > >> > remotely the udpate_seq is 102. > >> > > >> > On 7 November 2012 12:53, Stoo Goff wrote: > >> > > >> >> Adding ?_all_docs=true gives me the same result as before. Do you > mean > >> >> database/_all_docs? > >> >> > >> >> > >> >> On 7 November 2012 12:30, svilen wrote: > >> >> > >> >>> and if u add ?_all_docs=true what docs would u get? > >> >>> (do check the syntax) > >> >>> > >> >>> > >> >>> > >> >>> On Wed, 7 Nov 2012 11:46:56 +0000 > >> >>> Stoo Goff wrote: > >> >>> > >> >>>> Hi, > >> >>>> > >> >>>> I'm getting some strange differences when I view a database, > >> >>>> depending on whether I view the database remotely or locally. > >> >>>> > >> >>>> The server: > >> >>>> > >> >>>> Debian squeeze running Couchdb 0.11.0 > >> >>>> > >> >>>> The dev box: > >> >>>> > >> >>>> Ubuntu 11.10 running Couchdb 1.0.1 > >> >>>> > >> >>>> I initially created the database on the dev machine, then > replicated > >> >>>> it to an empty database on the server. I have a web app running on > >> >>>> the server connecting over localhost and everything seemed to be > >> >>>> working fine - in fact as far as the web app is concerned it's all > >> >>>> running perfect. > >> >>>> > >> >>>> I changed the Couchdb settings so I could view the data remotely. > >> >>>> Initially, I used Futon to take a look and that showed me a > >> completely > >> >>>> different set of data. So I tried looking at the data using CURL. > >> That > >> >>>> showed me the same as Futon. > >> >>>> > >> >>>> CURL run on the server: > >> >>>> > >> >>>> curl -X GET http://localhost:5984/muninn > >> >>> > >> > {"db_name":"muninn","doc_count":25,"doc_del_count":33,"update_seq":1194,"purge_seq":0,"compact_running":false,"disk_size":16826462,"instance_start_time":"1351793407368363","disk_format_version":5} > >> >>>> > >> >>>> CURL run on the dev machine: > >> >>>> > >> >>>> curl -X GET http://user:pass@odin:5984/muninn > >> >>> > >> > {"db_name":"muninn","doc_count":9,"doc_del_count":34,"update_seq":102,"purge_seq":0,"compact_running":false,"disk_size":16826462,"instance_start_time":"1352219217053672","disk_format_version":5} > >> >>>> > >> >>>> So, same disk size with completely different doc counts. With the > >> >>>> remote connection it looks like an historical view of the data, but > >> >>>> why would it do it? > >> >>>> > >> >>>> Any help or insight would be appreciated! > >> >>>> > >> >>>> Stoo > >> >> > >> >> > >> > > > > > --20cf307f38f61b9ec704cde7be5c--