Last modified by Billie D on 2021/02/15 17:38
From version 17.3
edited by Billie D
on 2021/02/14 15:11
To version 18.1
edited by Billie D
on 2021/02/14 15:13
Change comment: There is no comment for this version

Summary

Details

Icon Page properties
Content
... ... @@ -68,8 +68,10 @@
68 68  **AlwaysOn Availability Groups** (**AOAG**) replaces database mirroring and is essentially a merger of database mirroring and clustering technologies.
69 69  
70 70  SQL Server is installed as a **stand-alone instance** (as opposed to an AlwaysOn Failover Clustered Instance) on each node of a cluster. A cluster-aware application, called an **Availability Group Listener,** is then installed on the cluster; it is used __to direct traffic to the correct node__. Instead of
71 -relying on shared disks, however, **AOAG compresses the log stream** and **sends it to the other nodes**, in a __similar fashion to database mirroring__. When you are using AOAG, **failover **__does not occur at the database level__, __nor at the instance level.__ Instead, failover occurs at the **level of the availability group, **__availability group__ is a concept that allows you to __group related databases together__ so that they can __fail over as an atomic unit__.
71 +relying on shared disks, however, **AOAG compresses the log stream** and **sends it to the other nodes**, in a __similar fashion to database mirroring__. When you are using AOAG, **failover **__does not occur at the database level__, __nor at the instance level.__ Instead, failover occurs at the **level of the availability group, **__availability group__ is a concept that allows you to __group related databases together__ so that they can __fail over as an atomic unit, it allows you to group together the databases that map to a single application.__
72 72  
73 +__No hard limits are imposed for the number of availability groups you can configure on an instance, nor are there any hard limits for the number of databases on an instance that can take part in AOAG.__ **Microsoft**, however, has tested up to, and officially recommends, __a maximum of 100__ databases and 10 availability groups per instance.
74 +
73 73  AOAG is the most appropriate technology for high availability in scenarios where you have small databases with **low write profiles**. This is because, when used **synchronously**, it requires that the __data is committed on all synchronous replicas__ before it is committed on the primary database.
74 74  
75 75  Availability Groups, on the other hand, allow you to configure one or more **replicas as readable**. The **only limitation** is that **readable replicas** and **automatic failover** **__//cannot be configured//__** on the **same secondaries**. The norm, however, would be to __configure readable secondary__