Webinar Slides: High Noon at AWS — Amazon RDS vs. Tungsten Clustering with MySQL on AWS EC2
0 likes189 views
The document compares Amazon RDS and Continuent Tungsten for running MySQL on AWS, highlighting key differences in high availability, disaster recovery, read scaling, and maintenance capabilities. While RDS offers convenience, it lacks essential features like shell access and efficient failover, making it less suitable for enterprise-level applications. Continuent Tungsten, on the other hand, provides a robust solution with superior performance, zero-downtime operations, and comprehensive support for complex database environments.
Webinar Slides: High Noon at AWS — Amazon RDS vs. Tungsten Clustering with MySQL on AWS EC2
- 1. High Noon at AWS ~ Amazon MySQL RDS versus Tungsten Clustering running MySQL on AWS EC2
- 2. Introduction • Amazon Web Services (AWS) are gaining popularity, and for good reasons. The Amazon Relational Database Service (AWS RDS) is getting a lot of attention, also for very good reasons. It is quite a compelling idea to have on-demand data services that do not require hiring DBA staff. The expectation is set that everything works like magic and will satisfy all of your enterprise database availability needs. • If you want build high-volume, business-critical applications, possibly with geographically- distributed audiences, you really want to think twice about using RDS. • Continuent customers have a large number deployments in AWS running MySQL on AWS EC2 instances and they choose to rely upon Tungsten Clustering to provide High Availability (HA) and Disaster Recovery (DR). We also support Multi-Site/Multi-Master operations and offer true zero-downtime operations.
- 3. Things to Ponder – Questions… • How does the solution handle failover? • Will the solution handle enterprise-level workloads? • How does the solution handle read scaling? • Can you do zero-downtime maintenance? • What value are you getting for your dollar?
- 4. Points for Comparison • Performance • High Availability (Loss of instance) • Disaster Recovery (Loss of Region) • Clustered Master-Master Topologies (Multi-Site/Multi-Master) • Read Scaling • DBA: Tuning, Maintenance and Upgrades • Cost/Value
- 5. Summary Comparison What?! Amazon RDS! Continuent Tungsten! MySQL Performance Multi-AZ synchronous replication can cause i/o latency Loosely-coupled asynchronous replication does not cause performance issues High Availability (Loss of Instance) Failover in about 2-3 minutes via DNS Failover in about 10-30 seconds via inline Connector proxy Disaster Recovery (Loss of Region) Manual Fully automated regional failover with a single command Clustered Master-Master Topologies (Multi-Site/Multi-Master) No Active Clusters in each region are linked via Tungsten asynchronous replication Read Scaling Max 5 Read Replicas per Master which cost extra Failover slaves are fully available for reads with intelligent read/write splitting DBA: Tuning, Maintenance and Upgrades (MySQL, OS, IO) No SUPER or shell access, must use RDS Performance Groups which require a restart Zero-downtime rolling maintenance with full access to the OS root and MySQL SUPER Full MySQL Feature set Certain plugins and features not available All plugins and features available with some superseded by Tungsten functionality
- 6. RDS MySQL Limitations • Shell access to the database server operating system is unavailable. • No MySQL user accounts with the “SUPER” privilege. • Dynamic and non-dynamic MySQL variables are configured via RDS parameter groups only. • Authentication and Password Strength plugins may not be used.
- 7. MySQL Base Performance • RDS and EC2 instances used for testing were configured with the appropriate my.cnf and the same disk IO (5000 iops, type io1, r3-4xlarge) • Native MySQL 5.6 performs equal to or better than Native MySQL 5.7 in the Sysbench tests • EC2-based MySQL 5.6 performance is on par with RDS MySQL 5.6 • EC2-based MySQL 5.7 performance is consistently better than RDS MySQL 5.7 for OLTP traffic
- 8. High Availability Amazon RDS Continuent Tungsten on EC2 MySQL Master MySQL Standby Application Synchronous Physical Replication DNS Resolution Application Tungsten Connector MySQL Slave MySQL Master MySQL Slave Asynchronous Logical Replication
- 9. Tungsten clusters add HA and scaling without taking features away 19
- 10. High Availability Amazon RDS • Uses Multi-AZ physical synchronous replication • Standby Replicas not available for reads (or anything else) • Failover takes an average of 2-3 minutes • Failover is via DNS record changes, which could potentially cause delays due to DNS caching or propagation • New requests are not handled gracefully (i.e. “Connection refused” or “Connection timed out”) Continuent Tungsten on EC2 • Uses Tungsten asynchronous replication • All Tungsten cluster nodes are fully available for reads, OS access, etc. • Failover takes an average of 10-30 seconds • Failover is handled by an intelligent proxy (Connector) so there are no propagation or caching delays • New requests are handled gracefully – they are forced to wait by the Connector
- 11. Tungsten Disaster Recovery creates composite clusters that span sites and are ready for immediate failover 32
- 12. Disaster Recovery Amazon RDS • No automated cross-region failover • You may manually promote a Read Replica to a master, with potential unknown data loss • Since you have no access to the physical server, you cannot retrieve events that have not made it to the slaves • Recovery is much more difficult with a greater risk of ultimate data loss Continuent Tungsten on EC2 • Multi-Site failover is fully supported • Composite Clusters automate failover to another region with a single command, signaling the Connectors to route application traffic to the appropriate cluster’s master node • Tungsten Clustering uses the Tungsten Replicator for data movement, and uses fully-accessible Transaction History Logs to allow for easy management, recovery and inspection of the replication state and events
- 13. Tungsten Multi-Site/Multi-Master topologies operate independent, active clusters on 2 or more remote sites 33
- 14. Multi-Site/Multi-Master Topologies Amazon RDS • There is no concept of cross-site clustering. • Amazon does not offer a Multi-Master, active/active solution Continuent Tungsten on EC2 • A cluster per site provides high-availability • All sites have a write-able Master node • Cross-site Tungsten Replicators pull the events from remote sites • The cross-site Replicators are cluster-aware, and are able to select a new source in the event of a failure • Multi-Site/Multi-Master clusters are Active/Active, so zero intervention is required to make a site live • You may choose to write to only one side, mimicking Primary/DR Active/Passive behavior. • This is a typical topology when clients use Global Load Balancers to direct traffic
- 15. Read Scaling Amazon RDS • Read Replicas are not available for failover • It is possible for a read replica to not come back online after a failover requiring a full rebuild since there is no graceful recovery • Read/write-splitting must be handled by the application or third-party proxy • Maximum of 30 replicas per master in two tiers Continuent Tungsten on EC2 • All nodes are available for reads and failover • Add nodes to a cluster and use read/write-splitting • Add cluster-slave nodes or entire reporting clusters • Effectively unlimited number of read replicas • Graceful recovery built-in using cctrl and tungsten_provision_slave • Replicate to Big Data targets
- 16. Promise of No DBA Amazon RDS • Mom, look, no hands! DataBase-as-a-Service often creates the illusion that you can just jump on the bike, and start pedaling without your hands on the handlebar. Good luck! • Establishing an enterprise-level deployment requires significant time and effort, and deep DBA knowledge, which is not offered by Amazon • Basic Product Support is not included in the RDS subscription and needs to be purchased separately Continuent Tungsten on EC2 • All business-critical deployments need competent in- house DBA and/or Remote-DBA services from a knowledgeable service provider (i.e. Percona, Pythian, etc.) • Continuent provides deployment services to help you get fully into production • 24/7 Enterprise-level Product Support Included • Continuent works!
- 17. Database Administration Tuning, Maintenance and Upgrades Amazon RDS • Upgrades force downtime, Multi-AZ deployments force a failover which means a minimum of two minutes offline • You are unable to control when OS upgrades will be done, they could be done when you go to upgrade the MySQL version • Changing parameters requires editing a parameter group and a DB server restart! • No command-line access to the OS which means no visibility unless you use (and pay for) Cloudwatch detailed monitoring • Establishing an enterprise-level deployment requires significant time and effort Continuent Tungsten on EC2 • Rolling maintenance means that all upgrades may be done online by doing a graceful switch of the Master role to another node • Full access to every aspect of your systems • Access via command-line and your favorite devops/ scripting tools • Full access to monitor and alert your way with monitoring plugins included for popular tools like Nagios and Zabbix • We provide deployment services to help you get fully into production
- 18. Wrap-Up
- 19. Things to Ponder – Some Answers! • How well does the solution handle failover? – Tungsten Clustering provides for rapid, recoverable failover • Will the solution handle enterprise-level workloads? – Tungsten Clustering allows for proper hardware configuration, including using multiple, striped provisioned-iops EBS volumes – The disk i/o can be properly spread out across multiple, expandable filesystems • How does the solution handle read scaling? – Tungsten Clustering allows reads from all nodes, and no practical limit to the number of read nodes • Can you do zero-downtime maintenance? – Tungsten Clustering allows for rolling maintenance via the Connector routing capabilities • What value are you getting for your dollar? – EC2 instances cost 30% less on average than RDS instances of the same size, add our software and you get a vastly superior solution with 24/7 enterprise-level support at roughly the same cost as RDS!
- 20. Master/slave clustering is a robust technology for enterprise data management! Very High Availability Updates propagated without cost to applications Transparent connectivity with full SQL semantics Very High Performance 64
- 21. Continuent offers… • Highly available clusters of off-the-shelf MySQL servers • Zero-downtime maintenance and upgrade • High performance regardless of data volume or distance • Replication over regions to DR sites as well as non-MySQL data warehouses 65
- 22. For more information, contact us: Eric Stone COO [email protected] MC Brown VP Products [email protected] Eero Teerikorpi Founder, CEO [email protected] +1 (408) 431-3305