Microsoft Confidential

HADR with SQL Server 2016 AlwaysON

Session- 2 AlwaysON Architecture and internals 

1

Uday Bhanu PathaniyaPFE-SQL Serverudpathan@Microsoft.com

Microsoft Confidential

1. How AlwaysON works2. What's AlwaysON Availability Groups /Replicas/ Listener3. AlwaysON supportability and pre-requisites4. Demo of AlwaysON HA Configuration5. Backups on AlwaysON secondary replica

3

Legacy Architecture: Database Mirroring for local HA, Log Shipping for DR

Pre-SQL Server 2012

Challenges

Possible data loss in Log shipping.

Human intervention require in case of failover.

Unavailability of user databases during log restoration.

Can’t easily glue together databases that need to run on the same node

Data Warehouse load restrictions due to limitations in Log Shipping

Maintaining database mirroring connection strings (failover_partner) in all applications is painful, and in some cases (some 3rd party applications) not even supported

Not easy to access data on mirrored server.

No. of nodes limitations in mirroring.

Interdependency of databases are not address in mirroring as well as in log shipping.

What is AlwaysOn ?

Is a combination of database mirroring and

windows clustering.

Multiple mirrors with multiple databases that can failover together.

Single gateway(Listener) can

be configure for automatic failover

Nodes can be used to offload the select query workload and database

backup workload.

Single solution which can address HA & DR

needs.

How Always on work ?

Primary Data Center Disaster Recovery Data Center

SQL ServerPrimary

SQL ServerSecondary

Windows Server Failover Cluster (single WSFC crossing two data centers)

Availability Group

Synchronous

Asynchronous

SQL Server

Secondary

Based on windows failover cluster(WFC) & SQL Server database mirroring.

Read T-logs and transfer active portion of logs to all secondary replicas.

No Shared volume require for WFC.

Interdependent databases can be grouped into logical groups and can failover together.

Data transfer between replica nodes is compressed and encrypted.

listener support automatic client redirection to the primary replica or redirection to available readable secondaries.

Availability group listeners remove the need to designate a failover partner in the client connection string.

Grammar of AlwaysOn… • Read-write , Online user database from primary Instance of database server. • Databases added in availability in Availability groups are called availability databases & each Availability Database is a part of only single Availability Group.• Backup of the primary database has to restore on secondary replica in norecovery state and new secondary database will remain in restoring state until it is

not joined to Availability groupAvailability Database

• Logical container which logically binds the user databases which needs to be failover together. • All the availability databases will failover together on same secondary replica.• Single Availability Group can hosts multiple Availability Databases.Availability Groups

• All the possible failover partners(must be a separate instance of SQL Server on other node) are known as Availability Replica. • Each Availability replica is a copy of Availability database in a Availability Group. • Each Availability replica is assigned an initial role- Primary or secondary. Primary replica hosts read-write user database & at least one secondary replica

hosts read-only user database.Availability Replica

• There are two Modes- 1.) Synchronous-Commit mode & 2.) Asynchronous-Commit mode.• In 1. Synchronous-commit primary replica wait for acknowledgement from synchronous-commit secondary replica that it has commit the transaction

in t-log of secondary database then after primary replica commit transaction.• In 2. asynchronous-commit primary replica commit the transaction without waiting for acknowledgement from asynchronous-commit secondary

replica that it has commit the transaction.• Asynchronous-commit mode minimizes transaction latency on the secondary databases but allows them to lag behind the primary databases, making

some data loss possible.

Availability mode

• With SQL Server AlwaysOn no need to have shared storage, but can use SAN, DAS, NAS or Local Disk depending on your budget and requirements.

AlwaysOn Storage

• Active secondary replica supports backup offloading on secondary replica and readable secondary replica.• In backup offloading we can log backups , full backup of database , file or filegroup. Backup presences can be set on secondary replicas. • An availability replica can be allow read-only access to its local databases when performing the secondary role. • If an availability group currently possesses an availability group listener and one or more readable secondary replicas, SQL Server can route read-intent

