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!
Google Cloud MySQL Characteristics
Google Cloud SQL for MySQL is a managed database cluster within Google Cloud that runs MySQL community edition. It features High Availability using a failover replica in a different zone from the primary, and also supports read-only replicas. It follows the model of pay for what you use: CPU, storage, IP address, egress network traffic, etc.
Some of the notable features are:
- Fully managed deployment of databases
- Point and click backups
- Automatic failover
- Synchronous Replication for failover replica
- Basic proxy available, following the pay-for-what-you-use model
- Encryption of data in flight and at rest
Google Cloud MySQL Cross-Region Requirements
Multi-site WAN topologies usually use asynchronous replication to be set up between clusters over a WAN. Google Cloud SQL allows the user to create read replicas in other regions using asynchronous replication. These read replicas naturally can be used for reads, and can be used for disaster/recovery, to fail over to another region. After failing over, the new primary instance becomes a standalone cluster.
Google Cloud MySQL Limitations
- Only a single failover candidate
- Failover candidate cannot be used for reads, but doubles the cost when added
- Limited cross region support
- Very basic proxy available, but at extra cost
- Cross region failover creates a standalone cluster -- all other regions must be reprovisioned.
- Linear pricing - use 5x more instances, pay 5x more
- Application must be read/write aware
- Database maintenance and schema changes will cause application outages
Tungsten Clustering vs Google Cloud MySQL
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 GCP Google Cloud MySQLand 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:.
|Google Cloud MySQL
|Management & Monitoring
As part of our High Noon series of on-demand webinars, this webinar looks at some of the key characteristics of GCP MySQL 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 Google Cloud GCP MySQL 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.