What does AceMQ MySQL support include?

MySQL support covers 24/7 emergency incident response with a 15-minute SLA, root cause analysis on every P1, query and index tuning, replication and HA review, online schema change planning, CVE and patch advisory, quarterly health checks, and upgrade or migration support. Every ticket goes to a named senior engineer assigned to your account. There is no tier-1 triage layer and no per-incident charge.

Do you support Amazon RDS MySQL and Aurora MySQL?

Yes, alongside self-managed, Percona, and MariaDB deployments. The distinction matters more than most vendors admit: Aurora MySQL replaces InnoDB's storage and redo handling with a distributed log-structured layer, so replica lag, failover behaviour, and buffer pool tuning all work differently from RDS MySQL or a self-managed server. We support all of them, and part of what you get is knowing which advice from the internet stops being true on your platform.

How fast do you respond to a MySQL production outage?

P1 emergencies — server unavailable, replication broken, disk full, tables locked — get a 15-minute first response with a senior engineer joining a live bridge. P2 critical issues are 1 hour, P3 high-priority 4 hours, and P4 standard questions next business day. These are contractual response times covering nights, weekends, and holidays.

Our replica lags for hours every night. Can that be fixed without new hardware?

Usually yes. Replica lag during batch windows is almost always a concurrency problem in the apply path rather than a throughput problem on the replica. Older versions apply serially by default, and even with parallel workers configured, a single transaction that updates millions of rows serialises everything behind it. We check transaction sizing first, then binlog_transaction_dependency_tracking and worker configuration, then whether row-based logging on wide tables is inflating the stream. Splitting the batch into bounded chunks fixes more of these than adding CPU ever does.

We need to alter a 500GB table. What are our options?

Not a blocking ALTER, whatever the version claims about online DDL. Some operations run INPLACE without a table rebuild, but many still copy, and even an INPLACE operation needs a brief exclusive metadata lock at the start and end that can queue behind one long-running SELECT and stall every query on the table. For large tables we use gh-ost or pt-online-schema-change to build a shadow copy with the throttle tied to your replica lag budget, then swap atomically. We rehearse against a restored copy first so the runtime and lag impact are measured rather than guessed.

Do you support MySQL 5.7 now that it is end of life?

Yes. We support 5.7 and older builds that no longer receive upstream patches, including backported mitigations and workarounds where official fixes are unavailable. Plenty of regulated and vendor-locked environments cannot upgrade on Oracle's timeline. In parallel we map the 8.x upgrade path, because that jump carries real breakage — the default authentication plugin, utf8mb4 collation changes, and reserved word additions all surface as client failures rather than server failures.

How is AceMQ MySQL support priced?

Support is an annual contract priced on environment size, required SLA tier, and coverage hours — not per incident and not per ticket. That structure exists so nobody hesitates to page us during an outage. Quotes are returned within 24 hours and scoped against your actual deployment rather than a server count on a form.

MySQL Support

24/7 MySQL Support with a 15-Minute Emergency SLA

AceMQ supports MySQL in production — replica lag from single-threaded apply, InnoDB gap locks deadlocking under REPEATABLE READ, ALTER statements that hold a metadata lock for hours, and binlogs quietly filling a volume. Self-managed, RDS, Aurora, or Percona. Every ticket reaches a named senior engineer.

Senior MySQL engineers on call right now — 24/7/365

15 min emergency SLA24 /7 global coverage130 + enterprise customers26 + countries served

Available Now

Book a free Consultation.

Prefer to chat first?

Prefer to E-mail?

info@acemq.com

Trusted for mission-critical MySQL by teams in finance, healthcare, defense, and telecom

Escalation Path

Your first hour of a MySQL outage

Most vendors publish an SLA number. This is what actually happens, minute by minute, when you page a senior AceMQ engineer.

T+0

You page us

Phone, email, or Slack — any channel reaches the on-call senior engineer directly. No web form, no tier-1 queue.

T+15

Named engineer live

A senior engineer who already knows your environment joins a live bridge. Zero cold-start, no re-explaining your topology.

T+30

Root cause isolated

Direct broker access, log and metric review, and a working hypothesis with a rollback plan before we touch anything.

Post

Written RCA

