How are Amazon RDS Database Instances Provisioned?

2
votes

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?

1
amazon-web-servicesamazon-rds
If you have a mutli-az instance then during maintenance periods it will upgrade one instance, then fail over, then upgrade the other instance. However during a failover your applications may have a temporary period of maybe 60 seconds where they can't open new database connections, which is why it is still important to schedule this at the time that is most convenient for you. – Mark B
Regarding OS maintenance, you never have any visibility into the OS at all. You don't get SSH access. The OS is entirely managed behind the scenes for you. OS maintenance tasks that would require your DB server to be interrupted would happen during the maintenance window you specify. You definitely remove a large amount of the maintenance you need to perform yourself when you use RDS. – Mark B
@MarkB Why the failover-delay? If the application understands that fail-over can occur, shouldn't it only take enough time for a single connection to timeout and fail-over to switch to the alternate host? – Christopher Schultz

1 Answers

2
votes

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.