Currently I have a db.r5.2xLarge RDS Reserved Instance (Aurora Postgres).
I'm thinking about moving to db.r6g.2xLarge, if I do that will my reserved instance discount still apply?
I looked up on AWS documentation but coudn't find a clear answer.
RDS offers size-flexible reserved instances, which allow you to change the size within a class (e.g. r5.2xlarge -> 2* r5.xlarge), but they need to stay within a class.
Because of this, that wouldn't apply to your modification. The other (bigger) problem is that Aurora is not in the list of supported DB Engines for this:
Size-flexible reserved DB instances are available for the following Amazon RDS database engines:
MariaDB
MySQL
Oracle, Bring Your Own License
PostgreSQL
— Source
tl;dr: The discount won't apply anymore if you go through with your proposed change.
Related
I am using aws RDS with class db.r5.12xlarge, so when I am trying to downgrade my database to lower size then I am not able to find all sizes of db.r5 class. I have a requirement to set the database with size db.r5.8xlarge but this option is not showing while modifying the DB instance.
So these are available classes for my existing RDS cluster.
But when I am trying to create a new Database then I can see all sizes of R5 classes.
Here is the structure of my RDS cluster. I am using Aurora with MySql compatibility.
I ran into this same issue when trying to scale up an instance. Long story short, there's a compatibility matrix for instance classes and DB engines. Buried within you'll find that MariaDB, MySQL, or Postgres are not supported by the db.r5.8xlarge class. So much for instance size flexibility with reserved instances...
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html
I have a small single-instance deployment running on an EC2 instance which hosts both a web application and its database (MySQL). I've been looking to separate the deployment out into an EC2 instace for the web app and an RDS cluster for the database, and wanted to take advantage of the new AWS Savings Plans for both if possible.
My questions the are:
AWS Savings Plans seem to only apply to 'pure' compute EC2 instances, not to RDS instances as well. Can someone confirm or disprove this?
If Savings Plans did apply to RDS instances, is there a reason to not use them, and instead just use an Instance Reservation?
Since August 2020, AWS Savings Plans includes:
Amazon EC2
AWS Lambda
AWS Fargate
They do not apply to Amazon RDS db instances. For those, you can continue to use Amazon RDS Reserved Instances.
I want to clarify that even though Savings Plans do not cover RDS instances, they do cover EC2 instances that are part of EMR, ECS and EKS Clusters. Based on this link:
"Both plan types apply to EC2 instances that are a part of Amazon EMR, Amazon EKS, and Amazon ECS clusters. Amazon EKS charges will not be covered by Savings Plans, but the underlying EC2 instances will be. "
Also, Compute Savings Plans also apply to your Fargate and Lambda usage.
We moved to RDS from EC2 instances running self installed MySQL years ago. For me, at has been great. All of the RDS features work flawlessly, point and click, without the mundane work of spinning up, replicating, backing up, and failing over databases. It simply works great. Use reserved instances if you plan on keeping for at least a year. At 30% savings the cost is awash even if you bail on the server after about 9 months and don't use the entire year. Plus you can sell the unused remaining on the marketplace.
Downsides?
You do NOT get command line OS access to the MySQL server. You get an admin login to mySQL. The only way to manage it is through the AWS UI and the mysql client command line or managing client (like MySQL Workbench or Heidi).
You may want to run a mysqldump script on a separate EC2 to dump databases separately/additionally. AWS does SNAPSHOTS which require an entire restore of a sandbox server just to get a single table someone botched up, for example. I go to the MySQLdump files all the time. Never have needed the SNAPSHOT unless I am spinning up a sandbox copy of the entire instance for some reason.
In a nutshell, mySQL on RDS is great.
One other side note. We migrated an app using MySQL5.7 to Aurora MySQL with absolutely zero issues. Complete drop-in replacement (in our case).
I've been considering moving some databases from self-hosted database instances (e.g. MySQL or PostgreSQL on Linux, either bare-metal or within AWS itself) into Amazon RDS, but it's unclear to me how everything will behave once I've created the database and it's time for maintenance to begin.
For example, I have to choose the type of instance(s) that will be used for the database, which I guess means how responsive everything will be, and there is an option for multi-AZ deployments, but it's not clear how many of those types of instances I'm actually configuring. (Presumably, multi-AZ deployment requires at least two instances).
There are options for Failover, which leads me to believe that I can rely on the service to stay up if there are problems with an instance, but then there is also a section for selecting maintenance windows for automated upgrades, which I find confusing. If I were administering e.g. a two-instance MySQL setup, I'd upgrade one instance and then the other to avoid any downtime. Is that not how RDS behaves?
RDS advertises support for automatic "minor version upgrades" (yes, please), but doesn't say anything about OS upgrades. Presumably, the db engine will be running on Amazon Linux or something similar, and will periodically require updates to those packages. Does that all happen automatically, or do I need to manually perform those upgrades, etc.?
The whole point of using something like RDS is that the service should become something I no longer have to worry about: I don't have to deal with package maintenance, upgrades, failover, or unexpected downtime (as long as I pay enough, of course). But all of the options for the RDS instance are making me skeptical of the advantages provided by RDS over just running everything myself.
Can anyone with experience with AWS RDS comment on their experiences with maintenance, upgrades, and failover?
These were the same concerns which we had when we were planning to use RDS. Now that we are effectively using AWS RDS for multiple production workloads, let me try to clarify your queries. Hope this helps.
Your Question 1 : I have to choose the type of instance(s) that will be used for the database, which I guess means how responsive everything will be
Answer : Yes. This is to define what capacity (CPU,RAM etc) you will need for your database workload
Your Question 2 : There is an option for multi-AZ deployments, but it's not clear how many of those types of instances I'm actually configuring.
Answer : Multi-AZ deployments are to ensure high availability. AZ (Availability Zones) are isolated locations within an AWS Region to provide better protection against disaster scenarios. So when we choose a Multi AZ deployment, RDS will place 2 instances of your database server in 2 Availability Zones in the region where you are provisioning.
This is done automatically by RDS and we dont have to setup/maintain 2 servers separately/manually. ( Note : Your VPC should have atleast 1 subnet in each of the 2 different AZ to provision Multi AZ Setup)
Your Question 3: If I were administering e.g. a two-instance MySQL setup, I'd upgrade one instance and then the other to avoid any downtime. Is that not how RDS behaves?
Yes. RDS does it by itself without manual intervention if you enable Automatic Upgrades while setting up RDS (Only if you choose to have Multi AZ option)
Your Question 4 : RDS advertises support for automatic "minor version upgrades" (yes, please), but doesn't say anything about OS upgrades.
Answer : RDS dont expose/provide any OS access to us. The underlying OS and its upgrades/other activities are all done without affecting the RDS services hosted on top of it. We dont have to do anything about the OS of RDS. So we can forget about that part.
Your question 5 : Regarding Failover of AWS RDS Multi AZ database
I would classify into 2 cases.
Case 1 : Fail-overs required during maintenance/other automatic activities done by Multi AZ RDS instance.
Here, RDS will automatically do the failover one instance at a time. It will first move all the ongoing traffic to second instance and then upgrade/reboot the first instance and then do the same with second instance.
Case 2 : Fail-overs required during manual reboot/manually triggered actions done on Multi AZ RDS instance.
In this case, during the reboot, AWS RDS provides an option for you to select whether the reboot should be with failover or without one.
I have an m4.10xlarge EC2 instance and a AWS RDS, both running MySQL 5.7 with same data.
I tried running a few complex queries (cross joins, nested select) on them, and found that the EC2 instance has consistently better performance (lower duration and fetch time).
Can I safely conclude the EC2 database, which has more CPUs, has better performance than RDS, which has Provisioned IOPS (SSD)?
RDS specs:
No. You cant conclude so. You should use equivalent specs in RDS too. Also,right configuration of the db parameter groups play a great role in giving the optimal perfomance output from RDS.
You should use a better spec for your rds instance.
Configure the parameter group variables to match the global variables of your Ec2 setup to get similar performance.
How to scale horizontally amazon RDS instance? EC2 and load balancer+autoscaling is extremly easy to implement, but if I want scaling amazon RDS?
I can ugrade my RDS instance with more powerfull instance or I can create a read replica and I can direct SELECT queries to it. But in this mode I don't scale anything if I have a read-oriented web application. So, can I create RDS read replica with autoscaling and balance them with load balancer?
You can use a HAProxy to load-balance Amazon RDS Read Replica's. Check this http://harish11g.blogspot.ro/2013/08/Load-balancing-Amazon-RDS-MySQL-read-replica-slaves-using-HAProxy.html.
Hope this helps.
Note RDS covers several database engines- mysql, postgresql, Oracle, MSSQL.
Generally speaking, you can scale up (larger instance), use readonly databases, or shard. If you are using mysql, look at AWS Aurora. Think about using the database optimally- perhaps combining with memcached or Redis (both available under AWS Elasticache). Think about using a search engine (lucene, elasticsearch, cloudsearch).
Some general resources:
http://highscalability.com/
https://gigaom.com/2011/12/06/facebook-shares-some-secrets-on-making-mysql-scale/
If you are using PostgreSQL and have a workload that can be partitioned by a certain key and doesn't require complex transactions, then you could take a look at the pg_shard extension. pg_shard lets you create distributed tables that are sharded across multiple servers. Queries on the distributed table will be transparently routed to the right shard.
Even though RDS doesn't have the pg_shard extension installed, you can set up one or PostgreSQL servers on EC2 with the pg_shard extension and use RDS nodes as worker nodes. The pg_shard node only needs to store a tiny bit of metadata which can be backed up in one of the worker nodes, so they are relatively low maintenance and can be scaled out to accommodate higher query rates.
A guide with a link to a CloudFormation template to set everything up automatically is available at: https://www.citusdata.com/blog/14-marco/178-scaling-out-postgresql-on-amazon-rds-using-masterless-pg-shard