Moving MySQL databases into MariaDB

I had a problem with MySQL 8.4 recently. Eventually I gave up and resorted to moving to MariaDB. Switching applications because I hit a problem isn’t something I usually do lightly.

Overview

Most of the work won’t be shown here. However, this is an overview:

Created a new jail on the host: [12:09 zuul dvl ~] % sudo mkjail create -j mariadb01 -a amd64 -v 15.0-RELEASE
Add new DNS entries for that jail
Did the Ansible bootstrap stuff in the jail so Ansible would run
Copied the jail-mysql.yaml Ansible playbook to jail-mariadb.yaml and modified it
Built databases/mariadb118-server (which also built databases/mariadb118-client)
Added firewall rules so that new jail could also access my subversion repo – that’s still not working; I gave up
Configured the rsyncer user to do nightly database dumps and rsync them to the dbclone jail
Copied the latest database backups into the new jail for later restores
Anything else?

MariaDB configuration

I installed and then enabled MariaDB.

I enabled it (yes, that’s the right service name):

# service mysql-server enable
mysql enabled in /etc/rc.conf

I started it:

# service mysql-server start
Installing MariaDB/MySQL system tables in '/var/db/mysql' ...
OK

To start mariadbd at boot time you have to copy
support-files/mariadb.service to the right place for your system


Two all-privilege accounts were created.
One is root@localhost, it has no password, but you need to
be system 'root' user to connect. Use, for example, sudo mariadb
The second is mysql@localhost, it has no password either, but
you need to be the system 'mysql' user to connect.
After connecting you can set the password, if you would need to be
able to connect as any of these users with a password and without sudo

See the MariaDB Knowledgebase at https://mariadb.com/kb

You can start the MariaDB daemon with:
cd '/usr/local' ; /usr/local/bin/mariadbd-safe --datadir='/var/db/mysql'

You can test the MariaDB daemon with mariadb-test-run.pl
cd '/usr/local/' ; perl mariadb-test-run.pl

Please report any problems at https://mariadb.org/jira

The latest information about MariaDB is available at https://mariadb.org/.

Consider joining MariaDB's strong and vibrant community:
Get Involved


Starting mysql.

I ran this. I read it about. Figured it would be good. I know nothing else.

[13:09 zuul-mariadb01 dvl ~/mysql] % sudo mysql_secure_installation
/usr/local/bin/mysql_secure_installation: Deprecated program name. It will be removed in a future release, use 'mariadb-secure-installation' instead

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we'll need the current
password for the root user. If you've just installed MariaDB, and
haven't set the root password yet, you should just press enter here.

Enter current password for root (enter for none):
OK, successfully used password, moving on...

Setting the root password or using the unix_socket ensures that nobody
can log into the MariaDB root user without the proper authorisation.

You already have your root account protected, so you can safely answer 'n'.

Switch to unix_socket authentication [Y/n] n
... skipping.

You already have your root account protected, so you can safely answer 'n'.

Change the root password? [Y/n] y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
... Success!

By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] y
... Success!

Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] y
... Success!

By default, MariaDB comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] y
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] y
... Success!

Cleaning up...

All done! If you've completed all of the above steps, your MariaDB
installation should now be secure.

Thanks for using MariaDB!

Creating and restoring the database

Create the database:

[13:15 zuul-mariadb01 dvl ~/mysql] % mysql -u root -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 14
Server version: 11.8.6-MariaDB FreeBSD Ports

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

root@localhost [(none)]> create database wordpress_danlangilleorg;
Query OK, 1 row affected (0.000 sec)

root@localhost [(none)]> ^DBye

Populating that new database:

[13:16 zuul-mariadb01 dvl ~/mysql] % mysql -u root -p wordpress_danlangilleorg < wordpress_danlangilleorg.sql
Enter password:

That was easy.

Creating the database users

[13:17 zuul-mariadb01 dvl ~/mysql] % mysql -u root -p mysql                                                  
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 16
Server version: 11.8.6-MariaDB FreeBSD Ports

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

root@localhost [mysql]> grant usage on wordpress_danlangilleorg.* to 'wordpress'@'10.8.0.7' identified by 'foo';
Query OK, 0 rows affected (0.096 sec)

Oh, there's more, I found out later:

root@localhost [(none)]> GRANT SELECT, INSERT, UPDATE, DELETE ON wordpress_danlangilleorg.* to 'wordpress'@'10.80.0.97' ;
Query OK, 0 rows affected (0.014 sec)