D

SQL Server AlwaysOn AG Architecture

https://www.sqldbachamps.com
SQL Server AlwaysOn Availability Groups Architecture in Detail
SQL Server AlwaysOn Availability Groups (AGs) is a high-availability and disaster recovery solution introduced in SQL
Server 2012. AlwaysOn Availability Groups provide database-level high availability, allowing for multiple copies
(replicas) of a database to be maintained in real-time across different servers (or nodes). This architecture ensures that
the databases remain available even in the event of hardware or software failures, making it a powerful solution for
critical database systems.

AlwaysOn Availability Groups (AGs) have evolved from SQL Server Failover Cluster Instances (FCI) to provide more
flexible and advanced features such as read-write and read-only replicas, automatic failover, and better performance,
making them the preferred solution for high availability and disaster recovery in modern SQL Server environments.

Key Components of AlwaysOn Availability Groups (AGs)

1. Primary Replica

●​ The Primary Replica is the active replica in the Availability Group that handles read-write operations and client
connections.
●​ All transaction log changes are generated on the primary replica and are then sent to the secondary replicas
for synchronization.

2. Secondary Replicas

●​ Secondary Replicas are passive replicas that maintain a copy of the database from the primary replica. These
replicas can be configured to support read-only workloads, such as reporting or backups, without impacting
the performance of the primary replica.
●​ They can be located on different servers or data centers for disaster recovery purposes.
●​ Secondary replicas can be:
○​ Synchronous-commit: The secondary replica is always up-to-date with the primary replica, ensuring
zero data loss in case of failure.
○​ Asynchronous-commit: The secondary replica may lag behind the primary replica, offering a trade-off
between performance and data protection.

3. Availability Group Listener

●​ The Availability Group Listener is a virtual network name (VNN) that clients use to connect to the availability
group, irrespective of which replica is currently the primary.
●​ The listener routes client connections to the current primary replica automatically, whether it’s on the original
node or has failed over to another node.

4. Availability Databases

●​ An Availability Database is a user database that is part of an AlwaysOn Availability Group.

●​ It can be part of a single AG and replicated across the primary and secondary replicas. A single availability
group can contain one or multiple databases.

5. Replica Roles

●​ Replicas in an AG can assume different roles:

○​ Primary: Only one replica can be the primary at a time. It is the replica where clients can perform both
read and write operations.
○​ Secondary: Secondary replicas can be in one of two modes:

https://www.sqldbachamps.com
 ■​ Synchronous-commit: Transactional consistency is maintained between the primary and
secondary replicas.
■​ Asynchronous-commit: The secondary replica is not required to be in sync with the primary.
This mode introduces some lag between the replicas, but it provides greater flexibility in terms
of performance.

6. Failover Mechanism

●​ Automatic Failover: If the primary replica fails, SQL Server can automatically failover to a secondary replica
that is in synchronous-commit mode.
●​ Manual Failover: Administrators can manually failover to another replica, regardless of whether it’s in
synchronous or asynchronous mode.
●​ Failover occurs at the database level, which means a single replica can support multiple databases in an AG,
and when a failover happens, it impacts the entire Availability Group.

7. Synchronization Modes

●​ Synchronous-commit mode:
○​ Guarantees that data is written to both the primary and secondary replicas before a transaction is
committed, providing zero data loss in case of a failure.
○​ Best for critical systems where data loss is unacceptable.
●​ Asynchronous-commit mode:
○​ The primary replica commits transactions without waiting for secondary replicas to acknowledge the
changes. This mode is used for disaster recovery scenarios where the distance between replicas is
large, such as cross-region or cross-data-center setups.
○​ This mode can result in some data loss if a failure occurs, as there may be a delay in applying
transaction logs on secondary replicas.

8. Health Detection and Monitoring

●​ SQL Server AlwaysOn continuously monitors the health of replicas. If a replica is unreachable or not
synchronized with the primary, automatic failover can be triggered (if configured), or a manual intervention
may be required.
●​ Health is monitored using the Availability Group Dashboard and SQL Server Management Studio (SSMS).

https://www.sqldbachamps.com
SQL Server AlwaysOn AG Architecture Diagram
Below is a simplified diagram representing an AlwaysOn Availability Group (AG) architecture:

+-------------------+ +-------------------+

| Primary Replica|<----------------->| Secondary Replica|

| (Read-Write) | | (Read-Only) |

| | | |

+-------------------+ +-------------------+

| |

| |

| +---------------------+ |

+-------->| Availability Group |-------+

| Listener |

+---------------------+

+---------------------+

| Client Connections |

| (Using Listener) |

+---------------------+

SQL Server AlwaysOn AG High Availability and Disaster Recovery Architecture

