Replace MySQL with MiriaDB on CentOS 6

Last modified: [last-modified]

I’m running CentOS 6.3 64-bit and have been for a little while. I decided I wanted to swap out MySQL 5.1.x with MiriaDB 5.3.x.

Why? Because I can. Plus I’ve read a bit and it sounds like MiriaDB is better optimized than MySQL. Also Oracle is evil.

These instructions are based off my history file. I didn’t think to write this down as I did it. That means there may be a mistake in the following process but with some Googling you should be able to fix any problems you come across.

One thing to know before proceeding  If you’re using PHP 5.3.3 that comes with CentOS 6 you will get a header miss-match error when PHP uses the ‘php-mysql’ package to access MySQL. I believe you can safely ignore this. I did for a few hours and nothing seemed broken. I’ll include steps on fixing this problem in another post as it requires completely replacing PHP in CentOS with PHP from another repository. If you’ve compiled your own PHP then you’ll just want to re-compile it with the MySQL Native Driver (mysqlnd).

  1. Stop your webserver and any other applications that may be trying to access your MySQL Database
  2. Take a full backup of your MySQL database just in case
    mysqldump --add-drop-database --add-drop-table --allow-keywords --all-databases --complete-insert --quick --user=root --password=<ROOT PASSWORD> > fullDataset.sql
    service stop mysqld
    cp -Ra <Path to MySQL DB> <Path to MySQL DB>.bak
  3. Next find out what MySQL RPMs you have installed and remove them. This will automatically create a backup of your existing ‘/etc/my.cnf’ file.
    rpm -qa |grep mysql
    # --- Command output start ---
    # --- Command output end ---
    rpm -e --nodeps mysql-5.1.67-1.el6_3.x86_64 mysql-server-5.1.67-1.el6_3.x86_64 mysql-devel-5.1.67-1.el6_3.x86_64 mysql-libs-5.1.67-1.el6_3.x86_64
  4. Alright now you’ve got no MySQL on your system. Lets drop MiriaDB in.
    vim /etc/yum.repos.d/MariaDB.repo
    #--- Add the content below to the file ---
      name = MariaDB
      baseurl =
    #--- Save and close the file ---
    yum install MariaDB-client.x86_64 MariaDB-devel.x86_64 MariaDB-server.x86_64 MariaDB-shared.x86_64
  5. You should now have MariaDB 5.3.x installed. Next we want to put the old configuration file back.
    cp /etc/my.cnf.rpmsave /etc/my.cnf
  6. Fire up MiriaDB, verify the version and upgrade the databases
    /etc/init.d/mysql start
    mysql --version
    # --- Command output start ---
    mysql  Ver 15.1 Distrib 5.3.10-MariaDB, for unknown-linux-gnu (x86_64) using readline 5.1
    # --- Command output end ---
    # Upgrade the database
    mysql_upgrade -u root -p
  7. Configure MiriaDB to start on boot
    chkconfig --add mysql
    chkconfig --levels 35 mysql on

That’s it! You should now be running the latest stable version of MariaDB 5.3.x which you will be able to keep up to date with the ‘yum’ command.

LifeSize Express 220 dropping calls at 45 seconds on the dot

I recently deployed a LifeSize Express 220 in a school with a Satellite internet connection and a Cisco PIX 515 firewall running 8.0(4).28 and kept running into the strangest problem when making calls.

No matter if I was calling out or someone was calling in we’d be able to talk with video or audio only for exactly 45 seconds (per the call timer built into the LifeSize unit) and then the call would drop.

Initially I thought it had something to do with xlate, sip or h323 timeouts and the ‘inspect h323’ configuration that is set by default in the PIX firewall. Turns out it was a bit more then that.

Turns out the issue is a known one in how Cisco ASA/PIX firewalls running an OS older than 8.2.x inter-fear with LifeSize network traffic.


The solution as described in the video is:

  1. Go to https://<IP of your LifeSize>/support
  2. Login with the default credentials “cli” and “lifesize”
  3. Click ‘Enable’ next to the VSAT option
  4. Your LifeSize will now reboot

This will resolve the issue for you as long as the remote end of your call doesn’t have the same Cisco PIX/ASA with older firmware. If they do they will need to enable VSAT on their end or upgrade their firewall firmware.

I’m still going to leave the ‘no inspect h323’ configured on my PIX just in case.

If your curious how to change that default /support/ password I’ve read you can do it via SSH. I’ll eventually post how to do that since I’m curious myself.

Additional references: