1. What’s new in SQL Server 2016 Availability Groups
Arthur Baan |
SQL Saturday #551 – Holland 2016

2. Thanks to our platinum sponsors :|
SQL Saturday #551 – Holland 2016

3. Thanks to our gold and silver sponsors :|
SQL Saturday #551 – Holland 2016

4. Arthur Baan SQL Server Engineer @ Motiv ICT Security
SQL Server Development & Administration
Clustering, Mirroring, Availability Groups |
SQL Saturday #551 – Holland 2016

5. Agenda “Minor” improvements Load balancing read only replicas
Database Level Health Detection + Demo
Basic Availability Groups
Direct seeding + Demo
Distributed Availability Groups
Windows Server 2016 |
SQL Saturday #551 – Holland 2016

6. “Minor” improvements More automatic failover replicas
Synchronization improvements
Group Managed Service Accounts
“Minor” does not mean small but in the rest of the presentation we will see the more interesting new features.
More automatic failover replicas
More synchronous replicas. With SQL 2012 the maximum numbers of secondary replicas was 4. it was doubled in SQL2014. (That means 8 secondary replicas ) with a max of 2 replicas in synchronous mode. In SQL 2016 the maximum is still 8, but instead of 2 replicas in synchronous mode you can now have 3 replicas. And they can all be a candidate for the primary role. In SQL2016 it not possible to set a preferred replica. When a failover occurs it just fails over to another replica.
Synchronization improvements
With a maximum of 8 secondary replicas including a max of 3 synchronous replicas, better hardware and in-memory technology there is a need for an improved mechanism for sending log block to the secondaries to make sure that the synchronization to the replicas is not becoming a bottleneck
Group Managed Service Accounts
Introduced in Windows Server 2012 and supported for stand alone instances of SQL Server 2012 and up. With SQL Server 2016 gMSAs are now supported when installing on a Windows cluster. Creating gMSAs is done by Windows/AD administrator. Using gMSAs improves security because the password is managed by the domain and they are configured to use on selected servers. |
SQL Saturday #551 – Holland 2016

