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.
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
No comments:
Post a Comment