MySQL Support and Consulting

We run MySQL support under a single scope. Performance, high availability, backup and security are all covered by the same team.

$ mysqladmin extended-status | grep -E 'Threads_running|Slow_queries'
Threads_running 214
Slow_queries 31,482
$ gofast-cli digest --order-by Query_time:sum --limit 1
1 SELECT shop.order_items 68.4s 61%
→ missing index found, recommendation ready

We manage your MySQL systems end to end

Database problems rarely stay inside one area. A slow query overruns the backup window; a badly designed replication setup lengthens recovery time. We do not run the four areas separately.

Performance tuning

We establish the cause of the slowdown from the slow query log and performance_schema data. Grouping query patterns with our own tool GoFast, we identify which query is consuming the total time, and we report the effect of index and configuration changes with before and after measurements.

High availability

We install InnoDB Cluster, Group Replication and Galera Cluster, and design connection routing on the application side with ProxySQL. Failover behaviour is proven by rehearsing it.

Backup and recovery

We set up physical backups with Percona XtraBackup and logical ones with mysqldump and mydumper. Binary log archiving gives point-in-time recovery (PITR), and restore tests run automatically on a schedule.

Security and technical measures

We configure InnoDB encryption with the keyring component, and set up audit logging and data masking through the open source components of Percona Server. The privilege matrix is arranged around the principle of least privilege.

What does MySQL support cover?

A request for MySQL support usually covers three different needs at once. Which of them we take on is decided together at the contract stage.

Incident response. The production database may be unresponsive, replication may have stopped, or a disk may have filled up. We connect to the system, establish the cause, and return the database to a working state. Afterwards we report the root cause of the incident and the fixes that will keep it from recurring.

Continuous maintenance. We set up the monitoring stack, verify regularly that backups are being taken and can be restored, plan version and security patches, and track the capacity trend. As part of proactive monitoring we assess load and slow query measurements in near real time, and report problems before they surface. The scope of the service and the response times are set in the contract.

Consulting and projects. This covers work with a defined beginning and end: a new cluster architecture, a version upgrade, a data migration or a performance engagement. Along with the working system we hand over the installation configuration and the runbook.

All three needs exist at the same time in most organisations, and “we have support” means something different in each. We define the scope by the work to be done, not by the name of the need.

We set the scope of support from the MySQL distribution

MySQL is not a single product. The differences between the three distributions we meet most often in production directly determine which technical measure can be applied.

MySQL Community Edition is the distribution Oracle publishes under the GPL, and the most widely used one in Turkey. Components that corporate audits ask for — audit logging and data masking — are not present in it.

Percona Server for MySQL is a fully open source distribution built on the same core. It provides the missing components with open source equivalents. For organisations on Community Edition that develop a need for audit logging, we carry out the migration ourselves. Because the data files are compatible, the change requires nothing on the application side. We run this migration independently of the vendor as well; our right to install and integrate comes from the distribution’s open source licence.

MariaDB is an independent product that diverged from the MySQL code base. Because its replication, cluster and backup tooling differ, MariaDB is covered separately on the MariaDB Support page.

On versions, support for MySQL 8.0 ended in April 2026, and no security patches are published for systems running it. As the upgrade target we plan the move to 8.4 LTS over replication with a rollback plan ready, and set it out in detail on the MySQL 8.0 to 8.4 Migration page.

We choose the replication and cluster topology from your downtime target

High availability has more than one meaning on the MySQL side. Which topology we build is determined by the acceptable downtime (RTO) and the tolerable data loss (RPO).

Asynchronous replication is the most common setup. Because the primary server sends a transaction to the replicas after committing it, transactions not yet sent can be lost at the moment of failover. It is simple to build and does not affect write performance.

Semi-synchronous replication does not return success to the client until the transaction is confirmed to have reached at least one replica. It reduces the risk of data loss markedly, and increases write latency by one network round trip.

Group Replication and InnoDB Cluster provide automatic failover on a quorum basis. Installed together with MySQL Router, the application keeps working without noticing that the primary has changed. InnoDB Cluster installation and consulting is the architectural request we receive most often on the MySQL side.

