DB instances replicas can be created in two ways Multi-AZ & Read Replica
Multi-AZ deployment provides high availability and failover support
RDS automatically provisions and manages a synchronous standby replica in a different AZ (independent infrastructure in a physically separate location)
RDS automatically fails over to the standby so that database operations can resume quickly without administrative intervention in case of
Planned database maintenance
Rebooting of the Primary instance
Primary DB instance connectivity or host failure, or an
Availability Zone failure
RDS uses the PostgreSQL, MySQL, and MariaDB DB engines’ built-in replication functionality to create a special type of DB instance called a Read Replica from a source DB instance.
Load on the source DB instance can be reduced by routing read queries from applications to the Read Replica.
Read Replicas allow elastic scaling beyond the capacity constraints of a single DB instance for read-heavy database workloads
Multi-AZ deployments provides high availability and automatic failover support for DB instances
Multi-AZ helps improve the durability and availability of a critical system, enhancing availability during planned system maintenance, DB instance failure and Availability Zone disruption.
Multi-AZ is a High Availability feature is not a scaling solution for read-only scenarios; standby replica can’t be used to serve read traffic. To service read-only traffic, use a Read Replica.
Multi-AZ deployments for Oracle, PostgreSQL, MySQL, and MariaDB DB instances use Amazon technology, while SQL Server DB instances use SQL Server Mirroring.
In a Multi-AZ deployment,
RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone.
Copies of data are stored in different Availability Zones for greater levels of data durability.
Primary DB instance is synchronously replicated across Availability Zones to a standby replica to provide
eliminate I/O freezes during snapshots and backups
and minimize latency spikes during system backups.
DB instances may have increased write and commit latency compared to a Single AZ deployment, due to the synchronous data replication
Transaction success is returned only if the commit is successful both on the primary and the standby DB
There might be a change in latency if the deployment fails over to the standby replica, although AWS is engineered with low-latency network connectivity between Availability Zones.
When using the BYOL licensing model, a license for both the primary instance and the standby replica is required
For production workloads, it is recommended to use Multi-AZ deployment with Provisioned IOPS and DB instance classes (m1.large and larger), optimized for Provisioned IOPS for fast, consistent performance.
When Single-AZ deployment is modified to a Multi-AZ deployment (for engines other than SQL Server or Amazon Aurora)
RDS takes a snapshot of the primary DB instance from the deployment and restores the snapshot into another Availability Zone.
RDS then sets up synchronous replication between the primary DB instance and the new instance.
This avoids downtime when conversion from Single AZ to Multi-AZ
RDS Multi-AZ Failover Process
In the event of a planned or unplanned outage of the DB instance,
RDS automatically switches to a standby replica in another AZ, if enabled for Multi-AZ.
Time it takes for the failover to complete depends on the database activity and other conditions at the time the primary DB instance became unavailable.
Failover times are typically 60-120 secs. However, large transactions or a lengthy recovery process can increase failover time.
Failover mechanism automatically changes the DNS record of the DB instance to point to the standby DB instance.
Multi-AZ switch is seamless to the applications as there is no change in the endpoint URLs but just needs to re-establish any existing connections to the DB instance.
RDS handles failover automatically so that database operations can be resumed as quickly as possible without administrative intervention.
Primary DB instance switches over automatically to the standby replica if any of the following conditions occur:
An Availability Zone outage
Primary DB instance fails
DB instance’s server type is changed
Operating system of the DB instance is undergoing software patching
A manual failover of the DB instance was initiated using Reboot with failover (also referred to as Forced Failover)
If the Multi-AZ DB instance has failed over, can be determined by
DB event subscriptions can be setup to notify you via email or SMS that a failover has been initiated.
DB events can be viewed via the Amazon RDS console or APIs.
Current state of your Multi-AZ deployment can be viewed via the RDS console and APIs.
Amazon RDS uses the MySQL, MariaDB, and PostgreSQL (version 9.3.5 and later) DB engines’ built-in replication functionality to create a Read Replica from a source DB instance.
Updates made to the source DB instance are asynchronously copied to the Read Replica.
Load on the source DB instance can be reduced by routing read queries from the applications to the Read Replica.
Using Read Replicas allow DB to elastically scale out beyond the capacity constraints of a single DB instance for read-heavy database workloads.
Read Replica operates as a DB instance that allows read-only connections; applications can connect to a Read Replica the same way they would to any DB instance.
Read Replica creation
Up to five Read Replicas can be created from one source DB instance.
Automatic backups must be enabled on the source DB instance by setting the backup retention period to a value other than 0
Existing DB instance needs to be specified as the source.
RDS takes a snapshot of the source instance and creates a read-only instance from the snapshot.
RDS then uses the asynchronous replication method for the DB engine to update the Read Replica for any changes to the source DB instance.
RDS replicates all databases in the source DB instance.
RDS sets up a secure communications channel between the source DB instance and the Read Replica, if that Read Replica is in a different AWS region from the DB instance.
RDS establishes any AWS security configurations, such as adding security group entries, needed to enable the secure channel.
During the Read Replica creation, a brief I/O suspension on the source DB instance can be experienced as the DB snapshot occurs.
I/O suspension typically lasts about one minute and can be avoided if the source DB instance is a Multi-AZ deployment (in the case of Multi-AZ deployments, DB snapshots are taken from the standby).
Read Replica creation time can be slow if any long-running transactions are being executed and should wait for completion
For multiple Read Replicas created in parallel from the same source DB instance, only one snapshot is taken at the start of the first create action.
A Read Replica can be promoted to a new Independant source DB, in which case the replication link is broken between the Read Replica and the source DB. However, the replication continues for other replicas using the original source DB as the replication source
Read Replica Deletion & DB Failover
Read Replicas must be explicitly deleted, using the same mechanisms for deleting a DB instance.
If the source DB instance is deleted without deleting the replicas, each replica is promoted to a stand-alone, single-AZ DB instance.
If the source instance of a Multi-AZ deployment fails over to the standby, any associated Read Replicas are switched to use the secondary as their replication source.
Read Replica Storage & Compute requirements
A Read Replica, by default, is created with the same storage type as the source DB instance.
For replication to operate effectively, each Read Replica should have the same amount of compute & storage resources as the source DB instance.
Source DB instance, if scaled, Read Replicas should be scaled accordingly
Read Replica Features & Limitations
RDS does not support circular replication.
DB instance cannot be configured to serve as a replication source for an existing DB instance; a new Read Replica can be created only from an existing DB instance for e.g., if MyDBInstance replicates to ReadReplica1, ReadReplica1 can’t be configured to replicate back to MyDBInstance. From ReadReplica1, only a new Read Replica can be created, such as ReadRep2.
MySQL, PostgresSQL (update from June 2016) or MariaDB Read Replica can be created in a different region than the source DB instance which helps to improve
disaster recovery capabilities (reduces RTO and RPO),
scale read operations into a region closer to end users,
migration from a data center in one region to another region
Read Replica can be created from other Read replicas as well. However, the replica lag is higher for these instances and there cannot be more than four instances involved in a replication chain.
Read Replica Use cases
Read Replicas can be used in variety of use cases, including:
Scaling beyond the compute or I/O capacity of a single DB instance for read-heavy database workloads, directing excess read traffic to Read Replica(s)
Serving read traffic while the source DB instance is unavailable for e.g. If the source DB instance cannot take I/O requests due to backups I/O suspension or scheduled maintenance, the read traffic can be directed to the Read Replica(s). However, the data might be stale.
Business reporting or data warehousing scenarios where business reporting queries can be executed against a Read Replica, rather than the primary, production DB instance.
AWS Certification Exam Practice Questions
Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
Open to further feedback, discussion and correction.
You are running a successful multi-tier web application on AWS and your marketing department has asked you to add a reporting tier to the application. The reporting tier will aggregate and publish status reports every 30 minutes from user-generated information that is being stored in your web applications database. You are currently running a Multi-AZ RDS MySQL instance for the database tier. You also have implemented ElastiCache as a database caching layer between the application tier and database tier. Please select the answer that will allow you to successfully implement the reporting tier with as little impact as possible to your database.
Continually send transaction logs from your master database to an S3 bucket and generate the reports off the S3 bucket using S3 byte range requests.
Generate the reports by querying the synchronously replicated standby RDS MySQL instance maintained through Multi-AZ (Standby instance cannot be used as a scaling solution)
Launch a RDS Read Replica connected to your Multi-AZ master database and generate reports by querying the Read Replica.
Generate the reports by querying the ElastiCache database caching tier. (ElasticCache does not maintain full data and is simply a caching solution)
A company is deploying a new two-tier web application in AWS. The company has limited staff and requires high availability, and the application requires complex queries and table joins. Which configuration provides the solution for the company’s requirements?
MySQL Installed on two Amazon EC2 Instances in a single Availability Zone (does not provide High Availaility out of the box)
Amazon RDS for MySQL with Multi-AZ
Amazon ElastiCache (Just a caching solution)
Amazon DynamoDB (Not suitable for complex queries and joins)
Your company is getting ready to do a major public announcement of a social media site on AWS. The website is running on EC2 instances deployed across multiple Availability Zones with a Multi-AZ RDS MySQL Extra Large DB Instance. The site performs a high number of small reads and writes per second and relies on an eventual consistency model. After comprehensive tests you discover that there is read contention on RDS MySQL. Which are the best approaches to meet these requirements? (Choose 2 answers)
Deploy ElastiCache in-memory cache running in each availability zone
Implement sharding to distribute load to multiple RDS MySQL instances (this is only a read contention, the writes work fine)
Increase the RDS MySQL Instance size and Implement provisioned IOPS (not scalable, this is only a read contention, the writes work fine)
Add an RDS MySQL read replica in each availability zone
Your company has HQ in Tokyo and branch offices all over the world and is using logistics software with a multi-regional deployment on AWS in Japan, Europe and US. The logistic software has a 3-tier architecture and currently uses MySQL 5.6 for data persistence. Each region has deployed its own database. In the HQ region you run an hourly batch process reading data from every region to compute cross-regional reports that are sent by email to all offices this batch process must be completed as fast as possible to quickly optimize logistics. How do you build the database architecture in order to meet the requirements?
For each regional deployment, use RDS MySQL with a master in the region and a read replica in the HQ region
For each regional deployment, use MySQL on EC2 with a master in the region and send hourly EBS snapshots to the HQ region
For each regional deployment, use RDS MySQL with a master in the region and send hourly RDS snapshots to the HQ region
For each regional deployment, use MySQL on EC2 with a master in the region and use S3 to copy data files hourly to the HQ region
Use Direct Connect to connect all regional MySQL deployments to the HQ region and reduce network latency for the batch process
What would happen to an RDS (Relational Database Service) multi-Availability Zone deployment if the primary DB instance fails?
IP of the primary DB Instance is switched to the standby DB Instance.
A new DB instance is created in the standby availability zone.
The canonical name record (CNAME) is changed from primary to standby.
The RDS (Relational Database Service) DB instance reboots.
Your business is building a new application that will store its entire customer database on a RDS MySQL database, and will have various applications and users that will query that data for different purposes. Large analytics jobs on the database are likely to cause other applications to not be able to get the query results they need to, before time out. Also, as your data grows, these analytics jobs will start to take more time, increasing the negative effect on the other applications. How do you solve the contention issues between these different workloads on the same data?
Enable Multi-AZ mode on the RDS instance
Use ElastiCache to offload the analytics job data
Create RDS Read-Replicas for the analytics work
Run the RDS instance on the largest size possible
Will my standby RDS instance be in the same Availability Zone as my primary?
Only for Oracle RDS types
Only if configured at launch
Is creating a Read Replica of another Read Replica supported?
Only in certain regions
Only with MySQL based RDS
Only for Oracle RDS types
A user is planning to set up the Multi-AZ feature of RDS. Which of the below mentioned conditions won’t take advantage of the Multi-AZ feature?
Availability zone outage
A manual failover of the DB instance using Reboot with failover option
When the user changes the DB instance’s server type
When you run a DB Instance as a Multi-AZ deployment, the “_____” serves database writes and reads
When running my DB Instance as a Multi-AZ deployment, can I use the standby for read or write operations?
Only with MSSQL based RDS
Only for Oracle RDS instances
Read Replicas require a transactional storage engine and are only supported for the _________ storage engine
A user is configuring the Multi-AZ feature of an RDS DB. The user came to know that this RDS DB does not use the AWS technology, but uses server mirroring to achieve replication. Which DB is the user using right now?
If I have multiple Read Replicas for my master DB Instance and I promote one of them, what happens to the rest of the Read Replicas?
The remaining Read Replicas will still replicate from the older master DB Instance
The remaining Read Replicas will be deleted
The remaining Read Replicas will be combined to one read replica
If you have chosen Multi-AZ deployment, in the event of a planned or unplanned outage of your primary DB Instance, Amazon RDS automatically switches to the standby replica. The automatic failover mechanism simply changes the ______ record of the main DB Instance to point to the standby DB Instance.
When automatic failover occurs, Amazon RDS will emit a DB Instance event to inform you that automatic failover occurred. You can use the _____ to return information about events related to your DB Instance
The new DB Instance that is created when you promote a Read Replica retains the backup window period.
Will I be alerted when automatic failover occurs?
Only if SNS configured
Only if Cloudwatch configured
Can I initiate a “forced failover” for my MySQL Multi-AZ DB Instance deployment?
Only in certain regions
Only in VPC
A user is accessing RDS from an application. The user has enabled the Multi-AZ feature with the MS SQL RDS DB. During a planned outage how will AWS ensure that a switch from DB to a standby replica will not affect access to the application?
RDS will have an internal IP which will redirect all requests to the new DB
RDS uses DNS to switch over to standby replica for seamless transition
The switch over changes Hardware so RDS does not need to worry about access
RDS will have both the DBs running independently and the user has to manually switch over
Which of the following is part of the failover process for a Multi-AZ Amazon Relational Database Service (RDS) instance?
The failed RDS DB instance reboots.
The IP of the primary DB instance is switched to the standby DB instance.
The DNS record for the RDS endpoint is changed from primary to standby.
A new DB instance is created in the standby availability zone.