Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id E5D1C650E8C for ; Sun, 29 Jun 2008 10:54:36 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 98983-01 for ; Sun, 29 Jun 2008 10:54:20 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp192.iad.emailsrvr.com (smtp192.iad.emailsrvr.com [207.97.245.192]) by postgresql.org (Postfix) with ESMTP id 5885B650E7D for ; Sun, 29 Jun 2008 10:54:07 -0300 (ADT) Received: from relay9.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 010C71B4007; Sun, 29 Jun 2008 09:54:06 -0400 (EDT) Received: by relay9.relay.iad.mlsrvr.com (Authenticated sender: chander-AT-otg-nc.com) with ESMTP id D248E1B402E; Sun, 29 Jun 2008 09:54:05 -0400 (EDT) Message-ID: <486793F4.2020301@otg-nc.com> Date: Sun, 29 Jun 2008 09:53:56 -0400 From: Chander Ganesan User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Montaseri CC: Scott Whitney , Simon Riggs , pgsql-admin@postgresql.org Subject: Re: Warm standby server References: <8078a1730806261051x6befaa27uf3c95affe9c37cc2@mail.gmail.com> <20080626175743.4E1B33E216E@mail.int.journyx.com> <8078a1730806261120v44d222ecx46dd345ca2b184e@mail.gmail.com> In-Reply-To: <8078a1730806261120v44d222ecx46dd345ca2b184e@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/239 X-Sequence-Number: 29577 Scott & Montaseri, Montaseri wrote: > While I am not an expert on WAL, but again I question the merits of > such sophisticated HA configuration. Of course there are use cases for > such configs, but I am only advocating best price performance kind of > mentality > > As WAL writes the journals all the way down to the disk (ie write thru > and not write behind) before ack-ing toward the next step in a DB > operation, increasing the number of mirrors (one production, one > on-site, one off-site, I count 3 plexes here) will prolong each > operation, with the following exponentially increasing write latencies "traditional" warm-standby involves replicating the *archived* (read: not currently-in-use) WAL to the standby servers, something that doesn't require a synchronous write operation, and something that could be spread out over a period of time. However, you might have an issue if the system copies across WAL's slower than new ones are generated. Scott, you should be aware that the mechanism you are proposing has the potential to "lose" the transactions that had committed, but had not yet been archived. That would most likely be the changes in the "currently being written" WAL file - which hadn't been filled up, and thus had not yet been archived. For your colo standby server, you might consider using some synchronous mechanism for WAL storage. Such a mechanism would have an impact on server performance but would allow you to achive durability of committed transactions. I'll actually be talking a bit about this at the PGDay of Linux World (August 5th)... -- Chander Ganesan Open Technology Group, Inc. One Copley Parkway, Suite 210 Morrisville, NC 27560 919-463-0999/877-258-8987 http://www.otg-nc.com Ask me about Expert PostgreSQL, PostGIS, and other Open Source training.