This article describes the data synchronization process on SQL Server Always On Availability Groups in both Synchronous, and Asynchronous data commit mode.

本文介绍了在同步和异步数据提交模式下，SQL Server Always On可用性组上的数据同步过程。

High data availability is an important aspect of every DBA’s life. We need to minimize and mitigate the issues related to database unavailability.

高数据可用性是每个DBA生命的重要方面。 我们需要最小化和减轻与数据库不可用有关的问题。

In the production environment, we want to achieve RPO (Maximum allowed downtime) and RTO (Maximum acceptable data loss) goals of a production database service. Data should be available to business round the clock to avoid any business loss.

在生产环境中，我们希望实现生产数据库服务的RPO （最大允许停机时间）和RTO （最大可接受数据丢失）目标。 数据应全天候提供，以免造成业务损失。

In the following table, we can get a glimpse of the maximum allowed downtime based on availability percentage. We get a very strict maximum of downtime per year as we move towards a strict availability percentage.

在下表中，我们可以根据可用性百分比大致了解允许的最大停机时间。 随着我们朝着严格的可用性百分比迈进，我们每年都会获得非常严格的最大停机时间。

In SQL Server, we can achieve high availability using SQL Server Always On Availability Groups feature. Let’s get a quick overview of SQL Server Always on Availability Groups before we go in deeper.

在SQL Server中，我们可以使用SQL Server Always On可用性组功能实现高可用性。 在深入探讨之前，让我们快速了解一下SQL Server Always On可用性组。

In the following screenshot, we have three SQL instances participating in SQL Server Always On.

在下面的屏幕快照中，我们有三个SQL实例参与SQL Server Always On。

We can have a Primary instance and multiple secondary instances (depending upon SQL Version and Edition).

我们可以有一个主实例和多个辅助实例（取决于SQL版本和版本）。

Few important terms of SQL Server Always on Availability Groups are as follows.

SQL Server Always on可用性组的几个重要术语如下。

• Availability group: It is a logical group of user databases that should failover together on the secondary replica 可用性组：这是用户数据库的逻辑组，应该在辅助副本上一起进行故障转移
• Replica: Each availability group should contain two or more participating instance. Each participating instance is known as Replica in SQL Server Always On 副本 ：每个可用性组应包含两个或更多参与实例。 每个参与实例在SQL Server Always On中称为副本服务器
• Primary Replica: It hosts the primary database and available for all users for read-write connections 主副本 ：它承载主数据库，并且可供所有用户进行读写连接
• Secondary Replica: It hosts a copy of a database from the primary replica. It works as a failover target in case of any issues with the primary replica 辅助副本 ：它承载主副本中数据库的副本。 如果主副本出现任何问题，它可以作为故障转移目标

In the SQL Server Always On, Primary replica sends transaction log to secondary databases for all databases defined in the availability group.

在“ SQL Server始终打开”中，主副本将事务日志发送到可用性组中定义的所有数据库的辅助数据库。

We can have two types of data commit modes.

我们可以有两种类型的数据提交模式。

• Asynchronous-commit mode: In this mode, Primary replica sends the transaction log blocks to a secondary replica, but it does not wait for the acknowledgement for transaction commit. It is suitable for disaster recovery solutions 异步提交模式：在这种模式下，主副本将事务日志块发送到辅助副本，但它不等待事务提交的确认。 适用于灾难恢复解决方案
• Synchronous-commit mode: In synchronous-commit mode, the primary replica waits for the transaction commit from a secondary replica. Once it receives the confirmation, SQL Server confirms to the client 同步提交模式：在同步提交模式下，主副本等待来自辅助副本的事务提交。 收到确认后，SQL Server向客户端确认

In the following screenshot, we can see an overview of two node SQL Server Always On Availability groups

在下面的屏幕快照中，我们可以看到两个节点SQL Server Always On可用性组的概述

We might be interested to know the internals of SQL Server Always On. In the next section, let’s see how actually data synchronization happens in both Synchronous and Asynchronous data commit mode.

我们可能有兴趣了解SQL Server Always On的内部知识。 在下一节中，让我们看看在同步和异步数据提交模式下数据同步实际上是如何发生的。

同步数据提交模式下的数据同步 (Data Synchronization in Synchronous data commit mode)

In the following image, we can see the overall working of data synchronization in Synchronous commit.

在下图中，我们可以看到同步提交中数据同步的总体工作。

