Come back still with relational database service or are they.
And let's dive into a replica as and how you can maintain more or scale on the heat capacity of the
database.
So when the required read all capacity is reached because of intense limitation because of the number
of applications that are carrying that.
But you still need more capacity.
So what do you do then use or take advantage of the replicates.
So what is that replica.
We have as we mentioned before we have the primary and we have this standby right.
Or it could be only the problem and if it is a stand alone implementation so that either case can be
created from a stand alone against instance or from the primary of a multi easy or D s deployment.
So there is basically whatever is written to the primary we know before that it will be synchronously
replicated to the standby but it will be asynchronously replicated then to replicate.
So there is some delay here.
They call it time lag between when the information is written to the prime rate until it becomes available
on the reader because it's asynchronous replication not synchronous or prickish for this primary to
become the source of replication to replicates.
It must have automatic backups enabled.
So basically it must have a retention period of more than zero any value more than zero.
That means automated backups are running kernel you have read replicas made of a multi RDX deployment.
Yes but they would be made from the prime minister the primary would be the source and it will then
create or replicate to that he is going to have multiple region because yes you can have multiple reader
because for all the read replicas you can have up to 15 Orrery because that can be distributed in the
availability zones where the cluster is but within a region so it cannot span beyond the region that
the Republicans will be within the use cases for a BECAUSE WHY DO I NEED THEM.
If you want to shift to intensive application.
So instead of reading that it intends to application see the freedom from the primary.
Now I will shift the applications to read from exactly from one or more triplicates if I want to do
data warehousing then shifted or analytics then shifted to the real replicas and make all that operations
happen from here instead of overloading that primary database instance.
Use Case number two is killing beyond the capacity of your main database instance for heavy workload
and service the traffic while the source is unavailable let's say for any reason you have the primary
and the primary is either under attack it's it's going through a support process maintenance or anything
like that or it cannot scale it.
It has reached its limit from the.
What would that be Dipika help me with.
So now it can read from the replicas because they will still be available even if the source iOS on
Saturday or they will just kill the requirement because you cannot have more than four instances involving
that application chain.
So as you mentioned my sequel and maybe have is they support the replicas of real replicas.
How many can I can I really could.
So I have here.
The source has replicated so this is level one of each application.
Can I get to a second level.
Yes you can connect it to a third level yes you can connect it to a fourth level no income up more than
four levels can not be in a chain of prickish.
Now remember one thing you can do this but remember that here is asynchronous.
And then when the data gets here of data then this is asynchronous and when it gets updated then this
is asynchronous so you have legs and legs and Laxey need to be mindful of the potential delay.
The data will be available on that in that region because if you change them like that a potential exam
question let's say we have a multi is the primary standby.
And I have created three replicas.
OK so I have here multiple one or more Republicans.
Now all of them are replicating from the source right.
They are reading from the source.
What happens if there is a fail over manual or automatic from the primary to a standby.
So this one becomes the primary and this one which is the standby.
Do they still get their application from here.
The answer is No.
They will be shifting to the other one as the application source.
So if the first instance of a multi deployment fails over the secondary to the secondary any associated
with because our switch to use the secondary as the replication source with replicas are they automatically
deleted when I delete a database instance.
If I go ahead and delete the primary order is it because I'm going to go away.
No you have to do it manually as well.
What happens if I delete the primary.
So I have the primary source.
I get the source but I forgot to delete it.
Replicates what will happen now.
They will automatically all get promoted to exactly a single easy stand alone database instance you'll
end up having one two three for instance in different availability zones if you promote my sequel or
my database region because that is in turn if we get into another replica those three because we remain
active.
So here we have a primary and I have in my mind equal or my database so I have read Level 1 and this
was replicating to replicate level 2.
Now if I promote what you mean by promote If I change this one to become a fully fledged are the first
instance to read and write what happens to this one it doesn't die.
Does it go from the primary.
Does it go away.
What happens if you promote this one.
This one will continue to lead to this.
Anyways I was the source of applications that promote this this will continue as is and it will continue
to read from the new standalone ideas in cross region read replicas and let's say I have a standby multi
easy in one region or one.
Now if I'm very concerned about disaster recovery can I create in region are two replica of our primary
database instance that exists in region one a different region.
If you have a region and you have multiple ACS and you would like to build a fault tolerant solution
that would even cater for a regional failure.
So think of immediately for them are the US think of a cross region or read replicas and this is available
for my mom post.
My sequel maybe and possibly a sequel so it can be used to provide for lower RPO.
So basically when you do that three replicas if you lose a region then you can have since you are doing
replication into triplicated it will take you a few minutes to bring this up and running.
So that means your data loss will be less and that's why you were saying lower RPO.
Another way this could be asked about in a in a in a question.
Let's say you have an enterprise that has presence in many regions but in the HQ region in the main
company our headquarter region they would like to run sales analytics themselves reporting.
So you can query and have an application here that needs to query all these different databases.
They are are the result in different regions I mean and you want to query all of this and that will
be query intensive as well.
And then you can under-reporting and then the reports will be ready for the management.
Why don't you as a solution to avoid latencies over the Internet and all that.
Why don't you just create a replica of each one in the HQ region and then run your application on an
X across or against that reads replicas that are available within the same region.
That will give you two benefits.
The first one is you don't have to burden the artist that the business with the queries.
The second one is you avoid latencies and they available here to run that and you provide reporting
quicker.
You can promote read pick up promoting Republicans to stand alone.
So if you have read the replica in one easy or in one region that you would like for some reason to
promote this to become a stand alone single everliving it is on every instance.
So I'm not going to be a multi easy one then you can do that you can select that and then promoted to
become standalone fully fledged database.
Now what I do.
What do I do if I hit the largest or this instance and I still need to skate.
What do I do then.
There is a way to do partitioning and to split your data base over multiple odious instances.
However this goes back to the limitation we talked about.
Remember we talked about the non-relational and we said that it horizontally skills perfectly.
This is a limitation of our ideas and then we start going through workarounds.
If you want higher faster and on that day there is in probably if you crossed the all the limitations
of all the limits of the US probably you may need to consider that an addition that is if possible about
cloud it trace logging or calls to the API of the order of service and of course the cloud trail will
log that for your API calls to the odiously Debby's instance.
Let's not talk about the ideal usage patterns or the patterns and type patterns for our ideas.
Are This is the idea for existing applications that rely on my sequel Oracle or sequel server a traditional
relational database engines and one good reason for that is that our ideas offers full compatibility
and direct access to native database engines.
Most code libraries and tools designed for these databases and treat work and modified with Amazon are
the best.
So basically when you bring a sequel from on premise or Oracle or sequel as long as audience doesn't
have any limitations for the features you are trying to use then you can bring on your database.
If it is my sequel sequel server or Microsoft or Oracle into our ideas and you should be fine.
Amazon audience is also optimal for new applications with structured data that requires more sophisticated
queening enjoining capability.
Anti-pattern this is very important when not to use it when to avoid Ardis if an audience does not provide
a database platform you're looking for.
So give me an example IBM D-B to Informix Sybase or any other database that are not supported by our
ideas at the moment when you want to deploy the database or religion to be in the cloud.
Then you will have to go for a self-managed database on MSNBC too.
So the alternative if it is not supported by our s or like it Oracle RAC when you have some limitations
and these are not supported by the US then you need to deploy your oracle rack or similar databases
or IBM or Informix or Sybase.
You need to deploy it on easy to instances and you manage it and control it yourself.
So how can you do that how can you implement it yourself.
You need a relational database.
A.m.-I so from IBM or Informix so I've been able to or by installing software on an Amazon easy to instance
so that is the first one.
Complete control if you would like to have complete control including level control of the database
server with full route or admin logging privileges then you need to deploy your letters on easy to what
else what other limitations do we have or type patterns of index and query forecast data.
So if it's only about indexing and query focused so complex sophisticated querying or complicated joining
of tables then many cloud based solutions will not require or may not require especially that we'd be
the ones that those features in relation database such as joint and complex transaction so if you don't
need that then definitely dynamic to me would be a better option.
In your case numerous blocks What is the blob's binary large objects.
And as you said these are like videos images audio files.
One of the engines provides an audio support binary large objects blobs.
If your application makes heavy use of them so you have a solution that is all about users uploading
images and uploading videos and all that.
So in that case don't go for ideas.
You can't have indexing or pointers in a database.
And if that was intended because then it's even preferable to be on TV than are the US and save your
images and files and all the blogs on SD.
So basically you index or you query the database for a pointer and then you fix that pointer and go
ahead and get it from S 3.
Automated scalability.
If you want automated scalability and fully automated one and then there will be a better one for you.
So that was about the US.
So let's take a break again.
Thank you.