1.​ Primary Replica: Handles all read and write operations. It generates transaction log entries.
2.​ Secondary Replica: Receives transaction logs from the primary and applies them. It can be in synchronous or
asynchronous mode.
3.​ AlwaysOn Availability Group Listener: A virtual network name (VNN) for client applications to connect to the
Availability Group. The listener automatically directs traffic to the current primary replica.
4.​ Client Applications: Connect to the Availability Group using the listener. If failover occurs, the listener redirects
the application to the new primary replica without requiring manual changes.

https://www.sqldbachamps.com
Failover Scenarios in AlwaysOn AG
There are several scenarios in AlwaysOn Availability Groups where failover can occur:

1.​ Automatic Failover:

○​ Occurs when a synchronous-commit secondary replica becomes the new primary.
○​ This type of failover happens automatically, without manual intervention, provided the automatic
failover configuration is set up.
○​ It guarantees no data loss, as the transaction logs are synchronized between the primary and
secondary replicas.
2.​ Manual Failover:
○​ An administrator can manually failover from the primary replica to a secondary replica (whether
synchronous or asynchronous).
○​ This process is done using SQL Server Management Studio (SSMS) or T-SQL commands.
○​ Manual failover can be performed even if the secondary replica is asynchronous, though some data
loss might occur in this case.
3.​ Planned Failover:
○​ This is a manual failover performed during maintenance activities, such as patching or hardware
upgrades.
○​ The failover is planned, and there's typically minimal or no downtime.
4.​ Unplanned Failover:
○​ Occurs when a primary replica fails unexpectedly due to hardware, software, or network issues.
○​ In case of synchronous replicas, no data loss is expected. However, with asynchronous replicas, data
loss might occur.

Advantages of AlwaysOn Availability Groups

1.​ High Availability:​

○​ AlwaysOn AGs offer a high level of availability by providing automatic failover and multiple replicas,
which helps reduce downtime in the event of failure.
2.​ Disaster Recovery:​

○​ Secondary replicas can be in geographically distributed locations, providing disaster recovery solutions
in case of regional or datacenter failures.
3.​ Read-Scale Availability:​

○​ Secondary replicas in an Availability Group can be configured to serve read-only queries, offloading
reporting or analytical workloads from the primary replica.
4.​ Minimal Downtime:​

○​ Since AlwaysOn AGs provide automatic failover and continuous data synchronization, the downtime
during a failover is minimal, and the database services can quickly resume operation.
5.​ Integrated with SQL Server:​

○​ AlwaysOn AGs integrate directly with SQL Server, providing an easy setup and management experience
through SQL Server Management Studio (SSMS) and T-SQL commands.
6.​ Cross-Site Availability:​

○​ Availability Groups can span across different geographic locations (data centers), providing better
disaster recovery options without requiring shared storage.

https://www.sqldbachamps.com
Disadvantages of AlwaysOn Availability Groups
1.​ Complexity:
○​ Setting up and managing AlwaysOn AGs can be complex, requiring careful planning and understanding
of failover, replication, and networking configurations.
2.​ Requires Enterprise Edition:
○​ AlwaysOn Availability Groups are only available in the SQL Server Enterprise Edition. Organizations
using SQL Server Standard Edition will need to consider alternative high-availability options.
3.​ No Shared Storage:
○​ Unlike SQL Server Failover Cluster Instances (FCI), AlwaysOn AGs do not rely on shared storage, which
may make it more challenging to maintain transactional consistency across geographically dispersed
replicas.
4.​ Potential Data Loss in Asynchronous Mode:
○​ When secondary replicas are configured in asynchronous-commit mode, there’s a risk of data loss in
the event of a failure, as the primary replica may commit transactions before the secondary replica
applies them.
5.​ Resource Overhead:
○​ Maintaining multiple replicas can increase resource consumption (CPU, memory, and network
bandwidth), which might require additional hardware resources to handle the load effectively.

Summary:
SQL Server AlwaysOn Availability Groups (AGs) provide a powerful and flexible solution for high availability and
disaster recovery. They allow for multiple replicas of databases, offer automatic failover, and enable read-scale
availability for applications. By separating high availability from disaster recovery and supporting both synchronous
and asynchronous commit modes, AlwaysOn AGs can be tailored to suit a variety of business needs.

However, the configuration and management of AlwaysOn AGs come with a certain level of complexity, and it's
important to carefully consider factors like networking, server hardware, and SQL Server licensing when implementing
AlwaysOn Availability Groups in a production environment. AlwaysOn Availability Groups are ideal for environments
where minimal downtime, high availability, and disaster recovery are essential.

https://www.sqldbachamps.com