MariaDB MaxScale — Replica Rebuild – Part 7

Part 7 — MaxScale Configuration continued

This multi-part series breaks down each section into easy logical steps.

If you have not completed part 1, start here.


MaxScale Configuration

To allow MaxScale to process database connections, we must set up a listener and a service

It is possible to have a number of listeners and services to support different backend configurations but in this current use case. We are going to create one of each.

Service

To create the service we will use the maxctrl command:

Bash
maxctrl create service Application-Service readwritesplit user=maxscale_user password=aBcd123_

Once we have created the service we can add in to it the backend database servers that are linked to this service:

Bash
maxctrl link service Application-Service server1
maxctrl link service Application-Service server2
maxctrl link service Application-Service server3

Whilst we are configuring the service we are going to add some additional settings:

Bash
maxctrl alter service Application-Service \
transaction_replay=true \
transaction_replay_max_size=128M \
transaction_replay_attempts=10 \
transaction_replay_retry_on_deadlock=true \
master_reconnection=true \
master_failure_mode=fail_on_write \
causal_reads=fast \
master_accept_reads=true

You can check that the service is running:

Bash
maxctrl list services

Where you should see some output like this:

maxctrl list services

Listener

The listener is used to link a port connection to the service we just created:

Bash
maxctrl create listener Application-Service Application-Listener 3306 address=0.0.0.0

We have created this listener on the default MariaDB port of 3306. You can check the output by running:

Bash
maxctrl list listeners

You should see a result similar to this:

maxctrl list listeners

Other configuration

To help ensure our MaxScale service is well configured, we are going to alter the Server Monitor. This is to allow automated failovers, cooperative monitoring, disk space monitoring and decrease the monitor interval:

Bash
maxctrl alter monitor Server-Monitor \
enforce_simple_topology=true \
enforce_writable_master=true \
enforce_read_only_slaves=true \
auto_failover=true \
auto_rejoin=true \
cooperative_monitoring_locks=majority_of_running \
disk_space_check_interval=20000ms \
switchover_on_low_disk_space=true \
disk_space_threshold=/:80 \
monitor_interval=1000ms

Now that our MaxScale Server is ready to take connections, we can test it with Sysbench in Part 8.


Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7 | Part 8 | Part 9

Kester Riley

Kester Riley is a Senior Solutions Engineer who leverages his website to establish his brand and build strong business relationships. Through his blog posts, Kester shares his expertise as a consultant, mentor, trainer, and presenter, providing innovative ideas and code examples to empower ambitious professionals.

CentOS (15) Connector (5) Continuous Availability (1) Cooperative Monitoring (3) High Availability (12) Java (3) MariaDB (16) MaxScale (14) Python (2) Replica Rebuild (10) Rocky Linux (15)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.