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

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 first-line triage layer and no per-incident charge.

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.

MySQL 8.0 is: Oracle moved it to Sustaining Support on 21 April 2026 (mysql.com, checked 20 October 2026), so Oracle no longer ships new fixes for it. The 8.4 LTS series is the supported line to move to. AceMQ supports both around the clock, runs the 8.0 to 8.4 upgrade, and OSSeva can supply patched 8.0 Community builds if the upgrade has to wait.

It depends on the engine. REPAIR TABLE only helps MyISAM, ARCHIVE and CSV tables. For InnoDB the usual route is to restore the last good backup and replay the binary logs to the point just before the damage. If there is no usable backup, innodb_force_recovery lets the server start in a restricted mode so the data can be dumped and reloaded into a clean instance. We run this against a copy first, because the higher recovery levels can make the damage worse.

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.

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 worker configuration and, on 8.0, binlog_transaction_dependency_tracking, 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.

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.

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. Where you need security patches on a version you cannot yet leave, AceMQ's OSSeva platform provides patched builds of MySQL 5.7 and 8.0 Community Edition after Oracle stops fixing them.

Oracle sells technical support as part of MySQL Enterprise Edition, which also includes tools such as MySQL Enterprise Backup, Enterprise Audit and the monitoring console, and covers releases inside Oracle Lifetime Support. That is the only source of product fixes, and worth keeping for Enterprise customers on a supported release. It does not cover MySQL Community Edition, Percona Server, cloud-hosted MySQL, or any version in Sustaining Support, which since April 2026 includes MySQL 8.0. AceMQ provides MySQL support for all of those: expert MySQL support engineers on call around the clock for the MySQL server you actually run, with the reliability, scalability and uptime work that keeps incidents from recurring. Where a fault is a genuine defect on a supported Enterprise release, we prepare the Oracle case with the diagnosis done.

MySQL 5.7, 8.0, 8.4 LTS and the innovation releases, on Community Edition, Enterprise Edition and Percona Server, plus MariaDB estates that grew out of MySQL. Platforms covered are on-premises, self-managed in any cloud, Kubernetes with the common operators, and managed services such as Amazon RDS and Aurora MySQL, Azure Database for MySQL and Cloud SQL, where the provider runs the server and we cover schema, queries, replication behaviour and the upgrade calendar the provider imposes. High availability with Group Replication, InnoDB Cluster or Orchestrator, backup and point-in-time recovery, and upgrades from 5.7 through 8.0 to 8.4 LTS are all in scope.

Beyond incident response, the contract covers the work that prevents incidents: query and index reviews from the slow log and performance schema, InnoDB buffer pool and redo sizing, replication topology and lag monitoring, connection pooling with ProxySQL or in the application, online schema change tooling for large tables, and backup restores that are actually rehearsed. Each review leaves documented configuration and a runbook, so the next problem is handled faster whether or not we are on the call.

Yes. MySQL 8.0 moved to Sustaining Support in April 2026, so most estates are now planning the 8.4 LTS move. The usual surprise is authentication: mysql_native_password is disabled by default in 8.4 and removed in 9.0, so clients and accounts still using it fail to connect after the upgrade. We find those accounts and drivers first, test the application against 8.4 on a replica, and cut over with a rehearsed rollback.

With a baseline health check rather than waiting for the first outage. We review configuration, replication topology and lag history, the slow log, backup and restore evidence, and the versions and CVEs that apply to your builds, then agree access and escalation paths for incidents. The written findings rank what is most likely to page you next, so MySQL support starts by removing known risks while the 15-minute emergency response is already in place.

Yes. MySQL consulting from AceMQ is project work with a written outcome, run by the engineers who also answer the pager: the 8.0 to 8.4 LTS upgrade, a replication and HA review, query and index tuning, or an online schema change on a large table. Many teams start with one project and keep the support contract afterwards.

Yes. AceMQ works on MySQL in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.

Every AceMQ proposal is tailored to your requirements: your MySQL environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how MySQL is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.