Let’s go through in detail with each step on the above diagram.

让我们详细研究上图中的每个步骤。

1. A client connects to the primary replica (either using a listener or SQL instance name) and issues a DML transaction 客户端连接到主副本（使用侦听器或SQL实例名称）并发出DML事务
2. In Primary replica, transaction log block is generated. These transaction log records get stored in the log cache of the primary replica 在主副本中，将生成事务日志块。 这些事务日志记录存储在主副本的日志缓存中
3. SQL Server regular performs an automatic checkpoint. It flushes log data into the disk for a primary replica. At the same time, it also copies the log records to Log Pool SQL Server常规执行自动检查点。 它将日志数据刷新到磁盘中作为主副本。 同时，它还将日志记录复制到日志池
4. . The Log Capture process continuously scans the logs from the Log Capture and sends to each secondary replica. If we have multiple secondary replicas, we have individual threads for each replica, and its responsibility is to send a log block for the corresponding replica 。 日志捕获过程连续扫描来自日志捕获的日志，并将其发送到每个辅助副本。 如果我们有多个辅助副本，则每个副本都有单独的线程，它的责任是发送对应副本的日志块

   Note: SQL Server encrypts log records before sending it to secondary replicas.

   注意 ：SQL Server在将日志记录发送到辅助副本之前先对其进行加密。

5. In the secondary replica, Log Receive gets the log records from the primary replica and writes to Log cache. This process is repeated on each secondary replica participating in synchronous-commit mode 在辅助副本中，“日志接收”从主副本获取日志记录，并将其写入日志缓存。 在参与同步提交模式的每个辅助副本上重复此过程
6. On each secondary replica, Redo thread exists, and it writes all changes mentioned in log records to the data page and index page. It flushes the log for hardening on secondary database log 在每个辅助副本上，都存在重做线程，并且重做线程将日志记录中提到的所有更改写入数据页和索引页。 刷新日志以强化辅助数据库日志
7. As stated earlier, in synchronous data commit, primary replica waits for the acknowledgement from the secondary replica. At this stage, secondary replica sends an acknowledgement that transaction hardening is completed on secondary 如前所述，在同步数据提交中，主副本等待来自辅助副本的确认。 在此阶段，辅助副本发送一个确认，表明辅助服务器上的事务强化已完成
8. Once Primary replica, receives an acknowledgement from the secondary replica, it sends the transaction completion message to the client 一旦主副本从辅助副本接收到确认，它就会将事务完成消息发送到客户端
9. The secondary replica also contains a redo thread, and it is independent of the log block process in SQL Server Always on. Redo threads reads the logs from log cache. There might be a delay in processing by redo thread and log records might not be available in log cache because it is already hardened to disk. In this case, redo thread read log blocks from the log disk 辅助副本还包含一个重做线程，它独立于SQL Server Always On中的日志块进程。 重做线程从日志缓存中读取日志。 重做线程的处理可能会有所延迟，并且日志记录可能已在硬盘上硬化，因此在日志缓存中可能不可用。 在这种情况下，重做线程从日志磁盘读取日志块

异步数据提交模式下的数据同步 (Data Synchronization in Asynchronous data commit mode)

We can understand data synchronization in Asynchronous data commits mode with the following image.

我们可以通过下图了解异步数据提交模式下的数据同步。

1. A client connects to the primary replica (either using a listener or SQL instance name) and issues a DML transaction 客户端连接到主副本（使用侦听器或SQL实例名称）并发出DML事务
2. In Primary replica, transaction log block is generated. These transaction log records get stored in the log cache of the primary replica 在主副本中，将生成事务日志块。 这些事务日志记录存储在主副本的日志缓存中
3. SQL Server regular performs an automatic checkpoint. It flushes log data into the disk for a primary replica. At the same time, it also copies the log records to Log Pool SQL Server常规执行自动检查点。 它将日志数据刷新到磁盘中作为主副本。 同时，它还将日志记录复制到日志池
4. In Asynchronous data commit mode, the primary replica does not wait for the acknowledgement from participating secondary replica. It sends the acknowledgement to the client for transaction commit 在异步数据提交模式下，主副本不等待参与的辅助副本的确认。 它将确认发送到客户端以进行事务提交
5. In the secondary replica, Log Receive gets the log records from the primary replica and writes to Log cache. This process is repeated on each secondary replica participating in asynchronous-commit mode 在辅助副本中，“日志接收”从主副本获取日志记录，并将其写入日志缓存。 在参与异步提交模式的每个辅助副本上重复此过程
6. On each secondary replica, Redo thread exists, and it writes all changes mentioned in log records to the data page and index page. It flushes the log for hardening on secondary database log 在每个辅助副本上，都存在重做线程，并且重做线程将日志记录中提到的所有更改写入数据页和索引页。 刷新日志以强化辅助数据库日志
7. The secondary replica also contains a redo thread, and it is independent of the log block process in SQL Always On. Redo threads reads the logs from log cache. There might be a delay in processing by redo thread and log records might not be available in log cache because it is already hardened to disk. In this case, redo thread read log blocks from the log disk 辅助副本还包含一个重做线程，它独立于SQL Always On中的日志块进程。 重做线程从日志缓存中读取日志。 重做线程的处理可能会有所延迟，并且日志记录可能已在硬盘上硬化，因此在日志缓存中可能不可用。 在这种情况下，重做线程从日志磁盘读取日志块

