Replication that has drifted
Asynchronous replication with no GTIDs, a replica that has been behind for weeks, and no monitoring on lag. It looks like a standby right up to the moment you need it.

Get off MySQL 5.7, put real clustering in place, fix replication that has been drifting for months, and move to managed cloud without a bad weekend. Quoted as a fixed price against acceptance criteria you agree before we start.
The decisions that hurt — storage engine, character set, replication topology, buffer pool sizing — were usually made years ago by someone who has left. The work below is what it takes to get back to something supportable.
Asynchronous replication with no GTIDs, a replica that has been behind for weeks, and no monitoring on lag. It looks like a standby right up to the moment you need it.
MySQL 5.7 reached end of life in October 2023. Estates still on it get no security fixes at all, and the upgrade to 8.0 changes enough defaults that nobody wants to be the one who starts it.
MyISAM tables that cannot do transactions, latin1 columns that mangle anything outside ASCII, and utf8 that is not actually UTF-8. Each one is a migration, not a setting.
Each of these is scoped, quoted as a fixed price and signed off against acceptance criteria agreed before the work starts.
Sized against your real workload rather than a template: InnoDB buffer pool and log sizing, connection limits, a sensible sql_mode, utf8mb4 from the start, least-privilege accounts, slow query logging and a documented runbook. On-premises, Azure, AWS or Google Cloud.
GTID-based replication rather than file and position, semi-synchronous where the data loss matters, read replicas with ProxySQL routing so reporting stops competing with checkout, and monitored lag with alerting that reaches someone.
InnoDB Cluster with Group Replication and MySQL Router, Galera or MariaDB Cluster where synchronous multi-primary suits the workload, or Orchestrator for topology management on an existing estate. Failover demonstrated before handover.
Percona XtraBackup or MariaDB Backup for hot physical backups, binary log retention for point-in-time recovery, off-site copies, and a restore rehearsed against a stated RPO and RTO rather than assumed to work.
MySQL to MariaDB or back, on-premises to RDS, Aurora or Azure Database for MySQL, consolidation of sprawl onto fewer instances, and MyISAM to InnoDB or latin1 to utf8mb4 conversions with the application impact assessed first.
MySQL 5.7 to 8.0 and beyond, or MariaDB across majors: a compatibility assessment against the defaults and reserved words that actually change, a dry run on a copy of production, and a rehearsed rollback before the window opens.
Slow query analysis, index and schema review, buffer pool and I/O tuning, lock contention and deadlock diagnosis, and right-sizing cloud instances that were provisioned before anyone measured.
The same delivery method as our SQL Server and Oracle work: ITIL change management, and nothing goes to production that has not been rehearsed.
Talk it through with a senior consultant on a free 30-minute call. We write up the scope and the deliverables, agree them with you, and then quote a single fixed price against them — including telling you when the work is smaller than you feared.
Discuss your projectPublished
Yes. Onsys delivers MySQL and MariaDB project work for organisations across Australia and New Zealand, with project leadership based in Melbourne and follow-the-sun delivery from Colombo. Work is remote by default; on-site attendance in the Melbourne metropolitan area is arranged as part of the engagement where it helps.
Where the scope can be defined, the project is quoted as a single fixed price with milestone-based payments and written acceptance criteria, so there is no cost-overrun risk. Where it genuinely cannot be defined up front we say so and work at $150 per hour with a four-hour minimum. The scoping call is free and all prices are GST exclusive.
No. MySQL 5.7 reached end of life in October 2023, so it receives no security fixes at all. Estates still running it are accumulating unpatched vulnerabilities. The upgrade to 8.0 changes enough defaults — authentication plugin, character set, reserved words, sql_mode — that it needs a compatibility assessment and a dry run rather than an in-place attempt on a Friday.
Yes. We build InnoDB Cluster with Group Replication and MySQL Router, Galera or MariaDB Cluster where synchronous multi-primary suits the workload, or Orchestrator for topology management on an existing estate. We demonstrate the failover before handover and leave a runbook your team can follow without us.
It depends on what is actually costing you. MariaDB is usually about licensing and feature direction; managed services like RDS, Aurora or Azure Database for MySQL are usually about not carrying the operational load. Both change what your team has to do day to day. We give you an honest read at the scoping call, including when the answer is to stay where you are.
MySQL 5.7 through 8.4 including Percona Server, MariaDB 10.x and 11.x, and the managed services — Amazon RDS and Aurora MySQL, Azure Database for MySQL and Google Cloud SQL. Older versions are supported for the purpose of getting you off them.
Yes, and it is one of the more common reasons people call. Typical causes are single-threaded replication on a write-heavy primary, long-running transactions, missing primary keys on replicated tables, or replication configured on file and position rather than GTIDs. We diagnose the cause rather than just rebuilding the replica, because a rebuild without the diagnosis puts you back in the same place.
No. Project work is standalone and most clients hand the finished environment to their own team with the runbook and the documentation. If you would rather not carry it, our monthly DBA plans cover MySQL alongside SQL Server and Oracle, but nothing about the project depends on taking one.