AlwaysOn Availability Groups - Getting Started with SQL Server 2014 Administration - page 60

Using Microsoft Azure Virtual Machines
as replicas
One of the new features of 2014 is the ability to combine your on-premise AlwaysOn
Availability Group instances and also maintain a replica on Microsoft Azure Virtual
Machine. This feature allows you to combine the flexibility and control of managing
your own infrastructure along with maintaining a secondary stored site in the
Microsoft Azure data centers.
The commit mode
Earlier in this chapter, we described AlwaysOn Availability Groups as database
mirroring on steroids. Like database mirroring, AlwaysOn Availability Groups
have two modes that you can choose from when configuring each replica:
The asynchronous commit mode : We can choose this commit mode when
performance is more important than protecting against data loss. If every replica is
running in the asynchronous commit mode, then the primary replica will not wait
for any acknowledgement from the secondary replica that implies the transaction has
been written to the log of secondary. This allows the database to run with minimum
transaction latency, but it does run the risk of potential data loss. For example, if
a transaction commits to the primary and there is a failover before the transaction
writes to the log of the secondary, the data changes made as part of the transaction
could be lost.
The synchronous commit mode : We can chose this commit mode if protecting
the data is more important. With the synchronous commit mode, the primary
replica will wait for all secondary replicas to acknowledge that the transaction has
been written to their logs before completing the transaction. This ensures that all
transactions and data are available on all the secondary replicas. This mode will
have the highest transaction latency; therefore, it can have the biggest impact on
database performance.
Reporting and administrating on secondary
replicas
One of the big advantages that AlwaysOn Availability Groups have over database
mirroring is that the secondary replica copies of the database are more useful to you.
With database mirroring, the mirror copy of the database just sits there synchronizing.
You cannot perform admin tasks such as backups on the mirrored copy. You can only
run queries against the mirror if you make use of the database snapshot.