Documented root cause, the fix applied, and the prevention steps — delivered after every P1, not just when asked.

Response Times

SLA tiers, contractually guaranteed

Every tier reaches a senior MySQL engineer. There is no tier-1 triage layer to get through.

P1 — Emergency

15 min

Production down, messages not flowing, cluster or broker failure

P2 — Critical

1 hour

Severe degradation, rising error rates, approaching capacity limits

P3 — High

4 hours

Performance issues, configuration problems, non-critical failures

P4 — Standard

Next day

Questions, guidance, best practices, non-urgent improvements

Incident Triage

MySQL problems we fix every week

These are real symptoms from real MySQL production environments — and the first thing our engineers check when one comes in.

Symptom you're seeingWhat we check firstTypical resolution

Replica lag climbing into hours during the nightly batch

What we check firstWhether apply is actually parallel — replica_parallel_workers and replica_parallel_type, plus binlog_transaction_dependency_tracking. A single large multi-row transaction serialises the whole apply pipeline regardless of worker count, so we look at transaction size before we look at hardware.

Typical resolution1–2 hours

Disk read I/O spiking while query volume stays flat

What we check firstInnodb_buffer_pool_reads against Innodb_buffer_pool_read_requests for the real hit rate. An undersized buffer pool means the hot working set no longer fits, and every index lookup that used to be memory-resident becomes a disk seek.

Typical resolutionUnder 1 hour

Deadlocks and lock wait timeouts appearing under normal concurrency

What we check firstSHOW ENGINE INNODB STATUS for the last deadlock, then the access pattern behind it. Under REPEATABLE READ, gap and next-key locks on a secondary index range are taken far wider than developers expect, so two statements that look disjoint contend on the same gap.

Typical resolution1–2 hours

An ALTER TABLE has blocked writes for hours

What we check firstWhether that specific DDL is INPLACE or COPY on your version, and the metadata lock queue behind it — one long-running SELECT can block the ALTER, which then blocks every subsequent query on the table. For large tables we move the change to gh-ost or pt-online-schema-change.

Typical resolution2–4 hours

Binary logs filling the disk with no change in write volume

What we check firstbinlog_expire_logs_seconds against what is still reading the stream. A stopped replica or a paused CDC connector holds a position, and purge won't advance past a needed file. Row-based logging on wide-table updates also inflates binlog size dramatically.

Typical resolutionUnder 1 hour

"Too many connections" with the server mostly idle

What we check firstThreads_connected versus Threads_running and the count of long-sleeping connections. Usually an application pool with no max, or a framework opening a connection per request without returning it — raising max_connections buys hours, not a fix.

Typical resolutionUnder 2 hours

A report query became ten times slower after a data load

What we check firstIndex statistics freshness — InnoDB's sampled statistics can drift badly after a bulk load, flipping the optimizer to the wrong index. We run ANALYZE TABLE, review histograms for skewed columns, and check whether a GROUP BY is now spilling internal temp tables to disk.

Typical resolutionUnder 2 hours

After failover a replica refuses to start with a GTID error

What we check firstgtid_executed on both sides for errant transactions — writes applied directly to a replica that the new primary has never seen. These have to be identified and either injected as empty transactions or resolved by reseeding, and read_only enforcement fixed so it can't recur.

Typical resolution2–4 hours

Resolution times reflect typical MySQL engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.

Not on the list? Tell us what's breaking

Support In Practice

MySQL problems we've already solved

Representative engagements showing how these incidents get diagnosed and closed under an AceMQ support contract.

All use cases

Remediation

Memcached Slab Calcification and Eviction Remediation

Digital Commerce Platform

Emergency remediation of a Memcached tier evicting hot keys while reporting free memory, traced to slab class allocation.

MemcachedLinuxMySQL

Read case study

Assessment

Memcached Capacity and Hit Rate Assessment

B2B SaaS Platform Provider

Assessment of Memcached sizing, key distribution, and hit rate to determine whether adding capacity would actually help.

MemcachedLinuxMySQL

Read case study

Remediation

MySQL Replication Lag Remediation

E-Commerce Marketplace Operator

Resolving replica lag that grew to hours during batch windows because single-threaded apply could not keep pace with large multi-row transactions.

