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 5232E10617 for ; Tue, 16 Apr 2013 13:13:57 +0000 (UTC) Received: (qmail 82320 invoked by uid 500); 16 Apr 2013 13:13:55 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 82206 invoked by uid 500); 16 Apr 2013 13:13:55 -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 82185 invoked by uid 99); 16 Apr 2013 13:13:54 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Apr 2013 13:13:54 +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 (athena.apache.org: domain of hungryblank@gmail.com designates 74.125.82.53 as permitted sender) Received: from [74.125.82.53] (HELO mail-wg0-f53.google.com) (74.125.82.53) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Apr 2013 13:13:50 +0000 Received: by mail-wg0-f53.google.com with SMTP id z11so468590wgg.32 for ; Tue, 16 Apr 2013 06:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=BTnfI+Hf1EMMID8FqeQ3AeCq01EVcsGvyYWJAH0PWco=; b=Txw1siMcbmRjoxPb2ANgC79/yuSV/WZA8tOvTzdI4x2E/ZXXeqjch7JS90A7rNhcd6 Q4plW40Wlb02Heyj4DUzXL9leWmmaSIYP5ZtONgBZ7cIHG/rMtZ/UpsJ84YmojZ48odW tCQL0yKtdb9H/6qc4RM+tdNtJT63RXWkCBOuwEpKeH9noUYQ8sN0YAZYkUWECPVMWm/u er5Y6vA45lbhjMR4TsZmUZRIaR5JHWoMbXTq9oXC9mUANSkkkfvxaqTR4QKgknhjlm13 10IYS+MOc1fb1n6hS+Bt6kEKhKmcaCf9Et+8Rw/GKjCF82BwtHhk84wyZdq6eLW01dFg zp5Q== MIME-Version: 1.0 X-Received: by 10.180.94.133 with SMTP id dc5mr20298858wib.1.1366118009003; Tue, 16 Apr 2013 06:13:29 -0700 (PDT) Received: by 10.216.192.131 with HTTP; Tue, 16 Apr 2013 06:13:28 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Apr 2013 15:13:28 +0200 Message-ID: Subject: Re: Replication and sequence id question From: Paolo Negri To: user@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org Replications would be initiated from touchdb, typical case being a mobile application ships with a primed database or with an empty database, then when a connection is available the mobile application would then connect to the server in order to synchronize the database and receive updated data from the server. Paolo On Tue, Apr 16, 2013 at 3:00 PM, Robert Newson wrote: > Yes. The couchdb replicator stores the checkpoint at both source and > target. I don't know touchdb beyond its goal of being > couchdb-on-mobile, so I will defer to Jens as to whether the > replicator in touchdb also does this. Are you initiating replication > on couchdb or touchdb? > > B. > > On 16 April 2013 13:48, Paolo Negri wrote: >> Thanks again for the answer, I'm now confused by the role of the >> checkpoint and its storage, let's say that I have a mobile app that >> has been downloaded on 100k devices and I'm using touchdb to sync my >> db to the devices, does this mean that each device will need to store >> a checkpoint on my server side database, so that I'd end up with 100k >> local documents in the database each one belonging to one of the >> clients? >> >> Paolo >> >> On Tue, Apr 16, 2013 at 1:23 PM, Robert Newson wrote: >>> Hi Paolo, >>> >>> The checkpoint is stored in the database at source and target, so >>> couchdb will fail to find that document on server B and so it will >>> start from update sequence 0. >>> >>> B. >>> >>> On 16 April 2013 10:06, Paolo Negri wrote: >>>> Hi Robert >>>> >>>> On Tue, Apr 16, 2013 at 10:05 AM, Robert Newson wrote: >>>>> Hi Paolo, >>>>> >>>>> No, couchdb (and touchdb) will be just fine if you fail over to a >>>>> different server. What will happen is that the replication from server >>>>> B to your mobile client will start from update sequence 0 (as you will >>>>> have no previous checkpoint). >>>> >>>> I'm wondering what happens if the fallback is not explicit to the >>>> client let's say I have the database exposed under >>>> https://mydomain.com/mydatabase and under this url usually respond >>>> server A but after the failover requests are instead forwarded >>>> internally to server B won't the mobile client be looking for the >>>> checkpoint of server A and be confused about the fact of being talking >>>> with server B instead? >>>> >>>>> The replication process will then check >>>>> whether each update on server B is on your client already. If the A to >>>>> B replication is still running, then the majority of updates you get >>>>> from server B will already be present on your mobile device. Any that >>>>> are missing will be replicated. >>>>> >>>>> You can freely replicate from multiple servers to your mobile client, it works. >>>>> >>>>> B. >>>>> >>>>> On 16 April 2013 08:43, Paolo Negri wrote: >>>>>> Dear list >>>>>> >>>>>> I have a question related to couchdb replication, let me walk you >>>>>> through the scenario >>>>>> >>>>>> I have 2 servers server A and server B >>>>>> >>>>>> on both A and B I'm running couchdb >>>>>> B is configured to replicate all dbs from A >>>>>> >>>>>> I also have one mobile client that uses touchdb to sync data with one >>>>>> database on server A >>>>>> >>>>>> At some point server A breaks and then the mobile client can't reach A >>>>>> and then will fallback to B >>>>>> >>>>>> What happens in terms of syncing? will the mobile client be confused >>>>>> by the fact that the database on server B doesn't share sequence >>>>>> numbers with the same database in A? >>>>>> >>>>>> Thanks for your help, >>>>>> >>>>>> Paolo