将AlwaysON与辅助副本关闭同步 (Synchronized AlwaysON with Secondary replica down)

Suppose we have two synchronous node data commit AlwaysOn in our environment. As stated earlier, Primary replica waits for the acknowledgement from Secondary replica and then only sends an acknowledgement. If Secondary AG instance is down, SQL Server will not be able to deliver transaction log records to the secondary replica.

假设我们在环境中有两个同步节点数据提交AlwaysOn。 如前所述，主副本等待来自辅助副本的确认，然后仅发送确认。 如果辅助AG实例关闭，则SQL Server将无法将事务日志记录传递到辅助副本。

Think about it. We can get a few questions such as following.

想一想。 我们可以得到一些如下问题。

• What will be the transaction behavior in this case? 在这种情况下，交易行为是什么？
• Do users get transaction commit message? 用户会收到交易提交消息吗？

We can view this scenario in the following screenshot.

我们可以在以下屏幕截图中查看此场景。

In SQL Server Availability groups checks the status of each replica based on a parameter Session-Timeout. By default, its value is 10 seconds. It shows that the Primary replica waits for 10 seconds for a ping response. If it does not receive any response from the secondary replica, SQL Server change Synchronous data commit to Asynchronous data commits as a temporary measure. Due to this change, users will not face any issues while executing DML. Users will receive commit acknowledgement as soon as it gets committed in Primary replica.

在SQL Server中，可用性组根据参数Session-Timeout检查每个副本的状态。 默认情况下，其值为10秒。 它显示主副本等待10秒以执行ping响应。 如果它没有收到来自辅助副本的任何响应，则SQL Server会将同步数据提交更改为异步数据提交作为一种临时措施。 由于此更改，用户在执行DML时不会遇到任何问题。 用户将在主副本中提交提交后立即收到提交确认。

In the following screenshot, you can see this scenario.

在以下屏幕截图中，您可以看到这种情况。

Once the secondary replica is available and connects with the Primary replica, it again starts Synchronous data commit. SQL Server maintains the log entries until the time secondary replica becomes available. Once it reconnects with Secondary replica, it sends all log blocks as per the usual process. It increases the transaction log size in Primary replica until the secondary replica is unavailable.
If you remove the Secondary database from the availability group, SQL Server does not hold any transaction log records. If it takes longer to fix issues with the secondary replica, it is good to remove the replica from the availability group.

一旦辅助副本可用并与主副本连接，它将再次启动同步数据提交。 SQL Server会维护日志条目，直到辅助副本可用为止。 与辅助副本重新连接后，它将按照常规过程发送所有日志块。 它会增加主副本中的事务日志大小，直到辅助副本不可用为止。
如果从可用性组中删除辅助数据库，则SQL Server将不保存任何事务日志记录。 如果修复辅助副本所需的时间更长，则最好从可用性组中删除副本。

结论 (Conclusion)

In this article, we explored the internals of data synchronization for AlwaysOn availability groups. It will help to understand the end-to-end data flow. We will cover more on SQL Server Always on Availability Groups in upcoming articles.

在本文中，我们探讨了AlwaysOn可用性组的数据同步内部。 这将有助于理解端到端的数据流。 我们将在以后的文章中介绍有关“ SQL Server始终在可用性组上”的内容。

翻译自: https://www.sqlshack.com/data-synchronization-in-sql-server-always-on-availability-groups/