[prev in list] [next in list] [prev in thread] [next in thread] 

List:       slony1-general
Subject:    Re: [Slony1-general] Slony upgrades/mismatched versions/etc
From:       "Andrew Hammond" <andrew.george.hammond () gmail ! com>
Date:       2007-04-18 20:51:12
Message-ID: 5a0a9d6f0704181351m35f81dbatee1577702dc3e899 () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On 4/18/07, Bill Moran <wmoran@collaborativefusion.com> wrote:
>
>
> Based on the docs here:
> http://slony.info/documentation/slonyupgrade.html
> it would seem that I have to run the exact same version of Slony on all
> nodes at all times.  If I want to change that version, I have to update
> all nodes simultaneously.
>
> With regards to updating and versions, is this for _any_ version change?
> I'm guessing that I can't have a cluster with some 1.1 Slony and some 1.2
> Slony.
>
> But, in this particular case, I'm looking at moving some systems from
> 1.2.6
> to 1.2.9.  Do I have to move them all at once, or is the API locked down
> in the 1.2 version so that slight disparities are OK?


This might be a good design goal for slony 2.0: inter-database compatibility
between different revisions of the same major.minor version. It'd be a nice
analogue to the idea of not requiring an initdb across major.minor versions
of PostgreSQL. While it wouldn't let you avoid taking an outage (well,
exclusive locks across all tables in all sets) to upgrade functions, it
would let you stagger the upgrades across the cluster. I doubt it's worth
the extra maintenance effort though.

Andrew

[Attachment #5 (text/html)]

On 4/18/07, <b class="gmail_sendername">Bill Moran</b> &lt;<a \
href="mailto:wmoran@collaborativefusion.com">wmoran@collaborativefusion.com</a>&gt; \
wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;"> <br>Based on the docs here:<br><a \
href="http://slony.info/documentation/slonyupgrade.html">http://slony.info/documentation/slonyupgrade.html</a><br>it \
would seem that I have to run the exact same version of Slony on all<br> nodes at all \
times.&nbsp;&nbsp;If I want to change that version, I have to update<br>all nodes \
simultaneously.<br><br>With regards to updating and versions, is this for _any_ \
version change?<br>I&#39;m guessing that I can&#39;t have a cluster with some  1.1 \
Slony and some 1.2<br>Slony.<br><br>But, in this particular case, I&#39;m looking at \
moving some systems from 1.2.6<br>to 1.2.9.&nbsp;&nbsp;Do I have to move them all at \
once, or is the API locked down<br>in the 1.2 version so that slight disparities are \
OK? </blockquote><div><br>This might be a good design goal for slony 2.0: \
inter-database compatibility between different revisions of the same major.minor \
version. It&#39;d be a nice analogue to the idea of not requiring an initdb across  \
major.minor versions of PostgreSQL. While it wouldn&#39;t let you avoid taking an \
outage (well, exclusive locks across all tables in all sets) to upgrade functions, it \
would let you stagger the upgrades across the cluster. I doubt it&#39;s worth the \
extra maintenance effort though. <br><br>Andrew<br></div></div>



_______________________________________________
Slony1-general mailing list
Slony1-general@lists.slony.info
http://lists.slony.info/mailman/listinfo/slony1-general


[prev in list] [next in list] [prev in thread] [next in thread]