High Noon at AWS — Amazon RDS versus Tungsten Clustering with MySQL on AWS EC2 – June 21st, 2017
Are there any performance implications of running my DB instance as an Amazon RDS Multi-AZ deployment?
You may observe elevated latencies relative to a standard DB instance deployment in a single Availability Zone as a result of the synchronous data replication performed on your behalf. Tungsten Clustering has no such performance issues due to the asynchronous nature of the replication.
When running my DB instance as a Multi-AZ deployment, can I use the standby for read or write operations?
No, the Amazon RDS standby replica cannot serve read requests. Amazon RDS Multi-AZ deployments are designed to provide enhanced database availability and durability, rather than read scaling benefits. As such, the feature uses synchronous replication between primary and standby. Tungsten Clustering slaves are fully available as read replicas
How do I control/configure Multi-AZ synchronous replication
With Multi-AZ deployments, you simply set the “Multi-AZ” parameter to true. The creation of the standby, synchronous replication, and failover are all handled automatically. This means you cannot select the Availability Zone your standby is deployed in or alter the number of standbys available (Amazon RDS provisions one dedicated standby per DB instance primary). The standby also cannot be configured to accept database read activity. Tungsten Clustering allows you to specify the quantity of replica slaves, the AZ's they live in and they may also be used for reads.
Amazon RDS has "Multi-AZ" for deploying multiple copies?
No, you get a primary copy in one zone, and another copy in another zone. You cannot have more than these two copies - one master and one standby only. Tungsten Clustering allows you to have more copies (see above)
How does Amazon RDS handle failover?
Amazon RDS failover only happens in if you have "Multi-AZ" selected; it is an extra paid service. Amazon RDS failover times are typically two to three minutes. However, large transactions or a lengthy recovery process can increase failover time from minutes to hours. Failover relies upon a DNS change, as a result you will need to re-establish any existing connections to your DB instance. (Having an application get disconnected from the database can wreak havoc on some applications and negatively impact user experience!) Tungsten Clustering often fails over within 10 seconds, usually failover takes less than 30 seconds and does NOT require your application to reconnect the database when using Proxy or SmartScale Connector modes.
Does Tungsten Clustering really have zero downtime maintenance?
Changing certain parameters (like database ports) or applying a MySQL upgrade will require the RDS instance to be restarted. With Tungsten Clustering, since you can manually switch database roles between master and slave, you can easily apply changes on slaves, promote the slave to master, and perform the remaining maintenance with no downtime.
Isn't Amazon RDS cheaper?
First, the prices quote for Amazon RDS (along with provisioned IOPS and storage) does not include support. Amazon RDS also does not have the functionality of Tungsten (see all of the above). With a Tungsten Clustering subscription, you get all available features: clustering, HA, replication, SSL for all traffic (if desired), read/write splitting, replication filters, and more, all with 24/7 support.
Comments
Add new comment