>> We've talked about the high availability architecture of
the various service tiers and how you can go
further with zone-redundant configurations.
Now, there are two different ways to
go even further on a global scale.
Now, the two options that you have available for you are
geo-replication and auto-failover groups,
and they're very similar,
but they're also different,
so we laid out this table to highlight some of
the benefits or reasons you might choose one over another.
Now, with both geo-replication and auto-failover groups
you able to get read-scale across the globe in theory.
Now, some of the things to consider are
that with geo-replication you
can deploy a replica in the same region that you're in today.
Whereas with auto fail-over groups,
it cannot be in the same region and you can only
choose one other region for your auto-failover group to be.
For example, I could have
my server in East US or databases in East US,
and I can have an auto-failover group in West US,
but that would be it.
Now, for geo-replication, I can have
multiple replicas in multiple regions,
including my own, and I can use those replicas for read-scale.
In auto-failover.
I can also use this for read-scale.
The other call out I wanted to mention is that
managed instance today is only available in auto-failover group.
So if you're using managed instance,
auto-failover groups is going to be the way to go.
Now, one of the other benefits with
auto-failover groups is that you can get an automatic failover,
which means you can failover in the case of an emergency,
and you also do not have to update
your connection strings after that failover,
and we actually have a demo and a lab exercise for you
to try in a separate video.
>> Anna, great comparison. I think
it's important when you think about
these technologies to think in terms of a visual representation,
architecturally, what this looks like.
You see here for geo-replication,
you have your primary logical database server and your database,
and you're going to establish
a new secondary logical server to host
the geo-replication of data to a second database.
You're going to use things like
load balancers and traffic manager to make connections,
but remember, this is a manual change of
your connection strings to get access to this data.
Now, as Anna pointed out,
you're going to have read replica availability,
so your apps are going to have the ability to connect
from a read-write perspective to your primary
or also a read-only intent to
a database residing on
a given region or even in the secondary region,
which could be actual globally.
That's how geo-replication works for
Azure database perspective and you have
that capabilities with Azure database today.
Now, an auto-failover group is going
to look a lot similar to a geo-replication.
Remember, this is your only option for
a managed instance scenario.
You still have a logical secondary server here and you
still have the concept of data being
geo-replicated to this other secondary serve.
Remember, this only works across different regions,
not within the same region.
You still have the ability to read-write
capabilities with your app or read-only traffic,
and you're going to use load balancers and Azure Traffic Manager.
But if you look at these two in comparison,
what really stands out is the failover concept.
Remember, an auto-failover group is,
think of it just like a distributed availability group,
so we have auto-failover capabilities to
this secondary region and
you don't have to change the application connection strings.
You're going to use the abstraction of a listener concept,
just like you use today for availability groups,
for both your read-write scenarios and you read-only scenarios.
So you think about going further with
geo-replication for Azure database, or auto-failover groups,
or with managed instance auto-failover group,
this is just another piece of the puzzle that
give you better availability and
a lot of built-in capabilities with
Azure SQL. We'll see you in the next video.