Which one to choose RDS v/s MySQL on EC2
A lot of clients for whom we manage AWS come up with a simple question of which out of “RDS vs EC2” is better for their MySQL database requirements. The answer to this simple question is not so simple though. Both these options enable building a database in a VPC secure environment, support applications with high performance requirements, and are highly scalable. However, there are some important differences between RDS and EC2 databases.
Below are some points which are in direct favor of Amazon RDS
- There’s almost no manual configuration, management, or maintenance requirements – AWS even handles software patches automatically.
- Each RDS instance is pre-configured and optimized based on the selected size. RDS instances scale by adjusting memory or compute power up or down as needed.
- It’s also simple to configure read replicas or set up synchronous replication across availability zones for enhanced performance, availability, and durability.
- RDS also comes with automated scheduled backups and point in time restores.
Here are some scenarios to help you decide which one to use
I’m replicating into Amazon from a physical datacenter
This setup is common if you’re using Amazon’s VPC or Virtual Private Cloud. With a router dropped into your datacenter, VPC allows you to extend and spin up virtual instances from Amazon as if they’re sitting in your own existing datacenter. Great stuff, but you won’t be able to replicate from your existing master MySQL instance to cloud Amazon RDS instances. To do that, roll your own with MySQL or Percona RDS can only work with other RDS instances. At least for right now.
I’m using Amazon and replicating to another cloud provider
Again roll your own, as RDS won’t work with this configuration.
I’m developer or small startup building a new application.
Use RDS. It’s easier to deploy, and though there are fewer levers and dials you can control, you can always dump your data and move it to roll your own deployment later.
We’re a small shop without a fulltime DBA
Use RDS as it is easier to deploy. You’ll have a couple of replication options at your disposal. There are read replicas which are basic slaves using MySQL’s built-in asynchronous replication. You can scale horizontally with these read-only copies, but cannot failover to these instances. For that you’ll need a Multi-AZ configuration where you deploy across availability zones. Multi-AZ is said to be synchronous so it’s likely built on top of a distributed file system such as DRBD.
We want to do master-master for easy failover and failback
Use MySQL or Percona the two configurations for RDS don’t support this. With AWS Read Replicas you have one master and multiple read-only slaves, but no failover. With Multi-AZ you can’t access the inactive secondary database *until* you failover. Once you failover that instance becomes the primary.
I’m concerned about clean data. Is replication bulletproof?
No not out of the box. Whether you are using RDS or MySQL there are various scenarios where MySQL slaves can drift out of sync from the master, without throwing an error. This likely impacts Read Replicas though it’s hard to say if it affects Multi-AZ.
If you’re concerned about data integrity with MySQL replication (and you should be!) take a look at our Guide to MySQL Integrity Checking with Percona Toolkit.
Our use case is to scale reads with multiple instances
RDS can do this handily with Read Replicas. As long as your requirements are for vanilla replicas, this will work well for you.
Thank you for giving your valuable time to read the above information. Please click here to subscribe for further updates
KTEXPERTS is always active on below social media platforms.
Facebook : https://www.facebook.com/ktexperts/
LinkedIn : https://www.linkedin.com/company/ktexperts/
Twitter : https://twitter.com/ktexpertsadmin
YouTube : https://www.youtube.com/c/ktexperts
Instagram : https://www.instagram.com/knowledgesharingplatform
Loading...
