日志传送、事务复制 和 Always.on

关于日志传送 (SQL Server)

SQL Server 2016

 

适用对象：SQL Server 2016

SQL Server 使用日志传送，您可以自动将“主服务器 ”实例上“主数据库 ”内的事务日志备份发送到单独“辅助服务器 ”实例上的一个或多个“辅助数据库 ”。 事务日志备份分别应用于每个辅助数据库。 可选的第三个服务器实例（称为“监视服务器 ”）记录备份和还原操作的历史记录及状态，还可以在无法按计划执行这些操作时引发警报。

本主题内容：

• 优点

• 术语和定义

• 日志传送概述

• 互操作性

• 相关任务

优点

• 为单个主数据库以及一个或多个辅助数据库（每个数据库都位于单独的 SQL Server 实例上）提供灾难恢复解决方案。

• 支持对辅助数据库的受限的只读访问权限（在还原作业之间的间隔期间）。

• 允许用户将延迟时间定义为：从主服务器备份主数据库日志到辅助服务器必须还原（应用）日志备份之间的时间。 例如，如果主数据库上的数据被意外更改，则较长的延迟会很有用。 如果很快发现意外更改，则通过延迟，您可以在辅助数据库反映此更改之前从其中检索仍未更改的数据。

术语和定义

主服务器 (primary server)
位于生产服务器上的 SQL Server 实例。

主数据库 (primary database)
希望备份到其他服务器的主服务器上的数据库。 通过 SQL Server Management Studio 进行的所有日志传送配置管理都是在主数据库中执行的。

辅助服务器 (secondary server)
想要在其中保留主数据库的热备用副本的 SQL Server 实例。

辅助数据库 (secondary database)
主数据库的热备用副本。 辅助数据库可以处于 RECOVERING 状态或 STANDBY 状态，这将使数据库可用于受限的只读访问。

监视服务器 (monitor server)
跟踪日志传送的所有详细信息的 SQL Server 的可选实例，包括：

• 主数据库中事务日志最近一次备份的时间。

• 辅助服务器最近一次复制和还原备份文件的时间。

• 有关任何备份失败警报的信息。

重要事项
配置监视服务器之后，只有先删除日志传送才能对其进行更改。

备份作业
一种 SQL Server 代理作业，它执行备份操作，将历史记录信息记录到本地服务器和监视服务器上，并删除旧的备份文件和历史记录信息。 启用日志传送后，将在主服务器实例上创建作业类别“日志传送备份”。

复制作业
一种 SQL Server 代理作业，它将备份文件从主服务器复制到辅助服务器中的可配置目标，并在辅助服务器和监视服务器中记录历史记录。 在数据库上启用日志传送后，将在日志传送配置中在各辅助服务器上创建作业类别“日志传送复制”。

还原作业
一种 SQL Server 代理作业，它将复制的备份文件还原到辅助数据库。 它将历史记录信息记录在本地服务器和监视服务器上，并删除旧文件和旧历史记录信息。 在数据库上启用日志传送后，在辅助服务器实例上会创建作业类别“日志传送还原”。

警报作业
一种 SQL Server 代理作业，它在备份或还原操作在指定阈值内未成功完成时为主数据库和辅助数据库引发警报。 在数据库上启用日志传送后，在监视服务器实例上会创建作业类别“日志传送警报”。

提示
对于每个警报，您需要指定警报编号。 此外，请确保配置警报以便在引发警报时通知操作员。

日志传送概述

日志传送由三项操作组成：

1. 在主服务器实例中备份事务日志。

2. 将事务日志文件复制到辅助服务器实例。

3. 在辅助服务器实例中还原日志备份。

日志可传送到多个辅助服务器实例。 在这些情况下，将针对每个辅助服务器实例重复执行操作 2 和操作 3。

日志传送配置不会自动从主服务器故障转移到辅助服务器。 如果主数据库变为不可用，可手动使任意辅助数据库联机。

您可以为了实现报表目的而使用辅助数据库。

此外，可以针对日志传送配置来配置警报。

典型日志传送配置

下图显示了具有主服务器实例、三个辅助服务器实例和一个监视服务器实例的日志传送配置。 此图阐释了备份作业、复制作业以及还原作业所执行步骤，如下所示：