Galera Cluster, and Percona’s distribution built on that technology, Percona XtraDB Cluster, use synchronous replication with certification-based conflict detection. Every node can accept writes. Where an application writes to the same row from different nodes, we take conflict handling up together at the design stage.

ProxySQL sits in front of these topologies, between the application and the database. It separates read and write traffic, manages the connection pool, and holds queries in a queue during failover so the application does not receive errors. We treat ProxySQL installation and the design of the query rule set as an inseparable part of the cluster work.

A detailed comparison of the topologies, the failover rehearsals and the Patroni equivalent on the PostgreSQL side are on the High Availability and Cluster Solutions page.

MySQL support on managed cloud services

We also support organisations using Amazon RDS, Amazon Aurora, Google Cloud SQL and Azure Database for MySQL. A managed service gives no access to the operating system or the data files, the SUPER privilege is restricted, and physical backup tools such as XtraBackup do not run. The provider manages the backup and hardware layer.

Most of the performance work, on the other hand, is carried out in the same way. We arrange parameter groups around the workload, collect and analyse the slow query log through the provider’s log service, and correct the index design by examining execution plans. The number of read replicas and the instance sizing are taken up together, because they determine both performance and the monthly bill.

On a managed service the provider manages the hardware, the backups and the version upgrades, and does not manage query plans or index design. Those two areas remain the organisation’s responsibility — and therefore ours — on a managed service too.

How we work

We connect to your systems remotely under a non-disclosure agreement (NDA), through your jump host or your VPN. For our MySQL user we request only the privileges the work requires, and we record every change we apply.

The work starts with measurement. When we take on a MySQL system for the first time, we establish the version and configuration inventory, the replication topology, the state of backup and restore, the privilege matrix and the query profile of the workload. Our recommendations are built on that measurement. Changes destined for production are verified in a test environment first, and a rollback step is prepared in advance for each one. Every change is reported and approved by you before it is applied, and following the principle of change management we apply one change at a time. In addition to our own change record, we ask that a MySQL audit log be kept so everything we do can be followed on the server side.

We carry out the same work for PostgreSQL, MariaDB and MongoDB: PostgreSQL Support · MariaDB Support · MongoDB Support

The open source tool we use for slow query analysis: GoFast CLI

Our archiving tool, which permanently reduces the performance impact of growing tables: MySQL data archiving with GoArchive

Frequently asked questions

Yes, diagnosis needs access to the server. Access is opened after a non-disclosure agreement (NDA) is signed, by whichever method you specify — a jump host or a VPN. Our user's privileges are kept limited to the work in hand.

Yes, we offer incident response on its own. Response time changes markedly depending on whether we already know the system. On a MySQL system where monitoring is in place and we know the replication topology and the state of the backups, we reach the source of the problem far more quickly. In an environment we are connecting to for the first time, we first have to establish the version, the configuration and the state of InnoDB. For critical production systems we recommend at least a maintenance agreement covering monitoring and backup verification.

No. Community Edition is GPL licensed and can be used in production at no licence cost. Where audit logging or data masking is required, we set up the open source equivalents of those components with Percona Server. We do not propose a product that requires you to buy a licence.

Yes. On RDS and Aurora we carry out query and index optimisation, parameter groups, read replicas and capacity planning in the same way. Because tools that need operating system access do not run on a managed service, we take our measurements through the provider's monitoring and log services.

Support for MySQL 8.0 ended in April 2026, and no security patches are published for that version. The timing of the upgrade is set by your own risk assessment. On systems exposed to the internet or holding personal data, deferring the upgrade increases the number of unpatched vulnerabilities every month. The target version is 8.4 LTS. We plan the migration over replication, with a rollback plan in place.

Yes. We examine execution plans and index usage, including the queries an ORM generates, and we plan the necessary changes together with your development team. Rather than writing application code, we report which query is slow, why, and how to fix it.

Send us your MySQL support request