Jan Wieck JanWieck
Mon Mar 7 17:18:43 PST 2005
On 3/7/2005 12:01 PM, Chris Newland wrote:

> Hi all,
> 
> I understand the Slony failover mechanism and realise that taking
> pg_dump backups from a Slony cluster is the "wrong" way to protect
> against failures.
> 
> I'd like to ask what the Slony experts think is the best way to protect
> against a catastrophic loss of origin and all subscriber nodes if they
> are located in a single data centre and some physical disaster destroys
> the entire cluster.

The file based log shipping, currently being worked on by Chris Browne, 
would be the answer to that.


Jan

> 
> It is currently not possible for me to have a subscriber node at an
> external location because of performance reasons so I would like to have
> a way to dump only the application data (no Slony tables). This would
> allow me to build a fresh PostgreSQL server and reload the saved
> application data (which will hopefully never happen).
> 
> I imagine the upcoming log shipping feature would be an alternative and
> I would keep a remote subscriber node updated using batch updates that
> are out-of-band of the Slony transactions involving the origin node and
> local subscriber cluster.
> 
> Can you give me any indication on how close log-shipping is to a
> production-ready state?
> 
> If it's a long way then is there any quick way to dump the application
> data from the master without all of the Slony information?
> 
> Thanks for all your hard work on Slony.
> 
> Regards,
> 
> Chris Newland
> 
> 
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #


More information about the Slony1-general mailing list