On Wed, Nov 11, 2009 at 01:11:52PM -0500, Greg Smith wrote: - David Kerr wrote: - >Postgres installed on a Cluster configured in active/passive (both - >pointing to the same SAN - >(If PG or the OS fails we trigger a failover to the passive node) - >Log shipping between that cluster and a single PG Instance off site. - >Is this a common/reccomended method of handling clusterin with Postgres? - >google searches - >basically point to using a replication based solution, which i don't think - >would meet my performance demands. - > - The part I'm having trouble with here is how it is you expect to keep a - remote node up to date with log-shipping, but then reject log-shipping - based replication as not high enough performance for you? The classic - problem with log-shipping in PostgreSQL is that you've got a single - recovery process trying to replay the work of what many workers did on - the master, and that can turn into a potential lag problem as volume - spikes upwards. If you don't expect a standby is going to be able to - keep up with your volume due to that issue, the remote one is going to - be even worse though. We'd fail over to the standby db (recipient of the log shipping) in the case that our hosting center was nuked. those are considered "extreme" circumstances and we have a higher RTO/RPO in those cases. The apps actually aren't as robust as the DB in this case, so i'll have time to replay all of the logs that made it before "the big one" while those are being configured to come up. and if it does take longer that's not a huge issue i'll have a few hours to get 100% caught up. Dave -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