connection requests to one of them (read-only routingActive Secondary Replica

•Availability replica property:- How long the connection with another availability replica can remain inactive before the connection is close

Session-timeout period

Grammar of AlwaysOn.

• Availability group listener is a Virtual network name(VNN) to which clients can connect in order to access a database in primary or secondary replica.

• The physical instance name of SQL Server is hidden to clients while accessing availability databases through listener.

• The client connection string does not to modify in order to access either of Availability database base.

• We need DNS name for listener , a listener port designation one or more IP address.

• Client use DNS to resolve VNN into multiple IP addresses and then tries to connect with each IP address until the connection request successes or timed out.

• If we configure read only routing then all read-intent connections are redirected to readable secondary replica.

Availability Group listener

Connectivity with Availability Group Listener

Connect to the Primary Replica

Server=tcp: AGListener,1433;Database=MyDB;IntegratedSecurity=SSPI

Connect to Read-Only Secondary Replica

Server=tcp:AGListener,1433;Database=AdventureWorks;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly

Connect to Multisubnet failover

Server=tcp:AGListener,1433;Database=AdventureWorks;IntegratedSecurity=SSPI; MultiSubnetFailover=True

AlwaysON pre-requisites

KB 2654347:Hotfix for .Net 3.5 SP1

Other Hotfix KB 2494036 for

optimal WSFC quorum , KB

2687741 for faster failover to local

relica etc.

Each node must be configure under WSFC(preferably node-fileshare).

A separate SQL Server Instance on each WSFC node

and enable AlwaysOn feature

for each SQL Server service.

Enterprise edition of SQL Server 2016

All the server instances that host availability replicas for an availability

group must use the same SQL Server

collation.

No. of available worker threads are

very important.

Create endpoints or member of

sysadmin privileges require

DHCP IP can be used but it is

recommended to use static IPs.

AlwaysON Restrictions

• Restrictions for SQL Server failover cluster instance(FCI) • The cluster nodes of an FCI can host only one replica for a given availability group• FCIs do not support automatic failover by availability groups• Changing FCI network name

• Restriction for SQL Server Availability Group • Availability replicas must be hosted by different nodes of one WSFC cluster• Unique availability group name• Only 8 secondary replicas are supported. Either all can be configured as async • commit mode or up to 3 can be configure as sync-commit mode• Maximum number of availability groups and availability databases per computer depends on Hw

configuration. MS has tested 10AGs with 100 DBs per AG. • Restriction for SQL Server Availability Databases

• If file path is different then • New Availability Group Wizard/Add Database to Availability Group Wizard• the database files must be RESTORED WITH MOVE on each instance of SQL Server that hosts a secondary

replica.• A later add-file operation on the primary replica might fail on the secondary databases.

Demo-AlwaysON HA Configuration

Backups on AlwaysON secondary replica

• Copy-Only full backup of databases , files & filegroup is supported on secondary replica. • Differentail backup is not supported on secondary replica.• Backup log supports only regular backup & log chain remain consistent irrespective of backup log location or

availability mode( Synchronous-commit or Asynchronous-commit)• Secondary replica must be in SYNCHRONIZED or SYNCHRONIZING state.• In case of more than two nodes backup preferences(AG property) can be set to ‘Prefer Secondary’ , ‘Secondary

Only’ , ‘Primary’ ,’Any Replica’. • Additionally Replica backup priorities can be set to ‘Server Instance’, ‘Backup Priory(Lowest=1, Highest=100)’ ,

Exclude Replica. • It is recommended to configure script based backup jobs on each replica. • Use the sys.fn_hadr_backup_is_preferred_replica function to determine whether the current replica is the

preferred backup replica or not. • This function return 1 in case if the current replica is a preferred replica else 0.