hattip: High Scalability – High Scalability – Brian Aker’s Hilarious NoSQL Stand Up Routine.

In a CentOS/RHEL 5 environment installing the Percona MySQL rpm’s will include installing a package named MySQL-shared-percona. That package provides two key client libraries:

[root@server1 ~]# rpm -ql MySQL-shared-percona
/usr/lib64/libmysqlclient.so
/usr/lib64/libmysqlclient.so.16
/usr/lib64/libmysqlclient.so.16.0.0
/usr/lib64/libmysqlclient_r.so
/usr/lib64/libmysqlclient_r.so.16
/usr/lib64/libmysqlclient_r.so.16.0.0


The plain old mysql package from RHEL upstream on the other hand provides one version back:

[root@server2 ~]# rpm -ql mysql | grep libmysql
/usr/lib64/mysql/libmysqlclient.so.15
/usr/lib64/mysql/libmysqlclient.so.15.0.0
/usr/lib64/mysql/libmysqlclient_r.so.15
/usr/lib64/mysql/libmysqlclient_r.so.15.0.0


The packages in RHEL/CentOS 5 repos (including EPEL) are complied expecting “15″, but our Percona MySQL RPM is giving us “16″. Yum’s solution is to try and install both, but there’s a catch.

Take for instance this attempt to install the Maatkit rpm. It requires perl-DBD-mysql which being a native distro package is expecting version “15″ of those libraries.

[root@server1 ~]$ yum localinstall --nogpgcheck maatkit-5014-1.noarch.rpm
Loaded plugins: fastestmirror
Setting up Local Package Process
Examining maatkit-5014-1.noarch.rpm: maatkit-5014-1.noarch
Marking maatkit-5014-1.noarch.rpm to be installed
Loading mirror speeds from cached hostfile
* addons: centos.mirror.nac.net
* base: mirror.cs.vt.edu
* epel: serverbeach1.fedoraproject.org
* extras: mirror.trouble-free.net
* updates: centos.mirror.nac.net
Resolving Dependencies
--> Running transaction check
---> Package maatkit.noarch 0:5014-1 set to be updated
--> Processing Dependency: perl(DBD::mysql) >= 1.0 for package: maatkit
--> Processing Dependency: perl(Term::ReadKey) >= 2.10 for package: maatkit
--> Running transaction check
---> Package perl-DBD-MySQL.x86_64 0:3.0007-2.el5 set to be updated
--> Processing Dependency: libmysqlclient.so.15(libmysqlclient_15)(64bit) for package: perl-DBD-MySQL
--> Processing Dependency: libmysqlclient.so.15()(64bit) for package: perl-DBD-MySQL
---> Package perl-TermReadKey.x86_64 0:2.30-4.el5 set to be updated
--> Running transaction check
---> Package mysql.x86_64 0:5.0.77-3.el5 set to be updated
--> Processing Conflict: mysql conflicts MySQL
--> Finished Dependency Resolution
mysql-5.0.77-3.el5.x86_64 from base has depsolving problems
--> mysql conflicts with MySQL-server-percona
Error: mysql conflicts with MySQL-server-percona
You could try using --skip-broken to work around the problem
You could try running: package-cleanup --problems
package-cleanup --dupes
rpm -Va --nofiles --nodigest
The program package-cleanup is found in the yum-utils package.


MySQL-server-percona explicitly conflicts with mysql. Similar results can be found with anything that requires php-mysql.

So now what?

Well it turns out the upstream MySQL packages have accounted for this. They put out a “-compat” package for lots of versions of lots of distros, in this case including RHEL 5, that contains the other library versions that the “normal” mysql package would normally have provided. Downloadable from here.


[root@server1 ~]# rpm -qlp MySQL-shared-compat-5.1.39-0.rhel5.x86_64.rpm
/usr/lib64/libmysqlclient.so
/usr/lib64/libmysqlclient.so.12
/usr/lib64/libmysqlclient.so.12.0.0
/usr/lib64/libmysqlclient.so.14
/usr/lib64/libmysqlclient.so.14.0.0
/usr/lib64/libmysqlclient.so.15
/usr/lib64/libmysqlclient.so.15.0.0
/usr/lib64/libmysqlclient.so.16
/usr/lib64/libmysqlclient.so.16.0.0
/usr/lib64/libmysqlclient_r.so
/usr/lib64/libmysqlclient_r.so.12
/usr/lib64/libmysqlclient_r.so.12.0.0
/usr/lib64/libmysqlclient_r.so.14
/usr/lib64/libmysqlclient_r.so.14.0.0
/usr/lib64/libmysqlclient_r.so.15
/usr/lib64/libmysqlclient_r.so.15.0.0
/usr/lib64/libmysqlclient_r.so.16
/usr/lib64/libmysqlclient_r.so.16.0.0


