[MSSQL]总结log shipping 配置中容易出错的环节

        MSSQL的loggshipping给我的感觉是上手比较快，但是其中仍然有不少细节需要注意，否则配出来的环境一定会有问题。网上搭建logshipping的教程很多，但是鲜有将这些要点全部提出的，现在我总结于下： （logshipping具体搭建过程不再赘述）

1. MSSQL强烈不推荐在创建完实例后，再去更改主机名。

解析：

        使用虚拟机进行测试，且特别喜欢使用“克隆”的方式节省时间的同学一定会遇到。 如果我们预先在一个vm中安装好mssql服务，然后采克隆出1-2个vm，去做备机或者监控实例。那么至少我们需要去修改主机名的，否则vm之间一定会冲突。虽然mssql2008提供了更改@@servername的方式，但是官方仍然极力不推荐这样做的，这是设计导致的。

因此，正确的方式是规划、落实好主机名后，再依次安装mssql！ 或者克隆玩虚拟机后，使用sysprep进行操作系统初始化（机器名与操作系统SID都会重置）。

其实除了主机名重名，操作系统SID重名也会导致诸多问题，使用VM实验的同学要注意了。

2.MSSQL服务在安装之前，就需要做好帐号规划，最好使用专用的账户去启动相关服务，并且该帐号在共享文件夹有读写权限。

服务启动帐号示例：

共享文件夹权限示例：

解析：

         logshipping是借助windows共享机制进行文件传输的，但是我们容易忽略的是，相关操作是由sqlserver agent与sql server两个服务完成的，因此我们至少应该使用独立的操作系统帐号（例如这里是 sqladmin）去启动以上标注的服务，并且该帐号在共享文件夹必须有read/write权限。

3. 启动agent的帐号（sqladmin）必须加入mssql的sysadmin组。

操作示例：

解析：

         如果不加入sysadmin组，job仍然可能成功执行，但是在执行时会报“Only members of the sysadmin fixed server role can perform this operation”，相应的，会有alert出现。

4. 服务器之间时区与时间要一致，这个比较容易忽略。

5. 监控服务器建议使用专用的实例，并将被监控实例的agent帐号加入monitor instance的sysadmin group。

解析：实验表明，如果想偷懒使用DR instance兼任monitor instance的话，logshipping 报告一定抓取不到primary过来的日志传输记录。

6. 配置DR instance 与monitore instance时，建议使用主机名而非IP地址。

解析：实验表明，使用IP地址，多多少少也会带来日志传输记录不能被monitor的问题。

以上问题都处理好后，logshipping的report就很干净了：）