日志传送，SQL Server高可用性的重要举措

　　数据库高可用性是数据库选型考虑的主要因素之一，在微软的SQL Server数据库中，提供了很多高可用性的工具，而日志传送，是这些工具中的一个主角。若数据库管理员能够合理配置日志传送，则可以达到一个很高的可用性。本文中笔者结合自己公司的案例，介绍了在日志传送管理中该注意的问题与技巧。

　　若把用户在数据库选择时所需要考虑的因素进行一一排列，那么数据库的高可用性肯定是名列前茅的。所以，软件公司一直把如何提高数据库的可用性作为他们研究的主要课题之一。在微软的SQL Server数据库中，提供了很多高可用性的工具。而日志传送，是这些工具中的一个主角。若数据库管理员能够合理配置日志传送，则可以达到一个很高的可用性。或者说，可以把数据库的停机时间减少为零。

　　那么该如何来配置日志传送来达到这个目的呢?笔者就结合自己公司的案例，谈谈在日志传送管理中该注意的问题与技巧。

　　一、日志传送的三个角色与四个步骤。　

　　如上图，日志传送简单地说，就是通过上面的三个服务器角色与四个步骤来完成的。

　　第一步：备份日志。

　　主服务器会根据数据库管理员设置的备份计划，对事务日志按照计划进行备份。这是日志传送中的一个重要的内容。因为若主服务器的日志备份失败的话，则后续的工作都将无法进行。故我们往往需要对这个日志的备份进行监视，看看其是否按照数据库管理员所设想的方式在处理。为了达到这个目的，我们可以利用“监视服务器”来帮助我们监视这个作业。

　　第二步：日志文件传送。

　　当主服务器把日志备份好之后，主服务器就会根据数据库管理员的设置，把相关的日志文件自动传送给辅助服务器。在日志文件传送的过程中，主要需要考虑两个问题。

　　一是多久传送一次。一般情况下，对于数据库高可用性要求比较高的话，则可以在主服务器每次备份完事务日志后，就发送一次备份日志文件。不过，这要牺牲一定的网络带宽。这主要是根据企业的实际情况来处理。像笔者的企业，由于是SAAS模式的数据库租赁公司，所以，对于数据库可用性的要求非常的高。主服务器每次备份完成后，都会及时向辅助服务器传送备份日志。以达到辅助服务器与主服务器之间数据的同步。

　　二是做好日志文件传送的监督工作。准确、准时的把主服务器上的备份日志文件传送到辅助服务器上，这是辅助服务器正常运行的前提。为了让日志传送功能能够正常的运转，往往需要对日志文件的传送工作进行监督。需要通过监视服务器，来监视主服务器有没有把备份日志准时的发送出去;而辅助服务器有没有及时的接收备份日志。若出现异常的话，监视服务器需要利用消息或者邮件的方式通知数据库管理员。

　　第三步：辅助服务器还原事务日志。

　　当辅助服务器收到主服务器发送过来的备份日志后，就需要根据这个备份日志还原数据库。如此的话，当主服务器出现故障后，辅助服务器能够马上代替主服务器进行工作。所以，即使主服务器出现问题，用户也很难察觉到。

　　由于以上这三个作业都是通过计划来调度的，所以，这个还原作业也可以通过操作系统的任务计划来进行管理。对于辅助服务器的还原频率来说，需要数据库管理员进行合理的设置。在管理过程中，主要的问题就是数据同步与数据库设计管理方面的一个均衡问题。

　　这是因为日志传送是按照时间表进行的，故在主服务器与辅助服务器之间有个时间差。主服务器上的数据更改反映到辅助服务器上会有时间延迟。这个延迟有好处也有坏处。好处就是这些延迟可以用作还原用户错误的一种方法，因为可以延迟日志文件在辅助服务器上的应用，从而数据库管理员可以选择不采用错误的配置。但是，坏处也是很明显的。因为要通过日志服务器帮助数据库的高可用性的一个前提，就是要提高辅助服务器与主服务器之间的数据同步性能。而数据延迟会降低这个同步性。

　　所以，数据库管理员需要综合各种情形，来设置这个还原的频率。笔者是把这个数据同步看得更重。故数据库服务器与辅助服务器备份与还原的频率设置为三分钟。

　　第四步：警报。

　　警报虽然在日志传送中不是必须的，但其往往是日志传送正常运行的一个保障。他就好像是公路上的探头，当以上三个作业出现什么问题的时候，让数据库管理员可以马上知道，从而及时的采取措施，挽回损失。

　　具体的来说，需要对如下的作业进行监视。当出现不正常的情况时，及时通过信息或者邮件的形式向数据库管理员汇报。

　　1、 主服务器日志备份出现问题。如当主服务器延迟备份时，监视服务器就需要向数据库管理员报告相关的情况。

　　2、 备份日志传送出现异常情况。如辅助服务器没有及时收到备份的日志文件，监视服务器就会告知数据库管理员。此时，数据库管理员就需要去检查，看看是网络的问题，还是主服务器的问题。

　　3、 还原情况的监视。辅助服务器有没有按时对数据库进行还原;在还原的过程中有没有出现意外情况，都要及时的告知数据库管理员。如最常见的警报就是，当服务器没有按规定进行还原的时候，要触发警报作业。

　　二、日志传送的三个注意点。

　　在配置日志传送功能的时候，需要注意三大问题。否则的话，数据库管理员很可能无功而返。

　　一是多个数据库服务器如何设置辅助服务器。如笔者现在管理了九个数据库服务器，是否需要配备九个辅助服务器呢?若能够做到一对一的配置，那固然是好。但是，这浪费太严重。你若这么部署的话，可能会被你公司的总经理扫地出门。一般来说，企业中只要配备一个辅助服务器即可。因为很少会出现几个数据库主服务器一起当机的情况。笔者现在的九个数据库主服务器，只配置了两个辅助服务器，就可以满足数据库日志传送的需求了。

　　二是日志传送功能跟数据库的群集不一样。若采用群集功能，则当主数据库服务器出现故障的时候，系统会自动切换服务器，让辅助服务器代替主服务器来进行工作。但是，若利用日志传送功能的话，则无法达到这个目的。一般情况下，需要数据库管理员进行手工的切换。如当主服务器出现故障后，笔者预备的方案是，马上把主服务器从网络中撤下来，并且更改辅助服务器的设置，让其跟主服务器的设置一样。如此便不用更改客户端的配置，用户就可以连接到辅助服务器了。不过由于不能够自动进行切换，故数据库管理员要对这个转换方案进行测试。不能够等到真的出现问题了，再临时抱佛脚。

　　三是频率问题。由于日志传送的相关作业都是根据时间表来进行的。所以，数据库管理员需要根据公司的情况，对这个时间进行合理规划。因为频繁的备份、传送、还原会降低数据库的性能。若企业对于可用性的要求不高，如可以允许一个小时的当机时间，则可以降低这个频率。相反，像笔者这种从事应用软件租赁的企业，客户众多。若数据库出现故障的话，则会影响一大批用户。为此，对于数据库的可用性要求比较严格。所以，在这个频率上，就设置得比较高。这个频率没有固定的参考标准。数据库管理员要根据自己的企业的情况，结合自己的专业知识，做出合理的规划。