使用 SAN 复制/快照进行 SQL Server 灾难恢复？

Question

我们有一个在单个数据库服务器上使用 SQL Server 2008 的 Web 应用程序。所有存储都是本地的。在过去的一年里，我们一直试图让任何形式的 SQL Server 复制与我们的配置一起工作，但它不会。原因是因为我们有 2,000 多个不断更新的数据库（每个客户端一个），因此我们的测试表明所有形式的复制都过于占用资源。

每次我问这个问题时，人们都会关注我们有太多数据库这一事实。这是无法改变的（出于监管和其他原因），所以我想专注于我们如何复制数据。

我们被告知，一种选择是将所有数据移动到 SAN 并让 SAN 复制数据（或拍摄频繁的快照）。但是，如果我们的数据库服务器出现故障，在这种情况下是否存在数据库损坏的风险？是否可以利用复制到另一个 SAN 的 SAN 来提供合适的 DR 解决方案（在我们的例子中，我们最多可以丢失大约 30 分钟的数据，但我们不能丢失一整天的价值......即我们可以' t 去前一晚的备份）。

Answer 1

正如其他答案中提到的：

• 旧式数据库镜像和新式 AlwaysOn 需要线程，并且您肯定会用完 2000 个数据库的线程。我模糊地记得实际限制远低于 200 个数据库。（某处有关于此的白皮书，但我现在懒得去找它，这个答案已经超长了。）当然，每个实例 200 个数据库。理论上，您可以启动 20 个实例并在每个实例上运行 100 个数据库。管理所有这些会很麻烦，我怀疑管理所有这些实例之间的内存会很头疼。

• SQL Server 复制（复制表（或表的子集），而不是文件）并不是真正用于 DR。即使是少数数据库，也很难设置和管理。您可能需要更改数据模型才能使其正常工作，这可能意味着对您的应用程序进行更改。您需要一种自动化的方法来将相同的复制配置应用于 2000 个（大概相同或几乎相同）的数据库中的每一个。您需要用来配置复制的存储过程很混乱。通过 GUI 管理 2000 个配置为复制的数据库将是一场噩梦。当/如果您进行故障转移，您可能需要进行更改以使一切恢复正常。故障转移时间不是当您想要进行任何可以避免的挑剔更改或工作时。您希望尽快恢复并运行所有内容。

• SAN 存储单元之间的复制可能很昂贵，尤其是当您谈论来自 EMC 等设备的硬件时。一旦您开始与供应商合作，您就可以在升级、维护、额外空间等方面与他们结婚。

建议 #1： 您是否看过类似 Steeleye 的 DataKeeper 之类的东西？它是一种基于软件的复制产品，可在利用 Windows 故障转移群集的服务器上运行。我从未真正使用过它，除了参加一些狗和小马表演之外，我与公司没有任何联系。它看起来很适合您的情况。

建议#2： 如果是我而且我完全没有预算，我会考虑一些本土的日志传送系统。我怀疑内置的日志传送能否很好地处理 2000 个数据库。编写日志传送系统并不难，它可以解决您环境中的所有特定问题。（例如，您可能需要通过 sftp 将文件发送到您的 DR 站点。）

基本上，系统分为三个部分。每个部分都需要定期运行：

• 一部分进行事务日志备份，将每个数据库的 tlog 备份文件放入不同的文件夹（用于文件系统扩展）。我不会为此使用维护向导，我已经多次看到它变得不稳定并开始跳过数据库并且通常行为不端。如果您想提供 30 分钟的保证，可能每 15 分钟运行一次。

• 其中一部分将备份文件从暂存区复制到您的 DR 站点。如果您的 DR 有 VPN，这可能就像 robocopy CMD 文件一样简单。如果您需要更高级的东西（sftp 或 ssh/scp，或者如果您没有内置备份压缩，则可以使用 zip/unzip），您可以编写一个包或一个 powershell 脚本。这可以运行得更快，也许每 5 分钟一次，以确保它得到一切。一旦某些东西被异地复制，它就是“安全的”。

• 一部分将它在 DR 站点找到的 tlog 备份还原到您的辅助服务器上。您需要确保确定已恢复的 tlog 并将它们移出或按某个计划删除它们，否则您最终将耗尽空间。这不需要那么频繁地运行，但您需要确保它已在所有可用的 tlog 备份上运行，然后在出现问题时宣布 DR 次要“活动”。

您想要审核所有三个步骤的表，一些报告/脚本显示发生了什么（是在您的主站点或辅助站点上运行的特定数据库？在辅助站点上是否有任何数据库在两个小时内没有看到 tlog 恢复？ ) 和警报方案。

最重要的是，我还希望能够选择特定的数据库进行故障转移以及能够对所有内容进行故障转移。能够选择一个数据库进行故障转移允许轻松测试（您对测试数据库进行故障转移，而不是客户的数据库），并且如果您遇到扩展问题，可能会给您一个基本的负载平衡方案。您还需要一种在主服务器和辅助服务器之间“重新同步”的自动化方式（从主服务器获取完整备份并将其应用到辅助服务器、启动 tlog 流等）。这些功能对于 2.0 版可能更好。

（每个人都忘记了 MS 支持的最早的 tlog 传输是通过一些脚本实现的，您可以在 SQL 7.0 上下载和运行这些脚本。有 GUI，UI 是一些 SQL 报告和一些存储过程。）

除了编写一些 tsql 代码之外，这里的挑战是：

• 更改为完整恢复模式（在我看来，您可能正在以简单恢复模式运行）以及可能用于日志备份的存储使用量的增加、数据库大小的增加等。

• 确保您的存储系统可以处理频繁 tlog 备份的负载，并及时将它们复制到 DR 站点。IOW，如果您有 2000 个数据库并且想要保证直到最后一小时的数据，您需要能够对这 2000 个数据库中的每一个进行一个事务日志备份并将其放入网络存储（不在您的主服务器中的某个地方） ）。

• 确保一切正常。

在我完成所有这些工作后，我将开始研究自动化故障转移，如何告诉我的网站特定客户数据库的实时版本在何处运行，等等。如果您没有运行集群系统，请确保您保持所有登录名/密码、工作、链接服务器等同步是一个 PITA。