SQL Server高可用——日志传送（4-1）——概论

本文作为学习总结，部分内容出自联机丛书及其他书籍

日志传送是什么？

SQLServer 2012之前（2012出现了AlwaysOn），SQLServer存在四大高可用（集群/群集、日志传送、镜像和复制）。本主题主要讨论其中的日志传送功能。但是由于工作原因，只能谈论到使用级别，不做太深入的研究。

现在先来说说日志传送（Log Shipping）是什么？

它是高可用的其中一种，可以搭配其他高可用实现更有效的备份机制。而且从2000(2000之前是否存在就不考究了)就已经有该功能。证明它的可用性非常好。值得保留。由于本人工作的是2008R2，所以这里只拿2008R2做例子，2008几乎是一样的。

日志传送具有低成本、高效和简单且能保持业务连续性的特性。使得其一直都是中小型企业甚至某些大型企业在实现高可用时会考虑的解决方案。

但是所有的据我个人经验，在数据库领域（其他的我不评论），没有什么绝对，有好的地方就会存在不好的地方。要取得一个平衡才是硬道理。日志传送当然也有其不足的地方，就是带宽。无论在同一个物理位置还是不在同一个物理位置，网络传输日志的速度要足够的快。

日志传送的使用情景：

作为热后备服务器：

高可用的本质就是“冗余”，而冗余的最现实的实现就是备份。由于DBMS的结构，日志往往会更加大，也更加重要，所以高可用往往都是针对日志的。当使用日志传送作为热备的时候，可以在主服务器宕机的后【手动】转移到辅助服务器。使其能够尽可能地保持业务连续。高可用中，集群和镜像是可以自动转移。但是日志传送和复制是一个手动过程。需要人工干预，但是集群配置和使用都相当复杂，这就导致了它的局限性。至于镜像，后续再谈。

同时，由于日志传送建立在日志基础上，所以可以在误操作的时候“有可能”恢复到某一时刻。

最后，集群是服务器级别的解决方案，是整个实例的故障转移，但是其他3个高可用是数据库级别的解决方案。可以指定某些库故障转移。

作为灾难恢复解决方案：

灾难恢复是高可用最主要的目的。在日志传送中，最大的瓶颈和上面说的一样，就是网络带宽。由于各个高可用方案有其不足和优点，所以一般不会单纯用一种方式来保证业务连续性。

作为报表系统解决方案：

为减少主服务器的压力，可以在辅助服务器上创建报表服务器，前提是数据库的恢复模式为standby。但是在还原过程中库是不可访问的，这也会影响客户的使用。如果不实时更新，那么数据也是非实时的，且上面的数据是只读。这些会影响正常的报表使用，所以除非比较特殊的应用情景之外，这个不是作为报表系统的好的解决方法。

日志传送体系：

日志传送一般要3台服务器，也最好有3台，这样能分摊压力。也能在主服务器当掉的时候，监控服务器能正常起作用。由于我是用虚拟机来做，所以基本上不存在资源问题，也就按照最好的方法来配置，也就是分开3台服务器。

主服务器：

日志传送需要在主服务器上运行SQL代理作业，以便把事务日志备份到文件中。并且主服务器上处于日志传送状态的数据库恢复模式必须为大容量日志或者是完整恢复模式。

辅助服务器：

是备份文件还原的目标服务器，也成为备份服务器，当主服务器出现问题时，此台服务器就会起作用。成为主服务器继续供客户使用，但是这个过程是手动的。辅助服务器上同样有SQL代理作业，一个是用于复制备份文件夹下的日志文件，另外一个是用于还原。从图上可以看出备份文件是由主服务器提供。同样辅助服务器上的库的恢复模式要与主服务器的库相同。

监控服务器：

监视服务器是可选的，但是如果资源足够，还是建议配置一台监视服务器，理由已经在上面说明。一个监视服务器可以监控多个日志传送环境，如果没有，那么主服务器要承担它的责任。从而加重了负担。

环境要求：

网络：

首先3台机都要在一个能互访的网络里面。并且主服务器要能够访问备份文件夹（不然文件无法写入），辅助服务器要能从这个文件里面复制到它自己的本地。监视服务器必须能够同时访问这两台服务器。最好的方法是使用独立的网卡，如果没有，也要保证带宽足够。否则延时将导致辅助服务器的某些不可预知的问题。

服务器性能：

由于辅助服务器可能需要接管主服务器的工作，所以性能方面要最起码相等，甚至要更好。

存储要求：

由于日志传送和集群有所不同，没有要求必须有共享磁盘，而且由于主服务器和辅助服务器可能不在统一物理位置，所以也不太可能有共享磁盘系统。

监控服务器：

监控工作其实耗费的资源很少。可以部署在主服务器或者其他服务器上，但是为了获得高概率的生存机会（也就是不至于同时宕机）。还是建议放到独立于主服务器和辅助服务器的机器上。

软件：

SQLServer 2008企业版、标准版、工作组版均支持日志传送。且都必须要为大容量日志模式或者完整模式。

下篇将介绍 日志传送部署