MariaDB remote DBA · 24×7 MariaDB support · Galera Cluster and replication · MaxScale and ProxySQL · mariabackup and point-in-time recovery · Upgrades to 10.11, 11.4, 11.8 LTS and 12.3 · MySQL to MariaDB migration
MariaDB Remote DBA Measured in Checkpoint Age, Galera Flow Control, Per-Domain Replication Lag and Restore Drills, Not in Ticket Counts
MinervaDB MariaDB remote DBA is run by named senior engineers who read SHOW ENGINE INNODB STATUS, the wsrep status variables and the replication heartbeat before they touch a variable. The service covers 24×7 monitoring and incident response under a published severity matrix, InnoDB and optimizer tuning from measured evidence, GTID replication with domain IDs, Galera Cluster, MaxScale or ProxySQL routing, mariabackup with binary log archiving and scheduled restore drills, online schema change, security hardening, upgrades off MariaDB 10.6 to the current long-term support series, and MySQL to MariaDB migration, on bare metal, on RDS for MariaDB and SkySQL, and on Kubernetes. Every change ships as a reviewed runbook with a rollback path.
01 · Why MinervaDB for MariaDB remote DBA
MariaDB is not MySQL with a different name, and a MariaDB remote DBA has to know exactly where the two diverge
Galera in the server, GTID with domain IDs, parallel replication by default, a different optimizer, a different JSON model, different authentication plugins, MaxScale instead of Router. MariaDB support from MinervaDB is delivered by engineers who have operated both engines in production since the fork and who treat the differences as the job rather than as surprises.
MySQL and Sun Microsystems heritage
MinervaDB's leadership includes a former Principal Database Architect at MySQL and Sun Microsystems and former VP roles at Percona and PalominoDB. The MariaDB remote DBA on watch reads an InnoDB status dump, a certification conflict or a per-domain GTID gap the way an application engineer reads a stack trace, and fixes the cause rather than the symptom.
Real 24×7 with a published matrix
Follow-the-sun pods with S1 acknowledged within 15 minutes, S2 in 12 hours, S3 in 24 hours and S4 in 48 hours. Every alert rule maps to a runbook, every S1 closes with a written root cause analysis that names the evidence and the prevention step. 24×7 consultative support →
Vendor-neutral by principle
MinervaDB resells no MariaDB subscription, no SkySQL capacity and no licences. The MariaDB remote DBA recommendation can be Community Server instead of Enterprise, ProxySQL instead of a MaxScale licence, a self-managed Galera cluster instead of a managed service, or a workload that belongs on PostgreSQL or a columnar engine.
Measured before and after
Nothing is reported as improved until the status variables say so: checkpoint age against the redo file, buffer pool miss rate, wsrep_flow_control_paused, heartbeat lag per domain, statement latency per digest, restore duration per drill. Gains are estimates until the next measurement confirms them.
02 · MariaDB remote DBA operating model
From status counters and wsrep state to an accountable engineer, with a response target on every page
Instrumentation is layered: InnoDB status, performance_schema where it has been enabled by decision, the wsrep and replication state and the MaxScale or ProxySQL server view are exported as metrics, correlated with operating system and storage counters, evaluated by recording rules and routed to the MariaDB remote DBA on watch.
Figure 1. The MariaDB remote DBA monitoring and escalation pipeline: signals, collectors, Prometheus, Alertmanager and the on-call engineer, with the severity matrix and representative alert conditions.
Alerts are actionable by design. Thresholds are set per cluster from its own baseline rather than from a template, so a delayed replica does not page and a Galera node that leaves Synced does. Lag is read from a heartbeat table and per-domain GTID positions rather than Seconds_Behind_Master alone, flow control is alerted on as a paused ratio rather than a raw counter, and every rule carries the runbook the MariaDB remote DBA executes when it fires.
The monitoring stack integrates with what you already run: Percona Monitoring and Management, Prometheus and Grafana, Datadog or CloudWatch. A cluster is not accepted into 24×7 MariaDB support until a backup has been restored on an isolated host and a promotion or node-loss drill has been rehearsed. Access is named, least-privilege, time-bounded and audited; no shared credentials, no standing SUPER.
-- Galera health as the on-call MariaDB remote DBA reads it:
-- cluster membership, local state, flow control and
-- certification pressure in one pass
SELECT
variable_name,
variable_value
FROM information_schema.global_status
WHERE variable_name IN (
'wsrep_cluster_size',
'wsrep_cluster_status',
'wsrep_local_state_comment',
'wsrep_ready',
'wsrep_flow_control_paused',
'wsrep_local_recv_queue_avg',
'wsrep_local_send_queue_avg',
'wsrep_local_cert_failures',
'wsrep_local_bf_aborts',
'wsrep_last_committed'
);
-- Per-domain replication position on an async replica
SELECT @@gtid_slave_pos, @@gtid_binlog_pos,
@@slave_parallel_threads AS parallel_threads;
03 · MariaDB remote DBA for storage engines and tuning
The engine is chosen per table, the optimizer is MariaDB's own, and each variable has a counter that says whether it is sized right
InnoDB for transactional tables, Aria for crash-safe temporaries, MyRocks for compressed write-heavy data, ColumnStore for analytical scans, Spider for sharding and S3 for archives: a MariaDB remote DBA chooses from the workload, and tunes the MariaDB optimizer, which has diverged from MySQL's in statistics, join methods and pushdown, from optimizer_trace rather than habit.
Figure 2. MariaDB server architecture as operated by a MariaDB remote DBA: the pluggable storage engine layer, the MariaDB optimizer, what differs from MySQL, and the status variable that validates each configuration parameter.
| Variable | Starting envelope, OLTP on a dedicated 32 vCPU / 128 GB host, NVMe | What the MariaDB remote DBA monitors before changing it |
|---|---|---|
innodb_buffer_pool_size |
80 to 96 GB; resizable online; innodb_buffer_pool_instances removed in 10.6+ and later series |
Innodb_buffer_pool_reads against Innodb_buffer_pool_read_requests, pages free and dirty, dump and load on restart |
innodb_log_file_size |
8 to 16 GB; a single redo file since MariaDB 10.8, resizable online since 10.11 | Checkpoint age in SHOW ENGINE INNODB STATUS against the file size, Innodb_log_waits, async flush events during peak |
innodb_io_capacity / innodb_io_capacity_max |
From measured device IOPS with fio, not the vendor sheet; dynamic |
Innodb_buffer_pool_pages_dirty trend, page cleaner backlog, write latency |
innodb_flush_log_at_trx_commit / sync_binlog |
1 / 1 where the recovery point demands it; dynamic; on Galera the cluster's certification provides cross-node durability | Commit latency percentiles against the signed-off recovery point |
thread_handling / thread_pool_size / max_connections |
pool-of-threads with the pool sized to cores; max_connections from Threads_running, not from application fleet size; restart for thread_handling |
Threads_running and Threadpool_idle_threads, connection queueing, MaxScale or ProxySQL pool statistics |
slave_parallel_threads / slave_parallel_mode / gtid_strict_mode |
Parallel threads from replica cores; optimistic mode where the workload tolerates it; strict mode on |
Heartbeat lag per domain, apply conflicts and retries, gtid_slave_pos consistency across replicas |
wsrep_slave_threads / gcache.size / wsrep_sync_wait |
Applier threads from cores and write concurrency; gcache sized so a node can rejoin by IST after a maintenance window; sync wait per session, not globally | wsrep_flow_control_paused, receive and send queue averages, certification failures, IST versus SST on rejoin |
optimizer_switch / use_stat_tables / histogram_size |
Defaults kept unless optimizer_trace shows a regression; engine-independent statistics collected on the largest tables |
Plan shape and cost in optimizer_trace, rows examined per row sent, slow log digests before and after |
binlog_format / log_slave_updates / binlog_expire_logs_seconds |
ROW / on for cascading and Galera / retention covering the PITR window plus the slowest replica |
Binary log growth against disk, archive gap, GTID positions consistent |
The envelope above is a starting point a MariaDB remote DBA derives from, not a template to copy; final values come from the measured workload, and every change is applied on a non-production copy first with dynamic-versus-restart stated in the runbook. Exact server versions are confirmed before any version-sensitive setting is proposed.
04 · MariaDB remote DBA for replication and Galera Cluster
Three topologies, one routing layer, and a promotion or node-loss drill that is rehearsed rather than assumed
Asynchronous GTID replication with domain IDs, parallel apply and semi-synchronous durability where the recovery point requires it; Galera Cluster built into MariaDB; and multi-source or delayed replicas for reporting and logical damage. MariaDB consulting from MinervaDB says which one fits the write pattern, and the MariaDB remote DBA operates all three.
Figure 3. MariaDB replication and high availability topologies a MariaDB remote DBA operates: MaxScale or ProxySQL routing over asynchronous GTID replication with semi-sync, built-in Galera Cluster, and multi-source or cascading replicas, with the selection criteria and the quarterly drill.
| Topology | Failover model | Data-loss and recovery characteristics | When the MariaDB remote DBA recommends it |
|---|---|---|---|
| Asynchronous GTID replication with parallel apply | MaxScale mariadbmon with auto-failover and auto-rejoin, or a scripted promotion with fencing |
Transactions not yet shipped can be lost; recovery time is the promotion plus the repoint; per-domain positions let replicas re-parent safely | Read scaling, reporting and delayed replicas, geographic distribution, estates where seconds of loss are tolerable |
| Semi-synchronous replication | Same as asynchronous | Commit acknowledged only after one replica has the relay log; falls back to asynchronous on timeout, which is alerted | Transactional systems that need cross-host durability without changing the application |
| Galera Cluster | Every node writable; MaxScale galeramon or the ProxySQL scheduler removes nodes that leave Synced |
Synchronous certification; no loss on node failure while quorum holds; long transactions and hot rows abort; SST cost on rejoin bounded by gcache | Multi-writer needs with small transactions, three or more nodes or an arbitrator, and DDL scheduled with wsrep_OSU_method in mind |
| Multi-source replication | Reporting replica only; excluded from failover | Several sources by connection name with independent per-domain positions; lag tracked per source | Consolidated reporting, CDC feeds into ClickHouse or a lakehouse, cross-cluster aggregation |
| Cloud managed: RDS for MariaDB, SkySQL | Provider-managed | Provider-published behaviour; parameter groups, replica lag, backup retention and cross-region recovery still owned by the MariaDB remote DBA; Azure Database for MariaDB has been retired and estates on it are migrated | Teams optimising for operational simplicity over topology control |
MaxScale is licensed under the Business Source License, which limits production use without a subscription beyond a small server count; the MariaDB remote DBA states which routing layer fits your licensing position, and configures Galera Cluster from the MariaDB knowledge base rather than from vendor defaults. Promotion, repoint, application reconnect and re-parenting are drilled every quarter with a recorded time.
05 · MariaDB remote DBA for backup and point-in-time recovery
A backup that has not been restored is a hope, not a backup
Physical backups with mariabackup from a replica or a desynced Galera node, logical exports with mydumper for portability, and continuous binary log archiving for point-in-time recovery to any second. The part most teams skip is the restore drill, and it is the part the MariaDB remote DBA schedules first.
Figure 4. The MariaDB remote DBA backup and point-in-time recovery paths: mariabackup full and incremental, binary log archiving, logical exports where portability matters, the restore and replay path, and the drill cadence.
Backups are taken from a replica, or from a Galera node with wsrep_desync set so flow control does not stall the cluster, with the GTID position recorded in mariadb_backup_binlog_info so replay starts from a known point. Incrementals are LSN-based and prepared in order onto the full; the archive is encrypted with a key held outside the host, copied off-region and retained in both generations and time so the binary logs always cover the recoverable window.
The drill is a full restore plus PITR replay on an isolated host on a fixed schedule, with CHECK TABLE, an application smoke test, and the measured restore duration and achieved recovery point recorded in the runbook and reviewed with you. Where a full restore is the wrong tool, a delayed replica recovers a dropped table in minutes. The mechanics follow the mariabackup documentation and the MariaDB binary log reference.
# Nightly full from a replica, as the MariaDB remote DBA
# runbook lays it out; values sized per estate
mariadb-backup --backup \
--host=${MARIADB_REPLICA_HOST} \
--user=${BACKUP_USER} \
--password=${BACKUP_PASSWORD} \
--parallel=8 \
--target-dir=/backup/full/$(date +%F)
# stream through the compression and encryption of choice:
# mariadb-backup --backup --stream=xbstream | zstd | age ...
# Continuous binary log archive for the PITR window
mariadb-binlog --raw --read-from-remote-server \
--stop-never \
--host=${MARIADB_PRIMARY_HOST} \
--user=${BINLOG_USER} \
--password=${BINLOG_PASSWORD} \
--result-file=/backup/binlog/ \
$(mariadb -N -e "SHOW BINARY LOGS" | head -1 | cut -f1)
# Restore drill: prepare, copy back, then replay to a point
mariadb-backup --prepare --target-dir=/restore/full
mariadb-backup --copy-back --target-dir=/restore/full
mariadb-binlog --start-position=${START_POS} \
--stop-datetime="${RECOVERY_TARGET_TIME}" \
/backup/binlog/mariadb-bin.0* | mariadb
06 · MariaDB remote DBA for upgrades and lifecycle
MariaDB 10.6 reached end of life in July 2026; an estate still on it is running without security fixes, and every health check records that as an S2 finding
The MariaDB maintenance policy gives long-term series five years and short-term series one; 10.11, 11.4 and 11.8 are the LTS lines in support today, with 12.3 the newest. The MariaDB remote DBA plans the move as an engineered project with a rehearsed rollback, one long-term series at a time where the upgrade path requires it.
Figure 5. The MariaDB remote DBA upgrade lifecycle from 10.6 or earlier to 10.11, 11.4 or 11.8 LTS or 12.3: pre-checks, rehearsal on a clone, replica-first or node-by-node rolling upgrade, the three mechanisms compared, and the engagement lifecycle.
What changes on the way up
A single redo file since 10.8 and an online-resizable one since 10.11; innodb_buffer_pool_instances gone; optimizer defaults that change plan shapes; MariaDB Vector in 11.8 LTS; new authentication plugins. The MariaDB remote DBA reads the release notes across every hop, runs mariadb-upgrade on the rehearsal clone and replays a captured workload before any traffic moves.
Replicas and Galera nodes first
Each replica or Galera node is upgraded in place and rejoined with lag, wsrep state and errors watched between nodes; an upgraded replica is then promoted, or writes are moved in MaxScale, through the same drill the estate already rehearses. Galera rolling upgrades take no downtime; asynchronous estates take the seconds of a promotion.
Percona and MySQL calendars tracked too
Mixed estates are common. The same MariaDB remote DBA tracks MySQL 8.4 and 9.7 LTS and Percona Server calendars, and treats MySQL 8.0, end of life since 30 April 2026, the same way as MariaDB 10.6. MySQL remote DBA → · MySQL consulting →
07 · MariaDB consulting for MySQL to MariaDB migration
The two engines diverged after 5.5; a migration is a compatibility project, not a package swap
Authentication plugins, the JSON model, GTID formats, replication defaults, tooling and several SQL features differ. MariaDB consulting from MinervaDB inventories every divergence before the first byte moves, and the MariaDB remote DBA who runs the estate afterwards is the same engineer who planned the cutover.
Figure 6. MySQL to MariaDB migration as delivered by a MariaDB remote DBA: the divergence points checked before migration, the reversible migration sequence, and the security hardening applied to every MariaDB estate on the way in.
Divergences that break cutovers
caching_sha2_password accounts must move to mysql_native_password, ed25519 or PARSEC before drivers reconnect; MySQL's binary JSON type becomes a LONGTEXT alias with a JSON_VALID check; MySQL UUID-based GTIDs and MariaDB domain-server-sequence GTIDs are not interchangeable, so replication from MySQL into MariaDB is version-bounded and one-directional.
What MariaDB adds
Sequences, system-versioned and application-time period tables, sql_mode=ORACLE with a PL/SQL subset for estates leaving Oracle, engine-independent statistics, Spider sharding, ColumnStore for analytics next to the OLTP data, and vector search in 11.8 LTS. MariaDB consulting decides which of them earn a place in the target design rather than adopting all of them.
Reversible by construction
Full load into a clone with a captured workload replayed; replication or mydumper plus CDC to keep the target current; row counts and checksums per table; a MaxScale or ProxySQL repoint after a lag gate; the source retained through the observation window so rollback is a connection change. Migrations from Oracle and SQL Server follow the same shape. Data modernization →
08 · MariaDB remote DBA scope, environments and pricing
The same MariaDB support runbooks on bare metal, managed services and Kubernetes; the same access model everywhere
On managed services the work shifts from operating system and backup mechanics to parameter groups, instance right-sizing, storage IOPS, replica and multi-zone design, cost control and the query-level tuning no provider does for you. The MariaDB remote DBA says plainly when a workload does not belong on a managed service, and when it does not belong on MariaDB at all.
On-premises and bare metal
Kernel, filesystem and I/O scheduler tuning; O_DIRECT with write-cache behaviour validated under power loss; NUMA interleave; transparent huge pages off; redo and binary logs on storage measured with fio; a hardened server configuration under version control; security aligned to CIS Benchmark controls before a cluster enters MariaDB remote DBA coverage.
RDS for MariaDB and SkySQL
Parameter groups tuned from Performance Insights and the server's own status; instance class and storage from p95 utilisation; replica lag bounded; backup retention and cross-region recovery designed and drilled; monthly cost per transaction reported alongside latency. Cloud database optimization and FinOps →
Kubernetes
The MariaDB Operator or a Galera StatefulSet with pod anti-affinity across zones, storage classes with predictable fsync semantics, PodDisruptionBudgets that never evict a quorum together, MaxScale or ProxySQL as the routing layer, and mariabackup to object storage on the same restore-drill schedule as everywhere else.
| MariaDB remote DBA service line | What it covers technically |
|---|---|
| Monitoring and alerting | 15-second metric scrape, recording rules per cluster, Galera and replication rules, integration with PMM, Prometheus and Grafana, Datadog or CloudWatch |
| Incident response | Severity-based paging, runbook execution, root cause analysis with a prevention ticket, customer communication through the incident on a shared channel |
| Patch management | Minor-release tracking for MariaDB Community and Enterprise Server, staged replica-first or node-by-node rollout within a defined window, plugin and driver compatibility checks |
| Performance engineering | Weekly slow log digests, optimizer_trace driven plan attribution, index design, engine selection per table, InnoDB and thread pool sizing from status counters, MaxScale or ProxySQL query rules |
| Replication and Galera operations | GTID domains, parallel apply, semi-sync, Galera flow control and certification tuning, SST and IST sizing, quarterly promotion and node-loss drills, delayed and multi-source replicas |
| Backup assurance | mariabackup full and incremental with binary log archiving, retention in generations and time, scheduled restore drills with a recorded attestation |
| Online schema change | Native online DDL where it qualifies, gh-ost or pt-online-schema-change elsewhere, wsrep_OSU_method chosen per change on Galera, throttled on lag, with rehearsal and rollback gates |
| Security and compliance | TLS on every client and replication connection, ed25519 or PARSEC authentication, least-privilege roles, password policies, the server audit plugin, encryption at rest with file or HashiCorp Vault key management, evidence for SOC 2, PCI DSS and HIPAA |
| Capacity planning | Growth modelling, storage and IOPS forecasting, connection scalability from Threads_running, sharding thresholds with Spider or application sharding |
| Change control and knowledge transfer | Reviewed runbooks, ticketed changes with an approver, verified rollback paths, monthly health report, documentation and joint reviews |
Pricing
MariaDB remote DBA retainers start at US $4,500 per quarter. Hourly MariaDB consulting is US $300 per hour remote and US $500 per hour on site. Retainers include the takeover assessment, the runbook, monitoring integration with your existing stack, a monthly health report with the measured metrics behind every recommendation, and a quarterly restore and failover drill. Enterprise and multi-cluster estates are scoped from the assessment.
Access model
VPN or bastion reachability, named individual accounts per engineer, SSH certificate or key authentication with MFA, least-privilege database roles rather than standing SUPER, and full session and change auditing with every production modification tied to a ticket and an approver. Emergencies outside a subscription go through emergency database support.
Standing caveat: every recommendation on this page is tested on a non-production copy before it is applied to a production cluster, changes are staged and reversible by design, and a verified backup and DR posture is confirmed before any storage, retention, replication, schema or upgrade change is made.
09 · FAQ
MariaDB remote DBA questions we are asked most
Short answers to what engineering and platform leaders ask before the first call.
What does a MariaDB remote DBA engagement include?
Named engineers assigned to your estate, 24x7 monitoring and incident response under a published severity matrix with S1 acknowledged within 15 minutes, S2 in 12 hours, S3 in 24 hours and S4 in 48 hours, patch management within a defined window, InnoDB, thread pool and optimizer tuning from measured evidence, replication and Galera operations with quarterly drills, mariabackup and binary log archiving with scheduled restore drills, online schema change, security hardening, and upgrades and migrations delivered as staged, reversible runbooks. Every recommendation names the metric behind it and every change carries a rollback path.
Which MariaDB versions and distributions do you support?
MariaDB Community Server and Enterprise Server on the long-term support series in maintenance today, 10.11, 11.4 and 11.8, and on 12.3; MariaDB 10.6 and earlier estates that are past end of life and need a safe upgrade path; Galera Cluster; MaxScale and ProxySQL; and the managed services, Amazon RDS for MariaDB and SkySQL. Estates on the retired Azure Database for MariaDB are migrated. Exact server versions are confirmed before any version-sensitive guidance is given.
How is MariaDB different from MySQL for a remote DBA?
Galera is built into the server, GTIDs carry domain IDs and replication applies in parallel by default, the optimizer has its own statistics and join methods, JSON is a LONGTEXT alias rather than a binary type, authentication plugins differ, and MaxScale, Galera and mariabackup replace MySQL Router, Group Replication and XtraBackup. A MariaDB remote DBA from MinervaDB has operated both engines in production since the fork and treats those differences as the job.
Can you take over an estate that already has Galera, MaxScale or ProxySQL in place?
Yes. Onboarding starts with a takeover assessment that documents the existing topology, configuration deltas from default, backup state, monitoring gaps and security posture, and produces the runbook we then operate from. Nothing is changed until the assessment is reviewed with you, and the first restore drill and node-loss or promotion drill happen before the cluster enters 24x7 coverage.
How do you handle backups and point-in-time recovery on MariaDB?
Physical backups with mariabackup taken from a replica or a desynced Galera node, LSN-based incrementals between fulls, continuous binary log archiving for point-in-time recovery to any second, encryption with a key held outside the host, an off-region copy, and a scheduled restore drill on an isolated host so the recovery time is measured rather than estimated.
Do you migrate from MySQL to MariaDB, and from MariaDB back to MySQL?
Yes to both, with different scoping. MySQL to MariaDB is a compatibility project across authentication, JSON, GTID format, replication defaults, tooling and SQL features, run as a rehearsed, reversible cutover. MariaDB to MySQL is harder because features such as sequences, system-versioned tables and Oracle mode have no direct equivalent, so it is scoped from an inventory first. MinervaDB recommends against the move when the evidence says the current engine is the right one.
What does MariaDB remote DBA cost?
Retainers start at US $4,500 per quarter and include the takeover assessment, the runbook, monitoring integration, a monthly health report and a quarterly restore and failover drill. Hourly MariaDB consulting is US $300 per hour remote and US $500 per hour on site. Larger and multi-cluster estates are scoped from the assessment.
Talk to a senior MariaDB remote DBA engineer
Bring SHOW ENGINE INNODB STATUS, SHOW ALL SLAVES STATUS or the wsrep status variables from every node, your server configuration, the last mariabackup report and the date of your last restore drill to the first call. We will tell you what the next incident will be and what we would change first.