1. 主服务器实例执行备份作业以在主数据库上备份事务日志。 然后，该服务器实例将日志备份放入主日志备份文件（此文件将被发送到备份文件夹中）。 在此图中，备份文件夹位于共享目录（“备份共享 ”）下。

2. 全部三个辅助服务器实例都执行其各自的复制作业，以将主日志备份文件复制到它本地的目标文件夹中。

3. 每个辅助服务器实例都执行其还原作业，以将日志备份从本地目标文件夹还原到本地辅助数据库中。

主服务器实例和辅助服务器实例将它们自己的历史记录和状态发送到监视服务器实例。

互操作性

日志传送功能可以与下列 SQL Server 功能或组件一起使用：

• 从日志传送迁移到 AlwaysOn 可用性组的先决条件 (SQL Server)

• 数据库镜像和日志传送 (SQL Server)

• 日志传送和复制 (SQL Server)

事务复制的工作机制

SQL Server 2008 R2

其他版本

事务复制由 SQL Server 快照代理、日志读取器代理和分发代理实现。 快照代理准备快照文件（其中包含了已发布表和数据库对象的架构和数据），然后将这些文件存储在快照文件夹中，并在分发服务器中的分发数据库中记录同步作业。

日志读取器代理监视为事务复制配置的每个数据库的事务日志，并将标记为要复制的事务从事务日志复制到分发数据库中，分发数据库的作用相当于一个可靠的存储-转发队列。 分发代理将快照文件夹中的初始快照文件和分发数据库表中的事务复制到订阅服务器中。

在发布服务器中所做的增量更改根据分发代理的计划流向订阅服务器，分发代理可以连续运行以尽量减少滞后时间，也可以按预定的时间间隔运行。 由于数据更改必须在发布服务器中进行（使用事务复制时，无需指定立即更新或排队更新选项），从而避免了更新冲突。 最后，所有订阅服务器都将获得与发布服务器相同的值。 如果事务复制使用了立即更新或排队更新选项，更新可以在订阅服务器中进行，对于排队更新，可能会发生冲突。 有关详细信息，请参阅可更新订阅的工作机制。

下图显示了事务复制的主要组件。

初始数据集

新的事务复制订阅服务器中必须包含一些表，这些表需要与发布服务器中的表具有相同的架构和数据，这样才能从发布服务器中接收增量更改。 初始数据集通常是由快照代理创建并由分发代理分发和应用的快照。 初始数据集还可以通过备份或其他方式提供，如使用 SQL Server 集成服务提供。 有关详细信息，请参阅初始化订阅。

在向订阅服务器分发并应用快照时，只有那些等待初始快照的订阅服务器才会受到影响。 该发布的其他订阅服务器（已经初始化的订阅服务器）不会受到影响。

并发快照处理

在快照生成期间，快照复制会在作为复制的一部分发布的所有表上放置共享锁。 这样可以防止更新正在发布的表。 并发快照处理（事务复制的默认方式）在整个快照生成过程中并不保留共享锁，因而允许用户在复制创建初始快照文件时继续工作，而不会被打断。

快照代理

快照代理在事务复制中实现初始快照所使用的过程与快照复制所使用的过程相同（上述有关并发快照处理的情况除外）。 有关详细信息，请参阅快照复制的工作机制。

生成快照文件后，可以使用 Microsoft Windows 资源管理器在快照文件夹中查看这些快照文件。

修改数据修改与日志读取器代理

日志读取器代理在分发服务器中运行；它通常连续运行，但也可以按照您制定的计划运行。 执行日志读取器代理时，它首先读取发布事务日志（该日志与执行一般 SQL Server 数据库引擎操作期间用于事务跟踪和恢复的数据库日志相同），并标识任何 INSERT、UPDATE 以及 DELETE 语句，或者对已标记为要复制的事务进行的其他数据修改。 然后，该代理将这些事务批量复制到分发服务器中的分发数据库中。 日志读取器代理使用内部存储过程 sp_replcmds 从日志中获取标记为要复制的下一个命令集。 这样，分发数据库就成为一个存储-转发队列，从该队列中将更改发送到订阅服务器中。 只有已提交的事务才能发送到分发数据库中。

