David Parker dparker
Fri Oct 29 16:34:42 PDT 2004
>Healing from a FAILOVER is a very complicated thing to do. 
>I've seen some interesting literature exploring this area in 
>the CS journals (typically in the context of distributed 
>filesystems), but nobody's seriously attempted to implement it 
>for a production system yet, as far as I know.

Yeah, in a "real" failover situation, where the master database is
actually damaged, I don't expect life to be simple, though the current
slony functionality for re-building is pretty good. I would like to see
a mechanism whereby a snapshot of application + slony data could be
taken of the master to create a new copy from, something that would be
more efficient than gradually draining the transaction log, but the
current functionality certainly works.

Our problem is that we have this in-between state where, due to our
availability requirements, we can't wait for manual intervention to
verify whether the master database really needs to be failed over. So we
have to just go ahead and FAILOVER. I'm looking at introducing a third
backup, and there are other things that we can do to mitigate this
problem. The bottom line is that redundancy/resiliency in general is not
a simple problem. Slony is a big part of our solution, and I'm very
happy to have it!

>| Assuming there is no existing slonik functionality for this, 
>is there 
>| some combination of sl_* table fiddling and slon re-sync 
>that I could 
>| implement to make slony accept the old master as a new subscriber 
>| without going through the subscribe initial truncation?
>
>Probably, but I'd strongly recommend that you don't do this 
>(foot-cannon would be an understatement). The approach that 
>I'd suggest is to investigate the Hendrik "cold-add" patch.

Is this in 1.0.5, or is there a separate branch in CVS I should look
for?

Thanks for your response.

- DAP

>
>- --
>Andrew Hammond    416-673-4138    ahammond at ca.afilias.info
>Database Administrator, Afilias Canada Corp.
>CB83 2838 4B67 D40F D086 3568 81FC E7E5 27AF 4A9A -----BEGIN 
>PGP SIGNATURE-----
>Version: GnuPG v1.2.5 (GNU/Linux)
>
>iD8DBQFBgl3Ugfzn5SevSpoRAnkjAJ9ZM/Y7za+xb5lkAm6GAhFS6mkwhQCfSP+y
>76NwSidHV0SS6wRkI4hc7rA=
>=5ww6
>-----END PGP SIGNATURE-----
>


More information about the Slony1-general mailing list