Skip to content
Menu

Category: Databases

Managed MySQL and MariaDB in your account: replicas, backups and tested upgrades

The database behind your online shop, your ERP or your application, with a replica, backups we know how to restore and a clear path off unsupported versions.

Where it runs
In your account, in your name
Backups
With tested restores
Updates
Planned and documented

In short

MySQL and MariaDB are open source relational databases widely used in websites, online shops and business applications. Administering them means answering for them being available, fast and recoverable. We set up GTID replicas or Galera clusters where they fit, physical backups with point-in-time recovery that we restore in tests, metrics, slow query review and rehearsed upgrades.

Book a 20-minute callinfo@podsre.com

What do we take care of?

MySQL and MariaDB usually sit underneath something that brings in revenue: an online shop, an ERP, a CRM or the company’s application. Many have been on the same server for years, with the default configuration and a nightly backup that nobody has ever restored. We make sure that changes without stopping your business.

  • InnoDB and configuration

    Buffer pool memory, transaction log, connections and SQL mode.

  • Replicas

    GTID replication, asynchronous or semi-synchronous, or Galera on MariaDB.

  • Proxy

    ProxySQL or MaxScale to spread reads and switch primary.

  • Backups and binlogs

    Physical backups and archived binlogs for point-in-time recovery.

  • Metrics

    mysqld_exporter in Prometheus: replication lag, queries, locks and disk.

  • Access

    Per-application users, passwords kept out of the code and TLS.

What kind of replication do we set up?

Always with GTID, which identifies each transaction and lets you point a replica at another primary without hunting for binlog positions by hand. The important choice is how much you can afford to lose if the primary goes down.

Situation What we set up What it means
Losing a few seconds and a short outage is acceptable Asynchronous replication with GTID Simple and no cost on writes; failover is decided by us or by an orchestrator
No committed transaction can be lost Semi-synchronous replication The primary waits for a replica to receive each transaction; it adds some latency
Several nodes that write and immediate failover (MariaDB) Galera Cluster with three nodes No data loss, but sensitive to the network and to large transactions
Provider with a managed database RDS, Cloud SQL, Azure Database or another The provider handles failover; we tune, monitor and test restores

In front we put ProxySQL with MySQL or MaxScale with MariaDB: applications always connect to the same place, heavy reads can go to the replica and a change of primary does not mean editing anyone’s configuration. And a replica is no substitute for a backup: a DROP TABLE reaches every node almost at once.

What problems do we come across most often?

  • An unsupported version: MySQL 5.7 or 8.0, or a MariaDB outside its LTS cycle, with no security patches.
  • A replica broken without warning: it stopped on a duplicate key error weeks ago and nobody noticed.
  • Binlogs filling the disk: no expiry configured, or retained by an abandoned replica.
  • Tables without a primary key: they slow down row-based replication and cause problems in Galera.
  • Queries without an index: a listing that works fine with a thousand rows and brings the server down with a million.
  • Everything as root: the application, the backups and the people all log in with the same user, sometimes from the internet.

How do we take and test backups?

With Percona XtraBackup on MySQL or mariabackup on MariaDB we take hot physical backups, without locking the database, and we continuously copy the binlogs to object storage in another account or with another provider, encrypted. Restoring means applying the backup and replaying the binlogs up to the minute you choose. At least once a month we actually do it on a test server, check that it starts, that the replica can be rebuilt from there and run some control queries. The time it takes is your real recovery time, and it is written down in the report.

How do we upgrade versions?

In MySQL you can only move from one series to the next: from 5.7 to 8.0 and from 8.0 to 8.4 LTS. Beforehand we review new reserved words, changes to SQL mode, the character set and authentication, because 8.4 disables the old mysql_native_password by default and some old applications can no longer connect. In MariaDB we move from one LTS to the next, for example from 10.6 to 10.11 and then to 11.4. The safest method is to bring up a replica on the new version, let it sync, test the applications against it and switch the primary in a short cutover. If it goes wrong, the previous version is still there.

How do we find slow queries?

We enable the slow query log with a sensible threshold, aggregate it with pt-query-digest or Performance Schema and give you the handful of queries that take up most of the time, with the index or change we propose for each one. You almost always gain more there than by upgrading the server.

When do we recommend your provider’s database?