当整批事务都成功写入分发数据库之后，将提交这批事务。 在每一批命令都提交到分发服务器后，日志读取器代理将调用 sp_repldone以标记最终完成复制的位置。 最后，代理在事务日志中标记可以清除的行。 仍在等待复制的行不会被清除。

事务命令在传播到所有订阅服务器或达到最大分发保持期之前，一直存储在分发数据库中。 订阅服务器按事务在发布服务器中应用的相同顺序接收事务。

分发代理

对于推送订阅，分发代理在分发服务器上运行；对于请求订阅，分发代理在订阅服务器上运行。 该代理将事务从分发数据库移动到订阅服务器中。 如果订阅被标记为需要验证，则分发代理还要检查发布服务器和订阅服务器中的数据是否匹配。 有关详细信息，请参阅验证已复制的数据。

SQL Server AlwaysOn架构及原理

   SQL Server2012所支持的AlwaysOn技术集中了故障转移群集、数据库镜像和日志传送三者的优点，但又不相同。故障转移群集的单位是SQL实例，数据库镜像和日志传送的单位是单个用户数据库，而AlwaysOn支持的单位是可用性组，每个组中可以包括一个或者是多个用户数据库。也就是说，一旦发生切换，则可用性组中的所有数据组会作为一个整体进行切换。

   AlwaysOn底层依然采用Windows 故障转移群集的机制进行监测和转移，因此也需要先建立Windows Cluster，只不过可用性组中的数据库不一定非要再存放在共享存储上了。可以是存储在本地磁盘上。

   下面，先看一下AlwaysOn的关键特性：

   1. 同故障转移群集一样，也需要一个虚拟网络名称用于客户端的统一连接。

   2.一个主服务器可以最多对应四个辅助服务器，总数达到五个，而且辅助服务器支持只读功能。

   3.辅助服务器可以独立执行备份和DBCC维护命令。通过配置，可以实现客户端的只读请求可以被自动定向到辅助服务器。

   4.主服务器和辅助服务器之间的数据会被加密和压缩，以提高安全性和网络传输效率。

   5..支持自动、手动和强制三种故障转移方式。

   6.有仪表盘用于监控AlwaysOn的运行状态。

   7.可以实现多站点的部署，即主站点和辅助站点可以跨物理网络。

AlwaysOn的基本架构

   在Windows MSCS故障转移群集的基础上部署AlwaysOn高可用组，用户可以在群集节点上安装SQL Server单机实例，也可以安装SQL Server群集实例，AlwaysOn仅要求所有SQL Server实例都运行在同一个MSCS中，但SQL Server实例本身是不需要群集模式的，这与SQL Server2008 群集的实例完全不同。在此推荐使用单机模式的SQL Server，好处是：可用性副本是个单机实例，那么数据库副本就存放在该运行该实例节点的本地磁盘上；如果可用性副本是个群集实例，那么数据库副本就存放在共享磁盘上。

   可用性组从Windows群集角度来看，就是一个群集资源，其中的所有数据库作为一个整体在节点间进行故障转移，当然这不包括系统数据库，系统数据库是不能加入高可用性组中的。

   因为需要借助Windos群集实现监控和转移，所以AlwaysOn会受到一些限制：

   一个可用性组中的所有可用性副本必须运行在单一的Windows群集上，跨不同Windows群集的SQL Server实例不能配置成一个AlwaysOn可用性组。

   一个可用性组的所有可用性副本必须运行在Windows群集的不同节点上。运行在同一个节点上的两个不同实例不能用作同一个可用性组的副本。

   如果某个可用性副本实例是一个SQL群集实例，那同一个SQL群集的其他非活跃节点上安装的任何其他SQL实例都不能作为它的辅助副本。

   一个数据库只能属于一个可用性组。

   AlwaysOn最多可以支持五个副本，但只有一个可用性副本上运行的数据库是处于可读写状态。这个可读写的数据库被称为主数据库（PrimaryDatabase），同时这个可用性副本被称为主副本（primaryreplica）。其余的副本都被称为辅助副本（secondaryreplica），辅助副本上的数据库可能是不可访问的，或者是只能接受只读操作（取决于可用性组的配置），这些数据库被称为辅助数据库。一但发生故障转移，任何一个辅助副本都可以成为新的主副本实例。主副本会不断地将主数据库上的数据变化发送到辅助副本，来实现副本间的数据库同步。下图就显示了一个可用性组中各副本之间的关系。

   下面，咱们再通过一个图看 一下AlwaysOn可用性组与Windows故障转移群集之间的关系，在这个图中，Windows的故障转移群集使用到了两个子网，在左边的子网里，有两个节点 ；右边的子网里有三个节点，其中最右边两个节点上创建了一个SQL Server的群集实例，存放于共享存储；其他三个节点安装的是单机实例，存放于本地存储；一共四个实例组成了一个AlwaysOn可用性组，其中一个主副本，其他的都是辅助副本。

