Moving from MySQL 5.7 to MariaDB 10.1
Tags: mysql, mariadb, database, innodb
Published: 2019-08-20 14:56:08

---
title: Moving from MySQL 5.7 to MariaDB 10.1
published: true
description: A guide on how to properly move from MySQL 5.7 to Maria DB 10.1
tags: mysql, maria-db, databases, InnoDB
---

###Warning

<pre>
Please perform these tests first on a testing environment or a virtual machine.
</pre>

I never really needed to pay attention to MariaDB until it becomes a possible and viable option. The technical decision in place was obvious, moving into a newer version of MySQL and continuing with it and the unknowns of Oracle being the owner OR moving to MariaDB the well-spoken community replacement for MySQL.

After about an hour of reading, I decided to do the so spoken magical move from MySQL to MariaDB and this is what I have learned.

The next steps were all performed on CentOS 7 with an installed version of MySQL 5.7.13 and used the following article as reference: https://mariadb.com/kb/en/mariadb/yum/

The 1st steps to be performed are the obvious ones:


* mysqldump of all your databases
* backup of /var/lib/mysql
* backup of /etc/my.cnf

The next step is quite obnoxious given that it requires more than a simple yum remove.

<pre>
    sudo yum remove mysql mysql-server mysql-common
</pre>

That should remove by default all references from MySQL but, because MariaDB won't pass the install check if there are still references, run the following command:

<pre>
    sudo yum list installed | grep -i mysql
</pre>

It will give you a list like this:

<pre>
    mysql-community-client.x86_64 5.7.13–1.el7 @mysql57-community
    mysql-community-common.x86_64 5.7.13–1.el7 @mysql57-community
    mysql-community-libs.x86_64 5.7.13–1.el7 @mysql57-community
    mysql-community-libs-compat.x86_64 5.7.13–1.el7 @mysql57-community
    mysql-community-server.x86_64 5.7.13–1.el7 @mysql57-community
    mysql57-community-release.noarch el7–7 @/mysql57-community-release-el7–7.noarch
</pre>

With the exception of libraries like the PHP-MySQL one, all the remaining must be removed. This can be done by simply running:

<pre>
    mysql-community-client.x86_64 5.7.13–1.el7
</pre>

If you have read any article that teaches how to perform the migration from MySQL to MariaDB, up to MySQL 5.6 and MariaDB 10.0, the only thing you needed to do to make the migration fully successful was creating the yum repo and installing MariaDB but this option doesn’t work so well.

The following steps are every single step I have performed to install MariaDB 10.1 properly for a MySQL 5.7 migration.

###Step 1 — Create the Yum repo

<pre>
    sudo vi /etc/yum.repos.d/MariaDB.repo

    [mariadb]
    name = MariaDB
    baseurl = http://yum.mariadb.org/10.1/centos7-amd64
    gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
    gpgcheck=1
</pre>

###Step 2 — Install the rpm key

<pre>
    sudo rpm — import https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
</pre>

###Step 3— Completely remove MySQL data

Yes, you read it right, remove /var/lib/mysql and it is the only way to properly do it. If you haven’t done a backup when you started this, then, stop and return to MySQL.

<pre>
    sudo rm -rf /var/lib/mysql
</pre>

Installing MariaDB 10.1 with that folder there you will get a noticeable error with InnoDB that, doesn’t matter how many times you search, you won't find a good solution for it. The following is a copy of the error in it’s full:

