On Mon, May 31, 2010 at 7:25 AM, Lorenzo Bolzani <[email protected]> wrote: > > Hi all, > I'm evaluating for my current project. > > I suspect this question has been answered several times but I checked the > docs and google and I didn't found a clear answer. > > Can slony be used if the slave schemas are slightly different from the > master one? > > We have a 1 master and 2 slave installations of a system automation > application. The application can be upgraded independently on the three > nodes. > > So this could be an actual scenario: > > master: version 1.34 > slave1: version 1.35 > slave2: version 1.32 > > Any version update could imply some schema changes, for example: > > - add/drop/modify a column > - add/drop a table > > The schema changes must NOT be replicated because any version of the running > application expects different schemas (of course small changes can be > replicated without problems). > > What I'd like slony to do is to handle missing columns (with defaults if not > null), extra columns (ignoring), and for big changes transform data through > a custom script. > > Can this be achieved?
Not really. Slony expects the schemas on each node to match up. I'm guessing you could have extra fields maybe, but not fewer, on a destination table. You would have to burn down / recreate your set each time, as applying changes to the schema like you're talking about will break replication in a set that's already up and running. _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
