Operating Procedures

The following operating procedures are routinely performed in the course of MariaDB deployment:

Obtaining Support

MariaDB Corporation provides commercial support and services for MariaDB Enterprise.

New customers can contact MariaDB Corporation for more information.

Existing MariaDB Subscription customers can access technical support via the MariaDB Customer Portal as detailed in MariaDB Subscription Policy.

Validating Sums and Signatures

Use cryptographic hash sums and cryptographic signatures to validate the integrity and authenticity of a downloaded file.

Validating SHA256 sums

To check a known SHA256 cryptographic hash sum against the SHA256 of a file:

$ echo "b741361ea3a0a9fcaa30888a63ff3a8a4021882f126cf4ef26cf616493a29315  mariadb_es_repo_setup" \
    | sha256sum -c -

Validating signatures with YUM

To direct YUM (RHEL, CentOS) to validate cryptographic signatures, in /etc/yum.conf and each .repo file in /etc/yum.repos.d/ ensure this line DOES appear:

gpgcheck = 1

Validating signatures with APT

To direct APT (Debian, Ubuntu) to validate cryptographic signatures, ensure [trusted=yes] DOES NOT appear for any repository listed in the /etc/apt/sources.list configuration file or listed in the configuration files located in the /etc/apt/sources.list.d/ directory.

The cryptographic sums for trusted repositories are not checked.

To update the cache after changing the repository configuration: apt update

Validating signatures with ZYpp

To display the list of configured ZYpp repositories, including status of GPG checks for the repository: zypper repos

To enable GPG checks for a repository: zypper modifyrepo -g followed by the repository alias or name such as mariadb-es-server.

ZYpp may be globally configured for package validation via the repo_gpgcheck and/or pkg_gpgcheck in the ZYpp configuration file at: /etc/zypp/zypp.conf

Retrieve your Customer Download Token

MariaDB Enterprise Platform is available to MariaDB customers holding a valid entitlement.

New customers can contact MariaDB Corporation for more information.

Existing customers holding a valid entitlement can retrieve their Customer Download Token at:

Protect this token as you would protect any security credential.

Retrieve your Repository Configuration

MariaDB Corporation provides APT (Debian/Ubuntu) and YUM (RHEL/CentOS) repositories to entitled customers. Access to these repositories is dependent on your Customer Download Token.

Repository access details are used when installing from repository or creating a repository mirror.

To display APT, YUM, or ZYpp repository configuration:

  1. Download the mariadb_es_repo_setup utility:

    $ wget https://dlm.mariadb.com/enterprise-release-helpers/mariadb_es_repo_setup
  2. Validate the integrity of the download based on its SHA256 sum published here:

    $ echo "b741361ea3a0a9fcaa30888a63ff3a8a4021882f126cf4ef26cf616493a29315  mariadb_es_repo_setup" \
        | sha256sum -c -
  3. Set file permissions to enable execution:

    $ chmod -c +x mariadb_es_repo_setup
  4. Retrieve your Customer Download Token from https://customers.mariadb.com/downloads/token/

  5. Display the repository configuration:

    $ ./mariadb_es_repo_setup --token="CUSTOMER_DOWNLOAD_TOKEN"

Server Backup and Restore

Addition, removal, and change of database systems are types of production changes. Before undertaking any production changes:

  • Perform a backup of existing data and database configurations.

  • Establish a plan for data restoration for use in reverting a change.

  • Perform a test to confirm your backup is complete and viable.

Irreversible Changes


Installation of new database servers, change of server configuration, migrations, upgrades, and downgrades can produce irreversible changes which may require you to restore from the last good backup.

Changes to data format on disk, including from upgrades and downgrades, are generally irreversible. A fault during the upgrade or downgrade process may corrupt data. Confirm you have a recent, full, complete, and tested backup before any upgrade or downgrade operation.

When System-Versioned temporal data tables are in use, downgrade operations will generally require migration of data between servers or restore from a backup made pre-upgrade.

Full and Complete Backup

Before proceeding, perform a full and complete backup:

# mariabackup --backup \
      --user=mariabackup_user \
      --password=mariabackup_passwd \

Confirm successful completion of the backup operation and test the backup.

Business requirements may require you to retain backups made to support upgrade and downgrade operations.

Additional information regarding backing up and restoring the database may be found in the Recovery Guide.

Checking Server Status

Proper server operation may be checked using:

Checking Service Status

Supported OS platforms use systemd for service management.

To check service status on systemd-based systems:

# systemctl status mariadb.service

Checking for Server Process

To determine if a server process is running:

$ ps -ef | grep -e mysqld -e mariadb

Examining 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.


System Variable

Default Filename

Error Log



Audit Log



Slow Query Log



General Query Log



Binary Log



Examining systemd Journal and Runtime Status

To examine the systemd journal:

# journalctl -u mariadb

To examine the systemd runtime status:

# systemctl status mariadb.service -l

Testing via Server Connection

It can be diagnostically useful to confirm that you can connect to a server.

Ability to connect to a server is dependent on configuration. Some servers are subject to controls that prohibit access by server maintainers or otherwise restrict connection methods.

Where not limited, to connect via UNIX socket from the local server:

# mariadb

Where not limited, to connect to a remote server:

$ mariadb --host HOSTNAME --user USERNAME -p

Starting and Stopping

MariaDB Enterprise Server downloads include service files to allow you to start and stop MariaDB Enterprise Server. Supported OS platforms use systemd for service management.


Command for systemd-based systems


systemctl start mariadb.service

Start on boot

systemctl enable mariadb.service


systemctl stop mariadb.service

Do not start on boot

systemctl disable mariadb.service


systemctl restart mariadb.service

Check service status

systemctl status mariadb.service

Bootstrap a cluster node


Recover a cluster node's position


Considerations for MariaDB Enterprise Cluster

In MariaDB Enterprise Cluster, when the Server starts it attempts to establish network connectivity with the other Servers in the cluster. When it finds a Server, it checks whether the Server belongs to the Primary Component and if so it requests a state transfer to synchronize its local database with the cluster.

If the Cluster Node never finds the Primary Component, it remains non-operational and fails.

When the cluster is not running, you need to bootstrap the Primary Component on the first node you start.

This can be done using the galera_new_cluster script:

$ sudo galera_new_cluster

Once the Primary Component has been started, start all other Servers within a MariaDB Enterprise Cluster (using service or systemctl), as detailed in Starting and Stopping.