<pre>
    [vagrant@localmachine ~]$ sudo journalctl -xe
    — Unit mariadb.service has failed.
    —
    — The result is failed.
    Jun 27 17:46:46 vagrant systemd[1]: Unit mariadb.service entered failed state.
    Jun 27 17:46:46 vagrant systemd[1]: mariadb.service failed.
    Jun 27 17:46:46 vagrant polkitd[656]: Unregistered Authentication Agent for unix-process:12731:154478 (system bus name :1.31, object path /org/freedesktop/PolicyKit1/AuthenticationAgent,
    Jun 27 17:47:25 vagrant sudo[12754]: vagrant : TTY=pts/0 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/systemctl start mariadb.service
    Jun 27 17:47:25 vagrant polkitd[656]: Registered Authentication Agent for unix-process:12755:158423 (system bus name :1.33 [/usr/bin/pkttyagent — notify-fd 5 — fallback], object path /org
    Jun 27 17:47:25 vagrant systemd[1]: Starting MariaDB database server…
    — Subject: Unit mariadb.service has begun start-up
    — Defined-By: systemd
    — Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
    —
    — Unit mariadb.service has begun starting up.
    Jun 27 17:47:26 vagrant mysqld[12760]: 2016–06–27 17:47:26 140668548266112 [Note] /usr/sbin/mysqld (mysqld 10.1.14-MariaDB) starting as process 12760 …
    Jun 27 17:47:26 vagrant mysqld[12760]: 2016–06–27 17:47:26 140668548266112 [Note] InnoDB: Using mutexes to ref count buffer pool pages
    Jun 27 17:47:26 vagrant mysqld[12760]: 2016–06–27 17:47:26 140668548266112 [Note] InnoDB: The InnoDB memory heap is disabled
    Jun 27 17:47:26 vagrant mysqld[12760]: 2016–06–27 17:47:26 140668548266112 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
    Jun 27 17:47:26 vagrant mysqld[12760]: 2016–06–27 17:47:26 140668548266112 [Note] InnoDB: Memory barrier is not used
    Jun 27 17:47:26 vagrant mysqld[12760]: 2016–06–27 17:47:26 140668548266112 [Note] InnoDB: Compressed tables use zlib 1.2.7
    Jun 27 17:47:26 vagrant mysqld[12760]: 2016–06–27 17:47:26 140668548266112 [Note] InnoDB: Using Linux native AIO
    Jun 27 17:47:26 vagrant mysqld[12760]: 2016–06–27 17:47:26 140668548266112 [Note] InnoDB: Using SSE crc32 instructions
    Jun 27 17:47:26 vagrant mysqld[12760]: 2016–06–27 17:47:26 140668548266112 [Note] InnoDB: Initializing buffer pool, size = 128.0M
    Jun 27 17:47:26 vagrant mysqld[12760]: 2016–06–27 17:47:26 140668548266112 [Note] InnoDB: Completed initialization of buffer pool
    Jun 27 17:47:26 vagrant mysqld[12760]: 2016–06–27 17:47:26 140668548266112 [Note] InnoDB: Highest supported file format is Barracuda.
    Jun 27 17:47:26 vagrant mysqld[12760]: InnoDB: No valid checkpoint found.
    Jun 27 17:47:26 vagrant mysqld[12760]: InnoDB: If you are attempting downgrade from MySQL 5.7.9 or later,
    Jun 27 17:47:26 vagrant mysqld[12760]: InnoDB: please refer to http://dev.mysql.com/doc/refman/5.6/en/upgrading-downgrading.html
    Jun 27 17:47:26 vagrant mysqld[12760]: InnoDB: If this error appears when you are creating an InnoDB database,
    Jun 27 17:47:26 vagrant mysqld[12760]: InnoDB: the problem may be that during an earlier attempt you managed
    Jun 27 17:47:26 vagrant mysqld[12760]: InnoDB: to create the InnoDB data files, but log file creation failed.
    Jun 27 17:47:26 vagrant mysqld[12760]: InnoDB: If that is the case, please refer to
    Jun 27 17:47:26 vagrant mysqld[12760]: InnoDB: http://dev.mysql.com/doc/refman/5.6/en/error-creating-innodb.html
    Jun 27 17:47:26 vagrant mysqld[12760]: 2016–06–27 17:47:26 140668548266112 [ERROR] Plugin ‘InnoDB’ init function returned error.
    Jun 27 17:47:26 vagrant mysqld[12760]: 2016–06–27 17:47:26 140668548266112 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
    Jun 27 17:47:26 vagrant mysqld[12760]: 2016–06–27 17:47:26 140668548266112 [Note] Plugin ‘FEEDBACK’ is disabled.
    Jun 27 17:47:26 vagrant mysqld[12760]: 2016–06–27 17:47:26 140668548266112 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
    Jun 27 17:47:26 vagrant mysqld[12760]: 2016–06–27 17:47:26 140668548266112 [ERROR] Unknown/unsupported storage engine: InnoDB
    Jun 27 17:47:26 vagrant mysqld[12760]: 2016–06–27 17:47:26 140668548266112 [ERROR] Aborting
    Jun 27 17:47:26 vagrant systemd[1]: mariadb.service: main process exited, code=exited, status=1/FAILURE
    Jun 27 17:47:26 vagrant systemd[1]: Failed to start MariaDB database server.
    — Subject: Unit mariadb.service has failed
    — Defined-By: systemd
    — Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
    —
    — Unit mariadb.service has failed.
    —
    — The result is failed.
    Jun 27 17:47:26 vagrant systemd[1]: Unit mariadb.service entered failed state.
    Jun 27 17:47:26 vagrant systemd[1]: mariadb.service failed.
    Jun 27 17:47:26 vagrant polkitd[656]: Unregistered Authentication Agent for unix-process:12755:158423 (system bus name :1.33, object path /org/freedesktop/PolicyKit1/AuthenticationAgent,
    Jun 27 17:47:40 vagrant sudo[12775]: vagrant : TTY=pts/0 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/systemctl status mariadb.service
    Jun 27 17:48:10 vagrant sudo[12777]: vagrant : TTY=pts/0 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/journalctl -xe
    lines 2790–2842/2842 (END)
</pre>

###Step 4 — Install Maria DB

Now that the folder is removed and you got all SQL dumps, install MariaDB

<pre>
    sudo yum install MariaDB-server MariaDB-client
</pre>

###Final Step — Start service and restore DBS

Now all that is remaining is to restore the service and install the SQL dumps.

<pre>
    sudo systemctl start mariadb
</pre>

It is not a pleasant solution but it is a solution until they get the magical migration working just like it does for MariaDB 10.0

I have done a good couple of hours of searches and tests until I came to the conclusion that, at least at this moment, there is no direct easy magical migration path from MySQL 5.7 to MariaDB 10.1, but there is a path. During this period what I have found out is that their IRC channel is very useful and you won't find as many answers out there as you will for MySQL, to make matters harder when searching for something to help troubleshoot a lot comes back with MySQL answers.

Hope this helps in the same way that helped me.

####Notes:

While doing all of these tests yesterday I have missed one important part of the process: https://dev.mysql.com/doc/refman/5.5/en/upgrading.html

I will be testing again, but, based on the results that I have got with another test that I have done with MariaDB 10.0 I believe that those steps before the process and running this:

<pre>
    mysql_upgrade -u <user> -p
</pre>

after the full install should fix all issues that were described before making the magic fully work.

This post was originally at: https://bit.ly/31SUCmu