Deploy Primary/Replica Topology with Enterprise Server 10.5
This page is part of MariaDB's MariaDB Documentation.
The parent of this page is: Deploy Primary/Replica Topology
Topics on this page:
This procedure describes the deployment of the Primary/Replica topology with MariaDB Enterprise Server 10.5 and MariaDB MaxScale 2.5.
Primary/Replica topology provides read scalability and fault tolerance through asynchronous or semi-synchronous single-primary replication.
This procedure has 7 steps, which are executed in sequence.
MariaDB products can be deployed in many different topologies to suit specific use cases. The Primary/Replica topology can be deployed on its own, or integrated with MariaDB Enterprise Cluster.
This procedure represents basic product capability with 3 Enterprise Server nodes and 1 MaxScale node.
This page provides an overview of the topology, requirements, and deployment procedure.
Please read and understand this procedure before executing.
Start and Configure MariaDB Enterprise Server on Primary Server
Start and Configure MariaDB Enterprise Server on Replica Servers
The following components are deployed during this procedure:
Modern SQL RDBMS with high availability, pluggable storage engines, hot online backups, and audit logging.
Database proxy that extends the availability, scalability, and security of MariaDB Enterprise Servers
MariaDB Enterprise Server Components
MariaDB MaxScale Components
Listens for client connections to MaxScale, then passes them to the router service associated with the listener
Tracks changes in the state of MariaDB Enterprise Servers.
Read Connection Router
Routes connections from the listener to any available Enterprise Server node
Read/Write Split Router
Routes read operations from the listener to any available Enterprise Server node, and routes write operations from the listener to a specific server operating as the primary server
Connection configuration in MaxScale to an Enterprise Server node
Primary/Replica topology provides read scalability and fault tolerance through asynchronous or semi-synchronous single-primary replication of MariaDB Enterprise Server 10.5
The Primary/Replica topology consists of:
1 or more MaxScale nodes
1 Enterprise Server node operating as the primary server
2 or more Enterprise Server nodes operating as replica servers.
The MaxScale nodes:
Monitor the health and availability of the Enterprise Server nodes
Route queries to Enterprise Server nodes using Read/Write Split (
readwritesplit) and Read Connection (
Promote replica servers in the event that the primary server fails.
The Enterprise Server node operating as the primary server:
Receives write queries from MaxScale, logging them to the Binary Log
Provides Binary Logs to replica servers for replication
The Enterprise Server nodes operating as replica servers:
Receive read queries from MaxScale
Replicate writes asynchronously or semi-synchronously from the primary server
These requirements are for the Primary/Replica topology when deployed with MariaDB Enterprise Server 10.5 and MariaDB MaxScale 2.5.
In alignment to the enterprise lifecycle, the Primary/Replica topology with MariaDB Enterprise Server 10.5 and MariaDB MaxScale 2.5 is provided for:
CentOS Linux 7 (x86_
Debian 10 (x86_
Debian 11 (x86_
Microsoft Windows (x86_
Red Hat Enterprise Linux 7 (x86_
Red Hat Enterprise Linux 8 (x86_
Red Hat Enterprise Linux 9 (x86_
Rocky Linux 8 (x86_
Rocky Linux 9 (x86_
SUSE Linux Enterprise Server 12 (x86_
SUSE Linux Enterprise Server 15 (x86_
Ubuntu 18.04 LTS (x86_
Ubuntu 20.04 LTS (x86_
System User Accounts
MaxScale process owner
Enterprise Server process owner
MariaDB Enterprise Server Configuration Management
Configuration files (such as
The server can be started with command-line options that set system-variables and options.
Users can set system-variables that support dynamic changes on-the-fly using the SET statement.
MariaDB Enterprise Server packages are configured to read configuration files from different paths, depending on the operating system. Making custom changes to Enterprise Server default configuration files is not recommended because custom changes may be overwritten by other default configuration files that are loaded later.
To ensure that your custom changes will be read last, create a custom configuration file with the
z- prefix in one of the include directories.
Example Configuration File Path
MariaDB Enterprise Server Service Management
systemctl command is used to start and stop the MariaDB Enterprise Server service.
Enable during startup
Disable during startup
MariaDB Enterprise Server Logs
MariaDB Enterprise Server produces log data that can be helpful in problem diagnosis.
Log filenames and locations may be overridden in the server configuration. The default location of logs is the data directory. The data directory is specified by the datadir system variable.
MariaDB Enterprise Audit Log
Slow Query Log
General Query Log
MaxScale Configuration Management
MaxScale can be configured using several methods. These methods make use of MaxScale's REST API.
Command-line utility to perform administrative tasks through the REST API. See MaxCtrl Commands.
MaxGUI is a graphical utility that can perform administrative tasks through the REST API.
The REST API can be used directly. For example, the
The procedure on these pages configures MaxScale using MaxCtrl.
MaxScale Service Management
systemctl command is used to start and stop the MaxScale service.
Enable during startup
Disable during startup
Navigation in the procedure "Deploy Primary/Replica Topology":