Val*_* F. 23 sql-server migration mirroring restore log-shipping
问题定义
我们的数据库服务器需要转移到另一个数据中心。它运行在 Microsoft SQL Server 2012 Enterprise（64 位）上，包含两个大约 2TB 和 1TB 的数据库。
几乎没有停机时间将是理想的。
工作量
这些数据库用于 .NET 网站，并且会不断更新。
不过，周末不可用也是可以接受的。当前使用的数据库将一直是唯一使用的数据库，直到切换到新数据库。
理想情况下，只需将 DNS 条目更改为指向新的数据库服务器，同时确保数据库未更新，即可实现该切换。
此外，只要从一台服务器切换到另一台服务器（停机时间）保持在较低水平，此操作所花费的时间并不重要。
考虑的方法
备份还原
过去曾这样做过，但即使是通过内部网络完成的，停机时间也很长，因此比通过 Internet更有效
日志传送
据我所知，这种方法可以通过配置主/从并将主数据库的精确副本传输到其只读从属来最大限度地减少停机时间。如上所述，不需要访问从属数据库，我们只需要一种方法来拥有主数据库的副本而不会损坏数据。
它在资源利用方面似乎也非常有效，并且不会对主性能产生太大影响。
我可能对这种方法有误，因此请随时纠正我。
数据库镜像
我不太了解这种方法，但它似乎是一个有效的选择。不需要实时同步，主节点的性能非常重要，因此如果选择这种方法，异步将是可行的方法。
其他选择？
该服务器直接在裸机硬件上运行，因此不幸的是，不能选择较低级别的解决方案。也许有更好的方法来完成这项工作？
约束
如上所述，这些数据库非常大，以至于难以维护，但这是另一个问题。
SQL Server 的版本将相同（Microsoft SQL Server 2012 Enterprise 64 位）。
它必须在两个数据中心之间通过网络传输，因此很可能通过 Internet 传输。不幸的是，将磁盘从一个站点发送到另一个站点进行初始同步并不是一种选择。为转移提供某种安全性是理想的，但我们会在这种情况下做到最好。
这应该很好地概述了我们对这项任务的需求，希望你们中的一些人以前不得不面对这种情况。
Aar*_*and 21
直接备份和恢复显然是不行的。我也不会考虑任何形式的复制。
数据库镜像的设置相对简单，但需要两台服务器之间的实时连接、设置合作伙伴和端点等。可用性组可能是一种选择，但除了网络复杂性之外，您还必须同时拥有两台服务器作为同一个 WSFC 的成员 - 这意味着他们必须都在同一个域中。这不是数据中心迁移的典型设置（或者甚至可以临时工作）。
我的投票将是原木运输。这样做的好处是您可以使用您已经进行的备份和日志备份（对吗？），并且不必在两个数据库之间建立实时连接——它们不需要了解每个数据库另外，您不需要为镜像、合作伙伴、安全等设置端点。您只需要一种方法将文件从旧服务器获取到可以在新服务器上恢复的位置。您可以提前做好完整备份，将其转移到新服务器上，将其恢复，然后从该点到切换时应用（可能是差异和）增量日志备份。该过程实际上非常简单，如果您遇到任何困难，可以在网上找到许多有关日志传送的教程。
如果 Web 应用程序与数据库一起移动，因为 DNS 可能需要一段时间才能传播，您可能希望在旧应用程序的连接字符串中进行切换，以便在新数据库服务器可写后使其指向新数据库服务器的 IP ，因为 - 即使在切换之后，即使您的 TTL 设置很紧 - 客户端可能会继续访问旧的 Web 服务器。这完全取决于他们的提供商对您的 TTL 的尊重程度。
Eri*_*ing 17
我最近使用镜像在 6 个数据库中迁移了 15tb。非常简单，只需几秒钟的故障转移时间即可完美运行。
编辑：
我有两个新的虚拟化 SQL Server。数据库来自 3 台服务器，它们刚刚完全长大，并且正在影响托管在其上的较小数据库的性能。
这个过程非常简单。
我选择让它们处于异步模式，直到我们准备好对它们进行故障转移以减少网络负载等。镜像在维护（索引/统计）和其他高容量活动期间引起延迟有一定的声誉，但我没有发现这是真的。在手动故障转移之前，它们必须切换到同步模式。
在下一个维护窗口期间，我手动对每个数据库进行了故障转移，经过一些冒烟测试后，关闭了镜像，并最终从原始服务器中删除了旧数据文件。这个过程中的一个怪癖是镜像数据库失败会使前一个主数据库处于恢复状态，所以除非你很舒服地删除它们，否则你需要将它们重新联机然后分离，或者无论你喜欢的删除方法是什么. 此外，我没有为此配置见证，因为我不想要自动故障转移。这是一个受控事件。
如果您想了解更多详情，请告诉我。我省略了服务器和网络规范，但如果您愿意，可以提供。
谢谢