SQL Server日志传送log shipping

SQL Server的日志传送（log shipping）技术一直比较鸡肋，尤其当SQL Server 推出了Always On技术以后，估计使用日志传送（log shipping）这种技术方案的企业越来越少，但是日志传送也有自己的一些优点，有些特殊场景或业务背景下也有其存在的价值。最近由于特殊业务场景可能需要用到这个技术，所以做了一些测试和验证，比对一些知识做了一下总结、归纳。下面有部分内容从官方文档摘抄。此篇是总结性内容。如有不足，敬请指点！

日志传送（Log Shipping）介绍

SQL Server使用日志传送，可以自动将“主服务器”实例上“主数据库”上的事务日志备份发送到“辅助服务器”实例上的一个或多个“辅助数据库”。 

事务日志备份分别应用于每个辅助数据库。 可选第三个服务器实例（称为“监视服务器 ”）记录备份和还原操作的历史记录及状态，还可以在无法按计划

执行这些操作时引发警报。

事务日志传送提供了数据库级别的高可用性保护。日志传送可用来维护相应生产数据库（称为“主数据库”）的一个或多个备用数据库（称为“辅助数据库”）。发生故障转移之前，必须通过手动应用全部未还原的日志备份来完全更新辅助数据库。日志传送具有支持多个备用数据库的灵活性。如果需要多个备用数据库，可以单独使用日志传送或将其作为数据库镜像的补充。当这些解决方案一起使用时，当前数据库镜像配置的主体数据库同时也是当前日志传送配置的主数据库。

日志传送的拓扑结构图如下所示：

优点：

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

         支持对辅助数据库的受限的只读访问权限（在还原作业之间的间隔期间）。可做简单的读写分离。

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

缺点：

        容易出现异常，导致数据不一致。而且出现异常后基本无法补救，需要重新初始化。

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

        没有自我纠错、自我验证的处理机制。

        数据同步有延迟。

相关术语（摘自官方文档）

主服务器 (primary server)

   位于生产服务器上的SQL Server实例。

主数据库 (primary data )

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

辅助服务器 (secondary server)

   想要在其上保留主数据库的热备副本的SQL Server实例。

辅助数据库 (secondary data )

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

监视服务器 (monitor server)

   跟踪日志传送的所有详细信息的SQL Server的可选实例，包括：

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

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

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

备份作业

一种SQL Server代理作业，它执行备份操作，将历史记录信息记录到本地服务器和监视服务器上，并删除旧的备份文件和历史记录信息。