7. Load balancing read only replicas
Done using routing list
Existed in prior version (but did not work)
List is set per replica
Be careful mixing modes
No load balancing:
PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = ('Server1','Server2', 'Server3', 'Server4‘))
Server1 and Server2 are load balanced:
PRIMARY_ROLE ( READ_ONLY_ROUTING_LIST = (('Server1','Server2'), 'Server3', 'Server4‘))
Load balancing read only replicas
With more replicas available it makes sense to create some sort of load balancing of the read only replicas. With SQL Server 2016 you can create a read-only routing list in which you specify which replica(s) you want to load balance and which replica(s) you prefer. A read only routing list is set up per replica. Meaning that you can specify which replicas are preferred to act as a read only replica when this replica is primary. This way you can set the replica(s) closest to the primary replica are the preferred candidates for read only connections.
Done using routing list
Load balancing is done using a routing list. Setting up a routing list was possible in prior versions of SQL Server, but when connecting to an AG with intent read only, only the first replica was used. In order to use the load balancing you need to specify the replicas and use parenthesises to specify which replica will be used for load balancing.
List is set per replica
The routing list can be setup individually for each replica in order to get the right replicas in the load balancing. (The read only replicas can be different when the primary replica is in another data center).
Be careful mixing modes
When you define your list of readonly replica be careful when mixing modes as the asynchronous replicas may not be completely up to date
Resources |
SQL Saturday #551 – Holland 2016

8. Database Level Health Detection
With SQL2012/SQL2014 only instance level events
Set at Availability Group level
How it works
With SQL2012/SQL2014 only instance level events
With SQL Server 2012 and SQL Server 2014 failover was initiated on instance level events. For instance a log file that is not available did not trigger a failover. With SQL2016 it is possible to set failure detection at database level. This means that when a database that is part of an AG becomes unavailable a failover is triggered. Of course when a failover occurs the entire AG is failed over not just the database causing the problem.
Set at Availability Group level
Improved failover detection is set at AG level, meaning you can have AG with improved failover detection and AGs without it and thus using the “old” way of failure detection. It can be switched on or off if desired.
How it works
Health detection is normally done by examining the results of sp_server_diagnostics. With DB Level health detection enabled an additional check is performed querying sys.databases |
SQL Saturday #551 – Holland 2016

9. Improved failure detection
DEMO |
SQL Saturday #551 – Holland 2016

10. Basic Availability Groups
Replacement for mirroring
Available in Standard Edition
Limitations
Replacement for mirroring
BAGs  are real replacements of db mirroring.
Available in Standard Edition
It is available in Standard Edition (in fact it is only available in Standard edition). It has some limitations compared to advanced AGs
, but has similar features when compared to database mirroring
Limitations
Only one DB per AG possible
Only one secondary
Secondary is not accessible (not for read only, not for backup)
Resources |
SQL Saturday #551 – Holland 2016

11. Direct seeding Favorite improvement 
Replaces the backup/restore operations (not really)
How it works
The good, the bad (but not the ugly)
Direct seeding allows the automatic initialization of databases added to an AG to the other replicas. Back in the old days this was done performing a backup on the primary replica and restoring it on all secondary replicas.
Using direct seeding makes it easier to add databases to an AG. Or even adding a replica to an AG.
Replaces the backup/restore operations
When a replica is setup to allow direct seeding and a DB is added to an AG. SQL Server performs a VDI backup of the database and restores it on the replicas. The VDI backup is not compressed. It does not look at the backup compression setting of the server. If you want to use compression you need to enable trace flag 9567 this does cost CPU power
How it works
When you define your replica in your AG you create it using SEEDING_MODE = AUTOMATIC. This needs to be done on a per replica per AG basis. But you can change this setting after adding the replica to the AG. Next you need to grant create any database permission to the AG on the replica. And you’re good to go. When you add the database to the AG it will automatically try to add the database to all replica with the setting SEEDING_MODE set to automatic.
The good, the bad (but not the ugly)
The good news is of course that when adding a database to an AG the database is automatically added to the other replicas with direct seeding set to automatic. This will only works if the directories on all replicas are equal direct seeding will fail if it cannot perform the restore.
The bad news is that you cannot set it up using the wizard. Setting a replica to allow direct seeding can only be done using T-SQL. Not even sure about PowerShell
While the secondary replicas are being initialized no log backup can be performed. Be careful when using direct seeding on an busy database with a lot of logging and monitor the free space on your log drive.
Resources |
SQL Saturday #551 – Holland 2016

12. Direct seeding performance part 1
This image from the SQLCAT blog shows the difference between adding a replica using Backup-restore and automatic seeding when adding a 115GB database
SQLSweet16!, Episode 2: Availability Groups Automatic Seeding
Source: |
SQL Saturday #551 – Holland 2016

13. Direct seeding performance part 2
This image from the SQLCAT blog shows the difference between the amount of data sent across the network when adding a 115GB database without compression and with compression enabled.
SQLSweet16!, Episode 2: Availability Groups Automatic Seeding
Source: |
SQL Saturday #551 – Holland 2016

14. Direct seeding
DEMO |
SQL Saturday #551 – Holland 2016

15. Distributed Availability Groups
Group of Availability Groups
Ideal for multiple data center locations
Not dependent on availability of other side/site
Distributed Availability Groups can be seen as a group of Availability Groups. DAG are a solution if you have multiple datacenters and you don’t want to depend on the availability of the data connection between DCs. You can create two three-node clusters meaning you can have 6 copies of your data.
Advantage is that the log blocks are sent only once to the other AG instead of to every replica in the second AG.
Adds complexity for administration |
SQL Saturday #551 – Holland 2016

16. SQL Server 2016 combined with Windows Server 2016
Distributed transactions (MSDTC)
Cluster improvements
“ideal” for replacing mirroring
Distributed transactions (MSDTC)
SQL Server 2016 Availability Groups (finally) supports MSDTC when installed on Windows Server 2016 (it has been backported to Windows Server 2012 R2 with KB ) It does not work with DBs in the same AG. So only cross server transactions are allowed. MSDTC must be switched on when creating the AG an this setting cannot be altered.
Cluster improvements
Windows Server 2016 has many improvements in the area of clustering. Cross domain clusters, nodes not in any domain… |
SQL Saturday #551 – Holland 2016

17. Questions?
Now
Come talk to me (if you are afraid of public speaking  )
Later today in the Q&A DBA session |
SQL Saturday #551 – Holland 2016

18. Please fill in the evaluation forms|
SQL Saturday #551 – Holland 2016