Disaster recovery in general relies on two key factors which are
- Backups (and recovery)
- Backing up and being able to recover an organization’s data / databases is the most important responsibility an (IT) operations team has.
- Backing up and being able to recover an organization’s data / databases is the most important responsibility an (IT) operations team has.
- Disaster Tolerance
- Business critical applications and databases are usually deployed on two or more different locations whether it is in on-premise data centers or in public clouds. A switchover is then done upon failures.
A third often overlooked factor is consistently verifying that backups are actually restorable. There are several public cases where backups have been turned out to be corrupt and un-restorable when disaster actually strikes.
ClusterControl provides a complete enterprise grade backup management including verification. Backups can be taken as full, incremental or partial with offsite shipping to S3 compliant cloud storage providers. Offsite backups can be used to restore to a secondary site from scratch however it will take longer time (RTO) to provision and get the application/database back online. This is the most cost effective solution for applications that are not business critical.
In cases where Recovery Time Objectives - RTO is critical, database resilience is achieved by replicating from the primary database cluster in one location to a secondary database cluster in another location.
ClusterControl supports the following resilience options out of the box:
- Active - Active clusters (Asynchronous Replication)
- MySQL Galera
- MySQL NDB Cluster
- Active - Active clusters (Semi-synchronous Replication)
- MySQL Galera
- Active - Standby (or Master - Slave) clusters
- MySQL Galera
- MySQL Replication
- PostgreSQL
Cluster-to-Cluster replication can also be used in many other use cases such as:
- Migrating to a new datacenter
- Geo-location performance - keep data closer to a set of users for that region
- Replicating production to a dev/test environment for troubleshooting
- Replicate and test a newer version of the database before doing a switchover
- Use a secondary cluster for read-only access for reports or analytics
Hands-on PostgreSQL Cluster-to-Cluster Replication Demonstration