Skip site navigation (1) Skip section navigation (2)

Re: Warm standby server

From: Chander Ganesan <Chander(at)otg-nc(dot)com>
To: Montaseri <montaseri(at)gmail(dot)com>
Cc: Scott Whitney <swhitney(at)journyx(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-admin(at)postgresql(dot)org
Subject: Re: Warm standby server
Date: 2008-06-29 13:53:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
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
Ask me about Expert PostgreSQL, PostGIS, and other Open Source training.

In response to

pgsql-admin by date

Next:From: Jan-Peter SeifertDate: 2008-06-30 07:05:18
Subject: Windows xp initdb POSTGRES_SUPERUSERNAME
Previous:From: Peter KoczanDate: 2008-06-28 19:27:57
Subject: Re: Major upgrade advice

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group