- Documentation Library
- Table of Contents
- MySQL 5.5 Manual
- MySQL 5.4 Manual
- MySQL 5.1 Manual
- MySQL 5.0 Manual
- MySQL 3.23/4.0/4.1 Manual
- Table of Contents
This section describes what you should do to downgrade to an older MySQL version in the unlikely case that the previous version worked better than the new one.
If you are downgrading within the same release series (for example, from 4.0.20 to 4.0.19) the general rule is that you merely need to install the new binaries on top of the old ones. There is no need to do anything with the databases. As always, however, it is always a good idea to make a backup.
The following items form a checklist of things you should do whenever you perform a downgrade:
Read the upgrading section for the release series from which you are downgrading to be sure that it does not have any features you really need. See Section 2.11.1, “Upgrading MySQL”.
If there is a downgrading section for that version, please read it, too!
To see which new features were added between the version to which you are downgrading and your current version, see the change logs (Appendix B, MySQL Change History).
Check Section 2.11.3, “Checking Whether Tables or Indexes Must Be Rebuilt”, to see whether changes to table formats or to character sets or collations were made between your current version of MySQL and the version to which you are downgrading. If so and these changes result in an incompatibility between MySQL versions, you will need to downgrade the affected tables using the instructions in Section 2.11.4, “Rebuilding or Repairing Tables or Indexes”.
You can always move the MySQL format files and data files between different versions on the same architecture as long as you stay within versions for the same release series of MySQL.
If you downgrade from one release series to another, there may be incompatibilities in table storage formats. In this case, use mysqldump to dump your tables before downgrading. After downgrading, reload the dump file using mysql or mysqlimport to re-create your tables. For examples, ee Section 2.11.5, “Copying MySQL Databases to Another Machine”.
A typical symptom of a downward-incompatible table format change when you downgrade is that you cannot open tables. In that case, use the following procedure:
Stop the older MySQL server that you are downgrading to.
Restart the newer MySQL server you are downgrading from.
Dump any tables that were inaccessible to the older server by using mysqldump to create a dump file.
Stop the newer MySQL server and restart the older one.
Reload the dump file into the older server. Your tables should be accessible.
It might also be the case that the structure of the system tables
in the mysql database has changed and that
downgrading introduces some loss of functionality or requires some
adjustments. Here are some examples:
Trigger creation requires the
TRIGGERprivilege as of MySQL 5.1. In MySQL 5.0, there is noTRIGGERprivilege andSUPERis required instead. If you downgrade from MySQL 5.1 to 5.0, you will need to give theSUPERprivilege to those accounts that had theTRIGGERprivilege in 5.1.Triggers were added in MySQL 5.0, so if you downgrade from 5.0 to 4.1, you cannot use triggers at all.
User Comments
How to uninstall / downgrade on Mac OS X?
http://www.macosxhints.com/article.php?story=2008111115225247
After a bit of digging, I found the cause and the solution. The MySQL installer checks for the existence of other MySQL versions by looking in the /Library/Receipts folder, not by looking for an actual installed version of MySQL. So I deleted the MySQL receipts folder I found in /Library/Receipts
-- source robg
Also I had errors because I had a ".my.cnf" in my user folders ie. /Users/username/.my.cnf - which specified files from a previous version - deleting that fixed the problem...
Add your own comment.