Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 87A2AB5DC42 for ; Thu, 30 Jun 2011 12:06:21 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 60761-01-10 for ; Thu, 30 Jun 2011 15:06:15 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mail.postgresql.org (Postfix) with ESMTP id 2566BB5DCC0 for ; Thu, 30 Jun 2011 12:05:40 -0300 (ADT) Received: from [192.168.1.7] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0Lhkwb-1ROr3K0NxB-00nM0C; Thu, 30 Jun 2011 17:05:39 +0200 Message-ID: <4E0C90C2.3000207@2ndQuadrant.com> Date: Thu, 30 Jun 2011 11:05:38 -0400 From: Greg Smith User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: pgsql-admin@postgresql.org Subject: Re: Problem with Streaming Replication References: <1309436503938-4538638.post@n5.nabble.com> In-Reply-To: <1309436503938-4538638.post@n5.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:mBHKFGCugVvuWfmWNUlk3S9NtbJOoeyNqjETKJ/OJrg GvEuK980tJlF4+2LHu9KgYzRU/sZv34y7tcTsulpHG3ZgcKIIh LdNSUT7i1jZWv5DuYqk/flfM+woa3z8IWrbtSa/7hSawrIF9x3 dA5WjhF2Nl326OT7o2R/x8p3RfRp2ij3ar1z3uxQyAb0MiyEMQ FLQdm6uYXaqM2ejJ9SMcmj+ihFRNfluOuL7r9sa098= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=2.419 tagged_above=-10 required=5 tests=BAYES_00=-1.9, FS_REPLICA=3.599, RCVD_IN_DNSWL_NONE=-0.0001, SARE_SPEC_REPLICA=0.72 X-Spam-Level: ** X-Archive-Number: 201106/153 X-Sequence-Number: 37779 On 06/30/2011 08:21 AM, abraao895 wrote: > - The HD of the PC1(master) dead. The WAL file don't have replicated because > it is a asynchronous proccess and suppose that this already didn't have > happened. > > - The PC2(slave) doesn't have the last record. > That's exactly how some transaction loss can happen in this situation. Some software worried about this problem maintains a small transaction log outside of the database, so that it's possible to reconstruct really critical information after such a disaster. In PostgreSQL 9.1, due to be released later this year, synchronous replication is available on a per-transaction basis. That resolves the concern you have--important transactions can be confirmed on one of the slaves as a requirement before they commit. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD Comprehensive and Customized PostgreSQL Training Classes: http://www.2ndquadrant.us/postgresql-training/