Thing is, that won’t install clean on its own because it also tries to provide “16″, which conflicts with the Percona package:

[root@server1 ~]$ rpm -Uvh MySQL-shared-compat-5.1.39-0.rhel5.x86_64.rpm
Preparing... ########################################### [100%]
file /usr/lib64/libmysqlclient.so.16.0.0 from install of MySQL-shared-compat-5.1.39-0.rhel5.x86_64 conflicts with file from package MySQL-shared-percona-5.1.39-8.rhel5.x86_64
file /usr/lib64/libmysqlclient_r.so.16.0.0 from install of MySQL-shared-compat-5.1.39-0.rhel5.x86_64 conflicts with file from package MySQL-shared-percona-5.1.39-8.rhel5.x86_64


So here’s where we have to do the old one-step-back thing and –force it:

[root@server1 ~]$ rpm -Uvh MySQL-shared-compat-5.1.39-0.rhel5.x86_64.rpm --force
Preparing... ########################################### [100%]
1:MySQL-shared-compat ########################################### [100%]


Now for the case of the non “16″ libraries this is good because it gives us something that should be close enough. However for the specific libraries that our new server and client packages are built to use it’d be nice if they were dealing with the right copy, so now we force the Percona -shared package back on top of the MySQL one we just installed:

[root@server1 ~]$ rpm -Uvh MySQL-shared-percona-5.1.39-8.rhel5.x86_64.rpm --force
Preparing... ########################################### [100%]
1:MySQL-shared-percona ########################################### [100%]


Now we have all the versions of the mysql client libraries we need, and things install cleanly:

[root@server1 ~]$ yum localinstall maatkit-5014-1.noarch.rpm --nogpgcheck
Loaded plugins: fastestmirror
Setting up Local Package Process
Examining maatkit-5014-1.noarch.rpm: maatkit-5014-1.noarch
Marking maatkit-5014-1.noarch.rpm to be installed
Loading mirror speeds from cached hostfile
* addons: centos.mirror.nac.net
* base: mirror.cs.vt.edu
* epel: serverbeach1.fedoraproject.org
* extras: centos.mirror.nac.net
* updates: centos.mirror.nac.net
Resolving Dependencies
--> Running transaction check
---> Package maatkit.noarch 0:5014-1 set to be updated
--> Processing Dependency: perl(DBD::mysql) >= 1.0 for package: maatkit
--> Processing Dependency: perl(Term::ReadKey) >= 2.10 for package: maatkit
--> Running transaction check
---> Package perl-DBD-MySQL.x86_64 0:3.0007-2.el5 set to be updated
---> Package perl-TermReadKey.x86_64 0:2.30-4.el5 set to be updated
--> Finished Dependency Resolution

Complete!


Ta Da. You can yum install with abandon again.

Credit to David Murphy for the key step here from his comments on here.

Bullshit, thats backwards.

Thats what I thought. Then my DBA schooled me on two new feathers in my mysql wizards cap:
1.) if you’re very very careful, myisam supports concurrent inserts, which means you can write to a table like crazy without locking it
2.) innodb prior to 5.1.22 does not have a table lock on insert, but it does have a lock on generating the next entry for an auto_increment column, such that any insert into that table that needs a new auto incremented ID is stuck in line waiting for its turn. Which isn’t technically a table lock, but if most of your inserts are new records using that auto incremented column, its a similar result.

So if you combine the two corner cases of an app that almost only ever append-inserts and a particular version of mysql, the conventional wisdom on innodb vs. myisam completely inverts itself.

databases are hard

Looks like the Open Database Alliance is paying off:

XtraDB has been commited to MariaDB server and will be included in binary releases of MariaDB (scheduled on end of August – September) as replacement of InnoDB storage engine.

Combine this with OurDelta kinda going dormant, you’ve got all the major forks and add-ons combining into one unified build in MariaDB. This’ll give us something to run for the next year or two before we all switch to drizzle.