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 next 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!
InnoDB Cluster Characteristics
InnoDB Cluster uses MySQL’s group replication to handle the replication. It’s also known as semi-synchronous replication. For more information, check out this blog about the different types of replication used in MySQL clustering.
Some of the notable features are:
- Relatively recent development by Oracle
- Limited WAN-based topologies due to semi-sync replication, which could affect application performance
- Provides high availability with multi-master
- Supports Oracle’s MySQL Router, a basic proxy
- Usually managed with MySQL Shell
InnoDB Cluster Cross-Region Requirements
Typically clusters deployed over a WAN use asynchronous replication, which is loosely coupled between sites. Having any sort of synchronous replication solution deploy across a WAN is not practical due to lag and increased latency in the application. In the case of a multi-region deployment with InnoDB Cluster, you must use an asynchronous solution to join the clusters. This of course makes cluster management much more difficult.
InnoDB Cluster Limitations
- Write intensive workloads may perform poorly due to synchronous replication
- Poor WAN performance due to high latency across the sites
- Therefore multi-site topologies are rarely used with any kind of synchronous replication
- Available proxy is very basic
- Only InnoDB engine supported
- One slow node will slow the entire cluster
- Replicating data out of the cluster requires a different technology - ETL, MySQL replication, etc.
Tungsten Cluster vs InnoDB 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 InnoDB Cluster 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:
|InnoDB Cluster||Tungsten Cluster|
|Management & Monitoring||3.20||4.80|
As part of our High Noon series of on-demand webinars, this webinar looks at some of the key characteristics of InnoDB Cluster and how it fares when compared to Continuent Tungsten Clustering.
Watch this webinar to learn about how to best build a geo-scale, multi-region and highly available MySQL, MariaDB, or Percona MySQL backend, in the cloud, hybrid-cloud, multi-cloud, or on-premises.
Reach out to see if Tungsten Clustering is a better fit than Oracle’s InnoDB Cluster for your requirements and environment!
We’ve recently introduced this new High Noon series to help demonstrate how and why customers with business-critical or mission-critical MySQL applications have grown for years with Tungsten Clustering and continue to choose it versus alternatives.