MySQL often gets attention only when it slows down or stops. Our DBAs look after it all the time, on your own servers and on managed services such as Amazon RDS and Aurora: we find what is slowing it down, keep replication healthy, make sure backups restore, plan upgrades, and answer when something breaks.
What we cover
Performance
Slow MySQL usually has an ordinary cause: a query without the right index, a table design that no longer fits the data, server settings left at their defaults, or a bottleneck in disk I/O, memory or CPU. Sometimes it is another process, such as a backup job running at the busiest hour. We use the slow query log, the Performance Schema and the sys schema to find where the time goes, and fix the cause rather than adding hardware.
Monitoring
We watch replication status and lag, long-running queries and lock waits, deadlocks, connection counts, disk space and binary log growth, and the error log, including the permission and file-system errors that stop a server from starting. We fit in with the monitoring you already have, and when an alert matters we tell you what it means and what we are doing about it.
Backup and recovery
A logical dump on its own is slow to restore and cannot recover changes made after it ran. We combine physical or logical backups with binary logs, so a database can be recovered to a point in time, and we restore them on a schedule to prove that they work. When tables are corrupted or badly fragmented we repair or rebuild them, and we keep a written recovery runbook so the steps never depend on memory.
Replication and availability
We set up and maintain source-replica replication with global transaction identifiers (GTIDs), Group Replication and InnoDB Cluster where you need automatic failover, and read replicas that spread reporting load. On Amazon RDS and Aurora we configure Multi-AZ deployments and replicas. Whatever the setup, we test failover together with the application, so you know what users will see.
Patching and upgrades
Each MySQL release line reaches an end of life, after which it gets no more fixes, and managed services set their own deadlines for moving on. We check your schema, queries and settings against what changes in the new version (reserved words, the default authentication plugin and SQL modes), rehearse the upgrade on a copy, compare performance and plan a window with a way back. Minor releases are applied on a schedule you approve.
On call
When a server will not start, replication breaks or a query locks the tables your website needs, you reach DBAs who already know how your databases are set up. We find the cause, fix it or walk your team through the fix, and follow up in writing with what will stop it happening again. The hours we cover, and how to reach us outside them, are agreed at the start.
How we work
We usually begin with a health check: configuration, users and privileges, backups (with a test restore), replication, the slowest queries and capacity, in a written report ranked by risk. Then you choose ongoing remote DBA cover from named DBAs, a project such as an upgrade or a move to a managed service, or help when you need it. We work through named accounts with only the privileges the job needs, and every change is logged.
Case studies
Client names are withheld. We are happy to share details on a call.
DeliveredFixed within hours
Not disclosed
A client's in-house team had worked an unstable production database for some time without finding the cause. Our DBAs joined a secure screen-share, found the root cause and gave them a step-by-step plan to recover and to prevent a repeat.
Root cause found and fixed within hoursPrevention plan handed to the client's teamQuestions
Yes. The provider runs the servers, but tuning, schema changes, replicas, backups and upgrades are still yours to manage. We handle them through parameter groups and the provider's tools, with the same monitoring and tuning as on your own servers.
Often not. A few expensive queries, missing indexes or settings left at their defaults are the usual causes, and they cost less to fix than new hardware. We find the cause first; if more hardware is the answer, you will know exactly what kind and why.
Yes. MySQL 5.7 no longer receives fixes, so moving off it matters. We check for incompatibilities, rehearse the upgrade on a copy and plan the cut-over, and on Amazon RDS we plan around the provider's own timeline for the old version.
Yes. Our heterogeneous migration team moves databases between engines, for example from MySQL to PostgreSQL or to Oracle, converting the schema and code and validating the data before the switch.
Through the route your security team approves, such as a VPN, a jump host or a screen-share your staff control. Each DBA has a named account with only the privileges the work needs, and we agree in advance which systems and data are in scope.
From the blog
March 7, 2023
February 27, 2023
November 16, 2022
Related services
Move to the cloud, build for it
Trusted data, reports and analytics agents
Support, security and monitoring from one MSP
On-site IT support across New Jersey, New York City and Philadelphia. Remote services wherever you are. Areas we serve →
Tell us where your MySQL databases run and what is going wrong. We suggest where to start: a health check, a project or ongoing cover.
A few lines is enough. The engineers who do this work will reply within one business day.
Or email it.services@princetonits.com or call +1 (212) 507-9350.
Princeton IT Services