Let’s assume you just had the world’s most amazing idea, and you want to create an application around it. Now application gets more requests so you have to handle the application data using Database. You have to install all Software to support your application. You would have to install all the latest security patches and updates for your database server and also make sure that it stays in a healthy state. How can you scale automatically and backups and disaster recovery?
Do you want to reduce this overhead? Are you looking for someone has to do this? Do you want to focus only on application and you don’t want any code changes? Here is the solution that is AWS RDS.
The Amazon Relational Database Service (RDS AWS) is a web service that makes it easier to set up, operate, and scale a relational database in the cloud. It provides cost-efficient, resizable capacity in an industry-standard relational database and manages common database administration tasks.
Are you thinking that RDS is a database? it is not a database, it is a service that manages databases. RDS supports a number of database engines: MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL Server, Aurora. We can simply say RDS is a Database as Service(DBaaS).
Do you have a doubt about what is the difference between MySQL and which MySQL managed by RDS? In normal MySQL, you have to manage regular backups, underlying infrastructure, updations and regular backups but in MySQL managed by RDS you no need to do that. Just you have to focus on your application.
Do you want to for resilience, high availability and fault tolerance? By using Multi-AZ we can achieve that. RDS can be provisioned in single or Multi-AZ mode. Multi-AZ provisions a primary instance and a standby instance in a different AZ of the same region. Only the primary can be accessed using the instance CNAME. There is no performance benefit, but it provides a better RTO than restoring a snapshot. Replication of data is synchronous? it ‘s copied in real-time from the primary to the standby as it ‘s written. The primary and master each have their own storage. Maintenance is performed on the standby first, which is then promoted to minimize downtime.
Do you want backups without your effort at every time? RDS is capable of a number of different types of backups. Automated backups to S3 occur daily and can be retained from 0 to 35 days (with 0 being disabled). Manual snapshots are taken manually and exist until deleted, and point-in-time log-based backups are also stored on S3. Backups are taken using the standby, ensuring no performance impact.
Do you want to increase reads to your application? By using Read Replicas you can achieve that. Read Replicas are read-only copies of an RDS instance that can be created in the same region or a different region from the primary instance. Read Replicas can be addressed independently (each having their own DNS name)and used for reading workloads, allowing you to scale reads. Five Read Replicas can be created from an RDS instance, allowing a 5x increase in reads. Read Replicas can be created from Read Replicas, and they can be promoted to primary instances and can be themselves Multi-AZ. Read Replicas don’t scale writes, which have to occur on the primary instance. AWS handles the connection between regions automatically data in transit is encrypted.
RDS also offers encryption at rest. Encryption can be configured when creating DB instances. Encryption can be added by taking a snapshot, making an encrypted snapshot, and creating a new encrypted instance from that encrypted snapshot. Encryption cannot be removed. Read Replicas need to be the same state as the primary instance (encrypted or not). Encrypted snapshots can be copied between regions but a new destination region KMS CMK is used (because they are region-specific).
Did you observe that RDS also supports Aurora? But what is Aurora?
Aurora is a database engine developed by AWS that is compatible with MySQL, PostgreSQL and associated tools.
Aurora operates with a radically different architecture as opposed to the other RDS database engines. Aurora uses a base configuration of a cluster. A cluster contains a single primary instance and zero or more replicas
All instances (primary and replicas) use the same shared storage that is the cluster volumes. Cluster volume is totally SSD based, which can scale to 64 TiB in size. Replicates data six times, across three Availability Zones. Aurora only supports regions with a minimum of 03 Availability Zones.
Each Availability Zone maintains two copies of the storage of each RDS Aurora instance and altogether minimum six (06) copies in all three (03) Availability Zones. The primary compute Aurora instance writes data to the data copies in the storage cluster. On the other hand, the read replicas in the other instances can read the data from the storage cluster. The storage cluster is represented as a single, logical volume to the primary instance and to Aurora Replicas in the Aurora DB cluster.
An Aurora cluster can have only one primary instance. There are no standby instances in the Aurora cluster. Since the Aurora compute instances (EC2) and the Aurora storage cluster is independent, it is quite easy to scale the storage (can scale up to 64 Tebibyte ) rather scaling within EC2 instances in a traditional RDS Multi-AZ architecture. There can be 15 read replicas (compared to 05 in a typical RDS Multi-AZ architecture). Aurora maintains HA by having Aurora Read Replicas in the other Availability Zones. Aurora automatically fails over to an Aurora replica in case the primary DB instance becomes unavailable.
If the primary instance fails, Aurora automatically fails over to a new primary instance. It does either by creating a new primary instance or promoting a read replica. There will be a slight interruption in this process to the cluster. The promotion of a read replica will take less time than creating a new primary instance. But if there are no read replicas in the cluster, there is no option but to create a new primary instance. Hence AWS recommends you to have at least 1 or more read replicas (with the same specification of the primary instance) to minimize the downtime of the cluster.
I hope now you have a better understanding of AWS RDS. So far we have discussed the real problem scenarios and how can we solve these problems by using AWS RDS. And we discussed key terms of AWS RDS and Amazon Aurora. Do you have any doubts about this, feel free to reach out to us at Vitwit.
