Hi all, (you go on holiday for a week....)
>> 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)) And, more importantly, there will be people who will want to test and ensure that their application works within 5.1 without any problems before blindly updating to the latest version. In theory there shouldn't be any issues, but in any even slightly mission critical environment I would be equally conservative). > 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. Yeah, there are no *huge* differences (compared to the change between 4.1 and 5.0, for example), but there are enough that you would want to check to be sure. > Coexistence is a feature we choose to provide that mandates the use of > separate SUNWmysql5 (5.0) and SUNWmysql51 (5.1) packages. > ... > 5.0 will be de-integrated(?) as soon as deemed possible. I would be wary of doing this too quickly. We have customers still using 4.1, and even 3.23. I'm not suggesting years, but I would suggest at least 6 months for both the software and user elements upgrades to have time to work. >> 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. You *cannot* run an entire 5.0 database using 5.1 without running the upgrade procedure (mysql_upgrade). MySQL will fail to start if it doesn't find the correct number of system tables. In general that makes the update process: 1. Shutdown mysql 5.0 2. Run mysql_upgrade 3. Startup mysql 5.1 > 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 There shouldn't be any significant changes. There are very few changes to the MySQL network protocol between 5.0 and 5.1, and those changes that do exist are handled by the protocol and/or API anyway, since the MySQL version is exchanged during the initial handshake. Connector/J, Connector/NET, Connector/ODBC and the PHP interfaces all automatically handle any more significant changes between the binary exchanges when returning data. This is required for point releases, as much as the major versions like 5.0/5.1. Most other interfaces (Perl, Ruby) do the same, to a greater or lesser extent. > >> 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. It should be super smooth - have faith :)) The relevant page is here: http://dev.mysql.com/doc/refman/5.1/en/upgrade.html Although I will shortly be working on this entire chapter in the manual, so if we decide we need additional elements, the time to tell me is now. >> 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). ] See earlier responses for info on some of these concerns. MC -- Martin 'MC' Brown, mc at mcslp.com and mc at mysql.com Technical Writer, Database Group, Sun Microsystems Everything MCslp: http://planet.mcslp.com
