Re: High Availability: Hot Standby vs. Warm Standby

Greg Smith, 12.07.2010 18:11:
> Yes, but if you try you'll discover that actually getting any shared
> disk or file system replication solution setup so that you really do
> achieve less failover loss than the file shipping approach will be
> expensive, complicated, fragile in its own way, and just generally a
> pain to pull off. The fundamental problem with shared storage for
> example is how to keep a note that's failed from try to reassume being
> the master when it comes back. Doing that well requires hardware support
> aimed at that specific use case.
> Meanwhile, file shipping for Warm Standby use requires nothing special
> at all except some modest software setup. It's comparatively simple to
> setup, validate, and keep going on any hardware capable of running the
> database. This is why shared storage and the like isn't the only obvious
> solution even though it's technically capable of losing less
> transactions; you'll discover that keeping from losing that last little
> bit of data when there's a crash turns out to be quite expensive.
> Whether it worth it or not depends on the value of your data and whether
> it can be retained at some higher level when this happens instead.
>
Thanks Greg,

I really appreciate your answer. I'm nowhere a DB- or system-admin, but I'm promoting Postgres from a user's point of view and this makes people ask me whenever there is a question around Postgres (in this case replacing the existing Oracle Dataguard solution with PG)

Basically the requirement is that we cannot afford to lose any committed data. But if that comes at a too high cost, it might be possible to negotiate that. I will also need to check how busy the server actually is, maybe setting archive_timeout to a very low value (1 or two seconds) would be enough.

The time it takes to switch over to the standby server is not relevant (it doesn't matter if it's seconds or minutes, but it should not be hours ;) )

Using Warm-Standby would mean, if the server fails after a transaction commits, but before the WAL can be shipped to the standby, that transaction will be lost, right? At least on the standby server.

It would still be available on the primary server, but that wouldn't help much, because we would need to backup and restore the data from standby to the primary after the problems have been fixed, which would essentially overwrite that transaction in the WAL.

Currently our "favorite" is file system replication between two nodes.
The target system will be Solaris using a ZFS filesystem.
Are there any Solaris/ZFS specific features that would help here?

Thanks again for the input!

Regards
Thomas