From user-return-24645-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Thu May 30 14:06:51 2013
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 B7B5CFEF2
for ; Thu, 30 May 2013 14:06:51 +0000 (UTC)
Received: (qmail 98348 invoked by uid 500); 30 May 2013 14:06:50 -0000
Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org
Received: (qmail 98150 invoked by uid 500); 30 May 2013 14:06:47 -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 98122 invoked by uid 99); 30 May 2013 14:06:46 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 May 2013 14:06:46 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of adam.kocoloski@gmail.com designates 209.85.216.44 as permitted sender)
Received: from [209.85.216.44] (HELO mail-qa0-f44.google.com) (209.85.216.44)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 May 2013 14:06:39 +0000
Received: by mail-qa0-f44.google.com with SMTP id hu16so2887864qab.3
for ; Thu, 30 May 2013 07:06:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=content-type:mime-version:subject:from:in-reply-to:date
:content-transfer-encoding:message-id:references:to:x-mailer;
bh=aOjO92fiayQjKUePo33UsPhFBSAk2ccVZjp1JgEvN/g=;
b=VygR5e2qx74Slszsu+MnyYn9z+dHTeyy9CS3VgUB7AuIV0G8EWfd9T1st0/ja3SwZ9
JjHZvVmO1JLQr/DyTZdmYHEiA1bgkj4mq6VyRzH2bdjr9K+4MqxsjuG5ewwCTLoy4Uxc
1c8aud9/npNz+T1ztmrgM2d2kOWrciU/mkn3HKl0HFJSS9hyIHWvtP2QxPJfESAhNevo
dNLXltVUD/T8NBd4HbXzLBb1A++/97mM5k2IAExxel13KO1tbQJ/r6NeDeJN0SPuF+SS
iWllpYz3zZUUXQoxxSYdzY1QrY5ZrvYHlCXkq/3aZQVCz/fA9zxJGAKqm07QaK/Ew01M
A+5w==
X-Received: by 10.229.164.79 with SMTP id d15mr2526590qcy.3.1369922778888;
Thu, 30 May 2013 07:06:18 -0700 (PDT)
Received: from [172.16.9.233] (50-195-18-145-static.hfc.comcastbusiness.net. [50.195.18.145])
by mx.google.com with ESMTPSA id db3sm36723371qab.4.2013.05.30.07.06.17
for
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Thu, 30 May 2013 07:06:18 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Subject: Re: Speed up Replication with large Database
From: Adam Kocoloski
In-Reply-To:
Date: Thu, 30 May 2013 10:06:15 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id:
References:
To: user@couchdb.apache.org
X-Mailer: Apple Mail (2.1503)
X-Virus-Checked: Checked by ClamAV on apache.org
It's a hack, but if you know the sequence number of the database when =
you copied it you can add a parameter to the body of the replication =
specification to "fast-forward" it and bypass the checks:
"since_seq": 1234
Adam
On May 30, 2013, at 7:01 AM, Robert Newson wrote:
> Hi,
>=20
> The replication process will be reading through your databases
> _changes feed. Copying the file to the target will immediately ensure
> you have a redundant copy but it will not do anything to speed up a
> replication as the replicator has no one to detect that you copied the
> file. What it's now doing is asking the target if it has the documents
> present on the source. Since you've copied the file, the answer is
> always "yes" but it has to ask anyway. It will be going faster than if
> you hadn't copied it, as it won't need to transfer document or
> attachment bodies, but it will still take time.
>=20
> a 600 GB .couch file is very unwieldy, though, have you ever compacted
> that database?
>=20
> B.
>=20
>=20
> On 29 May 2013 16:24, Tilmann Sittig =
wrote:
>> Hello all,
>>=20
>> I have a Question concerning Replication i found nothing about so =
far.
>>=20
>> I was asked to change a single couchDB Server to a load-balanced =
2-node-setup.
>> Setup with haproxy went smoothly, but when i got to Replication, i =
was confronted with a large 600 GB data.couch file on the original =
server and a mediocre Bandwith between the servers.
>> So i sent a Harddisk to the Hoster, copied the data.couch file and =
installed it on the new 2nd Node.
>>=20
>> When i configured a continuous Replication after that transfer i =
expected a much faster Replication/Sync, but it is still running.
>>=20
>> Any Ideas how to speed that up?
>>=20
>> Thanks for your time,
>>=20
>> T.Sittig
>>=20
>>=20