1. Xtrabackup And MySQL 5.6 On an Amazon Instance

Xtrabackup And MySQL 5.6 On an Amazon Instance

Have you ever tried to install Xtrabackup on an Amazon EC2 instance with Oracle’s MySQL 5.6? Dependencies hell breaks loose when you ask for something as simple as running the GA version of MySQL and backing it up with the most popular open-source tool, XtraBackup. From this post you will learn how to resolve conflicts and make everybody happy.

Mysql55-libs Conflicts With Mysql-community-libs-5.6.22

A fresh Amazon Linux AMI, 2014.09 EC2 instance comes with a MySQL 5.5.40 in the amzn-updates repository. Today, MySQL 5.5 turns five years old. It’s a good and stable version. However, a lot of people want to run MySQL 5.6, because it’s better than 5.5 – it supports full-text indexes, while Oracle ends the support of 5.5 this year.

Oracle distributes MySQL releases via the YUM repository. Installing MySQL from the YUM repository is a good idea because YUM takes care of dependencies (what an irony, the post was supposed to be about dependencies conflicts) and getting new releases as simple as yum update.

So, there is an EC2 instance with Amazon Linux and MySQL 5.6

We need to backup the database. Xtrabackup is the most popular open-source tool. Luckily, Percona also distributes their packages via YUM repository. Let’s install Xtrbackup with YUM:

Bummer! The conflict happens because yum wants to install the file /usr/lib64/mysql/libmysqlclient.so.18 from the package mysql55-libs-5.5.40-1.3.amzn1.x86_64, but the file is already installed from the package mysql-community-libs-5.6.22-2.el6.x86_64.

What’s wrong here? Why can’t yum use libmysqlclient.so.18 from mysql-community-libs-5.6.22 ? Let’s have a closer look.
Xtrabackup depends on perl-DBD-MySQL, which depends on two virtual packages:

Let’s see what mysql-community-libs-5.6.22 provides:

Now it’s clear why yum can’t use mysql-community-libs-5.6.22 for perl-DBD-MySQL – it doesn’t provide libmysqlclient.so.18(libmysqlclient_16)(64bit).

mysql55-libs.x86_64 however does provide both libmysqlclient.so.18(libmysqlclient_16)(64bit) and libmysqlclient.so.18()(64bit):

Thus, YUM picks up mysql55-libs.x86_64, but fails to install it because file /usr/lib64/mysql/libmysqlclient.so.18 is already installed by another package.

Resolving the Dependency Conflict

Understanding the problem is one half of the solution. But how do you resolve the conflict completely?

No Oracle package provides libmysqlclient.so.18(libmysqlclient_16)(64bit). In fact, the mix of symbol versions libmysqlclient_16 and libmysqlclient_18 existed for a short time in MySQL 5.5. Several OS vendors including Amazon distributed libraries with the mix of symbol versions.

The dependencies of a package are auto-generated unless you disable it with “AutoReqProv: no“. So an rpm package requires a library that was used to build it.

I took step back and used the MySQL 5.1 library to rebuild perl-DBD-MySQL. When the new perl-DBD-MySQL is installed, YUM picks up either mysql51-libs.x86_64 or mysql-community-libs-compat.x86_64.

To build perl-DBD-MySQL with the MySQL 5.1 library, install mysql51-libs.x86_64 on a clean instance. You’d also need mysql51-devel.x86_64, gcc, rpm-build and maybe some other packages.

Get a source rpm of perl-DBD-MySQL and rebuild it:

It builds package perl-DBD-MySQL-4.029-1.amzn1.x86_64.rpm with MySQL 5.1 libraries:

Several packages provide MySQL 5.1 libraries:

None of them conflicts with any installed version of MySQL server: 5.1, 5.5 or 5.6.

Have a question? Ask the experts!

Previous Post Next Post