While MariaDB Enterprise Server ships with sensible defaults for most enterprise use cases, configuration may be needed to meet business requirements and workload demands.

Configuration generally occurs concurrent to installation or immediately after installation. Steps may include:


Common hardening practices applied in deploying new servers include:

  • Temporarily blocking access to servers until completion of configuration and testing.

  • Installing the operating system from an authoritative source, and with validation of software integrity using cryptographic signatures and sums.

  • Installing MariaDB Platform components from an authoritative source, either MariaDB Corporation repositories or internal repositories you maintain.

  • Deploying systems and software configuration in alignment to vendor best practices.

  • Applying settings and controls for added systems and network hardening, as suggested by CIS Benchmarks or other industry guidance.

  • Segmenting networks using VLANs on switches.

  • Using firewalls, such as ufw or iptables.

  • Configuring system security policies, including SELinux.

  • Configuring authentication and authorization, such as user account creation, privilege grants, and configuration of password validation, user blocking, and per-user resource limits.

  • Using data-at-rest encryption to secure data on disk.

  • Using data-in-transit encryption to secure data on the network.

Differences from MariaDB Community Server

  • mariadb-secure-installation is unnecessary as MariaDB Enterprise Server ships with a hardened configuration and mariadb-install-db performs hardening actions.

HA, Load Balancing, Failover

MariaDB Enterprise Server deployments typically incorporate replication or clustering for high availability and scale-out, and MariaDB MaxScale for load balancing and automatic failover.

Deployment of these solutions includes:

  • Installation and configuration of MariaDB Platform components.

  • Configuration of firewall settings to permit communication between servers.

  • Testing.

General Configuration

MariaDB Enterprise Server configuration is SET on-the-fly, by command-line options, or in the configuration file. The method used will depend on your use case and the intended durability of the change.

Available Reference

A complete list of configuration options is available in the Reference section of MariaDB Enterprise Documentation at:

Common Configuration Changes

Common configuration settings include:

  • Workload-specific performance tuning, including tuning of the InnoDB buffer pool.

  • Configuration of plugin load options, including MariaDB Enterprise Server.

  • Configuration of data-at-rest encryption and data-in-transit encryption.

Using the Configuration File

When MariaDB Platform starts, it reads from configuration files to specify the starting values for system variables.

The mariadb-enterprise.cnf file contains MariaDB Enterprise Server defaults.

Configuration files may include:

  • /etc/my.cnf or /etc/mysql/my.cnf

  • RHEL/CentOS: Files in the /etc/my.cnf.d/ directory, including mariadb-enterprise.cnf

  • Debian/Ubuntu: Files in the /etc/mysql/conf.d/ directory, including mariadb-enterprise.cnf

  • For Binary Tarball installations: $MARIADBHOME/etc/ includes the mariadb-enterprise.cnf configuration file. The mariadbd-safe utility uses this file.

Using Command-line Options

If you want to change starting system variables for one run, you can override the configuration file by setting some system variables using command-line options.

# /usr/bin/mysqld_safe --datadir=/data/mariadb/alt

Dynamic System Variables

Not all system variables require you to restart MariaDB Platform to change their values. Some system variables are dynamic, meaning that you can change the value at runtime using a SET statement.

SET SESSION alter_algorithm=INSTANT;

Dynamic system variables have scope, in that you can change the setting for your current client session, or you can change the setting globally for all connected sessions:

SET GLOBAL optimizer_trace=ON;

Variables changed with SET SESSION are valid during the current session. Variables changed with SET GLOBAL are valid until server restart.


Changes to MariaDB Platform configuration can have significant and unexpected results. Test all changes in a Testing environment before promoting the change to the Production environment.