When evaluating a solution, we need to define the requirements for our application around these following elements:
- High Availability (HA): Local fast and automatic failover, for high availability
- Disaster Recovery (DR): Remote fast and site level failover, for disaster recovery and continuous operations
- Zero Downtime: Perform complex system changes or routine maintenance, while keeping applications available
- Geo-Scale: Geographically distributed (active/passive or active/active) low-latency database deployments with a single consolidated management view
- Read Scale: Fast local response times for read traffic, even in a geo-distributed deployment
- Multi-Primary: Ability to deploy active MySQL clusters across multiple regions
- Transparency: No changes to application code or stack
- Flexibility: Avoid cloud or vendor lock-in
- Support: Access to 24/7 support by experienced MySQL database engineers
Welcome to the second blog in the “Continuent High Noon Series!” We are looking at the various solutions for MySQL that provide High Availability (HA), Disaster Recovery (DR), and Geo-Scale deployments. We will dig into the requirements, features, and limitations of each solution, then rate them on such topics as performance, scalability, failover, and more!
Galera is a specialized build of MySQL that provides true multi-master clustering with synchronous replication. A management GUI aptly named Galera Manager was recently released.
Some of the notable features are:
- A mature, widely deployed clustering solution
- All nodes in a local cluster are readable and writable.
- Provides high availability (all nodes are writable)
- Synchronous replication aims for consistency - almost no divergence among replicas.
- Replication uses a certification to eliminate conflicts and enforce ordering of transactions.
- Various versions are available, coinciding with MySQL versions
Galera Cross-Region Requirements
Multi-site WAN topologies usually use asynchronous replication to be set up between clusters over a WAN. Having synchronous replication deployed across a WAN will seriously degrade application performance and thus is not practical to deploy. In the case of a multi-region deployment, we must choose to add an additional asynchronous replication technology, forcing mix-and-match solutions (async and sync), which complicates the cluster deployment and management.
- Not a complete solution with integrated connectivity and cluster management
- Does not support ‘native’ (official) MySQL version -- one has to use the ‘Galerized’ version of MySQL
- Write intensive workloads will perform poorly due to synchronous replication
- Poor WAN performance due to high latency across the sites
- Therefore multi-site topologies are rarely used with Galera
- No Proxy included - must use a third party solution
- All tables in database must have a primary key
- Only InnoDB engine supported
- One slow node will slow the entire cluster
- Replicating data out of the Galera cluster requires a different technology - ETL, MySQL replication, etc.
Tungsten Cluster vs Galera Cluster
Continuent Tungsten Clustering is all about geo-distributed MySQL high availability on-premises, hybrid-cloud, and multi-cloud. Our customers stay with us (current average life-time 8+ years and counting), citing the completeness and maturity of the solution and the excellent, very fast (less than 3 minutes average response time) 24/7 support as reasons to choose Continuent.
The Galera and Tungsten Cluster features comparison table displays in an easy-to-view checklist each of the key elements needed to make a great MySQL HA/DR/Geo-Scale solution:.
|Management & Monitoring||3.40||4.80|
Watch this webinar to learn about how to best build a geo-scale, multi-region and highly available MySQL, MariaDB, or Percona MySQL cloud backend.
Are you looking for an Alternative to Galera? Try Tungsten Clustering!
We’ve recently introduced this new High Noon series to help demonstrate how and why customers with business-critical or mission-critical applications have grown for years with Tungsten Clustering versus alternatives.