Between a single MariaDB node and a full ProxySQL-fronted cluster sit two modest packages that are easy to confuse and useful for entirely different reasons. One gives a database a live twin. The other gives a company one place where every database's data arrives. This post follows a systems engineer using both on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic, for two problems that came up in the same month.
The engineer works for a facilities-management company we will call Greaves Estates, which runs six separate PHP applications, each with its own MariaDB. The MariaDB Master-Master Replication package deploys two nodes that replicate to each other; the MariaDB Multi-Source Replication package deploys several primaries that all replicate into one replica.
Problem one: the booking system needs a twin
The room-booking application is the one the whole company notices, and its single MariaDB node is a single point of failure that the engineer is asked to remove without adopting a cluster. The primary-primary package is the answer: two MariaDB nodes, each configured as the primary of the other, with GTID-based asynchronous replication in both directions and auto-increment offsets staggered so that rows inserted on both nodes never collide on a primary key. Both nodes hold a complete, current copy. The installer configures and verifies the replication; the engineer gets both nodes' credentials by email.
The honest caveat, which the package's own FAQ states: both nodes can accept writes, but most teams should write to one and treat the other as a hot standby with read capacity. Bidirectional writes to the same rows produce conflicts that asynchronous replication cannot resolve. The engineer points the booking application at node A, gives the reporting queries node B, and writes down the failover step: change the application's host to node B if A is lost. Node B has every row A had up to the replication lag, normally milliseconds on the internal network.
Problem two: six databases, one report
Finance wants a weekly utilisation report across all six applications, and the analyst has been exporting six CSVs. The multi-source package solves this the way it should be solved: several MariaDB primaries, the existing six, each replicate into a single replica node through its own named replication channel, so the replica holds a consolidated copy of every database. The report runs against one server with joins across applications, and production nodes never see the query load.
Two things the engineer handles at setup. Database name collisions: multi-source merges everything into one server, and two of Greaves's applications both called their database app. Replication filters, or renaming one database at the source, resolve it; he renames. Writes to the replica: it is designed as a read-only consolidation point, and writing to it risks conflicts with incoming replication, so the analyst gets a read-only user and the replica's own write access is restricted to the replication channels.
| Primary-primary package | Multi-source package | |
|---|---|---|
| Shape | Two nodes replicating to each other | Many primaries replicating into one replica |
| Purpose | Redundancy and read capacity for one database | Consolidation of several databases for reporting, backup, analytics |
| Direction | Bidirectional, asynchronous, GTID | One-way into the replica, one channel per source |
| Writes | Both can; write to one in practice | Primaries only; replica read-only by design |
| Failover | Repoint the application to the surviving node | Not a failover tool; sources are independent |
| Add-ons | TLS, backup, cluster recovery | TLS, backup on the replica |
Where these sit relative to the cluster package
The marketplace's MySQL/MariaDB/Percona Cluster gives primary-secondary, primary-primary or Galera topologies with a ProxySQL entry point and an orchestrator, which is the right shape when an application needs a single connection string, automatic routing and scale-out. The two small packages skip the proxy layer. That makes them cheaper and simpler, at the cost of the application knowing about two hostnames (primary-primary) or the reporting tool knowing about one extra server (multi-source). For a booking system that a company can repoint by hand in five minutes, and for a reporting replica that nothing production depends on, the engineer judged the small packages right.
Operations: the same tools as the big clusters
- Encryption: the MySQL SSL/TLS add-on installs on both packages' layers, generating certificates and requiring TLS for client connections.
- Backups: the Database Backup/Restore add-on dumps node B of the booking pair nightly, and dumps the consolidated replica, which is a backup of all six applications in one job.
- Health: the Database Cluster Recovery add-on's diagnostic checks replication threads and GTID positions on primary-primary topologies, which is how the engineer will learn if a channel stops. For multi-source, the replica's own
SHOW ALL SLAVES STATUSin a scheduled check does the same. - Cost: each MariaDB node scales vertically by the hour; the booking pair at about 8 cloudlets each and the consolidated replica at about 12 (a cloudlet is 128 MiB of RAM plus 400 MHz of CPU) add roughly 28 cloudlets an hour, about $68 a month before discounts at MassiveGRID's published $0.003372 per cloudlet-hour, to a company that previously had neither redundancy nor a report.
What each solved
The booking system gained a live twin, tested by stopping node A on a clone and repointing: under two minutes of read-only time for the bookers. Finance received the weekly report as a saved query against one server, and stopped receiving CSVs. The engineer's note for colleagues who find both packages in the marketplace: read the shape, not the name. Two nodes facing each other is redundancy; many nodes feeding one is consolidation.
Frequently Asked Questions
Why not use Galera for the booking system instead of primary-primary?
Galera gives synchronous, conflict-free multi-primary writes with automatic node recovery, at the cost of three nodes minimum, InnoDB-only with primary keys on every table, and more moving parts. For a small application that one team can repoint manually, the two-node asynchronous pair is simpler; when the application must fail over without a human, the cluster package with ProxySQL is the step up.
Can the multi-source replica also be a source for something else?
MariaDB supports chaining, so the consolidated replica could in turn replicate onward, for example to a replica in another region for disaster recovery. Enable binary logging with log_slave_updates on the replica first. Keep the chain short; each hop adds lag.
How much lag should I expect?
On the platform's internal network within one region, milliseconds under normal load. A bulk import on a source shows up as seconds of lag while the replica applies it. Monitor Seconds_Behind_Master or the GTID gap in a scheduled check, and alert if it grows.
A twin for the database that matters
The MariaDB Master-Master Replication package deploys two nodes replicating to each other in one click on MassiveGRID PaaS, and the Multi-Source package funnels several databases into one reporting replica. Per cloudlet-hour, free 14-day trial.
MariaDB Replication on MassiveGRID PaaS