>> [MUSIC] Hello, everyone. In this episode of [inaudible],
we will discuss the high availability options we
have with Azure database for MySQL flexible server.
I'm Sudheesh Narayanaswamy and I work as
a senior program manager with Azure Database for MySQL Server.
Let's see what all we will cover today.
We will check why we require high availability,
the high availability architectures
available with Azure database for MySQL,
our commitments on building an SLA, and also we will detail on
a few failover scenarios with demos. Why HA?
Whenever I think about high availability,
the Murphy's laws comes to my mind.
Anything which can go wrong will go wrong.
When something goes wrong,
we have to be ready to handle that situation.
That's where the high availability of
the service is very important to us.
In general, high availability office system or a component is
ability or the quality of the system
to perform over a period of time.
When we talk about the high performance
or high availability of a database,
it is to do with how much uptime
that database service can provide.
Now, usually, the architecture of the database service
is built such that it does not have
a single point of failure and it can fail
over whenever there is a problem on the node which is working.
You usually monitor a database
and then whenever a failure happens,
we feel what did the hell did it in that node.
When we talk about high availability,
few terms are very important,
like SLA, Service Level Agreement.
It's a commitment which a service provider gives,
which mentions the uptime of your service.
The second one is RPO, Recovery Point Objective,
which talks about the data laws
which is acceptable for the application.
Recovery Time Objective, which measures the down time,
which your application can incur when there is a downtime.
Now, let's take on the HA architecture.
Before we move into the details of how HA architecture is,
let's have a quick recap of how
the flexible server architecture looks
like without an HA being enabled.
As you can see in the picture,
the compute and the storage is decoupled,
the clients directly connected to the compute.
The storage maintains three copy of data and locks,
and the storage is on the actual premium storage,
so that if there is an event of a failure of the storage,
we have two more copies of the data
intact and we can recover it from here.
The data and the logs are also sent back to
the local redundant storage or
your redundant storage as you have
configured for backup purpose.
This you can use for restoration of
your database at the time of any kind of a failure,
or whenever you want to do binding time restore.
In Zone-redundant High Availability architecture,
you would have two flexible servers, one on each zone,
which would have compute and a short premium storage
with three copies of the data
as you would have on a non-active server,
and not the data which is being stored in
this actual data's storage is
same asynchronous and replicated into
the standby zone storage and then reapplied onto the standby,
keeping the standby ready at any time to take charge of.
In the event of a failure of
the primary node where the clients connect to,
the connections are dropped,
which are coming to the primary server.
At the same time, the standby server is made
primary and the old primary server becomes a standby.
As it has an exact replica about the data,
the new connections which are coming in will be directed using
that DNS changes into the new primary server,
which can now accept the read-write workloads.
Now moving on to the Same-zone architecture,
there is no difference between the architecture
other than the placement of the standby server where
in the same-zone it will be placed on
the same availability zone as compared to the zone-redundant HA,
wherein the place,
the standby in band primary on two different zones.
For the storage, we use the local-redundant storage
and the backups also used as the local-redundant storage backups.
Now let's look at a quick Demo on how we can create
an HA enable Azure Database for MySQL Flexible Server.
To create HA enable flexible server,
you navigate to the portal and click on "Create a Resource" for
Azure database for MySQL Flexible Server on the creator,
so speed you might have to give the subscription.
I name resource group,
server name which needs to be unique, or region which you
want the server to be created, and the workload type.
For HA, you should either give
production or production large-size because
we don't support burstable SKUs it
only support it for general purpose at memory optimized SKUs.
You could select one of those option.
Moving to availability zone, you can either say no preference,
which would mean it will take any of the three zones from
the available zone or you could specify one specific zone here,
which would make sure that
the primary server would be actually hosted on that.
Look at the MySQL version which you would like to have.
Then coming to the high availability option which is
the main configuration here,
is the ability to select Same-zone or Zone-redundant.
Now if you are using a Same-zone,
then you cannot later convert back to Zone-redundant.
But if you select Zone-redundant you'll
always get an option to specify a zone.
Also it gives you the capability later disable
the HA server or move it back to Same-zone or Zone-redundant HA.
This is a create time option Zone-redundant,
later you will not be able to change this option.
We have to be careful in selecting this option.
If you would like to have it in Zone-redundant,
please do select it at the time of creation.
Post that, give the username password.
Go and select the networking which you would need.
Specify the tag required and then click on "Review and Create".
Approximate estimation is 20 minutes for
the primary and standby to get created and be operational for you.
Once everything is finished, click on "Create".
Now, let's look at other commitments.
SLA, Service-level Agreement.
As you can see, if you have a Zone-redundant HA,
you will get 99.99 percent for a Same-zone HA,
which will have the standby in the same zone,
we would get 99.95 percent each as SLA.
For the Non-native Server we get 99.9 percent.
Moving on, how the server is being built.
Just to recap that, we have two servers;
one is a primary and the standby.
The billing is almost two times of what you would
have for an HA flexible server,
you would be billed two times.
We also are charged an additional 36 IOPS,
which we provisioning and block
it to make sure that whenever we have a failover,
we don't have problems when
getting the resources required for the failover to happen.
Now, let's quickly check on the post server
create experience for an HA enabled server.
Once a server is created with HA enabled options,
you would see under the "Properties" tab on all
of you being that it will tell you like,
what is the high availability where it is enabled.
You will also see whether it is a Same-zone or a Zone-redundant.
You also see what is
the availability zone of your primary server and what
is availability zone of your secondary server.
You also have a high availability B,
which also gives you these informations of
primary and standby availability zone, the status of it,
and also an option where you can
disable or enable the high availability.
If you would like to disable the high availability,
you can just go ahead and click on this and save the options.
This will make sure that the availability option is taken
out and the standby server is dropped
and it becomes a non available server.
You can later enable high availability and select
either Zone-redundant or Same-zone HA if
you have selected the Zone-redundant before.
If you have selected Same-zone or if you have not selected,
the only option available to you would be the Same-zone HA.
Coming to failover scenarios,
we have two failover supported; one is
a planned a failover or we call it as
a fool's failover or you can have unplanned failover.
In either of these cases, the RPO would be zero,
which means you will not have any kind of
a data loss in an accessible server.
Also the audio will be somewhere in between 60-120 seconds.
That is a failover time between standby to primary server.
For planned, it will be still lower.
It will be between 30-60 seconds in most cases.
When we talk about planned failover,
planned failover is somewhere you would like to do
a test of your HA solution like in case of let's say,
DRT, Disaster Recovery Tool,
you would like to do it and you wanted to failover
the application from one node to
another node and see what's available time,
what's an RPO, whether it's affected, that's
where the forced failover would help.
For unplanned ones are the one where the software crashes,
something happens to the hardware.
There's an infrastructure problem on the primary.
Any of these things,
which is usually monitored by our health monitoring system.
When it identifies that there is a failure,
it will trigger a failover automatically which will
actually make the old standby current primary and
the old primary current standby, and redirect all the traffic from
the old node to the new node to
make sure that there is continuity in the service.
Now let's check quickly on how we can do
a manual failover of an HA enabled server.
On the actual portal on the high availability pane
of Azure database for MySQL flexible server,
you would see an option to do a force failover.
You can see that currently the primary availability zone is
three and the standby availability zone is one.
Now, I want initiative force failure or clicking on this link.
Now, this will let me know that this operation of world
failover and it will take approximately 30 seconds to complete.
If I press on, "Okay", it will initiate the failover.
Now, we can see that the failover is complete.
You would see that the primary available zone has changed
to one and standby is changed to three.
For more details on
high availability of the Azure database for MySQL,
these resources would help.
It's already there in the description.
Thank you, and if you have any further questions,
feel free to write back to us on the e-mail I mentioned here.
[MUSIC]