Database Clusters on MassiveGRID PaaS

A database is the part of a stack that teams are least willing to run as a cluster themselves, because the failure modes are the most expensive. The database packages on MassiveGRID PaaS, built on Virtuozzo Application Platform (formerly Jelastic), do the clustering: the MySQL/MariaDB/Percona cluster package builds primary-secondary, primary-primary or Galera topologies with a ProxySQL pair in front so applications connect to one hostname; the PostgreSQL primary-secondary cluster adds hot standbys and Pgpool-II; the Redis cluster builds the six-node sharded layout Redis requires; and the multi-region packages for MariaDB Galera, MySQL, PostgreSQL and Redis place nodes in two or three of New York, London, Frankfurt and Singapore with replication between them. Two smaller packages, MariaDB master-master and multi-source replication, cover the cases where two primaries or a consolidated replica are the right tool.

Every node is billed by the cloudlet (128 MiB RAM plus 400 MHz CPU) at $0.003372 per cloudlet-hour, so a cluster costs what its nodes actually use. Failover is automatic, the Database Backup/Restore add-on dumps any of these engines on a schedule, the TLS add-ons encrypt client connections, and the Cluster Recovery add-on brings a Galera cluster back after a loss of quorum from the dashboard.

Match the topology to the write pattern. Primary-secondary (MariaDB or PostgreSQL) suits applications that write to one place and read from many; failover promotes a secondary. Galera suits applications that must keep writing through a node loss, at the cost of synchronous commit latency. Primary-primary is for two sites that each need a local writable copy. The topology guide goes through the trade-offs with examples.

Go multi-region for a reason, not by default. Cross-region replication adds latency to every synchronous write (Galera) or a replication lag to every read from a standby (MySQL, PostgreSQL). Teams choose it for local reads in several continents, for a standby that survives a regional outage, or for a data-residency rule; a single-region cluster with backups to a separate node is the right answer for most applications.

Size the nodes to the dataset and the working set. Redis is memory-bound, so its nodes are sized to the data they hold; MariaDB and PostgreSQL want enough RAM for the buffer pool to hold the hot part of the data. The sizing table on each package page gives three starting points and the monthly cost of each.

Every package page carries a sizing table with three configurations. To price a configuration of your own, or to see what a package costs on a working-hours schedule, use the PaaS pricing calculator.