What’s new in SQL Server 2016 Availability Groups Arthur Baan 15-10-2016 | SQL Saturday #551 – Holland 2016

Thanks to our platinum sponsors : 15-10-2016 | SQL Saturday #551 – Holland 2016

Thanks to our gold and silver sponsors : 15-10-2016 | SQL Saturday #551 – Holland 2016

Arthur Baan SQL Server Engineer @ Motiv ICT Security SQL Server Development & Administration Clustering, Mirroring, Availability Groups arthur.baan@outlook.com http://twitter.com/GuruArthur https://nl.linkedin.com/in/arthurbaan http://www.arthurbaan.com 15-10-2016 | SQL Saturday #551 – Holland 2016

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 15-10-2016 | SQL Saturday #551 – Holland 2016

“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. 15-10-2016 | SQL Saturday #551 – Holland 2016

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 https://msdn.microsoft.com/en-us/library/hh710054.aspx 15-10-2016 | SQL Saturday #551 – Holland 2016

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 15-10-2016 | SQL Saturday #551 – Holland 2016

Improved failure detection DEMO 15-10-2016 | SQL Saturday #551 – Holland 2016

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 https://msdn.microsoft.com/en-us/library/mt614935.aspx 15-10-2016 | SQL Saturday #551 – Holland 2016

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 https://blogs.msdn.microsoft.com/alwaysonpro/2016/05/02/sql-server-2016-alwayson-availability-group-enhancements-initial-data-synchronization-without-database-and-log-backup/ https://msdn.microsoft.com/en-us/library/mt735149.aspx 15-10-2016 | SQL Saturday #551 – Holland 2016

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 https://blogs.msdn.microsoft.com/sqlcat/2016/06/28/sqlsweet16-episode-2-availability-groups-automatic-seeding-2/ Source: https://blogs.msdn.microsoft.com/sqlcat/2016/06/28/sqlsweet16-episode-2-availability-groups-automatic-seeding-2/ 15-10-2016 | SQL Saturday #551 – Holland 2016

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 https://blogs.msdn.microsoft.com/sqlcat/2016/06/28/sqlsweet16-episode-2-availability-groups-automatic-seeding-2/ Source: https://blogs.msdn.microsoft.com/sqlcat/2016/06/28/sqlsweet16-episode-2-availability-groups-automatic-seeding-2/ 15-10-2016 | SQL Saturday #551 – Holland 2016

Direct seeding DEMO 15-10-2016 | SQL Saturday #551 – Holland 2016

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 15-10-2016 | SQL Saturday #551 – Holland 2016

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 KB3090973) https://support.microsoft.com/en-us/kb/3090973. 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… 15-10-2016 | SQL Saturday #551 – Holland 2016

Questions? Now Come talk to me (if you are afraid of public speaking  ) Later today in the Q&A DBA session https://msdn.microsoft.com/en-us/library/bb510411.aspx http://blog.dbi-services.com/sql-server-2016-availability-groups-and-performance-improvements/ https://msdn.microsoft.com/en-us/library/hh882461.aspx https://msdn.microsoft.com/en-us/library/hh231669.aspx 15-10-2016 | SQL Saturday #551 – Holland 2016

Please fill in the evaluation forms 15-10-2016 | SQL Saturday #551 – Holland 2016