An introductory look at the AWS RDS service


Amazon RDS (Relational Database Service) is a fully managed relational database service in the cloud (e.g. MySQL PostgreSQL/ Auora). Fully managed means that AWS manages all the underlying hardware for you and handles the updating of software (like MySQL server versions).

So, when we’re running on fully managed services, we can connect to the database server itself but we are unable to connect to the underlying operating system (as all that is managed for you by Amazon). While it is fully managed, you are able to resize or provision hardware for scaling (by choosing instance type) and can choose to deploy your RDS as a multi availability zone deployment.

Deploying into multiple availability zones gives us automatic recovery in the event of a system outage. Multi AZ (availability zone) synchronously replicates data to the backup instance located in another availability zone. This backup instance lives in the same region, but a different availability zone.

If there is an outage, AWS will automatically change the host name to your backup instance, reducing the amount of downtime that you would face as a result of an issue. Multi AZ also helps when we look to scale our hardware. For example, if you want to change the instance type, it will fail over to the backup instance until your changes are applied and your instance is back online.

As I mentioned, RDS is a managed service, so if there is a software update, it will shut down your primary instance, automatically fail over to your backup instance and install the updates – ensuring you do not face any down time. An added benefit is that backups are taken against the standby instance, so there is less risk of I/O freezes and can also help to reduce the performance impact of backups.

RDS is currently supported by:
– PostgreSQL
– Oracle
– Aurora

RDS provides automatic minor updates (software & OS) by default. It will also enable automatic point in time backups (snapshots). From these backups, we can restore to a specific point in time. The only requirement for these backups is that the database engine must be transactional (innodb tables). The automated backups are deleted once the database is deleted & cannot be recovered. However, it is possible to take a snapshot manually, which will remain until we choose to delete it.

Read replicas work on MySQL, PostgreSQL and Auora. It uses native replication on MySQL / PostgreSQL – when data writes to the primary instance, it will replicate it to the read replica. You cannot write to the read replica. It just receives changes to the database tables. Read replicas help us scale out for reading our databases – imagine you have a huge query to run on your database, you wouldn’t do that against the live server (as performance would be hit), but you would want to query the latest data. By querying the read replica, you get the latest data without impacting the live server performance.

So, read replicas enable us to offload database tasks from the production servers. The read replica can drive the BI (Business Intelligence) applications so that the BI is running off live data, without affecting the load on the production database.

We should use read replicas when we have
– High non-cached DB read traffic
– Running business functions like BI dashboards
– Importing / exporting data into RDS
– Rebuilding indexes – a large index can be rebuilt on read replica. the read replica can then be promoted to the primary instance.

We can monitor replication lag with Cloudwatch (the length of time it takes to copy data). Cloudwatch can also provide notifications when:
– Snapshots are taken
– Parameter group changes
– Option changes
– Security group changes

This means that we know when users are making changes. RDS also integrates with cloudwatch for:
– CPU utilization
– Freeable memory / swap usage (this is possible as AWS manages the OS for us on RDS).
– DB connections
– Read/write IOPS
– Read replica latency
– Read / write throughput

As a final note, it’s important to remember that we have to create a subnet group for our RDS instances to launch into. Subnet groups are a list of subnets that create a group. The subnet can live within 1 availability zone. If we use multi AZ, the standby instance needs to be in a different availability zone, but, the standby needs to be part of our network.

Image used under creative commons