MySQL database services for production teams.
JusDB provides MySQL database services for scoped projects, ongoing remote DBA coverage, production support, performance tuning, migrations, and high availability across Amazon RDS, Aurora, Cloud SQL, Azure, and self-managed environments. 24x7 on-call is available under your service agreement.
Or request a free audit of one database instance. Already in an incident? See MySQL support.
- NDA before access
- Read-only by default
- Changes measured against your baseline
MySQL version status
Pick the version you run
MySQL 9.7 LTS
Newest LTSThe newest long-term support (LTS) release, generally available since April 2026. Releases after 9.7 use year and month version numbers, such as 26.7.
MySQL supports upgrading to 9.7 LTS from 8.4 LTS, so a database on 8.0 moves to 8.4 first.
Plan a MySQL upgradeMySQL 8.4 LTS
Supported LTSA long-term support line, generally available since April 2024. Oracle gives each LTS line five years of Premier Support and three years of Extended Support.
MySQL 8.4 disables mysql_native_password by default, so accounts and clients that still use it need moving before the upgrade.
Plan an 8.0 to 8.4 upgradeMySQL 8.0
End of lifeCommunity end of life came in April 2026, and 8.0.46 was the last release.
On Amazon RDS, MySQL 8.0 left standard support on 31 July 2026, and instances still on it are enrolled in paid RDS Extended Support by default.
Plan the upgrade off 8.0MySQL 5.7
End of lifeEnd of life since October 2023, with no community fixes after that.
An upgrade from 5.7 goes through 8.0 first, because MySQL does not support moving from 5.7 straight to 8.4.
Keep 5.7 running while you upgradeVersion status from the MySQL documentation, Oracle's lifetime support policy, and Amazon RDS, checked 27 October 2026.
- Platforms
- Amazon RDS, Aurora, Google Cloud SQL, Azure Flexible Server, your own servers, and Kubernetes
- High availability
- InnoDB Cluster, semi-synchronous replication, Orchestrator, and ProxySQL
- Incidents
- Initial-response targets are set in your service agreement. See the targets
Symptoms
Eight MySQL problems we are asked to fix
Each one has a cause we can measure. The scoping call starts from the symptom you see and the version and platform you run.
Replica lag climbs during batch jobs and has not caught up by the next run, so reads go stale and a failover is no longer safe.
A schema change needs an outage window because ALTER TABLE on a large, busy table waits for a metadata lock, and every query behind it waits too.
InnoDB settings were sized for an older server so the buffer pool sends reads to disk, and a redo log that fills before pages are flushed stalls writes.
Deadlocks and lock wait timeouts reach the application daily and nobody has traced the transactions and lock order behind them.
The upgrade off 5.7 or 8.0 keeps slipping after community support ended, and Amazon RDS now bills Extended Support for both versions.
Connections pile up until max_connections is reached and the cause, whether pool sizing, a slow query, or a lock, has never been isolated.
Replicas drift from the primary after a write on a replica or a skipped transaction, and nobody has run pt-table-checksum to compare them.
The Amazon RDS or Aurora bill keeps rising while the workload stays flat, because larger instances stand in for missing indexes and slow queries.
If one of these is costing your team time, a scoping call is the place to start.
Book a 30-min scoping call (opens Google Calendar in a new tab)Failover
How an untested failover loses MySQL writes
Asynchronous replication confirms a commit to your application without waiting for any replica to receive it. If the primary fails at that moment, the replica you promote is missing those transactions.
One primary, two replicas, three outcomes
Choose a state to see where the writes go.
Application and routing
ProxySQL sends writes to the primary and sends reads only to replicas inside the lag limit you set.
Primary
Takes every write
Healthy
Replica 1
Semi-synchronous: has each commit before it is acknowledged
Current
Replica 2
Asynchronous: applies the binary log a little behind
Slightly behind
The application sees one primary. Reads can go to the replicas, and the lag limit keeps a stale replica out of the read pool.
Application and routing
Some connections still point at the old primary until DNS or the connection pools refresh.
Old primary
Failed, then came back with writes no replica has
Errant GTIDs
Replica 2, promoted
Was behind when the primary failed
Missing commits
Replica 1
Still replicating from the old primary
Not repointed
The promoted replica never received the last commits, but the application had already reported them as saved. Those transactions now exist only on the old primary, which disagrees with the new one.
Application and routing
ProxySQL moves writes to the new primary once it sees read_only switch off there.
Old primary
Fenced with super_read_only before it rejoins
Read only
Replica 1, promoted
Received every acknowledged commit
New primary
Replica 2
Repointed with GTID auto-positioning
Following
With lossless semi-synchronous replication (AFTER_SYNC), the primary acknowledges a commit only after a replica has it in its relay log, so the promoted replica holds every acknowledged commit. If no replica answers within rpl_semi_sync_source_timeout, the primary falls back to asynchronous replication, so we alert on that fallback. The runbook was rehearsed on a copy first.
We choose the replication mode per workload: semi-synchronous replication or Group Replication (InnoDB Cluster) where losing an acknowledged commit is not acceptable. Every replica runs with read_only and super_read_only, so a stray write cannot create an errant GTID.
We promote only a replica whose GTID set contains every other replica's, repoint the rest with GTID auto-positioning, and rehearse failover and a point-in-time restore on a copy before production depends on them. On Aurora, replicas share one storage volume and AWS runs the failover, so that review covers failover priority tiers, reader endpoints, and how your application reconnects.
What we cover
Full-spectrum MySQL engineering
From a 4-second query to a low-downtime cutover: slow-query log, EXPLAIN ANALYZE, pt-query-digest, and Performance Schema drive every change, measured against your baseline.
Performance tuning
We read the execution plans of your slowest statements before changing anything, and measure every change against your baseline.
- EXPLAIN ANALYZE and pt-query-digest on the real workload
- Covering indexes and query rewrites
- Lock waits and deadlocks traced to the transactions behind them
High availability
Failover designed around the data loss and downtime your business can accept (RPO and RTO), then drilled.
- InnoDB Cluster (Group Replication) with MySQL Router
- Semi-synchronous replication with Orchestrator or ProxySQL
- Failover drills against the agreed target
Replication and scaling
Replicas that keep up with the primary, and reads sent only to replicas that are current.
- Multi-threaded replicas tuned for lag
- Read routing with ProxySQL lag limits
- Cross-region read replicas
Percona expertise
Percona Server for MySQL and the Percona tools, set up so your team can keep running them.
- XtraBackup plus binary logs, with point-in-time restores tested
- PMM dashboards and alerting
- pt-online-schema-change and pt-table-checksum
Migration and cloud
Version upgrades and platform moves with a tested way back (a rollback plan).
- Upgrades to 8.4 LTS from 8.0, and from 5.7 through 8.0
- mydumper, myloader, and AWS DMS
- Moves between your servers, Amazon RDS, Aurora, Cloud SQL, and Azure
Security and compliance
Access, encryption, and audit settings reviewed against the controls your auditors ask about.
- Accounts moved off mysql_native_password, with least-privilege grants
- TLS, encryption at rest, and audit logging
- Control mapping your auditors can read
Incident support
A critical (P1) page, answered within your agreement's target
JusDB keeps your recovery procedures (runbooks) written down, so an incident starts from a known plan instead of a blank page.
Initial-response targets
2 to 4 hours
Business hours
During covered business hours
30 minutes
24x7 on-call
P1 incidents
Our engineering team is in India; business-hours coverage is Mon–Fri 09:00–18:00 IST (UTC+5:30), and 24x7 on-call is available under your service agreement.
Initial-response targets, not resolution guarantees. The target for your engagement is set in your service agreement.
What happens on a P1 page
Page
You page the on-call engineer
Through the escalation path your service agreement names.
Triage
Root cause from the slow-query log and Performance Schema
Lock waits, replica lag, and runaway statements traced to the transaction behind them.
Mitigate
Stabilize first, from the runbook
Kill the blocking session, fail over, or shed load, then fix the cause once production is steady.
After
A review after every P1
What happened, why, and the change that stops it happening again.
Before and between incidents
- Your setup, written down firstDuring onboarding we record your versions, replication topology, routing rules, and backup procedures, so an incident starts with context.
- One escalation path, in writingYour service agreement names how to reach the on-call engineer and in which hours.
- Reviews between incidentsWe review query performance, replication, capacity, and backup health, and report open risks with recommended next steps.
- Version dates trackedWe track MySQL and cloud end-of-life dates for the versions you run and plan upgrades before support ends.
Process
How a MySQL engagement runs, step by step
Written findings come before any change. Your team approves production changes, except routine actions you have pre-approved.
Scoping call
Your databases, versions, platforms, and what you need covered.
Read-only review under NDA
Our engineers use named accounts with only the permissions the review needs, then read your configuration, slow-query log, Performance Schema, and replication state.
A written report before any change
Each finding comes with the change we propose, how we will measure it, and a way to undo it (a rollback plan).
Changes, then handover
We rehearse risky changes on a replica or a copy, apply them in the windows you approve, measure them against the baseline, and hand over updated operating instructions (runbooks).
Step one is a 30-minute scoping call.
Book a 30-min scoping call (opens Google Calendar in a new tab)Ways to work
Choose the MySQL service your team needs
Start with the responsibility you need covered. Each engagement has its own scope, deliverables, access requirements, and acceptance criteria.
Projects
Scoped MySQL projects
A defined piece of work with written findings, hands-on changes, and validation against your baseline.
- MySQL consultingArchitecture decisions, performance problems, upgrades, and recovery plans, scoped as one project.
- Performance tuningSlow queries, locks, and InnoDB settings, measured before and after.
- Migration and upgradesVersion upgrades and platform moves with a rollback plan.
- High availabilityFailover design and drills for replication and InnoDB Cluster.
- NDB ClusterDesign and operations for MySQL NDB Cluster, the distributed, shared-nothing engine.
- Security auditAccess, encryption, and audit settings, with a written report.
Ongoing
Ongoing coverage and support
JusDB monitors the databases, carries out the agreed maintenance, and responds to incidents during the coverage the proposal names. The team keeps a change record, recovery procedures, and a review after every P1.
Where your MySQL runs, and the tools around it
Your team and ours
What a managed MySQL service still leaves to your team
Managed cloud databases automate much of the infrastructure layer, but your team still owns query performance, capacity, cost, and incident decisions.
| Question | Managed cloud service | Your own servers or Kubernetes |
|---|---|---|
| Servers, storage, and minor patches | The provider runs them. | Your team, or JusDB under your agreement. |
| Backups and restores | Automated backups and point-in-time restore are built in. Testing a restore is still your team's job. | Your team schedules XtraBackup and keeps the binary logs that a point-in-time restore needs. |
| Failover | The provider runs it. Your application still has to reconnect cleanly. | You choose it and run it: InnoDB Cluster, Orchestrator, or semi-synchronous replication behind ProxySQL. |
| Slow queries, locks, and schema changes | Yours. The provider runs the platform, not your queries. | Yours. |
| Versions and end of life | The provider's calendar. Past standard support, Amazon RDS enrolls instances in paid Extended Support. | Your calendar. Community fixes stop at end of life. |
| Moving off later | A logical dump or binary log replication to another MySQL target. | Data files and binary logs move with physical backups and replication. |
Your team keeps control
- Set business priorities, application requirements, and release plans
- Approve production changes, except routine actions you have pre-approved
- Own your cloud accounts, access policies, and vendor relationships
- Decide when maintenance can happen and how quickly service must recover
- Move the work in-house or to another provider after your agreement's notice period, with your data returned or deleted and the transition help your agreement sets out (Terms, section 8)
JusDB handles the agreed database work
- Monitor database health, investigate alerts, and involve the right people
- Review query performance, replication, capacity, and backup health
- Carry out approved changes and update the operating instructions they affect
- Report completed work, open risks, and recommended next steps
Weighing a managed service against running MySQL yourself? We compare both against your workload on a scoping call.
Book a 30-min scoping call (opens Google Calendar in a new tab)Further reading
MySQL guides, a comparison, and a sizing tool
Guides from our blog on connections, binary logs, tuning, and the 8.0 upgrade, plus a comparison and a calculator.
Guide
AWS RDS max connections and pool sizing
The memory formula behind the limit, sizing connection pools, and when RDS Proxy or ProxySQL helps.
Guide
MySQL binary log retention and purging
binlog_expire_logs_seconds, safe purges, and keeping binary logs from filling the disk, on Amazon RDS too.
Guide
MySQL performance tuning
The buffer pool hit ratio, indexes that slow your writes, and the settings that matter first.
Guide
MySQL 8.0 end of life: upgrading to 8.4
The breaking changes to fix before the upgrade, starting with mysql_native_password.
Comparison
MySQL vs PostgreSQL
Clustered indexes against heap tables, purge against VACUUM, and how each one replicates.
Calculator
MySQL memory and settings calculator
Estimate the buffer pool, per-thread buffers, and a safe max_connections for your server's memory.
FAQ
Common MySQL questions
What buyers ask about MySQL support hours, upgrades, distributions, and query tuning.
Still have a question?
Ask it on a scoping call. No production access needed.
Book a 30-min scoping call (opens Google Calendar in a new tab)Do you provide 24/7 MySQL support?
Yes. JusDB provides 24x7 on-call for MySQL under your service agreement; without it, coverage is business hours. Initial-response targets are 2 to 4 hours during covered business hours, Mon–Fri 09:00–18:00 IST (UTC+5:30). Where your service agreement includes 24x7 on-call, the initial-response target for P1 incidents is 30 minutes. Targets are not resolution guarantees.
How do you plan a MySQL upgrade cutover?
JusDB plans each MySQL upgrade as a cutover to a new replica or a blue/green copy, with validation and a rollback plan. We move 8.0 databases to 8.4 LTS, and 5.7 databases through 8.0 first, because MySQL does not support a direct upgrade from 5.7 to 8.4. Before the cutover we check removed features, changed defaults such as mysql_native_password, and query plans on the new version. JusDB does not guarantee one cutover duration.
What MySQL distributions do you support?
JusDB supports Oracle MySQL, Percona Server for MySQL, and MariaDB on your own servers, VMs, or Kubernetes, and managed MySQL on Amazon RDS, Aurora, Google Cloud SQL, and Azure Database for MySQL Flexible Server. MariaDB is also available as a managed service on Amazon RDS.
How do you tune slow MySQL queries?
JusDB starts from the slow-query log, pt-query-digest, and Performance Schema to find the statements that cost the most time, then reads their execution plans with EXPLAIN ANALYZE. The fixes are indexes, query rewrites, and InnoDB settings, each measured against your baseline.
Next step
Talk to a MySQL engineer about your databases
Tell us what is slow, fragile, or due to change. The first 30-minute call covers your databases, current ownership, and required coverage. No production access is needed. Or request a free audit of one database instance, subject to availability: mutual NDA before read-only access, a prioritized report within one week after access is ready, and no obligation.
NDA before access, read-only by default, and written scope first
Compare with other databases
If you are weighing alternatives, these are the databases most often compared with this one.
PostgreSQL
Teams compare it with MySQL for JSONB indexing, extensions such as PostGIS, and moves off Oracle.
MongoDB
For deeply nested documents and varied event payloads that fit a relational schema poorly, teams often run MongoDB beside MySQL.
SQL Server
Common where the stack already runs on Windows and .NET, or where SQL Server licenses are already in place.
TiDB
MySQL-compatible and horizontally scalable, an option when a sharded MySQL setup becomes hard to run.