AlwaysON Basics

Editor's Notes

• #2: © 2015 Microsoft Corporation Microsoft Confidential
• #4: © 2015 Microsoft Corporation Microsoft Confidential
• #5: To achieve automatic failover, synchronous database mirroring with a witness (a third SQL Server instance) is configured. When zero data loss is required, the database mirroring high-safety mode (synchronous) setting is enabled to help ensure zero data loss between the two servers located in the primary data center. To improve database availability within the primary data center, a third SQL Server instance is configured to act as a witness to enable automatic failover between the database mirroring partners. Log shipping is used for disaster recovery and log shipping involves ongoing transaction log backups of the principal database. These transaction log backups are then copied to a SQL Server instance in the disaster recovery data center. Incoming transaction log backups are restored in sequence on an ongoing basis. You could also choose to configure log shipping for read-only workloads, but with the drawback that read-only connections must be disconnected before incoming transaction log backups are applied.
• #9: Availability Databases To add a database to an availability group, the database must be an online, read-write database that exists on the server instance that hosts the primary replica. When you add a database, it joins the availability group as a primary database, while remaining available to clients. No corresponding secondary database exists until backups of the new primary database are restored to the server instance that hosts the secondary replica (using RESTORE WITH NORECOVERY). The new secondary database is in the RESTORING state until it is joined to the availability group Session-Timeout Period The session-timeout period is an availability-replica property that determines how long connection with another availability replica can remain inactive before the connection is closed. The primary and secondary replicas ping each other to signal that they are still active. Receiving a ping from the other replica during the timeout period indicates that the connection is still open and that the server instances are communicating. On receiving a ping, an availability replica resets its session-timeout counter on that connection. The session-timeout period prevents either replica from waiting indefinitely to receive a ping from the other replica. If no ping is received from the other replica within the session-timeout period, the replica times out. Its connection is closed, and the timed-out replica enters the DISCONNECTED state. Even if a disconnected replica is configured for synchronous-commit mode, transactions will not wait for that replica to reconnect and resynchronize. The default session-timeout period for each availability replica is 10 seconds. This value is user-configurable, with a minimum of 5 seconds. Generally, we recommend that you keep the time-out period at 10 seconds or greater. Setting the value to less than 10 seconds creates the possibility of a heavily loaded system declaring a false failure.
• #10: A unique DNS name This is also known as a Virtual Network Name (VNN). Active Directory naming rules for DNS host names apply. One or more Virtual IP addresses (VIPs)VIPs are configured for one or more subnets to which the availability group can failover. IP address configurationFor a given availability group listener, the IP address uses either Dynamic Host Configuration Protocol (DHCP) or one or more static IP addresses. Dynamic Host Configuration Protocol (DHCP) If an availability group resides on a single subnet, you can configure all the availability group listener IP addresses to use DHCP. For pre-production environments, DHCP offers an easy setup for an availability group that does not require disaster recovery to a remote site on a separate subnet. However, you should not use DHCP in conjunction with an availability group listener in a production environment. This is because, in the event of down time, if the DHCP IP lease expires, extra time is required to re-register the new DHCP IP address associated with the listener DNS name. The extra time will cause client-connection failure. Static IP addresses In production environments, we recommend that availability group listeners use static IP addresses. Furthermore, where availability groups extend across subnets in a multi-subnet domain, an availability group listener must use static IP addresses. Port Consideration You can also designate a non-standard listener port; however this means that you will also need to explicitly specify a target port in your connection string whenever connecting to the availability group listener. You will also need to open permission on the firewall for the non-standard port. If you use the default port of 1433 for availability group listener VNNs, you will still need to ensure that no other services on the cluster node are using this port; otherwise this would cause a port conflict. If one of the instances of SQL Server is already listening on TCP port 1433 via the instance listener and there are no other services (including additional instances of SQL Server) on the computer listening on port 1433, this will not cause a port conflict with the availability group listener. This is because the availability group listener can share the same TCP port inside the same service process. However multiple instances of SQL Server (side-by-side)should not be configured to listen on the same port.
• #11: Using a Listener to Connect to a Read-Only Secondary Replica (Read-Only Routing) Read-only routing refers to the ability of SQL Server to route incoming connections to an availability group listener to a secondary replica that is configured to allow read-only workloads. An incoming connection referencing an availability group listener name can automatically be routed to a read-only replica if the following are true: At least one secondary replica is set to read-only access, and each read-only secondary replica and the primary replica are configured to support read-only routing. The connection string references an availability group listener, and the application intent of the incoming connection is set to read-only (for example, by using the Application Intent=ReadOnly keyword in the ODBC or OLEDB connection strings or connection attributes or properties
• #12: Thread considerations The maximum number of threads used by availability groups is the configured setting for the maximum number of server threads ('max worker threads') minus 40. he availability replicas hosted on a given server instance share a single thread pool. Threads are shared on an on-demand basis, as follows: Typically, there are 3–10 shared threads, but this number can increase depending on the primary replica workload. If a given thread is idle for a while, it is released back into the general SQL Server thread pool. Normally, an inactive thread is released after ~15 seconds of inactivity. However, depending on the last activity, an idle thread might be retained longer. In addition, availability groups use unshared threads, as follows: Each primary replica uses 1 Log Capture thread for each primary database. In addition, it uses 1 Log Send thread for each secondary database. Log send threads are released after ~15 seconds of inactivity. Each secondary replica uses 1 redo thread for each secondary database. Redo threads are released after ~15 seconds of inactivity. A backup on a secondary replica holds a thread on the primary replica for the duration of the backup operation.
• #13: Thread considerations The maximum number of threads used by availability groups is the configured setting for the maximum number of server threads ('max worker threads') minus 40. he availability replicas hosted on a given server instance share a single thread pool. Threads are shared on an on-demand basis, as follows: Typically, there are 3–10 shared threads, but this number can increase depending on the primary replica workload. If a given thread is idle for a while, it is released back into the general SQL Server thread pool. Normally, an inactive thread is released after ~15 seconds of inactivity. However, depending on the last activity, an idle thread might be retained longer. In addition, availability groups use unshared threads, as follows: Each primary replica uses 1 Log Capture thread for each primary database. In addition, it uses 1 Log Send thread for each secondary database. Log send threads are released after ~15 seconds of inactivity. Each secondary replica uses 1 redo thread for each secondary database. Redo threads are released after ~15 seconds of inactivity. A backup on a secondary replica holds a thread on the primary replica for the duration of the backup operation.
• #15: The AlwaysOn Availability Groups active secondary capabilities include support for performing backup operations on secondary replicas. Backup operations can put significant strain on I/O and CPU (with backup compression). Offloading backups to a synchronized or synchronizing secondary replica allows you to use the resources on server instance that hosts the primary replica for your tier-1 workloads. Note that copy-only backups do not impact the log chain or clear the differential bitmap.
• #16: The AlwaysOn Availability Groups active secondary capabilities include support for performing backup operations on secondary replicas. Backup operations can put significant strain on I/O and CPU (with backup compression). Offloading backups to a synchronized or synchronizing secondary replica allows you to use the resources on server instance that hosts the primary replica for your tier-1 workloads. Note that copy-only backups do not impact the log chain or clear the differential bitmap.