Jyri Virkki wrote, On 08/ 8/08 05:15 AM:
> On Aug 7, 2008, at 7:42 AM, Lars Heill wrote:
>
>> ARC draft has been out for review since July 24:
>> http://mail.opensolaris.org/pipermail/webstack-discuss/2008-July/002209.html
>> It addresses coexistence between 5.0 and 5.1: Simply put: you should
>> be
>> able to add/run 5.1 while existing 5.0 server instances are not
>> affected.
>
> The drafts talks about the how but not much about the more fundamental
> (and likely most controversial) part of "why". It needs a section
> explaining the rationale.
We will add something to Section 6 (where currently touched upon).
Two server instances, e.g 5.0 and 5.1, should be able to coexist
because, e.g:
* an OS 2008.11 user should not need to upgrade to 5.1 just
yet just because that is what comes with the OS
* with MySQL central to a large number of other products, it
would be very difficult to herd all them into the same
upgrade gate at once (consolidation pain (TM))
There are three years between versions 5.0 and 5.1, an unusually long
time for dot releases, enough to make them be/appear "different enough"
to warrant such caution.
Coexistence is a feature we choose to provide that mandates the use of
separate SUNWmysql5 (5.0) and SUNWmysql51 (5.1) packages.
[ Mandates, not necessarily dictates: you could technically have multiple
installed instances of the same SVR4 package with MAXINST > 1, e.g
SUNWmysql5u, SUNWmysql5u.2, SUNWmysql5u.3 for 5.0.45, 5.1.27, 5.0.67,
but that is messy, as illustrated by this quite realistic example
- hopefully, IPS is cleaner :) ]
5.0 will be de-integrated(?) as soon as deemed possible.
> Is 5.1 incompatible with 5.0 to the extent that it is not possible to
> upgrade SUNWmysql5 from 5.0 to 5.1 without causing things to break?
That is perfectly possible, following regular MySQL upgrade procedures.
Since there happen to be three years of development and bug fixes between
5.0 and 5.1, it is not unreasonable to assume 5.0 users will move with
some caution, much more so than would be the case for micro version revs
(5.0.x to 5.0.y) with only weeks or a few months between them.
There is also the separation of upgrade of [internal] data formats
(tables on disk, e.g) and changes to user interfaces (SQL, JDBC
etc I do not have the dirty details, but I believe
> What would it take to provide a smooth upgrade experience to the user?
Upgrade is well documented, though a pointer to that documentation
in the ARC would be helpful.
The user may have a 5.0 database that he wants to upgrade to 5.1 by
following MySQL's upgrade procedures, however smooth they may or may
not be :) Whether he choses to have both 5.0 and 5.1 installed at
the same time, is a separate issue.
> The only hints I find in the draft are
> "MySQL is a mature product and the interfaces are stable
> and has been available for a long time in the open source
> community as well as an established product. "
> which suggest that it should be possible to upgrade painlessly.
> But it also says
> "MySQL also provides tools for upgrading the database tables
> between subversions (from 4.1->5.0 and 5.0 ->5.1 etc).The upgrade
> procedure from 5.0 to 5.1 is well documented ."
> which perhaps hints to some incompatibilities (if a "procedure" is
> needed).
>
> One way or the other, it's a topic which needs coverage in the draft.
Yes. Though upgrade is a MySQL product thing that we can do nothing
to change at this stage beyond pointing to relevant documentation in
Section 2.2 in the ARC.
Note also that there is a difference between the DBA task of upgrading
(migrating) e.g database tables (data format revs, etc: internal interfaces,
using product provided tools and procedures) and the user (end user,
other dependant product: external interfaces) upgrade. The latter
involves only external and established standards like SQL and JDBC
and is likely to be very transparent.
[ This is independent of how it is packaged (as long as we don't move
dirs and files around under the top level dirs or other silly stuff). ]
-- Lars
