Hey, everyone.
And welcome back.
Now into this video at a high level overview, we are going to discuss about the Amazon ideas multi
availability zone deployments also referred to as multi deployments.
Now, before we discuss more detail about it, let's look into a typical challenge.
So let's assume that you have a database that is running in the availability zone, number one.
Now, due to some reason, if this availability zone one goes down or maybe the hardware on which the
database was running goes down, then your entire application will go down because the heart of the
application where the data is primarily stored is database.
If database is down, then the entire website can go down.
And this is something that you do not really want for the production environments.
And this is the reason why it is very important that whenever you use ideas for production, you should
avoid the deployments based on a single availability zone only.
And the better architecture is to use a multi availability zone deployments.
So in a multi AC based deployment architecture, what happens is that you have the primary database
here and you have a secondary database that is running in a different availability zone of the same
region and there is a replication that happens between both of these databases.
Now, due to some reason, let's say the primary database goes down in such cases, the ideas will redirect
all the requests to the stand by instance.
All right.
So this is the automated process.
As a user or as an application, you do not really need to worry about that.
Now, one of the question that comes here is that in which scenario does this automated failover takes
place from primary to standby instance?
Now, before we look into the field of condition, let's quickly revise that in case if there are planned
or unplanned outage of your database instance, then this automatically switches to the standby replica
in another availability zone in the multi AC deployments.
This is something that we have seen.
Now let's look into some of the conditions.
First is that if there is a loss of availability in the primary availability zone.
Second is that if there is a loss of network connectivity to the primary instance, if there is a compute
unit failure on primary instance, again, the failover condition takes place.
If there is a storage failure on the primary database instance in such cases, also the automated failover
takes place.
And when we look into the failover time, it typically ranges from 60 to 1 to 20 seconds.
Now, let's do one thing.
Let's go ahead and understand this from demo perspective so that our concept is clear.
Now for today's demo, I have a database which is created based on multi AC deployment.
The name of the database is Demo DB, Multi AC.
Now, if you look into this specific database, let me go to the configuration.
Let's go a bit down.
You see that it states that multi AC is enabled so it is stating as yes.
So let's go ahead and look into how exactly it functions.
So we'll go to connectivity here.
Let me copy the end point of the IDs instance.
And let's quickly do an let's look up to see what is the IP address that is returned here.
The IP address is one 7231 37.32.
So at this stage, if I have to show you this in terms of diagram, you can consider that this IP address
that has been returned is that of the primary instance here.
Now for demo perspective, we'll do a failover and we'll see on how the IP address changes to that of
the secondary instance.
So let's do one thing.
Let's go ahead and reboot the database instance.
Now, whenever you reboot, you have an option of reboot with Failover.
So let's go ahead and do a confirm.
So this is just a simple way to identify on how the multi AC deployment works in real world scenarios.
In case if there is issue related to network and all the failover happens automatically, you do not
really need to worry about that.
So let me quickly do a confirm.
All right.
So the rebuilding is taking place.
So let's quickly wait for a moment here.
So on the refresh, our status is now available.
Now, at this stage, if you perform the NSS lookup again to find the IP address associated with the
database instance, this time you will see the IP address is different.
Earlier it was one 7231 3732 now it is one 7231 79.1 47.
So behind the scenes RDC has automatically redirected the request to the standby instance here.
Now, one important thing that needs to be noted is that the endpoint URL that we are discussing over
here, this remains to be the same.
So even if the primary database goes down and if the requests are going to this endpoint, the ideas
will automatically direct the request to the standby instance.
And this is the reason why the oral high availability works in a multi AC based architecture.