Part 2 – Create a new Database Server for testing
This multipart series breaks down each section into easy logical steps.
For this blog, we are going to compare our existing 10.5 system against a new MariaDB 11.4 server using the MaxScale Diff Router. To do this, we need to create ourselves a new MariaDB 11.4 Server and add it in to our existing cluster.
There are multiple ways to achieve this, but to ensure we do not impact our existing production cluster, I am going to build a new server.
I am going to do this by following the instructions here, ensuring that I specify a version of MariaDB to install and making sure the configuration file I create specifies the new server number.
You might decide instead to sacrifice one of your existing database servers, but this is not recommended.
Warning!
If you are following the instructions here to build your new server, when running this line, make sure you add the right server version (to match your existing servers).
./mariadb_es_repo_setup --token="$CUSTOMER_DOWNLOAD_TOKEN" --apply --skip-tools --skip-maxscale --mariadb-server-version=10.5It is possible that this version is no longer available for automatic download, and you may have to find and install the RPMS manually instead!
Also, you must make sure you make the required changes to the MariaDB configuration file, to ensure this server is unique in your replication. I am going to assume this new server is Server 4.
In your production system, it is likely you have a more complex MariaDB configuration file.
Server 4
[mariadb]
binlog_format = MIXED
binlog_row_image = MINIMAL
expire_logs_days = 10
gtid_strict_mode = 1
log_basename = server4
log_bin
log_error = /var/log/mariadb/server4.err
log_slave_updates
plugin_load_add = disks
server_id = 4
session_track_system_variables = autocommit,character_set_client,character_set_connection,character_set_results,time_zone,last_gtid
slave_parallel_threads = 4Load data into new server.
Once you have created your new database server, you will need to load data, ideally you will do this from a MariaDB Backup restoration.
You should either have a mariadb-dump or mariadb-backup as part of your regular backup cycles that you can use to build this server.
If you do not have a backup, please take one and restore it to the new server.
I am going to use mariadb-dump to create a backup and stream it to my new server.
To be able to stream the backup in, I am going to create a user on my destination server:
mariadb -e "GRANT ALL PRIVILEGES ON *.* TO 'backupuser'@'10.106.0.%' IDENTIFIED BY 'str0ngPassw0rd%'"On one of the pre-existing servers, I am going to run a backup, and stream it straight to the new server, make sure you replace the IP address as required.
mariadb-dump --all-databases --single-transaction --master-data | mariadb -ubackupuser -pstr0ngPassw0rd% -h10.106.0.13I am aware that this is not very secure, but I am just showing you the password so you can see the full command!
Configure Replication
The new server that you have created will need to be part of the replication cluster. Remember that replication works at the database layer, and not MaxScale, although if you are using MaxScale it can look after replication for you and promote a replica in case of a primary node failure.
You need to be very careful here: Until MaxScale knows about this new server, it will not reconfigure it as part of an automated failover. If you do any manual switchover or a failover occurs, this server will no longer be receiving a replication stream. You will need to fix this.
Now that we have loaded our backup in to the new server, which included the master data, all we need to do on the new server is run a CHANGE MASTER command and START REPLICA. You will need to use your IP address, username and password.
CHANGE MASTER TO MASTER_HOST='10.106.0.9', MASTER_USER='replication_user', MASTER_PASSWORD='aBcd123_', MASTER_USE_GTID=slave_pos;
START SLAVE;You can check that this server is now connected to your Primary by running the SHOW SLAVE STATUS command:
SHOW SLAVE STATUS\GYou should check that the threads are running and that there are no errors:
Slave_IO_Running: Yes
Slave_SQL_Running: YesUpgrading the MariaDB Server
Once we are happy the new server is replicating, we need to upgrade it so that we are able to test the server with MaxScale.
Upgrading the server is simple, we just need to change the version our repository points to and upgrade the RPM:
./mariadb_es_repo_setup --token="$CUSTOMER_DOWNLOAD_TOKEN" --apply --skip-tools --skip-maxscale --mariadb-server-version=11.4
yum clean all
yum makecache
systemctl stop mariadb
yum remove -y MariaDB-server MariaDB-backup
yum install -y MariaDB-server MariaDB-backup
cp /etc/my.cnf.d/server.cnf.rpmsave /etc/my.cnf.d/server.cnf
systemctl start mariadb
mariadb-upgradeThe upgrade process should only take a few seconds, the time in the process is the stopping and starting of MariaDB.
Once the server is upgraded, you can check that it is still healthy and running, by checking the replication status.
It is important to note that as you go through the versions of MariaDB, some of the required privileges change. On the primary Server, you need to grant some new privileges.
mariadb -e "GRANT SLAVE MONITOR, REPLICATION SLAVE ADMIN, RELOAD ON *.* TO 'maxscale_user'@'10.106.0.%';"Now that you have a server setup for replication, learn how to configure MaxScale in Part 3 of this series.
Leave a Reply
You must be logged in to post a comment.