THE MINERVADB DIFFERENCE
Why Enterprises Trust MinervaDB for MySQL Support
MySQL runs an enormous share of the world’s transactional systems — order capture, payments, subscription billing, identity, inventory and the event tables behind analytics pipelines. It earns that position by being fast and predictable when it is configured for the workload it actually carries. It becomes hostile when it is not: undo grows behind a forgotten transaction, a replica falls hours behind during a nightly batch, a schema change locks a hot table at peak, and an optimizer plan flips overnight because statistics drifted. None of these announce themselves as MySQL problems. They surface as checkout timeouts and angry dashboards.
MinervaDB exists for exactly that gap. Our MySQL 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, and sharded platforms 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 3 a.m.
Principal engineers, not ticket queues
The person who answers your severity 1 page is a MySQL 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 log, InnoDB metrics and EXPLAIN ANALYZE output. Then we change one thing, measure it, and keep or revert it. Nobody on our team tunes MySQL from a blog post.
Vendor-neutral by design
Community MySQL, Percona Server, Amazon RDS and Aurora, Google Cloud SQL, Azure Database for MySQL, Vitess and Kubernetes operators. We recommend what fits your workload and budget, not what pays a referral fee.
Availability that has been rehearsed
A failover design is a hypothesis until it has been executed under load with a stopwatch. Our MySQL 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 and storage behaviour 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 MySQL Server Actually Behaves Under Load
Effective MySQL Support starts with an accurate mental model of the server. MySQL is a layered system: a connection and thread layer, a SQL layer that parses and optimizes, and a pluggable storage engine — in practice InnoDB — that owns durability, concurrency and physical layout. 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 MySQL Support engagement. Client sessions arrive through a pooler such as ProxySQL or MySQL Router, are handed to a server thread, and their statements are parsed, costed and executed against the InnoDB handler interface. Every row read or written is a 16 kB page in the buffer pool. Every commit becomes a redo record and, when binary logging is enabled, a binlog event. Background threads flush dirty pages, fsync the redo log, purge undo, and ship events to replicas. 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 MySQL 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 and storage latency — rather than from a generic calculator. The reference documentation for each variable is published by Oracle in the MySQL InnoDB parameter reference, but the defaults it ships are deliberately conservative.
| Variable | What it governs | How MinervaDB approaches it |
|---|---|---|
| innodb_buffer_pool_size | The in-memory page cache for data and indexes | Sized against the measured working set, not a blanket percentage of RAM. On dedicated hosts we typically land between 60% and 75%, then verify with buffer pool hit ratio and read I/O rather than assuming. |
| innodb_redo_log_capacity | Total redo space, which bounds checkpoint pressure | Large enough that checkpoints are smooth rather than spiky. Undersized redo shows up as periodic write stalls that look like storage faults but are not. |
| innodb_flush_log_at_trx_commit | Whether each commit is durable on disk | Set to 1 for anything resembling a ledger. We only relax it when the data is genuinely rebuildable, and we document the loss window in seconds. |
| 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 / _max | How aggressively dirty pages are flushed | Calibrated to measured device IOPS, not left at the default. Too low causes flush storms and LRU stalls; too high wastes I/O the foreground needs. |
| innodb_flush_method | How InnoDB interacts with the OS page cache | O_DIRECT on Linux for anything with a real storage stack, to stop double buffering and make latency legible. |
| max_connections and thread handling | Concurrency admitted into the server | We push pooling out to ProxySQL or the application driver so MySQL sees a bounded, efficient number of active threads instead of thousands of idle ones. |
| innodb_purge_threads | 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 before it becomes an outage. |
| tmp_table_size, sort_buffer_size, join_buffer_size | Per-operation memory for sorts, joins and temp tables | Kept modest and fixed by better indexing. Inflating per-session buffers to hide a bad plan is how servers get OOM-killed. |
| table_open_cache and table_definition_cache | Metadata caching for large schemas | Raised deliberately on estates with tens of thousands of tables, where the default causes measurable open/close churn. |
SERVICE SCOPE
Full-Stack MySQL Support Services
Our MySQL Support subscriptions are deliberately broad, because production problems do not respect organisational boundaries. A slow checkout may be an index, a lock, a replica, a kernel setting or a connection pool — and you should not have to diagnose which before you are allowed to call someone.
24×7 incident response and emergency MySQL 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, wait events and replication state 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 EXPLAIN ANALYZE, performance_schema digests and sys schema views to fix index design, query shape, schema types and optimizer inputs — then quantify the improvement in p95 latency and rows examined per row returned.
High availability, replication and failover design
Topology design across availability zones with InnoDB Cluster, Group Replication, semi-synchronous replication or Orchestrator-managed asynchronous chains. We specify fencing, routing, quorum and candidate weights, then rehearse the failover with a stopwatch until the numbers are boring.
Backup, recovery and disaster readiness
Physical and logical backup strategy using Percona XtraBackup, MySQL Enterprise Backup or clone plugin snapshots, with 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
Version upgrades to MySQL 8.0 and 8.4 LTS with compatibility analysis and rehearsed rollback. Online schema changes with gh-ost or pt-online-schema-change on tables too hot to lock. Heterogeneous migrations to and from MySQL with row-level validation, not spot checks.
Monitoring, capacity and proactive review
We instrument what predicts incidents — history list length, checkpoint age, 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.
DURABILITY
What Actually Happens When MySQL Commits a Transaction
Most arguments about MySQL durability are really arguments about the commit path, and most of them are conducted without a shared picture of it. When binary logging is enabled, a commit is a two-phase protocol across two independent logs: InnoDB writes a prepare record to the redo log with a transaction identifier, the binary log writes and syncs the transaction, and only then does InnoDB mark the transaction committed. That ordering is what allows a crashed server to decide, unambiguously, whether a prepared transaction should be completed or rolled back on restart.
This is the part of MySQL Support work where we most often find a gap between what a team believes about their durability guarantees and what their configuration actually provides. A server running with a relaxed redo flush and an unsynced binary log is fast, and it will also cheerfully lose the last second of committed transactions and desynchronise its replicas after a power event. That may be a perfectly rational trade for a cache. It is never a rational trade for a payment ledger, and the difference should be a documented decision rather than an inherited default.
Group commit is why durability is cheaper than people assume
Teams frequently relax durability because they measured a single-threaded write benchmark and concluded that fsync per commit was unaffordable. Under real concurrency, MySQL batches the flush and sync stages across all sessions waiting at that moment, so the fsync cost is amortised across many transactions. We routinely restore full double-1 durability on busy systems while holding throughput flat, simply by letting group commit do its job and by putting the redo log and binary log on storage whose latency we have actually measured.
| Durability decision | What it buys | What it costs |
|---|---|---|
| innodb_flush_log_at_trx_commit = 1 with sync_binlog = 1 | A committed transaction survives OS crash, host loss and power failure, and replicas can never receive events the primary forgot | An fsync on the commit path, largely amortised by group commit on concurrent workloads |
| innodb_flush_log_at_trx_commit = 2 | Faster commits when storage latency is poor | Up to one second of committed transactions lost on host or power failure. Acceptable only for genuinely rebuildable data |
| sync_binlog = 0 or a value greater than 1 | Fewer fsyncs on the binary log | After a crash the binary log may be behind InnoDB, which can force a full reclone of every replica |
| Semi-synchronous replication with ACK from a remote zone | Bounded data loss even if the whole primary host is destroyed | Commit latency increases by the round trip to the acknowledging replica |
| Group Replication with quorum | Certified writes and automatic primary election with no committed-data loss | Write latency is governed by the slowest member of the majority, so zone placement matters |
REPLICATION
Replication Lag Is a Design Problem, Not a Weather Event
Replication is the load-bearing wall of most MySQL architectures. 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 MySQL 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 lookups without a usable index; or the replica’s own storage and locking can be slower than the source it is trying to keep up with. Treating all three as one metric — Seconds_Behind_Source — is why so much replication tuning fails.
Parallel apply, done properly
Modern MySQL can apply transactions in parallel on the replica, but only if the source gives it the dependency information to do so safely. We set writeset-based dependency tracking on the source so independent transactions can be identified, size the applier worker pool to the replica’s real CPU and I/O headroom, and keep commit order preserved wherever the application reads its own writes from a replica. On workloads dominated by a small number of very large transactions we go further and change the transaction boundaries in the application, because no amount of applier concurrency parallelises a single 40-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 | That GTID sets are consistent across the topology and that no writes bypass the binary log |
| Writeset dependency tracking with parallel appliers | Any replica that must stay within seconds of the source under batch load | Applied transactions per second, applier queue depth and the ratio of parallelised to serialised commits |
| Semi-synchronous replication | When the recovery point objective is effectively zero but the cost of full quorum is not justified | ACK latency distribution, timeout behaviour under replica loss, 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 the team has practised extracting a single table from it |
| Multi-channel replication | Consolidating several sources onto one reporting target | Channel isolation, independent lag tracking and that a single bad channel cannot block the others |
| Read routing by lag | Read scale-out where slightly stale reads are acceptable | That the router removes a replica from rotation on lag threshold rather than after users complain |
HIGH AVAILABILITY
Failover That Has Been Rehearsed, Not Assumed
Every organisation we provide MySQL 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 quorum-based Group Replication across three availability zones, Router-managed connection routing, proper fencing of the demoted primary and drivers that retry idempotent work, a total recovery time of twenty to forty seconds with zero committed-data loss is routinely achievable. The constraint is almost never MySQL itself — it is whether the surrounding automation, routing and rehearsal discipline exist.
| Layer | Failure it removes | How we implement and prove it |
|---|---|---|
| Quorum membership across three zones | Split brain during a network partition | Three or five members with zone-aware placement, then a deliberate partition test that confirms the minority side becomes unavailable rather than writable |
| Fencing of the old primary | Two servers accepting writes at the same time | super_read_only enforced on demotion plus removal from the router’s routing set, verified by attempting a write against the demoted node |
| Health-check based connection routing | DNS TTL guesswork and stale application connection pools | MySQL Router or ProxySQL probing live cluster 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 idempotency review of write paths, tested by killing the primary during a synthetic load run |
| 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 |
THE QUIET FAILURE MODE
The Problem That Slowly Ends MySQL 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 that 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 tablespaces grow, the history list lengthens, and every read starts walking longer version chains for the same result. CPU rises with no change in traffic. Disk consumption climbs. Crash recovery time grows with the history list. Nothing in the application changed, nothing looks busy, and the server gets progressively worse. This single pattern is responsible for more emergency MySQL 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 think-time.
What we monitor so it never becomes an incident
We alert on the trend of Innodb_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 file growth. We tune purge thread count and batch size, enable automatic undo truncation with separate undo tablespaces, 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.
PERFORMANCE
MySQL 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 MySQL 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 MySQL 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. Our job during MySQL Support work is to identify which of the small number of real causes is active — a wrong index, a bad cardinality estimate, row lock or metadata lock contention, buffer pool pressure, temp tables spilling to disk, 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 statistics, or parameter-sensitive plans | ANALYZE TABLE 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 | 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 |
| High CPU with flat traffic | Long undo chains from an old read view, or repeated full scans that fit in memory | Transaction scope repair and purge tuning, then index work driven by rows examined per row returned |
| Writes intermittently stall | Flush storms from mis-set io_capacity, dirty page ratio spikes, or doublewrite on slow storage | Calibrated io_capacity, adaptive flushing review, storage latency measurement, and redo sizing |
| Lock wait timeouts under peak | Wide transaction scope, gap locks from a non-unique search, or hot row contention | Isolation level and index review to narrow lock ranges, shorter transactions, and where appropriate application-level queueing |
| Connection storms and thread thrash | No effective pooling, so thousands of threads contend for the same latches | Bounded pooling in ProxySQL or the driver, so the server sees an efficient number of active threads |
| Replica lags only during migrations | Single-transaction schema change or unindexed row events replayed serially | Online schema change tooling, writeset dependency tracking, 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 MySQL estate whose value is entirely unproven until the worst day. We treat them as an engineering control with two measured numbers attached: recovery time objective, established by actually restoring onto representative hardware, and 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, and an unbroken binary log archive. We rehearse the whole chain — restore the full, apply incrementals, replay binary logs to a stop-datetime or to the GTID immediately before the mistake, verify with row counts and checksums, and only then repoint the application. Every MinervaDB MySQL Support client gets that rehearsal on a schedule, with the elapsed time written down.
| Failure scenario | Recovery approach | What has to be true in advance |
|---|---|---|
| Primary host lost | Automatic failover to a synchronised secondary | Quorum members in other zones, fencing on the old primary, and health-check based routing |
| A table dropped or a DELETE without a WHERE clause | Point-in-time recovery to the moment before the statement, or extraction from a delayed replica | Binary logs archived continuously, 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 | Backup retention long enough to cover realistic discovery lag, plus checksum tooling |
| Whole region unavailable | Promote a cross-region replica and accept the documented recovery point | Cross-region replication with measured lag, and a promotion runbook that has been executed |
| Storage-level page corruption | Restore the affected tablespace and replay, or rebuild from a healthy replica | Page checksums and doublewrite enabled, plus alerting on InnoDB corruption messages in the error log |
| Backup itself is unusable | Fall back to the previous verified generation | Every generation restored and validated on a schedule, not merely reported as successful |
OBSERVABILITY
Instrumentation That Predicts Incidents Instead of Narrating Them
Most MySQL 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 MySQL 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 recovery time grows before anything errors | SHOW ENGINE INNODB STATUS and Innodb_history_list_length |
| Oldest transaction age | A single idle-in-transaction session is the root cause of most gradual degradation | information_schema.innodb_trx joined to performance_schema threads |
| Checkpoint age against redo capacity | Approaching the async flush limit means imminent write stalls | InnoDB log sequence numbers and checkpoint metrics |
| Buffer pool hit ratio and free page trend | 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 |
| Replication apply queue and lag distribution | Averages hide the batch window where lag spikes; distribution does not | performance_schema replication tables plus relay log position deltas |
| Lock wait time and deadlock rate | Rising contention predicts the peak-hour timeout storm | performance_schema data_lock_waits 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 cache misses | Pooling problems and network faults surface here first | Aborted_connects, Aborted_clients and Threads_created rate |
SECURITY AND COMPLIANCE
MySQL Security Engineered for Audit, Not for Appearance
Database security tends to be assessed by questionnaire and implemented by hope. Our MySQL 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, modern cipher policy, and InnoDB tablespace encryption with keyring management that survives host replacement.
Privilege minimisation
Roles instead of per-user grants, no application account with SUPER or unnecessary global privileges, and a review process that removes access that no longer has an owner.
Authentication that fits your estate
caching_sha2_password as the default, LDAP or Kerberos where central identity is required, and password rotation that does not require an outage.
Auditing that answers real questions
Audit log configuration 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, and secure_file_priv constrained deliberately rather than by accident.
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.
COVERAGE
MySQL Support Across Every Version and Deployment Model
We support MySQL where it actually runs, which is rarely one place. A typical estate we take on has a legacy 5.7 instance nobody has dared to touch, a fleet of 8.0 servers on cloud virtual machines, a managed service running a fork with slightly different tuning knobs, and something on Kubernetes that an application team stood up without telling anyone.
UPGRADES AND MIGRATIONS
Upgrades 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 MySQL 5.7 to 8.0 upgrade changes the data dictionary, default character set and collation, authentication plugin, optimizer behaviour and several reserved words. A single ALTER TABLE on a hot 400 GB table can hold a metadata lock long enough to stall an entire checkout path. Neither of these needs to be a gamble.
How we run a MySQL major version upgrade
We start with a compatibility assessment using the upgrade checker plus a review of application SQL for reserved words, collation-sensitive comparisons and authentication assumptions. We then rebuild a copy of production from a real backup, replay a captured workload against it, and compare plans and latency for your most important statements. The production cutover is executed as a rehearsed replication-based switchover with a documented rollback path, so the decision to proceed or abort is made from evidence within a known window rather than in the middle of an unplanned outage.
Online schema change on tables that cannot be locked
Instant DDL in MySQL 8 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 to primary load, so the migration slows itself down instead of taking the site with it. Every migration includes a cut-over plan, a rollback plan and a validation step that compares row counts and checksums rather than trusting the tool’s exit status.
| Change type | Approach | Risk control |
|---|---|---|
| MySQL 5.7 to 8.0 or 8.4 | Rehearsed replication-based switchover after workload replay on a rebuilt copy | Plan and latency comparison per critical statement, plus a tested downgrade or rollback path |
| Minor version patching | Rolling restart through the replica set, primary last, with health verification at each step | Automated pre-flight checks and an abort threshold defined before the window opens |
| Large ALTER on a hot table | Instant 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 |
| Heterogeneous migration into or out of MySQL | Logical replication or CDC with dual-write validation and a phased read cut-over | Full row-level reconciliation, not sampling, before write traffic moves |
| Moving between cloud providers or to Kubernetes | 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
MySQL 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 MySQL 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 the single point of failure | Day-to-day operations, patching, backup verification, capacity planning and full documentation ownership |
| Project and consulting engagements | Upgrades, migrations, HA 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, HA, 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 MySQL 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 MySQL 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, wait events and replication state 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.
INDUSTRIES
MySQL 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.
E-commerce and marketplaces
Traffic that multiplies without warning, inventory hot spots, and schema changes that must ship during trading hours rather than during a quiet weekend.
SaaS and multi-tenant platforms
Thousands of schemas, 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.
Healthcare and regulated data
Encryption, auditability and retention obligations alongside clinical systems that cannot be taken offline for convenience.
Telecom, IoT and logistics
Very high ingest rates, time-partitioned retention, and archival strategies that keep the operational working set small enough to stay in memory.
“MySQL rarely fails because of MySQL. It fails because a transaction was left open, a replica 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 MySQL Support
What is included in a MinervaDB MySQL Support subscription?
Round-the-clock incident response with a contracted acknowledgement window, proactive monitoring and configuration review, performance and index engineering, replication and high availability design, 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 MySQL server is down?
Severity 1 incidents carry a 15-minute response commitment, 24 hours a day, every day of the year. A MySQL 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 Amazon RDS, Aurora, Cloud SQL and Azure Database for MySQL?
Yes. We work inside the constraints each managed platform imposes, using parameter groups and the diagnostics that remain available. Aurora in particular has a different storage architecture and different failure and replica lag semantics from community MySQL, and we treat it as its own engine rather than assuming shared behaviour. We also support Percona Server, Vitess, Kubernetes operators and bare metal.
Can you upgrade us from MySQL 5.7 to 8.0 or 8.4 without a long outage?
Yes, and we do it regularly. We run a compatibility assessment, rebuild a copy of production from a real backup, replay a captured workload, and compare plans and latency for your critical statements before touching production. The cutover itself is a rehearsed replication-based switchover with a documented rollback path, so the change window is short and the abort decision is made from evidence.
How do you diagnose a MySQL 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, EXPLAIN ANALYZE to compare estimated against actual rows, lock and wait instrumentation to detect contention, and buffer pool metrics to identify working set pressure. That evidence identifies which of those causes 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 — replication and HA design, upgrade rehearsals, performance forensics and out-of-hours cover. Others hand us the whole MySQL 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 disk or latency alarms. 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.
What availability can MySQL realistically achieve?
With quorum-based Group Replication across availability zones, health-check driven connection routing, proper fencing of the demoted primary, retry-capable application drivers and rehearsed runbooks, we routinely engineer clusters with a total recovery time of twenty to forty seconds and zero committed-data loss. The limiting factor is almost never MySQL itself — it is whether the surrounding automation, routing and rehearsal discipline actually exist.
RELATED SERVICES
Explore More MinervaDB Database Engineering Services
MySQL Consulting
Architecture, schema and capacity guidance from principal MySQL engineers.
MySQL Optimization
Query, index and server tuning driven by measurement rather than guesswork.
24×7 MySQL Remote DBA
Day-to-day operational ownership of your MySQL fleet.
MySQL Upgrades and Migrations
Rehearsed major version upgrades and platform moves with rollback paths.
MySQL Break-Fix Engineering
Targeted engagements for a specific production problem that needs to end today.
24/7 Emergency DBA Coverage
Immediate response when a production database is down right now.
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.
Enterprise Database Support
One vendor-neutral team across PostgreSQL, MySQL, SQL Server and NoSQL.
— TALK TO A PRINCIPAL ENGINEER —
Get Enterprise MySQL Support From Engineers Who Have Carried the Pager
Whether you need 24×7 cover for a revenue-critical 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.