MariaDB Support and Consulting

MariaDB diverged from the MySQL code base a long time ago: its cluster architecture, its backup tool and its approach to encryption now differ from MySQL's, and support has to be given in full knowledge of that difference.

$ mariadb -e "SHOW GLOBAL STATUS LIKE 'wsrep_%'" | grep -E 'cluster_size|state_comment|flow_control'
wsrep_cluster_size 3
wsrep_local_state_comment Synced
wsrep_flow_control_paused 0.31
→ flow control engaged: a slow node is holding the whole cluster back

We manage your MariaDB systems end to end

MariaDB's tooling is its own. A backup procedure written for MySQL does not run here, and MySQL's cluster solution does not exist here. We run all four areas with MariaDB's own tools.

Performance tuning

MariaDB uses its own query optimiser; the same query can produce a different execution plan on MySQL. We examine plans on MariaDB itself, and arrange index design and memory allocation around the workload.

Galera Cluster

We design the installation, the node count and the state transfer (SST) strategy together. We watch flow control behaviour and prove failover scenarios by rehearsing them.

Backup and recovery

MariaDB uses mariabackup; Percona XtraBackup, developed for MySQL, does not run on current MariaDB versions. We provide physical backup with mariabackup and point-in-time recovery (PITR) through binary log archiving.

Security and technical measures

In MariaDB, encryption at rest and audit logging are part of the core server; there is no need to move to a separate distribution. We configure the file_key_management and server_audit components together with key management and a retention policy.

MariaDB is no longer a version of MySQL

MariaDB was born as a fork of the MySQL code base, and in the early years the two products were largely interchangeable. That period has passed. Today their query optimisers produce different plans, their handling of JSON data has diverged, their GTID implementations are not compatible with each other, and their high availability solutions rest on entirely different architectures.

The practical meaning of that divergence for support is plain: a procedure written for MySQL does not run unchanged on MariaDB. The backup script calls a different tool, the cluster installation rests on a different technology, and encryption comes from a different place. A significant share of the problems we see in the field arise from the two products still being taken for the same thing.

We consider a migration from MySQL to MariaDB possible, and we carry them out — but we plan them as a project with a compatibility survey and a rehearsal in a test environment, not as a driver change.

Galera Cluster: MariaDB’s answer for high availability

InnoDB Cluster and Group Replication do not exist in MariaDB; high availability is provided by Galera Cluster, which ships built into the server.

Galera works synchronously and on a certification basis. A transaction is not committed until it has reached every node in the cluster and passed conflict detection. The result is that no data is lost at the moment of failover. In return two behaviours have to be understood from the start.

Flow control. When a node cannot keep up with the cluster, the cluster slows down to keep it from falling behind. In a three-node installation the slowest node determines the write performance of the whole cluster. A single node with a slow disk or a different load pulls the other two down with it. That is why we watch wsrep_flow_control_paused regularly: a value moving markedly away from zero is the first sign that a node in the cluster cannot keep up.

Conflict handling. Every node can accept writes, but when the same row is written from different nodes, one of the transactions is rolled back at the certification stage and the application has to catch that error and retry. If the application is not prepared for it, a multi-writer installation produces stability problems. On most production systems we recommend a design that concentrates write traffic on a single node; availability stays the same, and behaviour becomes predictable.

The third decision in the installation is state transfer: a node newly joining the cluster, or one that has been away for a long time, takes the data from scratch with a full state transfer (SST). The operation takes time in proportion to the data volume, and it occupies the node chosen as the donor. We plan which node that will be and when the transfer will happen.

We build traffic routing on the application side with ProxySQL; it is open source licensed and runs in front of MariaDB and Galera installations. For a comparison of the topologies and the failover rehearsals: High Availability and Cluster Solutions · ProxySQL Support and Consulting

Backup: XtraBackup does not run on MariaDB

Physical backup on MariaDB is done with mariabackup. The tool is a fork of Percona XtraBackup and is distributed with the MariaDB server; XtraBackup itself does not run on current MariaDB versions.

That detail looks small and turns out expensive. On installations where a backup procedure written for MySQL has been carried over to a MariaDB server unchanged, the script errors; if the error is not monitored, nobody notices that no backup is being taken, and the gap surfaces at the first recovery attempt.

For logical backup needs, mariadb-dump comes in, and mydumper, which can run in parallel, on large data sets. To return to a specific moment we configure binary log archiving, and that is how point-in-time recovery (PITR) is provided.

