AWS: RDS (Relational Database Service)

It is an fully managed Relational DB Engine service where aws is responsible for:

Security and patching of the DB instance

Automated backup for your DB instances

Software updates for the DB engine

Easy scaling for storage and compute as required

If selected, Multi-AZ with synchronous replication between the active and standby DB instances

Automatic fail over if Multi-AZ was selected

Providing the ability to create DB read replicas for DB read scaling (intensive read deployments)

Every DB instance has a weekly maintenance window

If you did not specify one at the time you create the DB instance,

• AWS will choose one randomly for you (30 minutes long)

AWS is NOT responsible for:

Managing DB settings

Building a relational DB schema

DB performance tuning

Supported Relational DB engines

• MS SQL Server
• Oracle
• PostgreSQL
• Maria DB
• AWS Aurora
• MySQL

Licensing Models

• Two Licensing models:

_ Bring Your Own License (BYOL)

_License Included

RDS Limits

Up to 40 DB instances per account

• 10 of this 40 can be ORACLE or MS SQL Server under License Included model.

or

Under BYOL model, all 40 can be any DB engine you need.

RDS instance storage

Amazon RDS use EBS volumes (not instance-store) fro DB and Logs storage

General Purpose RDS Storage:

Use for

• DB workloads with moderate I/O requirements

Provisioned IOPS RDS Storage:

Use for

• High performance OLTP workloads

Magnetic RDS Storage:

Use for

• Small DB workloads

Maximum Storage Capacity for RDS DB instances

Upto 4TB for MS SQL Server

Upto 6TB for the rest of supported RDS Engines

Multi-AZ RDS option

You can select the Multi-AZ option during RDS DB instance launch

RDS service creates a standby instance in a different AZ in the same region, and configures SYNCHRONOUS replication between the primary and standby.

You can NOT read and write to the standby RDS DB instance

You can not dictate/select which AZ in the region will be chosen to create the standby DB instance.

• You can however, which AZ is selected after the standby is created.

Depending on the instance class it may take 1 to few minutes to failover to the standby instance

• Recommended is to implement DB connection retries into your application, to account for this few minutes required for failover
• AWS recommends the use of provisioned IOPS instance for Multi-AZ instances

Multi-AZ RDS- Fail over trigger

• Loss of primary AZ DB instance failure
• Loss of Network connectivity to primary
• Compute (EC2) unit failure on primary
• Storage (EBS) unit failure on primary
• The primary DB instance is changed
• Patching the OS of the DB insyance

Manual failover (reboot with failover on primary)

Multi- AZ RDS — Failover Logistics

During failover, the CNAME of the RDS DB instance is updated to map to the standby IP address

• This is why it is recommended to use the endpoint to reference your DB instances and not its IP address
• The CNAME does not change, because the RDS endpoint does not change

Multi- AZ failover-Recommendation

RDS endpoint does not change by selecting Multi-AZ option, how ever the primary and standby instances will have different IP addresses, given they are in different AZs.

• Hence it is always recommended that you do not use the IP address to point to your Multi-AZ RDS instances, rather use the endpoint\
• This is very helpful in a failover scenario, since the primary will fail to the standby, i.e: IP address of RDS instance will change

Referencing by endpoint means, there is no change (endpoint wise) when a fail over happens, so no disruptions or manual interventions to facilitate RDS DB instance access in a fail over scenario.

Multi-AZ-Manual Fail over and Reboot

In Multi-AZ deployment, you can only initiate a manual RDS DB instance failover (Primary to Standby) when rebooting

• This is by selecting the Reboot with fail over” reboot option on the primary RDS DB instance

A DB instance is required for changes to take effect when you change the DB parameter group, or when you change a static DB parameter.

• This reboot restarts the DB engine
• The DB parameter group, is a configuration container for the DB engine configuration.

RDS -Subnet Groups

Is a collection of subnets in a VPC that you want to allocated for DB instances launched in the VPC

Each DB subnet group must have at least one subnet in each AZ in a region

Even if you are starting with standalone RDS instance, configure the subnet group with a subnet in each AZ in the region.

• This will facilitate launching your standby instance in the subnet group when you opt for the multi-AZ deployment

During creating your RDS instance you can select a preferred AZ, and specify which subnet group, and subnet of that group, for your RDS DB instance.

• Then RDS service will allocate an IP address in that subnet to your RDS instance.
• And then RDS service will create an ENI, attach it to the RDS instance, and assign the above IP address to it.

DB Automated Backups or Manual Snapshots

These are two methods to backup and restore your RDS instances

• AWS RDS automated backups
• And, User initiated manual backups

Either one backs up the entire DB instance and not just the individual DBs.

Either one creates a storage volume snapshots of your entire DB isntance

• Not Just the individual databases

You can make copies of automated backups and of manual snapshots

AWS RDS Automated Backups

Automated backups by AWS, back up your DB data to multiple AZs to provide for data durability.

Are labeled automated in AWS console (easily distinguishable).

Stored in amazon S3.

Multi-AZ automated backups will be taken from the standby instance not the primary.

The DB instance must be in “Active” state for the automated backups to happen,

• If in any other state, like storage-Full state, the automated backups will not happen.

Automated backups (not the manual ones) are used for point-in time DB instance recovery.

It can restore the DB up to 5 minutes in time, using the DB transaction logs and the Automated snapshot.

RDS automatically backs up the DB instance daily, by creating a storage volume snapshot of your DB instance, including the DB transaction logs (modifications), which are critical to be able to restore uo to last 5 minutes in time.

• You can choose when during the day this is done (Backup window)
• No additional charge for RDS backing up your DB instances

During your daily backup window, your I/O may be suspended (for standalone RDS deployments)

For Multi-AZ deployment, backups are taken from the standby DB instance (True for Maria-DB, MySQL, Oracle, Postgre SQL)

Automated backups are deleted when you delete your RDS DB instance

An outage occurs if you change the backup retention period from Zero to Non-Zero value or the other way around

Automated backups are currently supported only for InnoDB storage engine for MySQL.
* Use of automated backups with other MySQL DB storage engines, including ISAM, may lead to unpredictable behavior during restoration.

Sharing your Automated Snapshots

Can not be shared directly

DB Retention Period

The period of time AWS keeps the automated backups before deleting them

By default : 7 days if configured from the AWS console for all DB engines (Except Aurora, default is one day regardless how it was configured)

Thankyou,

Bharathi.