Lecturer: Okay, so one last quick bit of information
regarding Aurora for your SysOps exam.
So you can associate a priority tier between zero and 15
on each Read Replica.
And this has helped
in case you want to control the failover priority.
So RDS will promote a Read Replica
with the highest priority,
so the lowest tier.
And if two replicas have the same priority,
then Aurora will promote the largest in size.
And if they have the same priority and the same size,
then it will promote a replica at randomly.
And when that thinks,
you can migrate an RDS MySQL snapshot
to to an Aurora MySQL Cluster,
which is a way for RDS to help you
move up to Aurora to use this new service.
The other thing is around CloudWatch metrics for Aurora.
So you have a trick called the AuroraReplicaLag,
which is the amount of lag
when replicating updates from the primary instance.
So if you ever look at this diagram,
as you write data into you Aurora cluster,
it's going to be replicated.
And so then it could be a lag associated with that.
So the AuroraReplicaLagMaximum
is the maximum amount of lag
across all database instances in the cluster.
And the Minimum is the minimum amount of lag
across all database instances in the cluster.
Now if your replica lag is high,
that means that the users will have a different experience
based on the replica from which they get the data from
because of this eventual consistency.
That means for example,
a user, if it writes data in as an item into a cart,
and then refreshes the cart,
maybe the cart will miss the item,
which is not a great experience,
but this is due to the eventual consistency.
So another type of metric to look at is DatabaseConnections,
which is the current number of connections
to database instance.
And the InsertLatency,
which is the average duration of insert operations.
So that's it for Aurora.
I hope you liked it.
And I will see you in the next lecture.