Netherlands: Software

Introductie van Micorosoft SQL Server 2016

Issue link:

Contents of this Issue


Page 51 of 212

40 C H A P T E R 3 | Higher availability Forced Failover (with possible data loss) A failover that occurs when the availability group is configured with asynchronous-commit mode, or the databases in the availability group are not currently synchronized. For automatic failover to work, you must configure all members of the availability group for synchronous-commit mode and for automatic failover. You typically configure automatic failover for high-availability scenarios, such as rolling updates to SQL Server. In this configuration, any uncommitted transactions that have not reached the secondary replica are rolled back in the event of failover, thereby providing near zero data loss. Reviewing the improved log transport performance When AlwaysOn Availability Groups were first introduced in SQL Server 2012, solid-state storage devices (SSDs) were far less prevalent in enterprise IT architectures than they are now. SSDs enable more throughput, which can be problematic on a standalone system and can overwhelm the ability to write to the secondary database. In prior versions of SQL Server, the underlying processes responsible for synchronizing data between replicas are shared among availability groups, database mirroring, Service Broker, and replication. In SQL Server 2016, these processes are completely rewritten, resulting in a streamlined protocol with better throughput and lower CPU utilization. Although the process has been refactored, the sequence of internal operations for the log transport, shown in Figure 3-5, continues to include the following steps: 1. Log flush Log data is generated and flushed to disk on the primary replica in preparation for replication to the secondary replica. It then enters the send queue. 2. Log capture Logs for each database are captured on the primary replica, compressed, and sent to the corresponding queue on the secondary replica. This process runs continuously as long as database replicas are connecting. If this process is not able to scan and enqueue the messages quickly enough, the log send queue continues to grow. 3. Send The messages are removed from the queue and sent to each secondary replica across the network. 4. Log receive/Log cache Each secondary replica gets messages from the primary replica and then caches the messages. 5. Log hardened The log is flushed on the secondary replica, and then a notification is sent to the primary replica to acknowledge completion of the transaction. 6. Redo pages The flushed pages are retrieved from the redo queue and applied to the secondary replica.

Articles in this issue

Archives of this issue

view archives of Netherlands: Software - Introductie van Micorosoft SQL Server 2016