MySQLProxySQLPrometheus

Read case study

Support

MySQL InnoDB Lock Contention Support

Travel Booking Platform

Ongoing support for deadlocks and lock wait timeouts under booking concurrency, including history list growth from long-running transactions.

MySQLProxySQLPrometheus

Read case study

Assessment

MySQL Topology and Backup Recoverability Assessment

Media Streaming Provider

Review of replication topology, failover readiness, backup recoverability, and configuration drift across a MySQL estate that had grown organically.

MySQLPercona XtraBackupProxySQL

Read case study

What's Included

Everything in your MySQL support contract

No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.

Emergency Incident Response

Server down, replication broken, disk full, or a table locked behind a runaway DDL. A senior engineer joins a live bridge within 15 minutes with access to diagnose — not a ticket acknowledgement.

Root Cause Analysis

Every P1 closes with a written RCA: what failed, why, the fix applied, and the schema, index, or configuration change that stops it happening again. Delivered as standard, not on request.

Query & Index Tuning

EXPLAIN ANALYZE on your real slow log, composite index ordering, covering indexes, histogram statistics for skewed columns, and killing the temp-table spills that come from unindexed GROUP BY and ORDER BY.

Replication & HA Review

GTID hygiene, semi-synchronous replication trade-offs, InnoDB Cluster and Group Replication behaviour under partition, and failover automation that fails over for the right reasons.

CVE & Patch Advisory

Alerts for CVEs affecting your exact MySQL, Percona, or MariaDB build, with tested upgrade paths — including the 5.7 to 8.x jump where authentication plugin and collation changes break clients.

Online Schema Change & Migrations

Large table alterations with gh-ost or pt-online-schema-change, major version upgrades, and migrations between self-managed, RDS, Aurora, and Percona — planned with a rehearsed rollback.

Anywhere You Run It

We support MySQL wherever it's deployed

Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.

MySQL 5.7 (EOL) through 8.4Amazon RDS for MySQLAmazon Aurora MySQLAzure Database for MySQL Flexible ServerGoogle Cloud SQL for MySQLPercona Server & XtraDB ClusterMariaDBInnoDB Cluster / Group ReplicationKubernetes & OpenShift operatorsBare metal & on-premiseAir-gapped / no outbound accessHybrid cloud

Why AceMQ

What you get that you don't get elsewhere

Named Engineers, Zero Cold Start

The same senior engineers stay on your account. They know your schema, your replication topology, and your batch windows — so a P1 call starts with a hypothesis instead of twenty minutes of context transfer.

No Tier-1 Triage Layer

You reach a senior MySQL engineer directly by phone, email, or Slack. Nobody collects information to hand off, and there is no escalation approval between you and the person who can read an InnoDB status dump.

Schema Changes Without the Outage

Large table DDL is where most MySQL maintenance goes wrong. We plan alterations with gh-ost or pt-online-schema-change, measure the throttle against your replica lag budget, and rehearse the cutover before it touches production.

Aurora, RDS, and Self-Managed Are Not the Same

Aurora MySQL replaces the storage and redo layer outright, which changes failover, replica lag, and what buffer pool tuning even means. We support all three models and know which advice stops applying where.

Genuine Follow-the-Sun Coverage

Engineers across 26+ countries and every time zone. Your 3am replication break is someone's mid-afternoon — no overnight skeleton crew, no waiting for a region to come online.

Full-Stack, Not Just mysqld

We diagnose across the connection pool, the ORM's generated SQL, storage latency, filesystem and kernel settings, and Kubernetes. MySQL symptoms often have causes well outside the database process.

FAQ

MySQL support questions

Your MySQL Estate Shouldn't Depend on One Person's Memory

Whether you need emergency response tonight or a support contract that plans the next schema change properly, AceMQ staffs every engagement with a named senior MySQL engineer. Support quotes returned within 24 hours.

Get in Touch

Talk to a Support Expert

Send us a message and we'll follow up within one business day — or book a free 30-min consultation directly.

305-204-2607

info@acemq.com

66 W. Flagler St. 9th Floor
Miami, FL 33130

Prefer to talk now? Call us directly or use the consultation tab to find a time that works.