All right so in this video let's see how to recover from of instance failure.
So.
So here let's say are EC2 instance fails.
But the obvious one to you especially the data was fine.
Right.
Also the easy availability zone is fine as well.
So how do we recover in this scenario.
So what we have to do is we have to create a replacement instance.
Right.
And this instance has to be in the same zone.
Right.
This is very very important.
The replacement server must be in the same availability zone.
So great.
And the reason is we want to attach the I didn't want you to the replacement server and the data cannot
be attached to a server in a different you know different.
So OK.
All right so so.
So we'll do that once the replacement server is created.
We'll address the data volume to the replacement server.
We'll also have to move the elastic IP address from the failed instance to the replacement instance
and then restart right in then we restart the restart the server and then we should be we should be
fine.
We should be fine.
You can verify using the local D-B dot PHP page whether the recovery has happened probably right.
So.
So.
So the steps are first stop the several failed instance like we detach the idiots one you disassociate
the elastic IP address.
Then we launched the replacements over here and then we will address the data volume we will see if
the elastic IP address and then restart and Besler get it right.
These are the six or seven steps that we have.
So let's see how to do this.
So let's say this is our EC2 instance like the one that is in a running state is the EC2 instance.
And let's say this has freed by this has failed.
So what we do is first when we stop right let's stop this instance and then we dispatch frypan detach
the server and also disassociate the elastic IP address so let's wait for this to move into the stop
state and and then we rebuild the date of the last of the IP address can be removed earlier as well.
So you can you can do this from elastic IPs say this associate.
Right.
And this will remove the elastic IP address from that particular instance.
OK it also now hopefully the instances in a stopped state
right.
Let's wait for this because if you try to the the data while instance status change and there could be
some some problems right.
Solaces waitlists and and then we move the needle here.
So here is the server is now in stop state.
Let's now go to the volume and select the data.
What you remember right they don't care about the people you want the data to be detached.
The way to move the data to and and no not just the state.
It should change to available which means the data volume is now detached from the EC2 instance.
OK once we've done that we can remove this so we can remove the server just to keep things clean.
And and so that there's no confusion as to which server you see replacements so why which one is the
face I talk.
So I'm going to go ahead and terminate this server and now our failed instance is gone.
Right but we have the elastic IP address and the data volume with us right.
OK.
After this we go to our army and we use our army and launch a service.
Right.
And this is a replacement server and this has to come up in the same.
So remember that the zone is one beat.
So this in step three.
Let's make sure that we select zone 1 be like this is because our data is in one B and the one that
cannot be attached to a server in any other song.
So this is the key step.
All right.
Otherwise everything remains the same.
Right we use the same security group we use the same key pair as well.
And now we have a replacement instance in the same.
Right in the same.
So.
OK.
Now we will wait for this to move into a running state and then we'll attach the attach the data will
you and we we'll also associate the elastic IP address.
OK so.
So let's do the Elastic IP address first.
All right.
So this is how you see it the elastic I think to the replacement so well.
And no let's go to the data in a suit and attach this in abash this to the replacements of as well.
OK.
All right so that's them.
And you know we should restart the server needs to be restarted.
So this is the replacement so we select this.
And let me first put this into a stop state I'll write and then we start this over once again.
And we just filter this so that there's no confusion.
So we wait for this to be in the stop state and then we'll start this over again.
And after that we simply have to ratify the application.
Right.
And we be using the elastic IP address right here.
And we better find the same page localdb dot PHP page and this should say connected as well that that
would mean our recovery has gone through.
Well OK so let me get to this.
Let's see if this isn't a stop state.
Any moment now let's just get this.
Five more seconds maybe maybe I'll get here.
Just it stop.
Now let me stop this.
All right let me let me set the filter to running.
OK now here.
Here's the setup.
It's now in the running state.
Let's now verify the application.
This is the Lochgelly page and I've refreshed this page and you can see it say it's connected.
So this means we have recovered successfully from an instance of failure.
And remember you know some of the steps that we performed were one detached the day that will you like
to that I want you ideally after after stopping the server.
Next this associate the Lustiger IP address launched the replacement.
So we're in the same.
So this is crucial.
Right.
Then attach the data volume associate the elastic IP and restart.
Right don't forget to restart because so my sql will not work straight away.
OK.
And then verify the the application and you can use the local db dot php page right.
OK.
So good luck with this.
'[AWS] > Highly Available, Scalable, AWS Stack' 카테고리의 다른 글
15. Recovery: Availability zone failure (0) | 2022.01.19 |
---|---|
14. Recovery: Volume failure (0) | 2022.01.19 |
12. Prep for recovery: Create AMI & EBS snapshot (0) | 2022.01.18 |
11. Prep for recovery: Configure Elastic IP address (0) | 2022.01.18 |
10. Prep for recovery: Configure MySQL to use data volume (0) | 2022.01.18 |
댓글