dockxo beta
FeaturesPricingBlogChangelogGet started Sign in
blog/managed-mariadb-replicas-router

Managed MariaDB: primaries, replicas on other servers, and a router in front

How the managed database kind grew from a single container into a cluster with GTID replicas, MaxScale read/write split and automatic failover, without leaving the panel.

Sep 20, 2026·dockxo team·2 min read #databases#mariadb#architecture

Running a database in a container is easy. Running one you can lose a server under is not. The managed MariaDB kind exists to make the second thing as easy as the first.

Phase 1: a primary you can operate

A managed database starts with a wizard: credentials, size, whether to expose a port, and initial data — another database over the network, an uploaded dump or a URL. Its Database tab is an admin surface, not a log viewer: databases, users with per-database grants and a read-only option, dump import as a job, server tunables rendered into the container’s configuration.

Two decisions were made on day one that pay off later. Root is limited to the server’s containers, so a leaked password from an app is not a root password from the internet. And the binary log is on from the start, so a replica can be attached at any time without a restart.

Phase 2: replicas anywhere

Add a replica on any server in the account. The initial sync is a GTID dump streamed from the primary; after that MariaDB replication runs in real time, and the panel shows lag and errors. Promote turns a replica into the primary and re-points the other members automatically. If the primary was reachable only inside its server, promote exposes the new one for cross-server followers.

Because replicas are ordinary services, they get the same backups, notifications and health checks as everything else.

Phase 3: a router

Apps should not know which member is primary today. A database router puts MaxScale in front of the cluster: one endpoint, read/write split, automatic failover. Failover events are mirrored back into the panel so the Router tab always shows the real topology, and switchover can be started from there. Promote uses the router when one is present.

Health alerts

Every minute the panel checks each managed database: does it answer, are a replica’s replication threads running (with the error text when they stop), how far behind is it (limit per service, 60 seconds by default), are connections above 90 % of the maximum. Each problem is announced once to your Telegram chats or email addresses when it starts and once when it is over. The state survives a panel restart, so you are not re-paged for a problem you already know about.

Backups

A managed MariaDB is backed up as a consistent SQL dump while it keeps running, uploaded straight to your bucket by a backup plan. Restoring a project loads the dumps and deploys primaries before replicas, replicas before routers, routers before apps.