Okay.
Hello bloggers and welcome to this lecture and this lecture we're going to look at backups multi easy
and read replicas with ideas.
So this is gonna be a theoretical lecture.
And the next lecture we're gonna go into a lab and we're going to look at how we can set up multi easy
read replicas and backups.
So let's start with backups and there's two different types of backups for ideas.
We have our automated backups and then we have our database snapshots and our automated backups allow
you to recover your database to any point in time within a retention period and the retention period
can be between one and 35 days.
Now automated backups will take a full daily snapshot and will also store transaction logs throughout
the day.
And when you do a recovery AWB will first choose the most recent Daily backup and then apply the transaction
logs relevant to that day.
And so what this allows you to do is a point in time recovery down to a second within the retention
period.
So automated backups are enabled by default and the backup data is stored in S3 and you get free storage
space equal to the size of your database.
So if you have an idea for instance of 10 gigs you're going to get 10 gigs worth of storage and backups
are taken within a defined window set during the backup window storage Io may be suspended while your
data is being backed up and you may experience a little bit of elevated latency.
Database snapshots are done manually.
So think of someone taking a photo on a beach using a Polaroid camera for example so their user initiated
and they are stored even after you delete the original RDX instance.
Unlike automated backups and when you go in to delete your RDX instance often it will ask you if you
want to take a final snapshot of that instance before you delete it.
In terms of restoring your backups whenever you restore either an automatic backup or a manual snapshot
the restored version of the database is going to be a new RDX instance with a new DNS end point so bear
that in mind as well as soon as you do a restore.
It's not going to restore to the same for instance it's going to actually restore to a brand new RDX
instance and that's going to have a different endpoint.
Moving on to encryption so encryption at rest is supported for my sequel Oracle SQL Server Post rescue
El Maria D.B. and Aurora and encryption has done using the AWB as a mass service and once your ideas
instance is encrypted the data stored at rest in the underlying storage is encrypted as automated backups
read replicas and snapshots.
So as soon as you turn encryption on basically anything that you're doing such as backups read replicas
and snapshots are also going to be encrypted as well.
So moving on to multi easy and we cover this in databases one to one but just in case you forgot.
Let's say we've got an elastic load balance so we've got our easy two instances behind it.
They then connect in to our RDF database and this is in us e one A.
It then synchronicity replicates all changes or updates to that database to us e one base you've got
two copies of your database.
Now if you were to lose us is one a as an availability zone.
What's going to happen is Amazon are going to update the DNS settings and the RDX endpoint is automatically
going to fail over to the RDX instance in UST e one B to multi AC allows you to have an exact copy of
your production database in another availability zone and it's done synchronicity through synchronous
replication and as handles the replication for you.
So when your production database is written to this right will automatically be synchronized to the
standby database and see in the event of a planned database maintenance or DB instance failure or an
availability zone failure Amazon ideas will automatically fail over to the standby so that the database
operations can resume quickly without any administrated intervention so you don't need to go in and
change your connection strings or anything like that you're still using the same DNS endpoint Amazon's
basically just updating the IP address to point from one RDX instance to another they do all that you
don't have to worry about it and it will fail over automatically to another availability zone.
So just remember that multi easy is for disaster recovery only it's not primarily used for providing
or improving performance for performance improvements you're going to need read replicas now multi AC
is available for the following databases it's available for SQL Server Oracle my SQL Server Post rescue
L and Maria D.B. Aurora by its own architecture is completely fault tolerant we're gonna have a whole
dedicated lecture tour Aurora and how that works coming up.
So what's a read replica.
Here we have our easy two instances behind elastic load balancer they are then connecting in to our
production database our production database is then asynchronously replicating out to multiple copies
in this example.
Now this can really improve performance is in this current example.
Basically all our easy two instances are reading from the primary data base as well as doing rights.
But you can actually architect it so that you're easy to instances read from different read replicas.
And then they only write to a single database and of course those rights would then be replicated out
and you can even have read replicas of read replicas so you can have multiple copies of your production
database as read replicas and you can have read replicas as read replicas.
The cool thing about it as well is you can promote read replicas to be their own standalone database.
You can also do that as well so read replica allows you to have a read only copy of your production
database.
And this is achieved using asynchronous replication from the primary RDX instance to the read replica
and you can use read replicas primarily for very read heavy database workloads and where you're going
to see this come up in the exam is it will talk about how you can improve performance for a database
and there's two ways really you can do that is you can go in an Adelaide replicas and you can also go
in and start using elastic cache and we're going to have an elastic cache lecture coming up as well
but that's where you're going to see read replicas come up in your exams and read replicas are available
for the following databases.
So we have my sequel we have post rescue oh we have Maria DP Oracle and Aurora and the things to know
about read replicas is they use for scaling they're not used for D.R. and they must have automatic backups
turned on in order to deploy a reed replica.
We'll see that in the lab coming up and you can have five copies or fight three and you can have up
to five read replica copies of any database and you can have read replicas of read replicas.
But when you do that you do have to start watching out for replication latency and other things to know
about read replicas as each read replica will have its own DNS endpoint and you can now have read replicas
that also have multi A-Z turned on and you can create read replicas of multi easy source databases as
well and read replicas can be promoted to their own databases.
And this breaks the replication.
So if you do promote a read replica to be its own independent database the replication will no longer
work and you can also have a read replicate in a separate second region so you can have a read replicate
in a completely separate region to where your primary database is so bear that in mind as well.
So as always the best way to learn about ideas is to go ahead and get our hands dirty so if you've got
the time please join me in the next lecture.
Thank you.