Here and welcome back now into this, we will be discussing about a very interesting offering under
the relational database service called the Aurora Australis.
So let's go ahead and discuss more about it.
Now, before we go ahead and discuss about Aurora Sartorialist, let's look into a typical set up that
is followed across a lot of organizations.
So in a typical setup, one of the primary consideration during a database set up is the DB instances.
So you're an example is too small.
So, for example, let's say a developer needs a database instance for the development environment or
maybe for the staging environment.
So what is the DV instances that you will give?
Will you be giving it to small or medium for large?
Center is a very important consideration, yet specifically when it comes to the cost factor.
Now, if your workload changes, then you can modify the DB instance class size.
So let's say that initially you have given to the small, but as the workload changes, then maybe you
can increase the GBE instance class to an awful lot so it can support more amount of workload.
Now, when you discuss about a typical approach, there are certain challenges which almost all of the
organization face first challenges that workloads can be unpredictable.
So there can be a period of heavy workload that may last only for a few minutes or hours and also long
periods of light activity or even no activity.
Now, this specifically applies for me.
We are demonstrating in Wyoming so many times we have seen that there develop as well as you in the
request for a very big instance in this building in Wyoming and during weekends and during the time
when there are not testing, that huge instance is doing nothing but increasing the overall cost for
the organization.
And a similar thing applies for the production environment as well, because in a lot of organizations,
the overall workload in a production environment remains unpredictable.
So in these cases, it can be difficult to configure a correct capacity for the right time.
It can also result in higher cost when you pay for the capacity that is not being used.
So if we look into the choice of customers, there are three primary choices that are available for
us.
One is either new provision for the peak.
So although this is good, but that will lead to increased cost.
Second is, you can provision for less than week that will directly impact the business as well as the
end user.
The third one is you continue to monitor and adjust the capacity manually for the database.
However, this is not the best choice because it requires experts as well as the risk of outages in
that third point.
So now comes Aurora Australis.
So the Aurora Australis automatically scales up and down based on the capacity your workload consumes.
So Ventor databases, either it will automatically be shut down and then the workload assumes it will
automatically speed it back up.
And this is very interesting here.
So this is very similar to auto scaling if you have where you set the minimum and maximum capacity for
your database instance.
So let's say that from Monday to Friday, the developers that you would be more actively using the DBE
instance.
However, from Friday evening, there are no connections and there are no activity.
So if you're using Aurora, Serverless, Aurora, Cervalis will automatically shut down during the weekend
and from the Monday morning, there are no other connections.
STUTZER Then the Aurora Cervalis database will be back online.
So this can be better explained that I remember when the law is not present, it can either be shut
down or it can run with the minimal instances.
And when the workload is very high, then it can even scale to a very large instant's class.
So let's go ahead and understand the architecture of Aurora sartorialist so that it becomes better understood
on how exactly it works.
So unadopt you have the application, then you have a fleet of proxy servers so these can be lower balances.
Then you have an active Aurora instance that is running, you have a monitoring service and you have
a warm pool of Aurora Instant's.
So the application, whenever it wants to connect to the database, what it will happen is it will first
connect to the proxy feed.
And from this proxy fluid, that connection will be sent to the active Aurora instance that is running
OIR now, as we were seeing that Aurora instance can.
Up as well, down depending upon the amount of loan, so the monitoring service is actively monitoring
this or other incidents to decide whether the scale up, scale down or even shut down operation needs
to be initiated or not.
On the right hand side, you have a vault full of other instances.
So these instances are based on different size and depending upon the Lord, one of these instances
will replace the active Aurora instance.
So let's say that the amount of connection and the amount of load in Aurora is very, very.
So what will happen is this specific instance size will be replaced by a much smaller, smaller one.
So this Aurora serverless will scale down and this will in turn save you a cost.
Now, let's assume that the amount of traffic to our website is increasing.
So it is back to Monday and the connections, the order workload is increasing.
So what will happen is monitoring service will monitor that and automatically what will happen, the
smaller instance would be replaced by the bigger instance.
So that is what it does at a high level overview.
So if the architectural diagram, the one instance is something that is important for us to understand.
So the one instance, the presence of conflict, of instances that can be easily swept in to add capacity
to the environment.
So these instances are located in a range of sites providing orderer surveillance with more granular
approach to how it responds to variation in workload.
So currently within the vomitus pool, you see there are multiple sizes of instances that are available.
So depending upon the load, one of these instances will that with your current running Aurora instance
and that in turn will be able to serve the existing traffic.
So that's the high level overview about the Aurora Sartorialist and its architecture.
Now, before we conclude, let's do some interesting things.
So we'll have a quick demo related to address overlays and see on how exactly these things work.
So currently, I'm in the Ideas Council.
Let's go to their databases and I already have Aurora sidewalls instance that is running.
Now if you look into the size or the size is zero capacity unit.
So capacity unit is basically the combination of memory plus processing.
So currently it is zero capacity unit.
Now the question that comes is why now?
The reason why it is zero capacity unit is because the aurora is within riposted, because there was
no connection and there was no load.
So let's look into that.
So if we go to the logs and eventually you will see that at a certain time the capacity units were killed.
So if you see scaling delete cluster from two capacity units to one capacity unit for this reason,
and the reason is auto scaling.
Now, again, after some amount of time, it is again scaling the cluster from one capacity unit to
two capacity unit.
Again, the reason is auto scaling.
So not only it is scaling down, but it is also scaling up.
So currently we were playing between one and two capacity units.
Now, if you look into the last lock order here, it states that the debate last year was down from
two to one.
And then the big cluster has been paused and the debate cluster is paused.
So now the DB cluster is primarily because there are no connections.
So since it is past the order costing that might apply will be much more reduced.
Now, if I have to also show you this within the monitoring Aurier, let's do it from Twila's.
So currently you see that whenever the Aurora Cervalis instead started, so they created the Aurora
Cervalis, it started with a certain value or, you know, in time the amount of value decreased.
So if you see where it went to four, then it went to two, then it went to one and now it is zero.
So after some amount of time, it is zero and it continues to be zero.
All right.
So that means that it was associated with the SERVERLESS database capacity.
So I hope at a high level overview, you understood the concept of Aurora Serverless.
Now, let me quickly show you one thing.
So currently, since the database is within the post-paid, what will happen if a new connection comes?
So let's try it.
So I go to the query data and let's initiate a new connection to our Aurora server, less instance and
see if it succeeds or not.
So I have the database grading test that I had used and let's connect to the database.
So we're integrated.
And so if you quickly do a show database this.
And then you run it.
In the output, you get the database related output.
So, again, let's try it out.
So let's create a database, I'll call it escaped that DB and let's do it on.
And the query has been successfully executed, so let's again do a short database's.
And now, as expected, you have the capability that is available.
So going back to our Cervalis AutoTrader, let's go to the monitoring.
And now you would see that from zero, the overall database capacity unit changed to one, primarily
because we execute for the database query.
So even though the aurora is within the past, as soon as you run the query, you will see that it automatically
starts up.
And even from the console, the current capacity, it shows that it is one capacity unit and the same
would be applicable when you go to the main console where within the case you have one capacity unit
that is available.
Great.
So I hope at a high level where you you understood the basic concept of Aurora Cervalis that this will
conclude this video.
And I look forward to see you in the next video.