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
- Maria DB
- AWS Aurora
- Two Licensing models:
_ Bring Your Own License (BYOL)
Up to 40 DB instances per account
- 10 of this 40 can be ORACLE or MS SQL Server under License Included model.
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:
- DB workloads with moderate I/O requirements
Provisioned IOPS RDS Storage:
- High performance OLTP workloads
Magnetic RDS Storage:
- 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)