The MinervaDB Difference
Why Enterprises Trust MinervaDB for MariaDB Support
MariaDB carries an enormous amount of transactional weight — order capture, payments, subscription billing, identity, inventory, telemetry and the event tables behind analytics pipelines. It earns that position by being fast, predictable and honest about its trade-offs when it is configured for the workload it actually carries. It becomes hostile when it is not: undo grows behind a forgotten transaction, a Galera node falls into flow control during a nightly batch, an ALTER TABLE locks a hot table at peak, and an optimizer plan flips overnight because engine-independent statistics drifted. None of these announce themselves as MariaDB problems. They surface as checkout timeouts and angry dashboards.
MinervaDB exists for exactly that gap. Our MariaDB Support practice is staffed by engineers who read source code, reproduce failures on instrumented hardware, and refuse to change a production variable without evidence. We have carried pagers for high-write ledgers, multi-terabyte fleets on Kubernetes, sharded Spider deployments and ColumnStore analytics estates serving hundreds of thousands of queries per second. Every recommendation we make is measurable, reversible and documented — because that is the only kind of recommendation worth acting on at three in the morning.
Principal engineers, not ticket queues
The person who answers your severity 1 page is a MariaDB specialist with production ownership experience. There is no tier-one script layer to negotiate past before someone competent reads your error log.
Evidence before opinion
We baseline with performance_schema, the slow query log, InnoDB metrics, wsrep status and ANALYZE FORMAT=JSON output. Then we change one thing, measure it, and keep or revert it. Nobody on our team tunes MariaDB from a blog post.
Fluent in the whole MariaDB ecosystem
Community server, MariaDB Enterprise Server, Galera Cluster, MaxScale, ColumnStore, Spider, MyRocks, Amazon RDS for MariaDB and Kubernetes operators. We recommend what fits your workload and budget.
Availability that has been rehearsed
A failover design is a hypothesis until it has been executed under load with a stopwatch. Our MariaDB Support engagements include game days, timed switchovers and runbooks your own team can follow.
Performance as an engineering discipline
Index design, query rewriting, schema shape, optimizer inputs, storage engine choice and device latency are treated as one system. We fix the cause of a slow query, not the symptom in a dashboard.
Knowledge transfer, not dependency
Every incident produces a written root cause analysis. Every change produces documentation. Our best outcome is an internal team that needs us less each quarter.
Architecture
How a MariaDB Server Actually Behaves Under Load
Effective MariaDB Support starts with an accurate mental model of the server. MariaDB is a layered system: a connection and thread-handling tier, a SQL layer that parses, costs and executes statements, and a set of pluggable storage engines — in practice InnoDB for transactional work, with Aria, MyRocks, ColumnStore, Spider and the S3 engine available for workloads InnoDB was never designed to carry. Almost every production incident we are called into is explained by one of the boundaries between those layers rather than by any single component in isolation.
The diagram below is the map we work from during a MariaDB Support engagement. Client sessions arrive through MaxScale or an application pool, are admitted by the thread pool, and their statements are parsed, costed against engine-independent statistics and executed through the handler interface. Every row read or written in InnoDB is a 16 kB page in the buffer pool.
Every commit becomes a redo record and, when binary logging is enabled, a binary log event. Background threads flush dirty pages, fsync the redo log, purge undo history and ship events to replicas or to the Galera writeset cache. When any of those pipelines falls behind, the symptom appears in the application long before it appears in a status variable someone is watching.
The configuration parameters that decide most outcomes
There is no universal MariaDB configuration, but there is a small set of variables that determines whether an instance behaves predictably. We derive these from your real workload shape — read/write ratio, working set size, concurrency, transaction duration and storage latency — rather than from a generic calculator. Each variable is documented in the MariaDB server system variables reference, but the shipped defaults are deliberately conservative and assume nothing about your hardware.
| Variable | What it governs | How MinervaDB approaches it |
|---|---|---|
| innodb_buffer_pool_size | The in-memory page cache for data and index pages | Sized against the measured working set rather than a blanket percentage of RAM. On dedicated hosts we typically land between 60% and 75%, then verify with buffer pool hit ratio, free page trend and physical read rate instead of assuming. |
| innodb_log_file_size and innodb_log_files_in_group | Total redo capacity, which bounds checkpoint pressure | Large enough that checkpoints are smooth rather than spiky. Undersized redo shows up as periodic write stalls that look exactly like a storage fault and are not. |
| innodb_flush_log_at_trx_commit | Whether each commit is durable on disk | Set to 1 for anything resembling a ledger. We relax it only when the data is genuinely rebuildable, and we document the loss window in seconds rather than leaving it as folklore. |
| sync_binlog | How often the binary log is fsynced | Set to 1 alongside the above so a crashed primary can never hand a replica events it has forgotten. Group commit keeps the throughput cost far lower than most teams expect. |
| innodb_io_capacity and innodb_io_capacity_max | How aggressively dirty pages are flushed | Calibrated to measured device IOPS, never left at the default. Too low produces flush storms and LRU stalls; too high steals I/O the foreground workload needs. |
| innodb_flush_method | How InnoDB interacts with the operating system page cache | O_DIRECT on Linux for any real storage stack, to stop double buffering and make latency legible in the first place. |
| thread_handling and thread_pool_size | How concurrency is admitted into the server | MariaDB’s built-in thread pool is one of its genuine operational advantages. We use it, size it to CPU topology, and keep MaxScale or the driver pool bounded so the server never sees thousands of contending threads. |
| innodb_purge_threads and innodb_max_purge_lag | How quickly undo history is reclaimed | Raised on high-churn workloads and always paired with monitoring of history list length, so purge lag becomes visible long before it becomes an outage. |
| optimizer_switch, optimizer_use_condition_selectivity, join_cache_level | Which optimizer strategies and estimates are available | Reviewed as a set. MariaDB has genuinely useful features here — hash joins, condition pushdown, subquery materialisation — but they must be validated against your plans instead of enabled on faith. |
| use_stat_tables and histogram_size | Engine-independent statistics and histograms | Enabled with a refresh cadence, and histograms added on skewed columns. Plan stability is a statistics problem far more often than it is an optimizer problem. |
| tmp_table_size, sort_buffer_size, join_buffer_size | Per-operation memory for sorts, joins and temporary tables | Kept modest and fixed by better indexing. Inflating per-session buffers to hide a bad plan is how servers get killed by the OOM reaper. |
| table_open_cache and table_definition_cache | Metadata caching for large schemas | Raised deliberately on multi-tenant estates with tens of thousands of tables, where the default causes measurable open and close churn. |
Service Scope
Full-Stack MariaDB Support Services
Our MariaDB Support subscriptions are deliberately broad, because production problems do not respect organisational boundaries. A slow checkout may be an index, a lock, a Galera flow-control pause, a kernel setting or a connection pool — and you should not have to diagnose which one before you are allowed to call someone.
24×7 incident response and emergency MariaDB DBA cover
A named engineer answers, acknowledges within the contracted window, and works the incident until the service is stable. We take control of the diagnosis: error log, InnoDB status, lock graph, wsrep cluster state, open transaction list and replication position are captured before anything is restarted, so the root cause survives the recovery.
Performance engineering and query optimisation
Continuous review of your slowest and most frequent statements. We work from ANALYZE FORMAT=JSON, performance_schema digests, the slow query log and optimizer traces to fix index design, query shape, data types and optimizer inputs — then quantify the improvement in p95 latency and rows examined per row returned.
Galera Cluster and high availability engineering
Multi-master Galera design across availability zones, or asynchronous replication with MaxScale-managed automatic failover. We specify quorum weighting, gcache sizing, SST method, fencing and routing, then rehearse the failure with a stopwatch until the numbers are boring.
Backup, recovery and disaster readiness
Physical backup strategy with mariabackup, logical dumps where granularity matters, and continuous binary log archiving for point-in-time recovery. We restore your backups on a schedule, because a backup you have never restored is a hypothesis rather than a control.
Upgrades, migrations and schema change engineering
Major version upgrades across the MariaDB LTS series with compatibility analysis and rehearsed rollback, migrations from MySQL or Oracle into MariaDB with row-level validation, and online schema changes on tables far too hot to lock.
Monitoring, capacity and proactive review
We instrument what predicts incidents — history list length, checkpoint age, wsrep flow-control pauses, replication lag distribution, buffer pool churn, lock wait time — and hold a scheduled technical review where we walk your team through trends, risks and the capacity runway ahead.
Galera Cluster
Galera Cluster Support: Synchronous Replication Without the Folklore
Galera Cluster is the feature most enterprises adopt MariaDB for, and the one most often deployed on assumptions that do not survive contact with production. It is genuinely synchronous in the part that matters: a transaction is not acknowledged until it has been ordered and certified across the cluster, so there is no window in which a committed write exists on one node only. It is also emphatically not a way to make writes faster, and it is not a substitute for backups.
A large share of the Galera work we do under MariaDB Support is correcting three specific misunderstandings. The first is that adding nodes increases write throughput; it does not, because every node must certify and apply every writeset, so the cluster runs at the speed of its slowest member.
The second is that apply is asynchronous and therefore harmless; the applier queue is bounded by flow control, and once gcs.fc_limit is reached the whole cluster pauses writes until the laggard catches up. The third is that gcache size is a tuning detail; it decides whether a rebooted node rejoins in seconds through incremental state transfer or spends hours copying the entire dataset.
Certification is the whole story
When a transaction commits on any node, its changed rows are collected into a writeset identified by primary key and broadcast to every member in total order. Each node independently certifies that writeset against the transactions already ordered ahead of it.
If two nodes modified the same row concurrently, the later one fails certification and the originating client receives a deterministic deadlock error — the write is committed everywhere or nowhere. This is why a table without an explicit primary key cannot be replicated safely, why very long transactions are dangerous in a cluster, and why hot-row workloads see conflict rates that surprise teams migrating from a single primary.
| Galera design decision | When we recommend it | What we verify |
|---|---|---|
| Three or five members with zone-aware placement | Any cluster whose purpose is surviving the loss of a node or a zone without human intervention | That a deliberate network partition leaves the minority side Non-Primary and unavailable rather than writable, verified by attempting a write against it |
| gcache.size sized to peak write volume | Always, and revisited whenever write volume changes materially | That a node stopped for the length of a realistic maintenance window still rejoins by incremental state transfer instead of falling back to a full snapshot |
| wsrep_sst_method = mariabackup | Any cluster where a donor cannot afford to block during provisioning | That an SST completes under production load, and that the donor continues serving queries throughout |
| wsrep_slave_threads tuned to real headroom | Clusters where apply throughput, not network, is the constraint | Applier queue depth, flow-control pause time and the ratio of parallel to serialised commits under batch load |
| wsrep_sync_wait for causal reads | Applications that read their own writes through a router or a different node | That the latency cost is understood per statement class, and that it is enabled only where correctness actually requires it |
| Segmented clusters for multi-region | Geographically distributed deployments where replication traffic must not cross regions repeatedly | Segment configuration, inter-segment traffic volume, and that commit latency across regions is acceptable to the application rather than merely tolerable |
| An asynchronous replica attached to the cluster | Nearly always, for backups, reporting and point-in-time recovery | That the replica is excluded from write routing, that its GTID position is consistent, and that backups are taken there instead of from a cluster member under load |
Replication
Replication Lag Is a Design Problem, Not a Weather Event
Asynchronous replication remains the load-bearing wall of most MariaDB architectures, including most Galera deployments. It carries read scale-out, reporting isolation, cross-region redundancy and — through delayed replicas — protection from human error. It is also the component teams understand least precisely, which is why “the replica is lagging” is one of the most common reasons an organisation first contacts us for MariaDB Support.
Lag is not random. It accumulates in exactly three places, and each has a different fix. The receiver thread can be network or CPU bound; the applier can be serialised by transaction dependencies or by row events with no usable index; or the replica’s own storage, memory and competing read traffic can simply be slower than the source it is trying to keep up with. Treating all three as one number is why so much replication tuning fails.
Parallel apply, done properly
MariaDB implements parallel replication differently from MySQL, and the difference matters. Its GTID carries a replication domain, so genuinely independent workloads can be applied concurrently by domain, while slave_parallel_mode controls how aggressively transactions within a domain are attempted out of order. Optimistic modes speculatively apply and roll back on conflict, which is a large win on workloads with few real dependencies and a loss on workloads with many.
We choose the mode from measurement, size the worker pool to the replica’s real CPU and I/O headroom, and preserve commit order wherever the application reads its own writes. On workloads dominated by a handful of enormous transactions we change the transaction boundaries in the application instead, because no amount of applier concurrency parallelises a single forty-million-row DELETE.
| Replication design decision | When we recommend it | What we verify |
|---|---|---|
| GTID-based replication | Effectively always on new builds, and as a prerequisite for any automated failover or MaxScale-managed switchover | That GTID positions are consistent across the topology, that domain IDs are assigned deliberately, and that nothing writes to a replica outside replication |
| slave_parallel_mode with a tuned worker pool | Any replica that must stay within seconds of the source under batch load | Applied transactions per second, applier queue depth, rollback rate in optimistic mode, and the ratio of parallelised to serialised commits |
| Multiple replication domains | Estates where independent workloads share one server and must not block each other | That domain assignment matches genuine independence, and that failover tooling understands the multi-domain GTID position |
| Semi-synchronous replication | When the recovery point objective is effectively zero but the cost of a full Galera quorum is not justified | Acknowledgement latency distribution, timeout behaviour when a replica dies, and that a stalled replica cannot stall the business |
| Delayed replica at one hour or more | Any system where a bad migration or an unguarded DELETE is a realistic risk | That the delayed replica can be promoted, and that your team has practised extracting a single table from it under time pressure |
| Multi-source replication | Consolidating several sources onto one reporting or archive target | Channel isolation, independent lag tracking per connection, and that one bad channel cannot block the others |
| Read routing by measured lag | Read scale-out where slightly stale reads are acceptable | That MaxScale removes a replica from rotation on a lag threshold rather than after users complain about stale data |
High Availability
Failover That Has Been Rehearsed, Not Assumed
Every organisation we provide MariaDB Support to believes it has high availability. Rather fewer can state, from a measurement rather than an estimate, how long a primary failure takes to become invisible to their application. The gap between those two positions is where outages live. Automatic failover is not one feature; it is a chain of failure detection, election, fencing, connection routing and application retry behaviour, and the chain is exactly as strong as its weakest link.
We design for a specific, testable number. With MaxScale’s mariadbmon monitor performing detection, election by GTID position, fencing of the demoted primary and automatic rejoin of survivors — and with drivers that retry idempotent work — a total recovery time of fifteen to thirty seconds with zero committed-data loss is routinely achievable on asynchronous topologies. With Galera the recovery is faster still, because the surviving members already hold the data and the question is only how quickly routing converges. The constraint is almost never MariaDB itself: it is whether the surrounding automation, routing and rehearsal discipline exist.
| Layer | Failure it removes | How we implement and prove it |
|---|---|---|
| Quorum or candidate topology across zones | Split brain during a network partition, and promotion of a stale replica | Three or five Galera members with weighted placement, or an asynchronous topology with explicit promotion candidates ranked by GTID freshness, then a deliberate partition test |
| Fencing of the demoted primary | Two servers accepting writes at the same time | read_only and super_read_only enforced on demotion plus removal from the MaxScale routing set, verified by attempting a write against the old primary |
| State-based connection routing | DNS TTL guesswork and stale application connection pools | MaxScale probing live server state, with a measured time from election to first successful write through the router |
| Application retry semantics | User-visible errors during a perfectly successful failover | Driver-level retry with an idempotency review of write paths, tested by killing the primary during a synthetic load run |
| Automatic rejoin and reprovisioning | A survivor that never comes back, or comes back inconsistent | auto_rejoin validated against a real crash, plus a verified fallback to mariabackup provisioning when rejoin is refused |
| Rehearsal and runbooks | The failover that only works when the person who built it is awake | Quarterly game days under production-like load, timed, documented, and executed by your engineers with us observing |
Storage Engines
One Server, Several Engines: Choosing Correctly Is a MariaDB Support Decision
The pluggable storage engine architecture is what separates MariaDB from most of its peers, and it is a genuine engineering advantage when used deliberately. It is also a way to create operational problems that are invisible until the first restore. Engines differ in transactional guarantees, locking granularity, on-disk structure, compression behaviour, crash recovery and backup compatibility — which means the engine you choose changes not only query performance but your recovery point objective.
We treat engine selection as an architectural decision with evidence attached. InnoDB remains the default and the correct answer for almost all transactional work. MyRocks earns its place where ingest volume and storage cost dominate. ColumnStore removes entire nightly export pipelines by keeping analytical aggregation inside the same server. Aria quietly underpins internal temporary tables whether you chose it or not. Spider and the CONNECT and S3 engines solve distribution and archival problems that would otherwise require separate infrastructure.
| Engine | Transactional behaviour | Where it belongs, and what it costs |
|---|---|---|
| InnoDB | Full ACID, MVCC through undo, row-level locking | The default for OLTP and anything requiring rollback, foreign keys or point-in-time recovery. Wide random primary keys are its main self-inflicted wound, because every secondary index carries them. |
| MyRocks | Transactional, MVCC, LSM tree on disk | High-volume ingest and space-constrained fleets: telemetry, events, message history. Expect materially better compression and write amplification than InnoDB, and slower unindexed range access. |
| ColumnStore | No row-level transactions | Aggregation across billions of rows without exporting to a separate warehouse. Excellent for scans and grouping, entirely wrong for single-row updates and OLTP concurrency. |
| Aria | Not transactional, but crash-safe | Internal temporary tables, system tables and read-mostly reference data. Table-level locking makes it a poor choice for concurrent writes, and teams often discover they depend on it only when tmpdir fills. |
| Spider | Delegated to the backend nodes | Transparent horizontal partitioning across independent MariaDB servers. Cross-shard joins and distributed transaction semantics require deliberate design rather than optimism. |
| CONNECT and S3 | External or read-only | Cold partitions kept queryable at object-store cost, and direct access to external files or remote engines. Latency and the absence of writes are the trade-offs, and both must be reflected in your retention design. |
A mixed-engine estate is a legitimate architecture, but it changes your operational surface. mariabackup handles InnoDB, Aria and MyRocks differently, ColumnStore has its own backup path, and logical dumps are not interchangeable with physical ones. Part of our MariaDB Support work is making sure the backup and restore strategy matches the engines actually in use — not the engines the runbook was written for.
The Quiet Failure Mode
The Problem That Slowly Ends MariaDB Deployments
InnoDB is a multi-version storage engine. An UPDATE does not overwrite the old row for every reader; it writes the new version and preserves the previous one in undo, so transactions holding an older read view still see a consistent snapshot. Purge threads reclaim that undo once no read view needs it. The whole mechanism is elegant, invisible and entirely dependent on transactions ending.
When one session sits idle inside an open transaction, purge cannot advance past it. Undo grows, the history list lengthens, and every read starts walking longer version chains to return the same result. CPU rises with no change in traffic. Disk consumption climbs. Crash recovery time grows with the history list.
In a Galera cluster the damage compounds, because a long-running transaction also widens the certification window and increases conflict rates across every node. Nothing in the application changed, nothing looks busy, and the server gets progressively worse. This single pattern is responsible for more emergency MariaDB Support calls than any other, and it is almost always caused by application code holding a transaction open across a network call or a user’s think-time.
What we monitor so it never becomes an incident
We alert on the trend of history list length rather than an absolute threshold, on the age of the oldest open transaction from information_schema.innodb_trx, and on undo tablespace growth. We tune purge thread count and batch size, separate undo tablespaces with automatic truncation, and where necessary use purge lag throttling so writers slow down before undo becomes unmanageable.
Then we fix the actual cause: transaction scope in the application, a kill policy for idle-in-transaction sessions, bounded chunking for large DML, and long analytical queries moved off the primary entirely — to a replica, or to ColumnStore if the query was always an analytical one wearing OLTP clothing.
Performance
MariaDB Performance Tuning Is an Engineering Discipline
There is no configuration file that makes a badly indexed query fast, and there is no amount of hardware that permanently outruns an unbounded table scan. Performance work under a MinervaDB MariaDB Support engagement follows the same sequence every time: establish what the workload actually does, find where time is genuinely spent, form a hypothesis, change one thing, and measure whether reality agreed.
That discipline matters because MariaDB offers many plausible-sounding levers that do nothing for the problem in front of you. Increasing sort_buffer_size will not repair a missing composite index. Adding CPU will not fix a query examining four million rows to return nine. Enabling every optimizer feature will not compensate for statistics that were last refreshed before the data doubled.
Our job during MariaDB Support work is to identify which of the small number of real causes is active — a wrong index, a bad cardinality estimate, row or metadata lock contention, buffer pool pressure, temporary tables spilling to disk, Galera certification conflict, or replication apply contention — and then to change exactly that.
| Symptom | Usual real cause | What MinervaDB does |
|---|---|---|
| One query is slow only sometimes | Plan instability from stale or missing engine-independent statistics, or a parameter-sensitive plan | A statistics refresh cadence, histograms on skewed columns, and where justified an index or a rewrite that removes the ambiguity rather than a hint that hides it |
| Everything is slow at the same time each night | A batch job competing for buffer pool and I/O, or checkpoint pressure from undersized redo | Workload separation, chunked batch DML, redo capacity and flush tuning, and moving reporting to a replica or to ColumnStore |
| High CPU with flat traffic | Long undo chains behind an old read view, or repeated full scans that happen to fit in memory | Transaction scope repair and purge tuning first, then index work driven by rows examined per row returned |
| Writes intermittently stall | Flush storms from a mis-set io_capacity, dirty page spikes, or doublewrite on slow storage | Calibrated io_capacity, adaptive flushing review, measured device latency, and correct redo sizing |
| Lock wait timeouts under peak | Wide transaction scope, gap locks from a non-unique search, or genuine hot-row contention | Isolation level and index review to narrow lock ranges, shorter transactions, and where appropriate application-level queueing |
| Deadlock errors appear only after moving to Galera | Certification conflicts on rows updated concurrently on different nodes | Write routing to a single node for hot tables, narrower transactions, and application handling of deterministic conflict errors |
| Connection storms and thread thrash | No effective pooling, so thousands of threads contend for the same latches | MariaDB’s thread pool enabled and sized, with bounded pooling in MaxScale or the driver so the server sees an efficient number of active threads |
| A replica lags only during migrations | A single-transaction schema change, or row events replayed serially against a table with no usable index | Online schema change tooling, parallel replication mode review, and primary key coverage on every replicated table |
Backup and Recovery
A Backup You Have Never Restored Is Only a Hypothesis
Backups are the one part of a MariaDB estate whose value is entirely unproven until the worst day. We treat them as an engineering control with two measured numbers attached: a recovery time objective established by actually restoring onto representative hardware, and a recovery point objective established by tracking how far behind the binary log archive can fall.
Point-in-time recovery is the capability most teams assume they have and comparatively few have exercised. It requires a physical backup you can prepare, incremental deltas that apply cleanly in order, and an unbroken binary log archive. We rehearse the whole chain — restore the full, prepare and apply incrementals, replay binary logs to a stop-datetime, stop-position or the GTID immediately before the mistake, verify with row counts and table checksums, and only then repoint the application. Every MinervaDB MariaDB Support client gets that rehearsal on a schedule, with the elapsed time written down and compared against the objective they signed up to.
Galera changes what a backup is for, not whether you need one
A three-node cluster survives node loss without a restore, which is precisely why cluster operators drift into treating replication as backup. It is not. Galera replicates the destructive DELETE as faithfully as it replicates everything else, and it does so synchronously. We take physical backups from an asynchronous replica attached to the cluster rather than from a member under load, keep the binary log archive independent of the cluster, and maintain a delayed replica wherever the realistic failure mode is human rather than mechanical.
| Failure scenario | Recovery approach | What has to be true in advance |
|---|---|---|
| A cluster member is lost | Automatic continuation on surviving members, then rejoin by incremental state transfer | Quorum members in other zones, gcache sized for realistic outage length, and a verified mariabackup SST fallback |
| Primary host lost on an asynchronous topology | MaxScale-managed failover to the freshest promotion candidate | Ranked candidates, fencing on the old primary, and health-check based routing that has been timed |
| A table dropped, or a DELETE without a WHERE clause | Point-in-time recovery to the moment before the statement, extraction from a delayed replica, or flashback of the row events | Binary logs archived continuously in ROW format, and a delayed replica if minutes matter more than hours |
| Silent logical corruption found days later | Restore to a parallel instance from the relevant backup generation and reconcile the affected rows | Retention long enough to cover realistic discovery lag, plus checksum tooling that can compare two instances |
| A whole region becomes unavailable | Promote a cross-region replica or segment and accept the documented recovery point | Cross-region replication with measured lag and a promotion runbook that has actually been executed |
| Storage-level page corruption | Restore the affected tablespace and replay, or rebuild the member from a healthy node | Page checksums and doublewrite enabled, plus alerting on InnoDB corruption messages in the error log |
| The backup itself is unusable | Fall back to the previous verified generation | Every generation restored and validated on a schedule, not merely reported as successful by a cron job |
Observability
Instrumentation That Predicts Incidents Instead of Narrating Them
Most MariaDB monitoring is retrospective. It tells you convincingly that the database was slow at 14:07, which you already knew from the support queue. Useful instrumentation is different: it watches the small set of internal signals whose trend precedes an incident, and it alerts on the trend rather than on the eventual symptom. This is a standard part of every MariaDB Support engagement we run, and it is usually the change that ends the pattern of surprise outages.
| Signal | Why it predicts trouble | Where we read it |
|---|---|---|
| History list length | Rising undo means purge is losing ground; reads slow and crash recovery time grows before anything errors | SHOW ENGINE INNODB STATUS and Innodb_history_list_length |
| Age of the oldest open transaction | A single idle-in-transaction session is the root cause of most gradual degradation | information_schema.innodb_trx joined to the thread and process list |
| Checkpoint age against redo capacity | Approaching the async flush limit means imminent write stalls | InnoDB log sequence numbers and checkpoint metrics |
| wsrep flow-control pause time | A Galera cluster pausing writes for the slowest applier is the earliest sign of an unbalanced member | wsrep_flow_control_paused, wsrep_local_recv_queue_avg and wsrep_cert_deps_distance |
| Certification failure rate | Rising conflict means write routing or transaction scope needs to change before users see errors | wsrep_local_cert_failures and wsrep_local_bf_aborts |
| Buffer pool hit ratio and free page trend | A working set outgrowing memory shows here weeks before latency moves | Innodb_buffer_pool_reads against read_requests, plus free page counts |
| Rows examined per row returned | The single best proxy for index and plan quality across the whole workload | performance_schema statement digests and the slow query log |
| Replication apply queue and lag distribution | Averages hide the batch window where lag spikes; a distribution does not | Replica status, relay log position deltas and parallel worker state |
| Lock wait time and deadlock rate | Rising contention predicts the peak-hour timeout storm | performance_schema lock tables and the InnoDB deadlock log |
| Temporary tables written to disk | Sorts and joins spilling to disk indicate an indexing or memory design gap | Created_tmp_disk_tables against Created_tmp_tables |
| Aborted connections and thread pool queueing | Pooling problems, network faults and admission control issues surface here first | Aborted_connects, Aborted_clients and thread pool status variables |
Security and Compliance
MariaDB Security Engineered for Audit, Not for Appearance
Database security tends to be assessed by questionnaire and implemented by hope. Our MariaDB Support engagements treat it as configuration with evidence: what is encrypted, who holds which privilege, what is logged, and how quickly you could answer an auditor asking who read a particular table last quarter.
Encryption in transit and at rest
TLS enforced with require_secure_transport and per-account requirements, a modern cipher policy, and InnoDB tablespace and binary log encryption through the file_key_management or a KMS-backed key plugin that survives host replacement.
Privilege minimisation
Roles instead of per-user grants, no application account holding SUPER or unnecessary global privileges, and a review process that removes access which no longer has an owner.
Authentication that fits your estate
ed25519 or caching_sha2_password as the default, PAM, LDAP or GSSAPI and Kerberos where central identity is required, and password rotation that does not require an outage.
Auditing that answers real questions
The server_audit plugin scoped to the statements and objects that matter, shipped off-host so a compromised server cannot rewrite its own history.
Surface reduction
local_infile disabled, network binding restricted, no anonymous or test accounts, symbolic links off, secure_file_priv constrained deliberately, and MaxScale used to keep the database off the application network entirely.
Regulated-workload experience
Estates operating under PCI DSS, HIPAA, SOC 2 and GDPR obligations, where we supply the configuration evidence your auditors ask for rather than a policy statement.
MaxScale is frequently the most cost-effective security control available to a MariaDB estate: result-set masking for sensitive columns, a database firewall that rejects statement shapes no application should ever send, and the ability to keep every backend server on a private network with no direct client route.
Coverage
MariaDB Support Across Every Version and Deployment Model
We support MariaDB where it actually runs, which is rarely one place. A typical estate we take on has a 10.3 or 10.4 instance nobody has dared to touch, a fleet of 10.6 servers on cloud virtual machines, a Galera cluster somebody built from a tutorial, a managed service with slightly different tuning knobs, and something on Kubernetes that an application team stood up without telling anyone.
MariaDB 11.4 LTS
The current long-term series, including the replication, optimizer and default changes that break older automation
MariaDB 10.11 LTS
Widely deployed and well understood, and the usual target for estates leaving end-of-life versions
MariaDB 10.6 LTS
Still the workhorse of many fleets, with Atomic DDL and InnoDB behaviour we know intimately
MariaDB 10.4 and 10.5
Past or approaching end of life and still in production everywhere. We support them and plan the exit rather than pretending they are fine
MariaDB Enterprise Server
Enterprise builds, backported fixes and the operational differences from community releases
Galera Cluster
Multi-master synchronous clusters, segmented multi-region deployments and provisioning at scale
MariaDB MaxScale
readwritesplit and readconnroute routing, mariadbmon failover, masking, firewall and query caching
MariaDB ColumnStore
Columnar analytics inside the same estate, replacing fragile nightly export pipelines
Amazon RDS for MariaDB
Managed-service constraints, parameter groups and the diagnostics that remain available to you
Kubernetes operators
StatefulSet storage classes, operator-driven failover and the behaviour that differs from bare metal
Spider and sharded fleets
Horizontal partitioning, resharding operations and cross-shard query behaviour
Bare metal and virtualised
NUMA placement, kernel and filesystem tuning, and storage that behaves differently from its datasheet
Upgrades and Migrations
Upgrades, Migrations and Schema Changes Without the Weekend Outage
Version upgrades and schema changes are where otherwise careful teams accept risk they would never accept elsewhere. A major MariaDB upgrade can change optimizer defaults, system table layout, authentication behaviour, reserved words and replication compatibility in the same release. A single ALTER TABLE on a hot 400 GB table can hold a metadata lock long enough to stall an entire checkout path, and inside a Galera cluster the wrong DDL strategy can pause writes across every node at once. Neither of these needs to be a gamble.
Migrating from MySQL to MariaDB
MariaDB and MySQL diverged years ago, and the differences that matter in a migration are rarely the ones highlighted in feature comparisons. Authentication plugins, JSON type semantics, GTID formats, invisible column behaviour, default collations, system versioning and the exact optimizer defaults all need to be assessed against your application rather than assumed compatible. We run that assessment, build the target with configuration derived from your real workload, seed it and replicate from MySQL until lag is stable, reconcile every table with checksums rather than samples, and then cut over behind a router with a tested path back for a defined period afterwards.
Online schema change on tables that cannot be locked
MariaDB’s in-place and instant DDL support covers more cases than most teams realise, and we always test whether the change qualifies before reaching for tooling. When it does not, we use gh-ost or pt-online-schema-change with throttling tied to replication lag and primary load, so the migration slows itself down instead of taking the site with it. In a Galera cluster we choose between total order isolation and rolling schema upgrade explicitly, because the first pauses the cluster for the duration of the DDL and the second temporarily allows schema divergence — and the correct answer depends entirely on the change and the application.
| Change type | Approach | Risk control |
|---|---|---|
| MariaDB major version upgrade | Rehearsed rolling upgrade with replicas first, then a timed switchover, after workload replay on a rebuilt copy of production | Plan and latency comparison per critical statement, plus a tested rollback path and abort criteria agreed in advance |
| Minor version patching | Rolling restart through the replica set or cluster, primary last, with health verification at each step | Automated pre-flight checks and an abort threshold defined before the window opens |
| MySQL to MariaDB migration | Replication-based migration with a phased read cut-over and a reversible write cut-over | Full row-level reconciliation rather than sampling, and a documented period during which reverting is still supported |
| Large ALTER on a hot table | Instant or in-place DDL where eligible, otherwise gh-ost or pt-online-schema-change with lag-aware throttling | Row count and checksum validation before cut-over, and a tested revert |
| DDL inside a Galera cluster | Total order isolation for short changes, rolling schema upgrade for long ones, chosen deliberately per change | A rehearsal on a cluster of the same shape, with flow-control pause time measured during the DDL |
| Moving to Kubernetes or another cloud | Replication-based migration with a measured lag window and a reversible cut-over | A rehearsed rollback to the original platform for a defined period after cut-over |
Engagement
MariaDB Support Engagement Models
Different problems need different commercial shapes. Some clients need a pager covered every night of the year; others need a principal engineer for two weeks to settle an architecture argument with data. We do not force either into the other.
| Model | Best suited to | What is included |
|---|---|---|
| 24×7 enterprise MariaDB Support | Revenue-critical systems where downtime is measured in money per minute | Round-the-clock incident response with a 15-minute severity 1 commitment, proactive monitoring review, unlimited advisory contact and a named principal engineer |
| Business-hours support | Important systems with a genuine maintenance window and an internal on-call team | Response within business hours, scheduled performance review, change planning and escalation to 24×7 when needed |
| Remote DBA and managed operations | Teams with no dedicated DBA, or one who should not be a single point of failure | Day-to-day operations, patching, backup verification, capacity planning and full documentation ownership |
| Project and consulting engagements | Upgrades, migrations, Galera or MaxScale redesign, sharding decisions and performance rescues | A defined scope, a principal engineer, a written deliverable and knowledge transfer to your team |
| Health check and architecture review | Organisations that want an honest baseline before committing to anything | A structured assessment of configuration, schema, indexing, replication, high availability, backup and security, with a prioritised remediation plan |
| Emergency incident response | A production system that is down or degrading right now | Immediate engagement, diagnosis, stabilisation and a written root cause analysis afterwards |
When It Matters Most
What Happens When Your MariaDB Fleet Pages Us at 3 A.M.
An escalation policy is only meaningful if you know, in advance, who answers, how fast, and what they are empowered to do. Ours is deliberately simple: there is no tier-one filter, the first responder is a MariaDB specialist who already has your topology documented, and the severity you declare is the severity we work.
Stabilisation comes first, but never at the cost of the evidence. We capture the error log, InnoDB status, lock graph, running transaction list, wsrep cluster state, wait events and replication position before anything is restarted, because a restart that hides the cause guarantees a repeat. Within five working days you receive a written root cause analysis with the specific configuration, schema or application change required to prevent recurrence, and we track that change until it is closed. If the incident is happening right now, our 24/7 emergency DBA coverage is the fastest way to reach an engineer.
Industries
MariaDB Support for the Most Demanding Workloads
Financial services and payments
High-write ledgers where durability is non-negotiable, reconciliation windows are fixed, and an auditor will eventually ask exactly how a transaction was persisted and who could have read it.
E-commerce and marketplaces
Traffic that multiplies without warning, inventory hot spots that punish certification conflict, and schema changes that must ship during trading hours rather than during a quiet weekend.
SaaS and multi-tenant platforms
Tens of thousands of tables, noisy-neighbour isolation, per-tenant restore requirements and upgrade fleets rather than upgrade servers.
Gaming and real-time platforms
Latency budgets measured in single-digit milliseconds, extreme write bursts at launch, and leaderboards that punish lock contention and long transactions equally.
Healthcare and regulated data
Encryption, auditability and retention obligations alongside clinical systems that cannot be taken offline for administrative convenience.
Telecom, IoT and logistics
Very high ingest rates where MyRocks and time-partitioned retention earn their place, and archival strategies that keep the operational working set small enough to stay in memory.
“MariaDB rarely fails because of MariaDB. It fails because a transaction was left open, a Galera node was never measured under batch load, or a backup was reported as successful without ever being restored. Our job is to remove those three sentences from your incident history.”
MinervaDB Database Engineering
FAQ
Frequently Asked Questions About MariaDB Support
What is included in a MinervaDB MariaDB Support subscription?
Round-the-clock incident response with a contracted acknowledgement window, proactive monitoring and configuration review, performance and index engineering, Galera and replication design, MaxScale routing and failover engineering, backup verification and point-in-time recovery rehearsal, upgrade and schema change planning, security review, and unlimited advisory access to a named principal engineer. Every incident produces a written root cause analysis and every change is documented for your team.
How fast do you respond when a production MariaDB server is down?
Severity 1 incidents carry a 15-minute response commitment, 24 hours a day, every day of the year. A MariaDB specialist acknowledges and takes the incident — not a dispatcher. We capture diagnostic evidence before restarting anything, stabilise the service, and then produce a root cause analysis within five working days with the specific change needed to prevent recurrence.
Do you support Galera Cluster and MaxScale, or only standalone MariaDB?
Galera and MaxScale are central to our MariaDB Support practice rather than an add-on. We size gcache, choose and test the SST method, tune applier concurrency and flow control, design segmented multi-region clusters, and configure MaxScale routing, monitoring, automatic failover, masking and firewall rules. We also test the failure modes, including deliberate network partitions, because a cluster that has never been partitioned in a rehearsal will be partitioned in production instead.
Can you migrate us from MySQL to MariaDB without a long outage?
Yes, and we do it regularly. We start with a compatibility assessment covering authentication, data and JSON types, GTID format, collations and optimizer defaults, then build the target and seed it, replicate from MySQL until lag is stable, reconcile every table with checksums rather than samples, and cut over behind a router with a tested path back for a defined period. The write freeze is typically measured in seconds. If you are running both engines, our MySQL Support practice covers the source side of that migration too.
Which MariaDB versions and platforms do you cover?
MariaDB 11.4 LTS, 10.11 LTS, 10.6 LTS and the older 10.4 and 10.5 series, plus MariaDB Enterprise Server, Galera Cluster, MaxScale, ColumnStore, Spider, MyRocks, Amazon RDS for MariaDB, Kubernetes operators, virtualised platforms and bare metal. We support end-of-life versions and plan the exit from them rather than refusing to look at them.
How do you diagnose a MariaDB query that is only slow sometimes?
Intermittent slowness is almost always plan instability, contention or a cache effect rather than a property of the query text. We use performance_schema statement digests to establish the real latency distribution, ANALYZE FORMAT=JSON to compare estimated against actual rows, optimizer traces to see why an index was rejected, lock and wait instrumentation to detect contention, and buffer pool metrics to identify working set pressure. That evidence identifies which cause is active, and each has a different fix.
Do you replace our internal DBA team?
Either model works, and both are common. Many clients keep their internal team and use MinervaDB for depth they cannot justify hiring for full time — Galera and high availability design, upgrade rehearsals, performance forensics and out-of-hours cover. Others hand us the whole MariaDB DBA function. In both cases we document everything and train your engineers as we work, because dependency is not a service model.
How do you stop InnoDB undo and history list growth?
We alert on the trend of history list length and on the age of the oldest open transaction rather than waiting for a disk or latency alarm. Remediation combines purge thread and batch tuning, separate undo tablespaces with automatic truncation, and purge lag throttling where necessary — but the durable fix is nearly always in the application: narrower transaction scope, a kill policy for idle-in-transaction sessions, bounded chunking for large DML, and long analytical queries moved to a replica or to ColumnStore.
What availability can MariaDB realistically achieve?
With a quorum Galera cluster across availability zones, or an asynchronous topology with MaxScale-managed failover, health-check driven routing, proper fencing of the demoted primary, retry-capable drivers and rehearsed runbooks, we routinely engineer estates with a total recovery time of fifteen to thirty seconds and zero committed-data loss. The limiting factor is almost never MariaDB itself — it is whether the surrounding automation, routing and rehearsal discipline actually exist.
Is Galera Cluster a replacement for backups?
No, and treating it as one is among the most expensive mistakes we are called in to repair. Galera replicates a destructive statement to every member synchronously and faithfully. It protects you from hardware and host failure, not from a bad migration, an unguarded DELETE or logical corruption. Every cluster we support has physical backups taken from an asynchronous replica, an independent binary log archive for point-in-time recovery, and usually a delayed replica as well.
Related Services
Explore More MinervaDB Database Engineering Services
MySQL Support
24×7 MySQL DBA cover, InnoDB tuning and replication engineering.
PostgreSQL Support
The same engineering discipline applied to PostgreSQL estates.
SQL Server Support
Enterprise SQL Server DBA cover, tuning and availability engineering.
MongoDB Support
Replica sets, sharding and performance work for MongoDB deployments.
Kafka Support
Streaming infrastructure operated with the same evidence-driven method.
24/7 Emergency DBA Coverage
Immediate response when a production database is down right now.
Enterprise Database Support
One vendor-neutral team across MariaDB, PostgreSQL, MySQL, SQL Server and NoSQL.
MinervaDB Consultative Support
Architecture, capacity and engineering guidance from principal engineers.
— TALK TO A PRINCIPAL ENGINEER —
Get Enterprise MariaDB Support From Engineers Who Have Carried the Pager
Whether you need 24×7 cover for a revenue-critical Galera cluster, a performance rescue this week, or an honest architecture review before you commit budget, we will tell you what we would actually do and what it will cost. No scripted discovery call.