侦听器

   AlwaysOn创建后，客户端就需要进行连接，为了让应用程序能够透明地连接到主副本而不受故障故障转移的影响，我们需要创建一个侦听器，侦听器就是一个虚拟的网络名称，可以通过这个虚拟网络名称访问可用性组，而不用关心连接的是哪一个节点，它会自动将请求转发到主节点，当主节点发生故障后，辅助节点会变为主节点，侦听器也会自动去侦听主节点。

一个侦听器包括虚拟IP地址、虚拟网络名称、端口号三个元素，一旦创建成功，虚拟网络名称会注册到DNS中，同时为可用性组资源添加IP地址资源和网络名称资源。用户就可以使用此名称来连接到可用性组中。与故障转移群集不同，除了使用虚拟网络名称之外，主副本的真实实例名还可以被用来连接。

   SQL Server2012早期版本的SQL Server只有在实例启动的时候地会尝试绑定IP和端口，但是SQL Server2012却允许在副本实例处于运行状况的时候随时绑定新的IP地址、网络名称和端口号。因此可以为随时为为可用性组添加侦听器，而且这个操作会立即生效。当添加了侦听器之后，在SQL Server的错误日志中可以看到类似：在虚拟网络名称上停止和启动侦听器的消息。

   要注意的是，SQLBrowser服务是不支持Listener的。这是因为应用程序在使用Listener的虚拟网络名连接SQLServer时，是以一个默认实例的形式进行访问的（只有主机名，没有实例名），因此客户端根本就不会去尝试使用SQLBrowser服务。

各副本间的数据同步

   AlwaysOn必须要维护各副本间的数据一致性，当主副本上的数据发生变化，会同步到辅助副本上。这里AlwaysOn通过三个步骤来完成：

步骤1：主副本记录发生变化的数据；

步骤2：将记录传输到各个辅助副本；

步骤3:把数据变化操作在辅助副本上执行一遍。

具体实现如下：

   在主副本和辅助副本上，SQL Server都会启动相应的线程来完成相应的任务。对于一般的SQL Server服务器，即没有配置高可用性，会运行Log Writer的线程，当发生数据修改事务时，此线程负责将本次操对应的日志信息记录到日志缓冲区中，然后再写入到物理日志文件。但如果配置了AlwaysOny主副本的数据库，SQL Server会为它建立一个叫Log Scanner的线程，不间断的工作，负责将日志从日志缓冲区或日志文件里读出，打包成日志块，发送到辅助副本。因此可以保证发生的数据变化，不断送给各辅助副本。

  辅助副本上存在固化和重做两个线程完成数据更新操作，固化线程会将主副本Log Scanner所发过来的日志块写入辅助副本磁盘上的日志文件里，因此称为固化，然后重做线程负责从磁盘上读取日志块，将日志记录对应的操作重演一遍，此时主副本和辅助副本上的数据就一致了。重做线程每隔固定的时间点，会跟主副本通信，告知自己的工作进度。主副本由此知道两边数据的差距。Log Scanner负责传送日志块，不需要等待Log Writer完成日志固化；辅助副本完成日志固化以后就会发送消息到主副本，告知数据传输完成，而不需要等待重做完成，这样各自独立的设计，是尽可能减少 AlwaysOn所带来的操作对数据库性能的影响。