On Mon, May 31, 2010 at 7:25 AM, Lorenzo Bolzani <l.bolzani at gmail.com> 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.