Replication Manager, failover and monitoring for MySQL, MariaDB and PostgreSQL

What the tool covers

Replication Manager is an open-source database monitoring, backup and high-availability tool providing automated failover, scheduled maintenance and observability for MariaDB, MySQL and Percona Server replication topologies, and since version 3.1.43 for PostgreSQL clusters.

The monitoring side is the widest part. Real-time replication monitoring with support for GTID, multi-source and delayed replication, topology detection across async, semi-sync, multi-master, mesh, wsrep, group replication and relay topologies, performance schema digest analysis and workload tagging, and monitoring of the processlist and long-running transactions. There is a NOC slideshow for a full-screen auto-rotating display of all monitored clusters, and multi-cluster management from a single instance.

Backups are covered with scheduled logical and physical backups through mysqldump, mydumper, mariabackup and xtrabackup, plus snapshot backups and point-in-time recovery via Restic, an S3-compatible object storage backend for backup repositories, and retention policies with automatic purge.

Maintenance is the quieter half: scheduled table optimisation and analysis, automated log archiving and table defragmentation, rolling restart and reprovisioning, schema monitoring with checksum verification, and SLA tracking.

Failover and switchover are the core. Leader election and automatic primary election on failure detection, controlled replica to primary promotion, replication best-practice enforcement, near-zero data loss targeting across most failure scenarios, and automatic rejoining and reseeding of a database that fell behind.

The project is GPL-3.0, written in Go, on the develop branch, with frequent releases in the 3.1.4x series and the last push on 2026-10-20.

Why monitoring and failover are one product here

The relationship between the monitoring side and the failover side is what makes this more than a dashboard, and it is worth understanding before you let it near production.

A monitoring tool tells you that a replica is down. A failover tool changes which node your application talks to. The second is what people actually want, and it is the part that is hard to get right, because the change is not just a database promotion. It is a promotion plus a proxy route change plus a change of what the application considers the primary, plus in the case of a failed primary a rejoin.

That is why the proxy integration is bundled rather than left as documentation. ProxySQL, MaxScale, HAProxy and Spider all need to be told which backend is now the writer, and a failover that promotes a node without updating the proxy leaves the application writing to the old primary until something times out. The automated backend management for those four proxies is the answer to a problem that hand-rolled failover scripts get wrong regularly.

The same reasoning explains the rejoin and reseed support. After a failover the old primary is behind and possibly diverged, and bringing it back is a separate operation with its own failure modes. Automatic rejoin with reseeding means the cluster returns to full redundancy without a human following a runbook at three in the morning.

The alerting side supports email, Pushover, Slack, Teams and Mattermost, and metrics history is exposed through the Carbon and Graphite API rather than a proprietary format, which means the metrics land in whatever you already run.

The observability features around it are the quieter half of the value. Performance schema digest analysis and workload tagging tell you which query shapes are responsible for load, the processlist and long-running transaction monitoring catches the runaway application query, and the per-module log level configuration means you can turn up the detail on one component without drowning in logs from the others. The extensible log plugin system for security, compliance and workload analysis is the hook for feeding those logs into a SIEM.

The PostgreSQL addition and what changed

The PostgreSQL support is the newest part of the project, added in 3.1.43, and the README describes it in enough detail to be worth reading separately.

Clusters are monitored the same way MariaDB and MySQL are, but with their own switchover, failover and rejoin path. Three topologies are supported: active-passive, WAL streaming with a primary and physical standbys, and logical replication with publishers and subscribers where DDL goes through pglogical.

Switchover and failover move the routes on HAProxy and ProxySQL 3, and the rejoin of a former primary is done with pg_rewind. That last detail is the one that matters operationally, because pg_rewind is the difference between a failed primary rejoining in minutes and a failed primary requiring a full reseed from a backup.

Backups use pg_dumpall and pg_basebackup for logical and physical, with restore and reseed from them and the WAL archive shipped to replication-manager. The observability side pulls from pg_stat_* for processlist, variables, table sizes, workload, WAL and vacuum graphs, and there is a scheduled vacuumdb --analyze. The README links to a documentation page on PostgreSQL topologies and says to see it for what is available compared with MariaDB, which is an honest framing of a feature that is newer than the rest of the product.

The proxy integration is worth noting too. There is automated backend management for ProxySQL, MaxScale, HAProxy and Spider, with ProxySQL 3 PostgreSQL backends and read/write split. The point of putting the proxies under management rather than leaving them to scripts is that the proxy's notion of which node is primary has to be updated whenever the topology changes, and that is the step most hand-rolled failover gets wrong.

Two features around credentials are also listed. There is credential rotation for replication and monitoring accounts with HashiCorp Vault integration, and encrypted secrets in configuration files with support for multi-layer config inheritance, plus a built-in database and proxy configurator with tag-based config tracking.

The API surface is REST and gRPC with role-based access control, OAuth2 single sign-on compatible with GitLab, GitHub and any OIDC provider, and an integrated WebTTY for terminal sessions.

Packaging, licensing and where it fits

The tool is developed and supported by SIGNAL18 CLOUD SAS, and the licence is GPLv3 with the complete text in the repository. The README notes that it includes third-party libraries released under their own licences, with the vendor directory as the place to look, and that it includes derivative work from the go-carbon library by Roman Lomonosov, released under the MIT licence and found under the graphite directory.

The derivative work note is the kind of detail that gets overlooked and then matters, so it is worth being explicit that this is a GPL project with vendored third-party code of mixed licences rather than a clean-room implementation.

Provisioning is on OpenSVC and Kubernetes, with init container support, and the topic list includes both alongside the proxies and the database topologies. The OpenSVC support is unusual and tells you something about the deployment context, since OpenSVC is a service orchestrator used in European hosting operations rather than a cloud-native tool.

The comparison to make is with the alternatives. Orchestrators such as Patroni, ProxySQL and Orchestrator cover pieces of this. Patroni is the closest for PostgreSQL and is the standard answer for automatic failover, and it is focused rather than broad, doing one thing very well. Orchestrator does topology management and failover for MySQL. What Replication Manager adds is the breadth: monitoring, backups, maintenance, proxy management and alerting in one interface, and the same interface across three database families.

The cost of breadth is that you now have a component in the critical path that must itself be highly available, and a tool that can perform failover is a tool that can perform a failover at the wrong moment. The near-zero data loss targeting is a claim that needs testing in your environment rather than accepting, and the automatic rejoin and reseed behaviour is worth understanding before you let it act unattended.

For a team with hand-rolled failover scripts, this is a clear improvement in reliability and observability. For a team already running Patroni for PostgreSQL and something else for MySQL, the argument is consolidation rather than capability.

The licensing question matters for one group in particular. GPL-3.0 is fine for a tool you run internally, and the licence is awkward if you intend to redistribute it as part of a product, which is the same constraint that applies to any GPL deployment tooling.

Editorial conclusion

Adopt Replication Manager if you run replicated MySQL, MariaDB or PostgreSQL and have been handling failover with scripts, because topology detection and automatic promotion are the parts it does well. Skip it if your database is a managed service where the provider already owns failover, or if you run a single node with no replication. Verify first by pointing it at a replica set in a staging environment and exercising a controlled switchover, since the automatic failover path is the one you want to see behave before you need it.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. signal18/replication-manager on GitHub