So is this error messege a known issue or is it normal? am I doing something wrong?

I also gets warnings like :
Warning : Triggers for table `schema1`.`trigger_!` have no creation context, which requires me to recreate triggers, is this normal for upgrade too?

Thanks a lot

This also depends on various issues one of which is the amount of downtime you can take and also how you are using MySQL.

MySQL often recommends (if possible) doing an upgrade by doing a MySQL dump of the databases and then loading them clean into a the new version. This is the best idea as it ensures that you have a clean dump and a clean load but is mainly impractical for many people, especially if the database is sufficiently large, as this takes too long.

In that case often the alternative is to take a copy of a running slave (if you are working in a replicated environment) and then upgrade to the newer binaries and run mysql_check followed by mysql_upgrade. That works pretty well as long as you don’t have stored procedures or triggers which the 5.1 upgrade may not cope with properly.

I had some nasty issues on some instances with this problem, but luckily I was able to remove the triggers and all of a sudden the upgrades became a lot less painless.

Then there’s the issue which is still “in theory” an issue with 5.0 to 5.1 upgrades that when you run mysql_upgrade it tries to check and upgrade all tables which need to be changed but fails miserably with Innodb tables. Recommendation by the mysql_upgrade binary is to dump the tables and then load them back. Of course to run mysql_upgrade you are running the new 5.1 binaries and to do the dump you need to downgrade again to 5.0…. If the table is large you are back to the problem that the dump/load takes ages. Then again none of this is really necessary: ALTER TABLE ENGINE=INNODB rebuilds the table under 5.1 and MySQL is happy… (why this is not done as part of the mysql_upgrade I don’t know though I suspect that this will be fixed in the future).

Apart from these issues the upgrade can be trivially easy. For most people it is, but it would be nice to have a complete, simple, step list of the tasks that are required, all in the right order so that nothing gets forgotten.

Working in a replicated environment also does not help as it is often impractical to upgrade all boxes at the same time, especially if you want to avoid down time. So you follow the “procedure” of upgrading slaves one by one until you only have the master to do. Be aware that if you upgrade the master by running something like mysql_upgrade it will potentially write to the bin logs commands used to update the server itself. This of course gets picked up by the slaves and breaks replication as it fails on the slaves which have already been upgraded. To avoid this it’s often best to build a new master (originally just a slave which has been upgraded), and then put all existing slaves underneath it. Then all that’s required to complete the upgrade is to make the applications talk to the new master.

So I for one would vote for better documentation, that covers the case of the single small mysql server, but also at least mentions the issues that need to be taken into account when the server size gets too large for dump/load to be used, or what extra steps or things need to be taken into account if the server is working in a replicated environment.

It would also be nice if mysql_upgrade finally works for all engine types (within reason), and also if somehow mysql_check (5.1) could be run on an old version and give some sort of idea of which tables may need to be rebuilt BEFORE you change the version you are running. This type of thing is typical in Oracle or Sybase so should not be so hard to implement in MySQL. Perhaps it is not needed by everyone but it does make our life easier and as such should gain more users.

read http://dev.mysql.com/doc/refman/5.1/en/checking-table-incompatibilities.html for some examples.

see http://dev.mysql.com/doc/refman/5.1/en/checking-table-incompatibilities.html

Anytime you upgrade, it is recommended to test your code against the new version of MySQL in a QA environment.

When upgrading between any two versions, there is always a possibility you will encounter incompatibilities.
I highly recommend testing the upgrade in a QA environment, it’s always good to see how your specific application will work with new versions of MySQL.

I’m given a very short time frame to perform the upgrade MySQL server from 5.0.27 to 5.0.45. I think I go with the option to setup the slave first and try to minimize downtime.
I’ve checked Change history on http://dev.mysql.com/doc/refman/5.0/en/news-5-0-x.html and it seems that this upgrade should be seamless.
Before I proceed with this, are there any major incompatibility issues between these two minor versions that I have to be aware of?

Any advice is more than welcome.