MySQL – Upgrading from 5.5 to 5.6

I upgraded an old server from 5.1.34sp1 to 5.1.67 some time back... that was about the same amount of "jump" in minor versions as you are contemplating. In this case, the system worked without incident.

Within the same major release of MySQL (e.g. 5.1.x to 5.1.y), assuming the versions involved are after the GA milestone, upgrading should be relatively straightforward.

For upgrades between versions of a MySQL release series that has reached General Availability status, you can move the MySQL format files and data files between different versions on systems with the same architecture.

^{— http://dev.mysql.com/doc/refman/5.1/en/upgrading.html}

Nevertheless, a complete backup is essential.

Importantly, if you haven't tried restoring your backup on a different server, then for all practical purposes, you don't actually have a backup.

Giving you the "ssh commands" (actually, shell commands) to do the upgrade isn't possible, since there are variations in installation that make it impossible to provide a list of "type these things and it will work" commands. Assuming your current installation is using an Oracle tarball binary distribution, you'll need to download and extract the binaries into a new directory, stop the server, move or relink the data files where the new copy of MySQL can see them, and rename a couple of directories or change a couple of symlinks. There's not really a concept of "uninstalling" the old version, since the old version can live harmlessly on your server in a different directory. You just move it out of the way, and if the upgraded version doesn't start up properly, will often still be able to start the old version back up, if needed. Eventually, you can remove the old directory, with caution, to avoid removing the wrong things.

You'll need to read the documentation.

http://dev.mysql.com/doc/refman/5.1/en/upgrading.html

http://dev.mysql.com/doc/refman/5.1/en/upgrading-from-previous-series.html

After you do the upgrade, don't forget to run the mysql_upgrade utility. This utility does not upgrade the version of your server; instead, it upgrades your data files to be fully compatible with the new version you've just installed. You run this after you do the upgrade, and after you restart the MySQL server daemon.

http://dev.mysql.com/doc/refman/5.1/en/mysql-upgrade.html

Depending on how well the server was maintained in the past, if it was upgraded in the past, then it's possible that this was not done when it was upgraded previously. If so, it would actually be a good idea to run it before doing the upgrade, so that all of your structures are all consistent. Two important points, here: The version of the mysql_upgrade utility that you run needs to be the version bundled with the currently running version of the server, and you need to make your backup before you run this. If you have some serious latent structural corruption that can't be automatically fixed, this can be theoretically be uncovered by mysql_upgrade and the server may shut down to prevent the detected corruption from causing even more serious problems. This is because mysql_upgrade uses CHECK TABLE as part of its work, and:

If CHECK TABLE finds a problem for an InnoDB table, the server may shut down to prevent error propagation. Details of the error will be written to the error log.

^{— http://dev.mysql.com/doc/refman/5.1/en/check-table.html}

This is not a likely scenario, but it's a documented possibility of which you need to be aware.

As a general rule, the slave server should be upgraded before the master, not after. This is somewhat less critical when remaining within 5.1 (if you were upgrading to 5.5, you absolutely need to upgrade the slaves first) but upgrading the master last is most definitely the most correct approach.

Upgrading the slave first will also give you a better idea of what to expect, and if the slave's data is consistent with the master, you can always promote it to master if your upgrade of the actual master fails.

Some things, such as microsecond in TIMESTAMP, will automatically be available because the CREATE TABLE on 5.7 will use the new format. innodb_file_per_table has a new default, so the tables will be laid out differently. That should not be a problem.

mysql_upgrade is for converting the mysql tables and for ALTERing to accommodate microseconds, etc, in an existing mysql instance where you are updating the software, not where you are loading the data.

Coming forward from 4.0 can cause troubles with changed syntax, the addition of CHARACTER SET, etc. But 5.1 is not that much different for what you are doing than 5.7.

There have been lots of changes/additions to mysql, information_schema, and performance_schema. So, be sure not to dump and reload them.

Use pt-show-grants if you need to carry GRANTs forward. Then check the results.

Do you have specific examples of things that concern you?