LAB - Deploy an Amazon RDS Multi-AZ and Read Replica in AWS
Last updated
Was this helpful?
Last updated
Was this helpful?
In this hands-on lab, we will work with Relational Database Service (RDS). This lab will give you hands-on experience with enabling Multi-AZ and backups, creating a read replica, promoting a read replica, and updating the RDS endpoint in Route 53. Multi-AZ and read replicas serve different purposes with RDS. Multi-AZ is strictly for failover, as the standby instances cannot be read from by an application. Read replicas are used for improved performance and migrations. With read replicas, you can write to the primary database and read from the read replica. Since a read replica can be promoted to be the primary database, it makes for a great tool in disaster recovery and migrations.
Log in to the AWS Management Console using the credentials provided. Make sure you're in the N. Virginia (us-east-1) Region throughout the lab.
Configure Your Multi-AZ Instance
Note: The target group for the load balancer may need additional time to provision. Before starting the lab, navigate to EC2 > Target Groups and select TG1 to ensure you have at least one instance registered as healthy. If your target group shows no instances are healthy, then wait a few more minutes until one changes.
From the EC2 service page, scroll down to Load Balancing and select Load Balancers.
Select the load balancer and then copy the DNS name of the load balancer.
Open a new browser tab, and paste your copied DNS name.
You will use this web page to test failovers and promotions in this lab.
Go back to the AWS Management Console, and navigate to RDS using the Services menu or the unified search bar.
In the Amazon RDS sidebar menu, select Databases.
Select the radio button to the left of your wordpress database details.
Along the top of the page, click Modify.
The database's configuration options may take a moment to load.
Enable Multi-AZ deployment:
In the Availability & durability section, select Create a standby instance (recommended for production usage).
Scroll to the bottom of the page, and click Continue.
In the Schedule modifications section, select Apply immediately.
Click Modify DB instance.
After a few moments, click Refresh.
You should see the Status change to Modifying. If you don't see this change, you may need to click Refresh again. The instance may take up to 10 minutes to enable Multi-AZ.
Verify the Multi-AZ Deployment
After the instance is available again, verify that Multi-AZ is enabled:
In the Amazon RDS sidebar menu, select Events.
Review the events history for your instance.
You should see an event for converting the instance to Multi-AZ.
Reboot the instance to simulate the Multi-AZ redundancy:
In the Amazon RDS sidebar menu, select Databases.
Ensure the radio button to the left of your instance is selected.
Use the Actions dropdown to select Reboot.
On the Reboot DB Instance page, select Reboot With Failover? and click Confirm.
This ensures the secondary instance takes over when this instance goes down. The reboot takes a few moments.
Navigate to the DNS web page tab and refresh the page.
The web page will experience only a small amount of downtime while the database is being modified (which causes a temporary 502 error). After the reboot is complete, the Multi-AZ standby is now the primary.
Navigate back to the AWS Management Console and use the Amazon RDS sidebar to select Events (you may need to expand the sidebar menu).
Review the events history for your instance.
You should see events for the Multi-AZ failover listed.
In the Amazon RDS sidebar menu, select Databases to return to your instance details.
Ensure the radio button to the left of your instance is selected.
Use the Actions dropdown to select Create read replica.
In the Settings section, enter wordpress-rr into the DB instance identifier field.
In the AWS Region section, ensure the Destination Region is set to US East (N. Virginia).
Leave the other default settings and click Create read replica at the bottom of the page.
The read replica will take about 5-10 minutes to become available.
Navigate to the DNS web page tab and refresh the page.
The web page should stay up because the read replica changes are asynchronous.
Promote the Read Replica
Navigate back to the AWS Management Console.
After the read replica is available, select the radio button to the left of it.
Use the Actions dropdown to select Promote.
Leave all the defaults and click Promote read replica at the bottom of the page.
After a few moments, click Refresh.
You should see that the read replica's Role has changed from Replica to Instance, and that the Status is now Modifying.
Change the CNAME Record to Point to the New Endpoint
After the read replica instance is available, select the wordpress-rr instance name.
On the Connectivity & security tab, copy the Endpoint to your clipboard.
Open Route 53 in a new tab.
You can disregard any error messages that display.
In the Route 53 sidebar menu, select Hosted zones.
Select the mydomain.local hosted zone name.
In the hosted zone details, you should see a CNAME record that points to your wordpress database endpoint.
Check the checkbox to the left of the CNAME record.
In the Record details pane on the right, click Edit record.
Replace the existing Value with your copied read replica endpoint.
Click Save.
Navigate to the DNS web page tab and refresh the page.
You should see no downtime.
