将数据库移动到新的数据中心

Sna*_*ken 8 sql-server-2005 sql-server migration sql-server-2014

我的公司正在将我们的基础设施迁移到新的数据中心,我正在尝试找出使新服务器上的数据库与当前生产数据库保持同步的最佳方法,直到新环境准备好投入使用。作为一名全职 DBA,我做了一些研究,从我所读到的内容来看,跨国复制设置似乎最适合我们的需求。

一些细节:生产数据库的大小约为 90 GB,使用 Robocopy 将其副本移动到其中一台新服务器需要大约 9 个小时。当前的生产数据库需要在整个迁移过程中保持在线和可访问。由于是简单恢复,所以数据库镜像不可用。

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

我的计划:

  1. (完成)将当前数据库和日志转移到新服务器并将其附加到 SQL Server 的新实例
  2. 在我们的开发数据库机器上设置一个分发器并从生产数据库发布到它
  3. 在新的数据库机器上创建一个订阅者,该订阅者将接受从分发者推出的更新,每晚一次

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

总的来说,我是否正确理解了这些概念?

Kin*_*hah 9

您目前的情况:

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

我看到你的方法有很多缺点:

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

根据我的经验,以下是我的建议:

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

您不必移动任何系统数据库。确保在手动之前完成所有准备工作 - 编写登录、作业、ssis 包等的脚本并在目标服务器上创建它们。

有关恢复后步骤和其他最佳实践,请参阅此答案

注意:您也可以实现数据库镜像(SYNC 或 ASYNC,具体取决于您使用的 sql server 版本),但日志传送实现起来很简单,如果您对其进行测试,它不会让您失望。我已经使用上述技术成功地将 TB 级数据库从一个数据中心移动到另一个数据中心,并且运行良好。

当前的生产数据库需要在整个迁移过程中保持在线和可访问。

总会有停机时间,您必须对其进行安排。即使您在集群等解决方案上投入大量资金,当您进行故障转移时,也会有一些停机时间。您必须平衡您的公司可以投资多少来实现接近零的停机时间与一些可接受的停机时间可用的停机时间。