There's a stack of system related questions here. We don't know what the hardware looks like for your master or slave. Maybe you're lacking RAM on the slave, or any number of other differences.
The master is probably receiving bursts of updates in parallel from many client connections, and for whatever reason, the slave can't keep up since all replication is done in serial.
If you have a lot of InnoDB activity on the master, you can probably disable InnoDB on the slave and gain some speed that way. That option and a few others are given here:
16.4.4.7: How can I use replication to improve performance of my system?
http://dev.mysql.com/doc/refman/5.0/en/replication-faq.html#qandaitem-16-4-4-1-7
Or there could be configuration tweaks in my.cnf
that could help you. I'd start by looking at your memory usage on the slave, and looking up buffer and memory related options for innodb and/or myisam depending on which of those engines you're using (or others).
You can also look through your binlogs with the mysqlbinlog
tool to see what database and tables have the most activity. Then start working with your application developers and start chipping away at the problem.
Also check your mysqld error log on the slave. There might be clues in there.
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.
Best Answer
I have a more direct way to upgrade from MySQL 5.1 to 5.6
The idea is to do the following:
CAPTURE DATA
CAPTURE GRANTS
Here is my personal emulation of pt-show-grants to capture SQL Grants
Here are my posts where I discussed these things before
Mar 26, 2015
: mysql upgrading from 5.1 --> 5.6 do I have to do mysqldump before upgrade?Oct 17, 2014
: Any known issues upgrading from MySQL 5.1.73 to 5.6.21?GIVE IT A TRY !!!