The recommended approach is to use the MariaDB package repository to install MaxScale. After enabling the repository by following the instructions, MaxScale can be installed with the following commands.
-
For RHEL/Rocky Linux/Alma Linux, use
dnf install maxscale
. -
For Debian and Ubuntu, run
apt update
followed byapt install maxscale
. -
For SLES, use
zypper install maxscale
.
Download the correct MaxScale package for your CPU architecture and operating system from the MariaDB Downloads page. MaxScale can be installed with the following commands.
-
For RHEL/Rocky Linux/Alma Linux, use
dnf install /path/to/maxscale-*.rpm
-
For Debian and Ubuntu, use
apt install /path/to/maxscale-*.deb
. -
For SLES, use
zypper install /path/to/maxscale-*.rpm
.
MaxScale can also be installed using a tarball. That may be required if you are using a Linux distribution for which there exist no installation package or if you want to install many different MaxScale versions side by side. For instructions on how to do that, please refer to Install MariaDB MaxScale using a Tarball.
Alternatively you may download the MariaDB MaxScale source and build your own binaries. To do this, refer to the separate document Building MariaDB MaxScale from Source Code
MaxScale assumes that memory allocations always succeed and in general does
not check for memory allocation failures. This assumption is compatible with
the Linux kernel parameter
vm.overcommit_memory
having the value 0
, which is also the default on most systems.
With vm.overcommit_memory
being 0
, memory allocations made by an
application never fail, but instead the application may be killed by the
so-called OOM (out-of-memory) killer if, by the time the application
actually attempts to use the allocated memory, there is not available
free memory on the system.
If the value is 2
, then a memory allocation made by an application may
fail and unless the application is prepared for that possibility, it will
likely crash with a SIGSEGV. As MaxScale is not prepared to handle memory
allocation failures, it will crash in this situation.
The current value of vm.overcommit_memory
can be checked with
sysctl vm.overcommit_memory
or
cat /proc/sys/vm/overcommit_memory
The MaxScale Tutorial covers the first steps in configuring your MariaDB MaxScale installation. Follow this tutorial to learn how to configure and start using MaxScale.
For a detailed list of all configuration parameters, refer to the Configuration Guide and the module specific documents listed in the Documentation Contents.
Read the Encrypting Passwords section of the configuration guide to set up password encryption for the configuration file.
There are various administration tasks that may be done with MariaDB MaxScale. A command line tools is available, maxctrl, that will interact with a running MariaDB MaxScale and allow the status of MariaDB MaxScale to be monitored and give some control of the MariaDB MaxScale functionality.
The administration tutorial covers the common administration tasks that need to be done with MariaDB MaxScale.
The main configuration file for MaxScale is in /etc/maxscale.cnf
and
additional user-created configuration files are in
/etc/maxscale.cnf.d/
. Objects created or modified at runtime are stored in
/var/lib/maxscale/maxscale.cnf.d/
. Some modules also store internal data in
/var/lib/maxscale/
named after the module or the configuration object.
The simplest way to back up the configuration and runtime data of a MaxScale installation is to create an archive from the following files and directories:
-
/etc/maxscale.cnf
-
/etc/maxscale.cnf.d/
-
/var/lib/maxscale/
This can be done with the following command:
tar -caf maxscale-backup.tar.gz /etc/maxscale.cnf /etc/maxscale.cnf.d/ /var/lib/maxscale/
If MaxScale is configured to store data in custom locations, these should be included in the backup as well.