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 19CB010613 for ; Tue, 23 Apr 2013 09:06:04 +0000 (UTC) Received: (qmail 31747 invoked by uid 500); 23 Apr 2013 09:06:02 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 31162 invoked by uid 500); 23 Apr 2013 09:05:57 -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 31022 invoked by uid 99); 23 Apr 2013 09:05:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Apr 2013 09:05:50 +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: local policy) Received: from [66.111.4.27] (HELO out3-smtp.messagingengine.com) (66.111.4.27) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Apr 2013 09:05:45 +0000 Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9D02320C38 for ; Tue, 23 Apr 2013 05:05:24 -0400 (EDT) Received: from web4.nyi.mail.srv.osa ([10.202.2.214]) by compute2.internal (MEProxy); Tue, 23 Apr 2013 05:05:24 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=codekick.com; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date; s=mesmtp; bh=zfi6nrChDpIvJAx0+0F394Y YsVo=; b=L/ULzsECK31QSyZ20EB7p9URggrrv0MfL6IBoSq0GUO8rN+jDj+5v7X TVUH869IX6LQ5OmwlbAGCWs227stQ7eCv/rOM1ivs1Zs5JYjOOP0xtgptyhlOoUS AVfP6t5OkM0NVIH2VchOq0yVsUFGRwZbZ3mr05wgP06pguB+nL8g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date; s=smtpout; bh=zfi6nrChDpIvJAx0+0F394YYsVo=; b=YHBP8Od6Acuunz5KHGqM6wOSRqfr C/kH04vcrTFep2Eo4+L9IEOSwpVDNiuUJhqSgTA0hFixD7+R8b38Dy9WgO8PuYbA b3A0KaqwSDbwUBXsEA+uCahVPNGRahKl6KyffARZxbAKA+2COmh+cpQl2zW83GaL /tJJjdEawOf2W10= Received: by web4.nyi.mail.srv.osa (Postfix, from userid 99) id 767E5701077; Tue, 23 Apr 2013 05:05:24 -0400 (EDT) Message-Id: <1366707924.31855.140661221524722.1A7F1BA9@webmail.messagingengine.com> X-Sasl-Enc: mmsDrodcPkz13inzZKa9fKmHZ+QSJ1EE1jUK3R5fmHUr 1366707924 From: Calle Arnesten To: user@couchdb.apache.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-3ef74f37 Subject: Re: Problem with restart of continuous replication Date: Tue, 23 Apr 2013 11:05:24 +0200 X-Virus-Checked: Checked by ClamAV on apache.org Thanks for your answer. I was using persistent _replicator. It was set up like this from both ends: curl -X PUT -d "{ \"source\":\"\", \"target\":\"\", \"continuous\":true }"\ /_replicator/ -H "Content-Type:application/json" The strange thing was that after the 2 hour communication problem, the replication was automatically restarted on one of the ways but not the other way. /Calle On Tue, Apr 23, 2013, at 10:15, Robert Newson wrote: > I recommend using the persistent _replicator replication manager, it > will restart your replication jobs after a crash. POST's to _replicate > with continuous:true will continue until a) the connection is severed > or b) the node reboots, whichever comes first. > > http://wiki.apache.org/couchdb/Replication#Replicator_database > > B. > > On 23 April 2013 03:01, Calle Arnesten wrote: > > Hi, > > > > I have a two-way continuous replication set up between two servers with CouchDB. About a week ago we had a DNS problem that caused the machines to not to be able to communicate for almost 2 hours. My assumption was that CouchDB would automatically try to restart the replication. When I double-checked this a day or two later, replication was only restarted for one way and not both. After rebooting the machine the replication started working both ways again. > > > > Now my question is: Was my assumption wrong that replication should be restarted automatically? If not, what could be the cause of it not working? The machine that it happened to have CouchDB 1.2.1 installed. > > > > Also, do you have any recommendations on how to monitor that replication works and notify by mail when it doesn't? > > > > /Calle