Netherlands: Software

Introductie van Micorosoft SQL Server 2016

Issue link: http://hub-nl.insight.com/i/692679

Contents of this Issue

Navigation

Page 45 of 212

34 C H A P T E R 3 | Higher availability New to availability groups? If you are still using database mirroring, there are several reasons to transition your high-availability strategy to availability groups. Database mirroring is deprecated as of SQL Server 2012, for example, and basic availability groups are now included in SQL Server 2016 Standard Edition as a replacement. Also, if you are exploring options for high-availability/disaster-recovery (HA/DR) solutions but have never implemented availability groups, SQL Server 2016 provides several benefits to consider. Whereas database mirroring occurs at the database level, using a single thread to perform the data replication, data is moved within availability groups by using a worker pool, which provides better throughput and reduces CPU overhead. When your application requires multiple databases, you can assign the databases to a single availability group to ensure that they all fail over at the same time. By contrast, the unit of failover with database mirroring is a single database. With database mirroring, you use a SQL Server witness instance to manage automatic failover, but with availability groups you rely on Windows Server Failover Clustering (WSFC) to arbitrate uptime and connections. Furthermore, clustering is a more robust solution than database mirroring because it provides additional levels of protection. A key benefit of availability groups is the ability to scale out replicas that you can configure to support both high-availability and disaster-recovery requirements. For high-availability scenarios, you should locate two or three servers in the same geographic location, configured to use synchronous-commit mode and automatic failover. That said, automatic failover should be used only in low-latency scenarios because writes to the primary replica are not considered complete until they reach the transaction log on the secondary replica. For disaster-recovery scenarios in which the servers are more than 100 kilometers apart, asynchronous-commit mode is a better choice to minimize the performance impact on the primary replica. Another benefit of availability groups is the ability for databases on a secondary replica to support online reads as well as database backups. This capability allows you to implement a scale-out architecture for reporting solutions by having multiple copies of secondary replicas in multiple geographies. You provide connectivity to the availability group by using a virtual IP address called the listener, which you configure to connect transparently to the primary replica or to a secondary replica for reading. Figure 3-1 is a diagram of an availability group with replicas in New York, Los Angeles, and Seattle and a listener to which clients connect. Figure 3-1: An AlwaysOn Availability Group with a primary replica and two secondary replicas. Supporting disaster recovery with basic availability groups You can now use basic availability groups in the Standard Edition to automatically fail over a single database. The use of basic availability groups is subject to the following limitations:

Articles in this issue

Archives of this issue

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