When it exists for your engine, the workload is normal and you do not need plugins or parameters that the service does not allow. RDS, Cloud SQL, Azure Database for MySQL or the managed databases from DigitalOcean and OVHcloud handle patching and failover well. We run MySQL or MariaDB ourselves when the provider does not offer it, as with Hetzner, when you need Galera or MariaDB-specific features, or when the cost of the managed service grows faster than the database. In both cases automated monitoring is continuous; human response is during business hours, as in SRE as a service. The metrics end up in monitoring with Grafana and Prometheus.

Where do we set it up?

In your account, with the provider you already use or the one that fits best. If the data has to stay in the EU, Hetzner and OVHcloud are the European options.

Providers we set it up on

  • Hetzner
  • AWS
  • Google Cloud
  • Azure
  • DigitalOcean
  • OVH
  • Own server
ProviderHow we set it upThings to bear in mind
HetznerCloud or dedicated servers with MySQL or MariaDB, a replica or Galera on a private network and binlogs archived in Hetzner Object Storage.Hetzner does not offer a managed database: we set up the replica, the load balancing and the backups.
AWSRDS for MySQL, RDS for MariaDB or Aurora MySQL when they fit; otherwise, EC2 with GTID replication and backups to S3.We review parameter groups, read replicas, backup retention and that restores actually work.
Google CloudCloud SQL for MySQL with regional high availability, or Compute Engine with a replica and backups to Cloud Storage.Cloud SQL does not offer MariaDB: if you depend on MariaDB-specific features, it runs on virtual machines.
AzureAzure Database for MySQL (flexible server), or virtual machines with MySQL or MariaDB.Azure retired its managed MariaDB service; anyone using it has to move to MySQL flexible server or to their own machines.
DigitalOceanDigitalOcean managed MySQL with standby nodes, or Droplets with MySQL or MariaDB.Simple for small and medium workloads; we check the connection limits of the plan.
OVHOVHcloud managed database for MySQL, or Public Cloud instances with a replica or Galera.
Own serverMySQL or MariaDB on your servers or virtual machines, with the replica on another physical machine and backups to external S3 storage.Galera needs three nodes and a stable network between them; with two, one failure leaves the cluster without quorum.

What is included

  • Asynchronous or semi-synchronous replication with GTID, or a Galera cluster on MariaDB when the workload calls for it.
  • ProxySQL or MaxScale in front, to spread reads and switch primary without touching the applications.
  • Physical backups with Percona XtraBackup or mariabackup and binlogs archived off the server, encrypted.
  • Regular point-in-time test restore, with the time measured in the report.
  • Metrics with mysqld_exporter and alerts on replication lag, disk, connections and locks.
  • Review of the slow query log, indexes and InnoDB memory.
  • Upgrades from 5.7 to 8.0 and 8.4 LTS, or between MariaDB LTS versions, rehearsed first on a copy.
  • One user per application with minimal privileges, TLS and access only from the private network.

Frequently asked questions

We are still on MySQL 5.7 or 8.0; is upgrading urgent?

Yes. MySQL 5.7 stopped receiving patches in 2023 and the 8.0 series reached end of life in April 2026. The sensible target is 8.4 LTS, going through 8.0 if you are coming from 5.7, because you cannot jump straight there. We rehearse it first with a copy of your data and your applications.

MySQL or MariaDB?

If you already have one running, switching is hardly ever worth it. Today they are different products: replication, the GTID format and some features do not match, so a migration between them is treated as a project, not an upgrade. For something new, we decide based on what your application and your provider support.

Do we need a Galera cluster?

Rarely. Galera gives you writes on several nodes and failover without data loss, but it requires three nodes, a low-latency network and tables with a primary key, and large transactions slow it down. For most workloads a primary with a replica and ProxySQL or MaxScale in front is enough.

Is mysqldump enough for us?

For small databases, as a complement. A logical backup takes a long time to restore as the database grows and only recovers to the moment it was taken. With a physical backup and archived binlogs you can recover to the minute before an accidental deletion, in much less time.

Do you also manage PostgreSQL or MongoDB?

Yes, with the same approach of replicas, tested backups and planned upgrades. You will find the details on the PostgreSQL and MongoDB pages.

Tell us about your case

In a free 20-minute call we look at where you are and where to start. No commitment.

Book a 20-minute call

Official documentation consulted

The technical details on this page are based on:

Reviewed on

WhatsApp