将数据库移至新数据中心

我的公司正在将基础架构移至新的数据中心，我正在尝试找出使新服务器上的数据库与当前生产数据库保持同步的最佳方法，直到新环境准备就绪。我不是一名全职的DBA，而是进行了一些研究，从阅读的内容来看，跨国复制设置似乎可以最好地满足我们的需求。

一些细节：生产数据库的大小约为90 GB，使用Robocopy大约需要9个小时才能将其副本移至新服务器中。当前的生产数据库将需要保持联机状态，并且在整个迁移过程中都可以访问。它的恢复很简单，因此数据库镜像不可用。

事务复制是保持数据库同步的最佳方法吗？

我的计划：

1. （完成）传输当前数据库并登录到新服务器，并将其附加到SQL Server的新实例
2. 在我们的开发数据库计算机上设置分发服务器，然后从生产数据库中发布该分发服务器
3. 在新的数据库计算机上创建一个订户，该订户将每晚每晚接受一次从分发服务器推出的更新

我有两件事。事务复制要求每个发布的表都有一个主键，生产数据库中的许多表都没有定义主键。我认为这不会成为太大的问题，因为我主要关心的只是同步数据库。我们将在以后的数据中测试使用数据库的不同应用程序，但我想确保它不是一个严重的问题。其次，是否还需要从原始实例（例如master）中移出任何关联的系统DB？我们将在新环境中迁移到Active Directory设置，因此我不在乎用户等，但是我不确定系统DB的必要性。

总体而言，我是否正确理解了这些概念？

您当前的情况：

• 您要移至新数据中心的90 GB数据库。
• 数据库处于简单恢复状态。
• 您正在考虑使用T-Rep保持数据同步。
• 数据库中有许多没有主键的表-这是发布任何表的必要条件。
• 您已经将备份复制到目标数据中心。

我发现您的方法存在许多弊端：

• 与其他技术相比，T-Rep不容易设置。如果有任何架构更改，则需要一个新的快照。
• 如果要使用T-REP，则必须进行架构更改-将主键添加到没有的表中。
• 对现有数据库进行任何更改，都必须对应用程序进行全面测试，以避免任何意外行为。
• 如果您的数据库有大量事务，并且取决于两个数据中心之间的网络带宽，那么复制延迟也将存在。

根据我的经验，以下是我的建议：

• 将数据库更改为完全恢复。与创建PK相比，这不是主要影响。
• 交付源数据库的完整备份-进行压缩备份并启用即时文件初始化。这将帮助您减少目标数据中心上的还原时间。
• 在目标服务器上还原数据库WITH NORECOVERY。
• 实现Logshipping并从备份中对其进行初始化。
• 每1分钟让logshipping发送一次日志。
• 在故障转移期间，请在源上进行最后的尾日志备份，然后使用将其还原到目标上WITH RECOVERY。这将使目标数据库联机。
• 目标数据库联机后，您必须同步用户。
• 您应该更改web.config使其指向新服务器。

您不必移动任何系统数据库。确保先进行所有准备工作-编写登录名，作业，SSIS包等脚本，然后在目标服务器上创建它们。

有关恢复后的步骤和其他最佳实践，请参考此答案。

注意：您也可以实现数据库镜像（SYNC或ASYNC，具体取决于您使用的sql server的版本），但是日志传送很容易实现，并且如果您对其进行测试，它也不会令您失望。我已经使用上述技术成功地将TB数据库从一个数据中心迁移到了另一个数据中心，并且它的运行情况非常好。

当前的生产数据库将需要保持在线状态，并且在整个迁移过程中都可以访问。

总是会有停机时间，您必须安排它。即使您在群集等解决方案上投入了大量资金，但当您进行故障转移时，也会有一些停机时间。您必须权衡您的公司可以投入多少资金来使停机时间几乎为零，而可以接受的停机时间却可以接受。

我自己没有机会使用它，我认为它仍处于预览状态，但是Azure平台上的SQL Data Sync可能是一个潜在的选择：

https://azure.microsoft.com/zh-CN/documentation/articles/sql-database-get-started-sql-data-sync/

它与本地以及Azure SQL数据库一起使用，似乎是使数据库保持同步的有用工具。