HADR AlwaysONAvailabilityGroupHADR Offered by SQL * Backup Restore * * Mirroring * * LogShipping * *Cluster* *Replication* * AlwaysOn - The best HADR solutionWhat is Alwayson? * AlwaysOn Availability Groups is a high-availability and disaster-recovery solution that was new with SQL Server 2012. * It enables you to maximize availability for one to many user databases as a group. * Deploying this technology involves configuring one or more Availability Groups. * Each Availability Group defines a set of user databases that can fail over as a single unit by reveraging a Windows Failover Cluster and the clustered SQL Server name and IP address. * Provides an enterprise-level alternative to database mirroring. + Always On availability groups maximizes the availability of a set of user databases for an enterpriseWhat is availability group (AOAG) *An availability group supports a replicated environment for a discrete set of user databases, known as availability databases. *You can create an availability group for high availability (HA) or for read-scale. * Availability group supports one set of primary databases and one to eight sets of corresponding secondary databases. * UP TO 10 AG RECOMMENDED, NOT ENFORCEDWindows Failover Cluster Database Log SynchronizationWhat are availability Databases *It’s a database that belongs to an availability group * For each availability database, the availability group maintains a single read-write copy (the primary database) and one to eight read only copies (secondary databases). *UP TO 100 DB PER AG RECOMMENDED NOT ENFORCEDWhat is Availability replicas * Each availability group defines a set of two or more failover partners known as availability replicas. * Availability replicas are components of the availability group. * Each availability replica hosts a copy of the availability databases in the availability group. + the availability replicas must be hosted by separate instances of SQL Server residing on different nodes of a WSFC cluster. + Each of these server instances must be enabled for Always On. *An availability replica provides redundancy only at the database level-for the set of databases in one availability group* Every availability replica is assigned an initial role-either the primary role or the secondary role, which is inherited by the availability databases of that replica. 1. Primary replica (single): + makes the primary databases available for read-write connections from clients 2. SECONDARY REPLICAS (MULTIPLE): * support read-only access to secondary databases, to permit backups on secondary databases. + 2012: 1 PRIMARY AND 4 SECONDARY REPLICA, + 2012 : ONLY 2 SYNCHRONOUS COMMIT + 2014\16\17\; 1 AND 8 SECONDARY REPLICA + 2014: 3 SYNCHRONOUS COMMITAvailability modes *The availability mode determines whether the primary replica waits to commit transactions on a database until a given secondary replica has written the transaction log records to disk (hardened the log). + Always On availability groups supports two availability modes- 1. asynchronous-commit mode and 2. synchronous-commit mode.Types of failover *Within the context of a session between the primary replica and a secondary replica, the primary and secondary roles are potentially interchangeable in a process known as failover. + Three forms of failover exist-automatic, manual, and forced (with possible data loss). *The form or forms of failover supported by a given secondary replica depends on its availability mode Availability Mode Failover Mode Setting Secondary Replica Failover Supported Synchronous Manual Manual (without data loss) Synchronous Automatic ‘Automatic/Manual (without data loss) Asynchronous Manual Manual (possible data loss)What is Availability Group listener *An availability group listener provides a set of resources that is attached to a given availability group to direct client connections to the appropriate availability replica. *An availability group listener is associated with a unique DNS name that serves as a virtual network name (VNN), one or more virtual IP addresses (VIPs), and a TCP port number. Availability group listeners direct incoming connections to the primary replica or to a read-only secondary replica.Active secondary replicas Active secondary capabilities include support for: + Performing backup operations on secondary replicas * The secondary replicas support performing log backups and cooy-only backups ofa full database. file, or hlegrodp, You can coniigure the avaiabllty group to spechy 9 preference for where backups should be performed + Read-only access to one or more secondary replicas (readable secondary replicas) * Any secondary availability replica can be configured to allow only read-only access to its local databases * Itis also possible to prevent read-only workloads on the primary replica by only allowingSetting for the Secondary Replicas to Support Read Operations Readable |Description Secondary No ‘The secondary replica does not allow read operations. Any connections to the secondary replica will be denied. Read- The secondary replica allows read operations, but it accepts only intent connections with the application intent xeanowz, This ReaDowtY intent is only anew connection property available as part of new Tabular Data Stream (TDS) protocol. Older client applications or client applications that do READONLY property for application intent cannot connect to the read-only secondary replica. To connect to the secondary replica, you must provide the following in the connection string: Appiicationzatent. = Readonly. Yes ‘The secondary replica enables read operations. It accepts all connections, including the ones that don’t specify the xeaoon: application intent property in the connection string. This option enables legacy client applications to connect to the secondary replica for read workload ‘because only read-only commands succeed. Commands that try to create ‘or modify data will fail with this error message: Msg 3906, Level 16, state 1, Server SQLHA2, Line 1 Failed to update database TAdventureWorks” because the database is read-only.Benefits * Supports a flexible failover policy for greater control over availability-group failover. * Supports automatic page repair for protection against page corruption. * Supports encryption and compression, which provide a secure, high performing transport. * Provides an integrated set of tools to simplify deployment and management of availability groups + Transact-SQL DDL statements for creating and managing availability groups * SQL Server Management Studio + The Always On Dashboard monitors + The Object Explorer Details * PowerShell cmdlets.Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups * SQL Server Instance Prerequisites and Restrictions * Network Connectivity Recommendations * Client Connectivity Support * Prerequisites and Restrictions for Using a SQL Server Failover Cluster Instance (FCI) to Host an Availability Replica + Availability Group Prerequisites and Restrictions * Availability Database Prerequisites and RestrictionsPrerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups + .Net Hotfixes that Support AlwaysOn Availability Groups * Windows System Requirements and Recommendations * Ensure that the system is not a domain controller. * Ensure that each computer is running either x86 (non-WOW64) or x64 Windows Server 2008 or later versions. * Ensure that each computer is a node in a Windows Server Failover Clustering (WSFC) cluster. * Ensure that the WSFC cluster contains sufficient nodes to support your availability group configurations. + Ensure that all applicable Window hotfixes have been installed on every node in the WSFC cluster.Configuring SQL Server Always On Availability Groups + Assuming we are running mission critical business - We need to be able to tolerate the following problems: a. If the production server dies, | need to fail over automatically b. If the datacenter goes down, I need to fail over to a DR datacenter c. The BI team wants to run reports on the live database d. Backups need to run fasterConfigure a New Availability Group * Start with installing a Windows Failover Cluster on each server that will participate in the Availability Group. * Install SQL Server 2014 as a standalone instance on each server that will participate in the Availability Group. + On each SQL Server that will be participating in the Availability Group, open SQL Server Configuration Manager, choose SQL Server Services, and then select the SQL Server properties. Under AlwaysOn High Availability, check the Enable AlwaysOn Availability Groups check box. Then you must restart the SQL Server for the setting to take effect. ‘eye aay [cine Ao ret eves nay ge fhFi 56 Vw Dt Too Wino. rf create the Seas Availability Group + Choose one of the SQL Servers as the primary replica. This SQL Server must have the database(s) that will be included in the Availability Group. + In the Microsoft SQL Server Management Studio, click the SQL Server (in this example, SQLHA1), then right-click and choose New Availability Group Wizarda + In the Introduction, click Next. On the ensuing Specify Availability Group Name page, choose 2 name* Click Next. On the next Select Databases page shown in Figure 25.5, click the check box for the databases (for example, AdventureWorks). If more than one database meets prerequisites, it will appear in the list for you to choose. For a database to be eligible, it must meet the following prerequisites:+ Under the Replicas tab on the Specify Replicas page, choose any secondary replica that you want to participate in the Availability Group. Click Next again+ Under the Backup Preferences tab on the Specify Replicas page, specify where backups should occur from the following options:+ Under the Listener tab on the Specify Replicas page, choose “Create an availability group listener.” Provide a Listener DNS name, which is the network name that client applications use to connect to this Availability Group. rc | npr tiem Seo re te lore eABi meetin tint eer ‘team ancmame tpt tannn aeeesns — Spay tana ety pe Sate = + Onthe Select Initial Data = ‘Synchronization page shown, a pee ey ees choose Full. For “Specify a shared Seema accir cea aa network location accessible by all ae replicas,” choose a shared folder Geer arents ete remem te hey ee accessible by all participating replicas—for this example, \\SQLHAI\DBBackups. Also, you can choose “Skip intial data synchronization” and manually restore to each secondary replica* Click Next to run the validation. Then click Next. On the next Summary page, click Finish to create the AG1 Availability Group. i+ When you finish, you should be able to go to the Windows Failover Cluster Manager to see that the Availability Group has been createdConfigure an Existing Availability Group * At some point, a new requirement may arise if one of the following situations occurs: * The application is upgraded and an additional, new database is created that has dependencies to the other availability databases inside the Availability Group. * The company has increased reporting requirements and needs to deploy another readonly database to offload the work on the primary replica. * A disaster-recovery site is identified and you are asked to deploy a replica there. * Backups are running on the primary replica and are impacting its performance. You have been asked to deploy a replica to perform backups. * You have consolidated several databases from the Availability Group and must remove one of them * You want to remove a replica because it is no longer needed, or it has been replaced with another replica running on faster hardware.«Cay AlwaysOn High Availabilty 3 Gi Availabilty Groupe | Add/Remove Replica © ET oan # Gi Availa| Add Replica. © Ca Management — + Any time you want to add a replica, follow these steps: a: fin itograion Send reberar 1. Join the new replica to the Windows Cluster group & (B SCL Server Agents powell from Windows Failover Cluster Manager. = (B SCUHA2 5A Server (Bl Databases Repos 2. Enable AlwaysOn Availability Group for that SQL @ Ga System Datat Server instance ms Gi Database Sna 3. Choose Add Replica, as shown td AdventureWe Refresh w Ga Securty GB Sever Objects + To remove a replica, simply choose the replica, Ga Replication right-click, and select Delete. @ Gd Alwayz0n High Availability Delete. Properties Ga Management i Integration Services Catalogs Li SOL Server Agent + To remove an Availability Group, choose the Availability Group, right-click, and select Delete.© Gy AlwaysOn High Availability = Gi Availebilty Groups Add/Remove a Database ‘Add Database... ee Ga Aveilat Ga Availat Add Listener AG. + select the Availability Groups folder, right-click atthe 4 Show Dashboare the Availability Group (for example AG1), and choose Add Database, wie bingrion Savi ae # er Agent + To remove a database from the Availability B ss GOL ‘gent || Start PowerShell Group, simply choose the database, right-click, = a and select Delete. Databases Reports © (Ba System Databs & Gad Database Srap) Delete & ty AdventureWol Refresh Ge Security Propo a (a Server Objects & Gi Replication # (a) AlwaysOn High AvailabilityAvailability Group Failover Operation * Two failover modes are available: automatic and manual. * Failover of the Availability Group depends on which of these two modes the replica is configured with. * Availability Group to fail over to the local secondary replica: ALTER AVAILABILITY GROUP AG1 FAILOVER; *To force a failover with data loss, use this T-SQL command: ALTER AVAILABILITY GROUP AG1 FORCE_FAILOVER_ALLOW_DATA_LOSS;Suspend an Availability Database + An availability database that is suspended means no transaction record data movement occurs, and that the transaction log on the primary replica keeps growing and cannot be truncated. + When a secondary database is suspended, its database state is changed to SUSPENDED, and it begins to fall behind the primary database Comet 3) 28 FDS 16 SGLHAI S04 Server 12015250 ~ = G Abennetions # a Sects 2 i Seve Obes Repheaton = GS Alen High vey © Oy Bombay Groupe = AGI Poman) Da Aral Replicas 5 ena Datars 2 ca Maan au wa Menogenent & Ga negation Seices SCUHA (St Server 129)Performance *The read-only secondary replicas are usually behind the primary replica (in most cases, by seconds) because secondary replicas are impacted by the following: * The length of the database transaction. * The workload on the secondary replica. The timely transaction record data movement processing may be reduced if the replica is busy running a read-only workload. * The network latency between the primary and secondary replicas + When the workload is I/O-intensive (for example, when data is transferred to the secondary replicas), it can create index or bulk copy operations.+ The steps for data to arrive to a query on the secondary replica require the following operations, S04 SERVER + Data arrives to the secondary replica, oe and it is applied and hardened to the iis | transaction log. of + An acknowledgment is sent to the / primary replica, + The redo thread applies the transaction log changes to the data page. + Then the query in the secondary replica can see the new data.BACKUP ON THE SECONDARY REPLICA *you can offload a backup that is a high I/O and CPU operation from the primary replica to a secondary replica. *A copy-only full backup is a SQL Server backup that is independent of the sequence of conventional SQL Server backups. It doesn't affect the overall backup or restore procedures for the database.ALWAYSON GROUP DASHBOARD (© tet sey ARSON ee ee Pay) * From the Dashboard, P you can determine the health and performance of each Availability Group.MONITORING AND TROUBLESHOOTING * you must monitor an Availability Group as part of regular operations to identify any issues with the Availability Group that may prevent the data from being synchronized with the secondary replicas, or if failover to a secondary replica fails. * To perform detailed monitoring and troubleshooting, use the DMVs to identify, verify, and to then troubleshoot an Availability Group. * sys.availability_groups * sys.dm_hadr_availability_group_states * sys.availability_replicas * sys.dm_hadr_availability_replica_states + sys.dm_hadr_database_replica_states * sys.dm_hadr_database_replica_cluster_states + sys.availability_group_listener_ip_addresses * sys.availability_group_listeners + sys.dm_tcp_listener_states + sys.fn_hadr_is_primary_replica