couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From JC de Villa <>
Subject Re: Replication problems between 32 and 64 bit.
Date Mon, 21 Mar 2011 11:23:57 GMT
Erg. You're right. Sorry about that. I found the bin in my downloads
and thought that was what I installed.

But curl'ing the couches on dev, master and the new machine get me...


Would it matter if I was doing the replication over ssh?

JC de Villa

On Mon, Mar 21, 2011 at 7:13 PM, Robert Newson <> wrote:
> 1.0.0_1 should be the 1st version of the package for 1.0.0, I think.
> B.
> On 21 March 2011 10:52, JC de Villa <> wrote:
>> Sorry for the late reply. Everything else is inline.
>> On Sat, Mar 19, 2011 at 7:10 PM, Robert Newson <> wrote:
>>> Is it the design documents that aren't being replicated? If so, you
>>> need to authenticate at the target (you need admin access to update
>>> ddocs).
>> Yep, did that. Anywho, it's not just the ddocs that aren't
>> replicating. At whatever particular point the replication stops,
>> nothing further gets pulled from the master. Not to mention the other
>> three databases that fail completely.
>>> .couch files are compatible across all platforms, you can copy them
>>> anywhere. Are you using the same version of couchdb in all places?
>> Hmm... using 1.0.0_1 that made available for download last
>> year running on lucid, and 1.0.1 from the Maverick repos. IIRC,
>>'s 1.0.0_1 is equivalent to 1.0.1 right?
>> But here's how it looks like. The dev machine holds a copy of the
>> couch which replicates continuously from Master. Since we're moving
>> things over to a new machine, I initiated a pull into the new machine,
>> which never completes on the first three databases. For the rest of
>> the databases, partially replicates, then replication crashes for
>> those  last three.
>> I put up the same version of couch on my workstation, and it completes
>> just fine, whether I pull from master or dev, but whenever I pull from
>> the New machine (from master, dev or my workstation), it doesn't
>> complete.
>> Dev <----- Master -----> New Machine
>>  1.0.0_1  | 1.0.0_1  | 1.0.1
>> | | maverick repo
>>  ok       |          | Fails.
>>> I'm in a good mood, so I'll forget you said "table" :)
>> Lol. Sorry... Jumping between couch and postgres.
>> I'll try replicating again today. Seems there was a full moon this
>> past weekend. I wouldn't put it past gremlins or other cosmic forces
>> to have fudged with my brain or my machines.
>>> B.
>>> On 19 March 2011 07:15, JC de Villa <> wrote:
>>>> Resending again. That spam filter threw this back to me about 4 times
>>>> already, I think.
>>>> Hi guys,
>>>> I've been using couch over the past year and love it completely, but I
>>>> was just wondering. In replicating between 32 and 64 bit couch, should
>>>> there be any difficulty? I've been trying to replicate from a virtual
>>>> machine running 32 bit Ubuntu 10.04 to a server on ubuntu 10.10 64bit
>>>> and have been failing constantly. The replication hangs on a few
>>>> tables right near the end of the replications and eventually looks
>>>> like they time out (disappears from the Status list). The few that
>>>> don't hang don't complete never get a complete copy. Always just one
>>>> or two docs shy of the full replica.
>>>> In total, I initiated 6 pull replications into the 64 bit machine,
>>>> with the 32bit VM as the source - Three crash, three continue but
>>>> never get the entire set.
>>>> I have a separate dev VM thats also 32bit thats continuously
>>>> replicating from the main 32bit  instance that never shows any
>>>> problem. My workstation (also on 32bit) can pull at anytime without
>>>> any problem (whether continuous or not.
>>>> Are the couch files compatible between 32 and 64 bit? If so, I could
>>>> just move the database files onto the 64bit machine as we're migrating
>>>> to that eventually. Alternatively, I could just install the 32 bit
>>>> version I grabbed from a few months back and use that for the
>>>> couch.
>>>> Thoughts? And thanks in advance also.
>>>> JC de Villa

View raw message