On Friday 04 March 2005 14:15, Jan Wieck wrote:
> On 3/4/2005 5:14 PM, Darcy Buskermolen wrote:
> > On Friday 04 March 2005 13:55, Jan Wieck wrote:
> >> On 3/4/2005 3:35 PM, Alan Hodgson wrote:
> >> > Is there a way to backup and restore a cluster member without having
> >> > to redo the replication setup?  I have 5 nodes to upgrade to 8.0.1.
> >> > The slave nodes only replicate a subset of the tables on the master.
> >> > Re-replicating out the slave nodes and setting up the paths and
> >> > listeners, especially one at a time, is a major pain.
> >> >
> >> > I know enough to kill the slons, make the db unavailable to other
> >> > processes, and back it up and restore it without anything else
> >> > touching it.  I know to update the table OID's in sl_table.  However,
> >> > I seem to be missing where it sticks the old trigger info.  Is this
> >> > even possible?
> >>
> >> <BLINK> WARNING WARNING WARNING </BLINK>
> >>
> >> I have not tested any of the below! It is an idea that you have to prove
> >> right or wrong!
> >>
> >> END WARNING
> >>
> >> After "disconnecting" a subscriber, you want to call the
> >> alter_table_restore procedure for all replicated tables. That will
> >> remove the slony trigger and restore the original application triggers
> >> and rewrite rules.
> >>
> >> Then you do the upgrade via dump+restore
> >>
> >> Next you call the alter_table_for_replication procedure for all those
> >> tables to get back into subscriber status.
> >>
> >> Last you invoke a slonik script that reloads the db version specific
> >> parts of the slony stored procedures.
> >>
> >> The subscriber should now be ready to start its slon and catch up.
> >>
> >>
> >> Good luck and let us know if it works that way.
> >
> > I'm not sure if this will deal with sl_table.tab_reloid ,
> > sl_sequence.seq_reloid
>
> right ... it won't. There is some tool to do that in 1.0.5, no?
no, nothing native in 1.0.5 I did post an email  to -general some 3 months 
back or so about a method to do this.
Basicly you create a table that has oid -> realname mappings you dump that 
with your data, then you update the reloids in the sl_* tables based on the 
reverse select (where you get the new reloids for the old relnames).


>
>
> Jan
>
> > Hence the repair config option in 1.1
> >
> >> Jan