SQLServer 服务器架构迁移

原文:SQLServer 服务器架构迁移

最近服务器架构迁移，将原来的服务器架构迁移到新的服务器，新的服务器在硬件方面比之前更好！原来服务器使用双向同步，并且为水平划分到多个数据库服务器。迁移过程中，数据库方面涉及到数据一致性，帐号，重新划更多分区，规范索引，分布式查询，删除无效触发器等等。程序方面重新修改配置文件，SQL等。

原架构如图：

现在有相同的服务器，所有分库都迁移到新的服务器，再增加一台服务器作为独立的分发服务器。然而，总库已经没有多余的服务器了，怎么办？解决方法是 ，总库（DBA）中再安装一个数据库实例！这样，每台服务器都有对应了。为什么总库也要对应一个服务器？因为总库与分库有数据差异，用户使用的都是分库，所以原总库数据不能要！但是数据库名称仍然不变，所以只有新增一个实例了！总库不能要，怎么将分库数据汇总成一个完整的总库？过去使用过的方法，现在完整备份各分库还原到总库服务器并使用不同名称，停机维护时，将分库日志备份并还原到总库服务器中的各个分库，此时再使用merge与原总库对比，则原总库将会三一个完整的数据库。
但是，对比时间太长了！当前的方案是，将在各个分库建立事物发布，汇总到一个新实例中！（参考：SQL Server 中心订阅模型（多发布单订阅））

那么，整个迁移方案中，可以分为5个阶段：

第一阶段：前期阶段，计划方案，确定步骤，预先执行部分耗时操作；

第二阶段：停机前一两小时，预先准备，将步骤看清一边，预先执行可执行的操作；

第三阶段：停机维护中，更改分布式脚本；切换用户对数据库的访问；访问测试；

第四阶段：停机时间到，开启访问，重要的部分工作先完成；

第五阶段：接下来这一两天完成所有后续工作；并且观察数据库方面的性能；

切换架构如图：

上图中，上半部分是原架构，下半部分是新架构。考虑的问题较多！！同样分几个阶段处理：

第一阶段：

新服务器的和数据库的安装升级配置不必说了；

将总库备份还原到新实例，设置简单模式，并将里面的数据全部清空（truncate）并收缩数据库；

删除所有索引，批量创建主键；

添加文件及文件组，设置文件增长率；

重新划分更多分区，设置LOCK_ESCALATION ；

更改默认值约束，去掉无用触发器；

迁移登录帐号；

备份当前的空数据库，留着还原到新的分库中；

设置分发数据库；

原来的分库（db1~dbn）创建事物发布到新的总库中，只对表发布；（参考：SQL Server 中心订阅模型（多发布单订阅））

授予权限；

（新分库还原上面的空库并参考上面的一些步骤）

新总库创建发布到新分库中；

新分库设置完整模式并设置备份计划；

第二阶段：

链接服务器的更改；

停掉以前的复制；

禁止备份作业及其他相关作业；

检查同步情况；

对比没有汇总的一些参数表；

第三阶段：

停机维护启动；

检查同步情况及新旧数据库是否有差异（sysindexes）

更改sql脚本；

升级web配置文件

第四阶段：

授予开发人员权限；

部分权限修改；

观察系统运行情况；

第五阶段：

原总库数据库删除，新总库迁移到SSD盘；

辛苦备份计划创建；

作业转移或重建；

删除原分库到新总库的复制；

观察系统运行情况；

整个过程，方便的，几乎都用脚本来执行，因为脚本可以提前写好，可以计划好顺序。实际上，不出问题的话，停机维护时间可以不到半小时。总之，能其他做的先做，能往后做的后做，减少停机维护时间。