Table of Contents
- Introduction
- Get Started
- System Configuration for the Master
- System Configuration for the Slave
- Install MariaDB
- Database Configuration for the Master
- Database Configuration for the Slave
- Configure and Start Replication
- Import Sample Data
- Check Replication Status
- Summary
Introduction
Configuring database replication is a fairly common task you may encounter as traffic to a database driven website increases. Configuring standard replication using MariaDB (or MySQL) involves provisioning a master server and one or more slave servers. The master server will maintain a binary log (binlog) which the slave server(s) will read and then execute whatever operations are recorded in the log.
Replication does not replace the need to maintain backups of your database data. It can help make the backup process less taxing on a busy master server. Once replication is configured, you can schedule backups to happen on the slave server instead of the master server. If your application is capable of sending reads and writes to different database servers, you may be able to enhance overall application performance by directing read-only queries to one or more slave servers. Write operations can be directed to the master server.
Get Started
This tutorial will demonstrate configuring standard database replication using MariaDB 10 on Ubuntu 16.04 LTS.
Provision two servers with Ubuntu 16.04 LTS, optionally placing one server in each availability zone. Add a second network interface to each server and connect them to form a private LAN with non-publicly routable IP addresses. The first network interface can be connected to the internet so we have a way to access the servers using SSH. Set cores, memory, and disk space as desired. In the example we are using a single core server with 2 GB of memory and 20 GB of hard disk space. Set a password and optionally provide SSH keys for each server. The two server setup would look something like this in the DCD.
Once the servers have been provisioned, connect to each of them using the Remote Console in the DCD or SSH. The username will be root with the password that you set when provisioning. You can get the IP address for each server by looking at the Network tab of the server properties in the DCD.
The main network interface (NIC) on each server will be assigned a dynamic public ip address. We will set a static private ip address on the second network interface by editing /etc/network/interfaces on each server. We will also customize the hostname and add an entry to /etc/hosts so we can reference the servers by name instead of just ip address. We will also take the opportunity to add a new user, grant them sudo access, and update the OS.
System Configuration for the Master
On the sqlmaster server:
Set a static IP address on the second NIC. The file /etc/network/interfaces should look like this by default:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
allow-hotplug eth1
iface eth1 inet dhcp
allow-hotplug eth2
iface eth2 inet dhcp
allow-hotplug eth3
iface eth3 inet dhcp
allow-hotplug eth4
iface eth4 inet dhcp
allow-hotplug eth5
iface eth5 inet dhcp
We are going to make a change to eth1, comment out the line starting with iface eth1 and add three new lines:
# The secondary network interface
allow-hotplug eth1
#iface eth1 inet dhcp
iface eth1 inet static
address 172.16.1.20
netmask 255.255.255.0
Run these two commands to reload the network configuration:
ifdown eth1
ifup eth1
Set a hostname for the master:
hostnamectl set-hostname sqlmaster
Update /etc/hosts:
vi /etc/hosts
root@ubuntu:~# cat /etc/hosts
127.0.0.1 localhost
172.16.1.20 sqlmaster
172.16.1.21 sqlslave
Add a new user:
adduser {YOUR_USERNAME}
Adding user `' ...
Adding new group `' (1000) ...
Adding new user `' (1000) with group `' ...
Creating home directory `/home/' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] Y
Grant the new user sudo access:
adduser {YOUR_USERNAME} sudo
Adding user `' to group `sudo' ...
Adding user to group sudo
Done.
Update the system by running apt update (output will be similar to this):
apt update
Get:1 http://security.ubuntu.com/ubuntu xenial-security InRelease [94.5 kB]
Hit:2 http://us.archive.ubuntu.com/ubuntu xenial InRelease
...
Fetched 2,141 kB in 1s (1,558 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
45 packages can be upgraded. Run 'apt list --upgradable' to see them.
Apply the updates by running apt upgrade (output will be similar to this):
apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
linux-headers-4.4.0-31 linux-headers-4.4.0-31-generic linux-image-4.4.0-31-generic
linux-image-extra-4.4.0-31-generic
The following packages will be upgraded:
base-files bash console-setup console-setup-linux gcc-5-base grub-common grub-legacy-ec2 grub-pc grub-pc-bin
grub2-common keyboard-configuration klibc-utils language-pack-en language-pack-en-base language-pack-gnome-en
language-pack-gnome-en-base libklibc liblxc1 libpam-systemd libpython3.5 libpython3.5-minimal
libpython3.5-stdlib libstdc++6 libsystemd0 libudev1 linux-firmware linux-generic linux-headers-generic
linux-image-generic lsb-base lsb-release lxc-common lxcfs lxd lxd-client python3-software-properties python3.5
python3.5-minimal snapd software-properties-common systemd systemd-sysv tzdata udev update-notifier-common
45 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 130 MB of archives.
After this operation, 297 MB of additional disk space will be used.
Do you want to continue? [Y/n]Y
The upgrade process will take a while to complete. Reboot the server when it finishes, unless you have a good reason not to do so in your test environment.
reboot
On the slave server we will repeat the steps above with minor differences.
System Configuration on the Slave
Set a static ip address on the secondary network interface by editing /etc/network/interfaces. Make the change to eth1, comment out the line starting with iface eth1 and add three new lines:
# The secondary network interface
allow-hotplug eth1
#iface eth1 inet dhcp
iface eth1 inet static
address 172.16.1.21
netmask 255.255.255.0
Run these two commands to reload the network configuration:
ifdown eth1
ifup eth1
Set a hostname for the slave:
hostnamectl set-hostname sqlslave
Update /etc/hosts:
vi /etc/hosts
root@ubuntu:~# cat /etc/hosts
127.0.0.1 localhost
172.16.1.20 sqlmaster
172.16.1.21 sqlslave
Add a new user:
adduser {YOUR_USERNAME}
Grant the new user sudo access:
adduser {YOUR_USERNAME} sudo
Update the system by running apt update and apt upgrade. Use reboot to restart the server once apt upgrade completes successfully.
Install MariaDB
Now we can move into installing "MariaDB". The latest version is available if we add a repository first. Connect to both sqlmaster and sqlslave using SSH and log in as the user we added before the reboot.
Instructions for getting the MariaDB repository configured on our servers can be found by going through the MariaDB Repository Configuration Wizard.
- For Chose a Distro, select Ubuntu.
- For Choose a Release, select 16.04 LTS "xenial".
- For Choose a Version, select 10.1[Stable].
- For Choose a Mirror, select one of the options presented and the lower section of the screen will populate with instructions.
Although the instructions suggest installing "software-properties-common" first, that package should already be present in your ProfitBricks Ubuntu 16.04 LTS server installation. (If the next step doesn't work, you may consider running sudo apt-get install software-properties-common and try again.)
Please Note: The next set of steps should be executed on both sqlmaster and sqlslave.
First we will run apt-key to add the repo keys to our apt keyring. This allows apt to verify the packages we are installing are signed by an authorized source.
sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8
[sudo] password for:
Executing: /tmp/tmp.nvEoMYxzEO/gpg.1.sh --recv-keys
--keyserver
hkp://keyserver.ubuntu.com:80
0xF1656F24C74CD1D8
gpg: requesting key C74CD1D8 from hkp server keyserver.ubuntu.com
gpg: key C74CD1D8: public key "MariaDB Signing Key <signing-key@mariadb.org>" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
Now we will add the repository, in this example using the first mirror in the list. You are welcome to choose a mirror closer to the data center location or based on your personal preference.
sudo add-apt-repository 'deb [arch=amd64,i386,ppc64el] http://mirrors.accretive-networks.net/mariadb/repo/10.1/ubuntu xenial main'
When that completes, run sudo apt update so it can connect to the new repository and get a list of available packages.
Finally we can install mariadb-server with sudo apt install mariadb-server:
sudo apt install mariadb-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
galera-3 iproute libaio1 libcgi-fast-perl libcgi-pm-perl libdbd-mysql-perl libdbi-perl libencode-locale-perl libfcgi-perl libhtml-parser-perl libhtml-tagset-perl libhtml-template-perl libhttp-date-perl libhttp-message-perl libio-html-perl libjemalloc1 liblwp-mediatypes-perl libmariadbclient18 libmysqlclient18 libmysqlclient20 libtimedate-perl liburi-perl lsof mariadb-client-10.1 mariadb-client-core-10.1 mariadb-common mariadb-server-10.1 mariadb-server-core-10.1 mysql-common psmisc socat
Suggested packages:
libclone-perl libmldbm-perl libnet-daemon-perl libsql-statement-perl libdata-dump-perl libipc-sharedcache-perl libwww-perl libterm-readkey-perl mailx mariadb-test tinyca
The following NEW packages will be installed:
galera-3 iproute libaio1 libcgi-fast-perl libcgi-pm-perl libdbd-mysql-perl libdbi-perl libencode-locale-perl libfcgi-perl libhtml-parser-perl libhtml-tagset-perl libhtml-template-perl libhttp-date-perl libhttp-message-perl libiohtml-perl libjemalloc1 liblwp-mediatypes-perl libmariadbclient18 libmysqlclient18 libmysqlclient20 libtimedate-perl liburi-perl lsof mariadb-client-10.1 mariadb-client-core-10.1 mariadb-common mariadb-server mariadb-server-10.1 mariadb-server-core-10.1 mysql-common psmisc socat
0 upgraded, 32 newly installed, 0 to remove and 0 not upgraded.
Need to get 23.9 MB of archives.
After this operation, 184 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
answering Y will allow the installation to proceed.
The install will present this lovely screen asking you to set a root password for the database server:
and confirm it:
The install will continue:
...
Setting up mariadb-server (10.1.14+maria-1~xenial) ...
Processing triggers for libc-bin (2.23-0ubuntu3) ...
Processing triggers for systemd (229-4ubuntu6) ...
Processing triggers for ureadahead (0.100.0-19) ...
Eventually you will be returned to a prompt and MariaDB 10.1 will be running on the system. The running binary is /usr/sbin/mysqld.
When it finishes, we will want to run mysql_secure_installation in order to secure the installation. If you set a database password during the install then enter the same password to authenticate. You can answer n, Y, Y, Y, and Y to the questions. If you didn't set a password or would like to change it, then answer Y to the first question and provide a password.
sudo mysql_secure_installation
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
you haven't set the root password yet, the password will be blank,
so you should just press enter here.
Enter current password for root (enter for none):
OK, successfully used password, moving on...
Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.
You already have a root password set, so you can safely answer 'n'.
Change the root password? [Y/n]n
... skipping.
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...
ERROR 1008 (HY000) at line 1: Can't drop database 'test'; database doesn't exist
... Failed! Not critical, keep moving...
- 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!
Now we can get to configuring the database for replication.
Database Configuration for the Master
Please Note: The following steps are only performed on sqlmaster.
Configuration files can be placed in /etc/mysql/ and/or /etc/mysql/conf.d/.
Create a new file /etc/mysq/conf.d/replication_master.cnf with the following contents:
[mysqld]
bind-address = 172.16.1.20
server-id = 1
We are overriding two parameters and are relying on defaults or settings in the configuration files that are parsed ahead of this one. The bind-address setting tells the database server to listen on the static IP address that we assigned. This overrides the default setting of binding to localhost, which prevents remote connections. Since we need the slave server to be able to connect to the master server, we have to change the bind-address. The other parameter being set is server-id. It needs to be set to a unique integer on each server (master or slave) that we are using for replication.
Database Configuration for the Slave
Please Note: The following steps are only performed on sqlslave.
Create a new file /etc/mysql/conf.d/replication_slave.cnf with the following contents:
[mysqld]
bind-address = 172.16.1.21
server-id = 2
The reason for setting these two parameters is the same as explained above when configuring the master server. The slave server will generate some relay log files, which will be placed in the data directory (/var/lib/mysql/) unless we provide additional override settings. These settings are commented out in /etc/mysql/my.cnf. We can place uncommented copies of them in our replication_slave.cnf file like this:
relay_log = /var/log/mysql/relay-bin
relay_log_index = /var/log/mysql/relay-bin.index
relay_log_info_file = /var/log/mysql/relay-bin.info
This is not necessary for replication to work, but it keeps the logs a bit more organized.
We will restart mysqld on each server so that new configuration can be applied.
sqlmaster:~$ sudo systemctl restart mysqld
sqlslave:~$ sudo systemctl restart mysqld
Configure and Start Replication
Lets open a database command shell by running mysql -u root -p on sqlmaster:
sqlmaster:~$ mysql -u root -p
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 10.1.16-MariaDB-1~xenial mariadb.org binary distribution
Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>
We will execute a GRANT statement to add a replication user:
MariaDB [(none)]> GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'172.16.1.21' IDENTIFIED BY 'r3pl1c@T3';
MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
There shouldn't be any other database activity going on since we are doing this in a test environment, however, lets be safe and lock the database so that no writes will happen while we initialize replication.
MariaDB [(none)]> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.00 sec)
If you did have data on sqlmaster, now would be the time to export it and copy it over to sqlslave.
Running SHOW MASTER STATUS; will help us get the binary log filename and position. We need the File value of mariadb-bin.000019 and the Position value of 329 to initiate replication.
MariaDB [(none)]> SHOW MASTER STATUS;
+--------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| mariadb-bin.000019 | 329 | | |
+--------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
The following commands need to be run on sqlslave in order to start replication.
Open a database command shell by running mysql -u root -p on sqlslave:
sqlslave:~$ mysql -u root -p
Enter password:
Adjust the following to match your specific settings:
CHANGE MASTER TO
MASTER_HOST='172.16.1.20',
MASTER_USER='replication_user',
MASTER_PASSWORD='r3pl1c@T3',
MASTER_PORT=3306,
MASTER_LOG_FILE='mariadb-bin.000019',
MASTER_LOG_POS=329,
MASTER_CONNECT_RETRY=10,
MASTER_USE_GTID = current_pos;
and then paste it into the MariaDB monitor:
MariaDB [(none)]> CHANGE MASTER TO
-> MASTER_HOST='172.16.1.20',
-> MASTER_USER='replication_user',
-> MASTER_PASSWORD='r3pl1c@T3',
-> MASTER_PORT=3306,
-> MASTER_LOG_FILE='mariadb-bin.000019',
-> MASTER_LOG_POS=329,
-> MASTER_CONNECT_RETRY=10,
-> MASTER_USE_GTID = current_pos;
Query OK, 0 rows affected (0.02 sec)
Lets get replication started!
MariaDB [(none)]> START SLAVE;
Query OK, 0 rows affected (0.01 sec)
Looks like it was successful, so lets UNLOCK TABLES on sqlmaster.
MariaDB [(none)]> UNLOCK TABLES;
Query OK, 0 rows affected (0.00 sec)
Just to verify, lets run SHOW DATABASES to see that MariaDB on sqlmaster and sqlslave are both empty:
MariaDB [(none)]> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
+--------------------+
3 rows in set (0.00 sec)
Import Sample Data
If you already have a database dump or backup file available, you can import it on the master to test replication.
There are also some sample databases available.
If you would like to test using the example "employee" database, then run the following commands on sqlmaster:
sqlmaster:~$ wget https://launchpad.net/test-db/employees-db-1/1.0.6/+download/employees_db-full-1.0.6.tar.bz2
--2016-08-05 21:49:52-- https://launchpad.net/test-db/employees-db-1/1.0.6/+download/employees_db-full-1.0.6.tar.bz2
Resolving launchpad.net (launchpad.net)... 91.189.89.223, 91.189.89.222
Connecting to launchpad.net (launchpad.net)|91.189.89.223|:443... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: https://launchpadlibrarian.net/24493586/employees_db-full-1.0.6.tar.bz2 [following]
--2016-08-05 21:49:53-- https://launchpadlibrarian.net/24493586/employees_db-full-1.0.6.tar.bz2
Resolving launchpadlibrarian.net (launchpadlibrarian.net)... 91.189.89.229, 91.189.89.228
Connecting to launchpadlibrarian.net (launchpadlibrarian.net)|91.189.89.229|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 26715056 (25M) [text/plain]
Saving to: 'employees_db-full-1.0.6.tar.bz2'
employees_db-full-1.0.6.tar.bz2 100%[==========================================================================================================>] 25.48M 1.26MB/s in 20s
2016-08-05 21:50:14 (1.25 MB/s) - 'employees_db-full-1.0.6.tar.bz2' saved [26715056/26715056]
Uncompress the archive:
sqlmaster:~$ tar xjvf employees_db-full-1.0.6.tar.bz2
employees_db/._load_departments.dump
employees_db/load_departments.dump
employees_db/load_dept_emp.dump
employees_db/._load_dept_manager.dump
employees_db/load_dept_manager.dump
employees_db/._load_employees.dump
employees_db/load_employees.dump
employees_db/._load_salaries.dump
employees_db/load_salaries.dump
employees_db/._load_titles.dump
employees_db/load_titles.dump
employees_db/._employees.sql
employees_db/employees.sql
employees_db/employees_partitioned.sql
employees_db/._employees_partitioned2.sql
employees_db/employees_partitioned2.sql
employees_db/employees_partitioned3.sql
employees_db/objects.sql
employees_db/test_employees_md5.sql
employees_db/test_employees_sha.sql
employees_db/Changelog
employees_db/._README
employees_db/README
Change into the directory and import the data:
sqlmaster:~$ cd employees_db
sqlmaster:~/employees_db$ mysql -u root -p -t < employees.sql
Enter password:
+-----------------------------+
| INFO |
+-----------------------------+
| CREATING DATABASE STRUCTURE |
+-----------------------------+
+------------------------+
| INFO |
+------------------------+
| storage engine: InnoDB |
+------------------------+
+---------------------+
| INFO |
+---------------------+
| LOADING departments |
+---------------------+
+-------------------+
| INFO |
+-------------------+
| LOADING employees |
+-------------------+
+------------------+
| INFO |
+------------------+
| LOADING dept_emp |
+------------------+
+----------------------+
| INFO |
+----------------------+
| LOADING dept_manager |
+----------------------+
+----------------+
| INFO |
+----------------+
| LOADING titles |
+----------------+
+------------------+
| INFO |
+------------------+
| LOADING salaries |
+------------------+
The data we imported on the master server is automatically replicated to the slave server. We can verify by running SHOW DATABASES; on both sqlmaster and sqlslave.
sqlmaster:~/employees_db$ mysql -u root -p
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 7
Server version: 10.1.16-MariaDB-1~xenial mariadb.org binary distribution
Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| employees |
| information_schema |
| mysql |
| performance_schema |
+--------------------+
4 rows in set (0.00 sec)
and the output on sqlslave should match:
MariaDB [(none)]> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| employees |
| information_schema |
| mysql |
| performance_schema |
+--------------------+
4 rows in set (0.00 sec)
Check Replication Status
On sqlmaster we can run SHOW MASTER STATUS and see that the values have changed:
MariaDB [(none)]> SHOW MASTER STATUS;
+--------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| mariadb-bin.000020 | 62702199 | | |
+--------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
Running SHOW SLAVE STATUS \G on sqlslave provides helpful output that lets you monitor the replication process. Using \G instead of ; at the end of the command changes the output format to be a bit more readable.
MariaDB [(none)]> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.16.1.20
Master_User: replication_user
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: mariadb-bin.000020
Read_Master_Log_Pos: 62702199
Relay_Log_File: relay-bin.000005
Relay_Log_Pos: 62702489
Relay_Master_Log_File: mariadb-bin.000020
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 62702199
Relay_Log_Space: 62702826
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: Current_Pos
Gtid_IO_Pos: 0-1-183
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
1 row in set (0.00 sec)
Summary
We have successfully provisioned two servers and configured MariaDB 10.1 to perform standard replication between one master and one slave server. You may find the official MariaDB documentation helpful if something didn't work as planned. You are also welcome to comment here, or in the ProfitBricks DevOps Community section of this website.