The backup architecture itself — setting the RTO and RPO targets, designing the backup types together, and running automated restore tests — is a discipline independent of the tool and is covered under its own heading: Database Backup and Recovery

Encryption and audit logging come with the core server

This is MariaDB’s clearest advantage over MySQL Community Edition: encryption at rest and audit logging come with the server. Where the same capabilities on the MySQL side require a move to the Percona Server distribution, on MariaDB no distribution change arises at all.

Encryption is configured with the file_key_management component, and the weight of the work lies not in enabling the component but in key management. An installation where the encryption key is stored unprotected on the database server largely defeats the purpose of encrypting. We design where the key is stored, who can reach it, and how it is rotated as part of the installation.

Audit logging is kept with the server_audit component. Where the records are written, how long they are kept and who can reach them are designed separately; audit records themselves contain personal data and therefore have to be protected. For the full set of technical measures auditors ask for: Database Security and Technical Measures

The storage engine choice is made by measuring

MariaDB offers more than one storage engine. InnoDB is the default and is the right choice on the large majority of production systems. Aria is used for the server’s own temporary tables. ColumnStore provides column-based storage for analytical queries, and Spider distributes tables across more than one server.

We assess the alternative engines, but we do not recommend one without measurement. Going outside the default raises the operational cost: backup behaviour, the locking model and Galera compatibility all change with the engine. Galera replicates only transactional tables; data held on a non-transactional engine does not stay consistent across the cluster. For that reason we assess an engine change together with the architecture.

Version policy

MariaDB patches its long-term support (LTS) versions for years, while the support period for short-cycle releases is markedly shorter. On production systems we do not recommend going outside LTS. Staying on a short-cycle release turns an unplanned upgrade into a necessity the moment a security patch is needed.

On systems we take on, we establish the support status of the current version and plan the upgrade calendar. On Galera installations we carry upgrades out node by node, without stopping the cluster entirely.

How we work

We connect to your systems remotely under a non-disclosure agreement (NDA). We define only the privileges the work requires for the database user, and we record every change we apply.

When we take on a system for the first time, we establish the current state: version and support status, Galera cluster health and flow control history, the state of backup and restore, the encryption and audit logging configuration, and the query profile of the workload. The recommendations are built on that measurement.

We carry out the same work for MySQL, PostgreSQL and MongoDB: MySQL Support · PostgreSQL Support · MongoDB Support

Frequently asked questions

It was in the early versions; it is not today. The two products have been developed separately for a long time. Their query optimisers, their handling of the JSON data type, their GTID implementations and their cluster solutions have all diverged. Setting up replication from MySQL 8.0 to MariaDB is not supported either. We consider the migration possible, but we plan it as a project with a compatibility survey and a rehearsal in a test environment, not as a driver change.

No. InnoDB Cluster and Group Replication are components of Oracle's MySQL distribution and do not exist in MariaDB. MariaDB's answer for high availability is Galera Cluster, which ships built into the server. The two architectures reach a similar outcome by different routes; Galera works synchronously and on a certification basis, and the application's write pattern directly affects the design.

Technically you can; on most production systems we do not recommend it. When the same row is written from different nodes, the conflict is detected at the certification stage and one of the transactions is rolled back — the application has to catch that error and retry. If the application is not prepared for it, a multi-writer installation produces stability problems. A design that concentrates write traffic on a single node gives the same availability with far more predictable behaviour.

It does not run on current MariaDB versions. MariaDB ships its own fork, mariabackup, with the server, and physical backup is done with that tool. Carrying a backup procedure written for MySQL over to MariaDB unchanged is one of the faults we meet in the field: the backup script errors, and if nobody notices, the gap surfaces at the first recovery attempt. On every system we take on, the first thing we verify is that the backup is really being taken and can be restored.

It does not, and this is one of MariaDB's clear advantages over MySQL Community Edition. Encryption at rest and audit logging come with the MariaDB server; there is no need to move to a separate distribution. The work focuses less on enabling the components than on getting key management right: an installation where the encryption key is stored unprotected on the database server largely defeats the purpose of encrypting at all.

On production systems we do not recommend going outside the long-term support (LTS) versions. MariaDB patches versions marked LTS for years, while the support period for short-cycle releases is markedly shorter; staying on a short-cycle release turns an unplanned upgrade into a necessity the moment a security patch is needed. We establish the support status of your current version and plan the upgrade calendar together.

Send us your MariaDB support request