Sometimes it is desired to use particular software versions in production, and not necessary the latest ones. There may be several reasons for that, where I think the most common is when a new version should spend some time in testing or a staging environment before getting to production. In theory each new version is supposed to be better as usually it contains a handful of bug fixes and even new or improved functionality. However there is also a risk of some regression or a new bug introduction as a side effect of code changes.

Quite often DBAs want the same MySQL version to be installed on all database instances, regardless of what actually is the latest version available in the software provider’s repository. There are several ways to achieve this:
* download specific version packages manually and then install them,
* have custom local repository mirror where you decide when and which version gets there, and just update from there using yum/apt,
* have database instance images with all software prepared,
* point to a particular version just using default package-management utility.

My idea was to remind about this last method as maybe the least known one.
In this article I will focus on YUM as it seems this is the only one currently offering multiple versions from official repositories of Oracle and Percona MySQL variants. APT theoretically is also able to install older versions, but command “apt-cache madison …” returns only the latest one for me. For example using Oracle repo:

So let’s see how it looks like for YUM repositories. I have installed repositories from Oracle, MariaDB and Percona on Centos 6 test machine. This is what they offer for the main server package versions:

So at least for both Oracle and Percona packages we can use yum to install several versions back (12 in case of Percona Server 5.6).

How can we do that? Let’s install Percona Server version 5.6.19. To get a full package name with it’s version, we join it’s name with version but the CPU family part needs to be removed or replaced to the end. So Percona-Server-server-56.x86_64 +  5.6.19-rel67.0.el6 -> Percona-Server-server-56-5.6.19-rel67.0.el6 or Percona-Server-server-56-5.6.19-rel67.0.el6.x86_64:

But what if it happens that we have to revert to previous version? We can actually do that with YUM very quickly:

What if we want to downgrade, but let’s say few versions down? It is also possible with a single YUM command. By the way, after the last step we are on Percona Server 5.6.17 rel66.0 version and YUM nicely shows that when listing all available packages, see the screen shot below:

yum_list_color

So let’s downgrade to Percona Server 5.6.15 rel63.0 – it’s actually very easy as the “downgrade” option also understands the version attribute:

We can do the same, or more complicated package operations, using the YUM transaction feature:

The fact that we can use single command or single YUM transaction, instead of a manual rpm download and installation, is not the only advantage of this method. The other very important one is that we don’t have to worry about breaking package dependencies when we uninstall current version manually in order to install different one, as there may be many packages that depend on MySQL.

However, if anyone does “yum update” on this system, our packages will be upgraded to the latest version, which is what we probably don’t want to happen yet, and surely not without our supervision:

To prevent that, we should lock our packages on current version. To achieve that, we need yum-plugin-versionlock package which allows us to do this:

Now these packages cannot be updated unless you clear the locks with

(clear any locks) or particular locks:

I think the fact that you can install particular MySQL and Percona Server versions using YUM lets you simplify software management tools recipes, like Chef, Puppet or Ansible. For example, the Chef’s yum_package resource has version attribute, and an example recipe for Percona Server 5.6.20 installation may look like this:

Hopefully we will see similar functionality from APT MySQL repositories eventually.

2 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Michael Rikmas

Thanks Przemek. Very useful!

0
Radu Popa

Very helpful. Thank you.

0