主页 / dba / 问题 / 320939
Accepted
S M
Asked: 2022-12-14 16:46:24 +0800 CST

在 SQL Server 中交叉注册备份

  • 772

我的组织正在实施一个有趣的复制应用程序，以从多个 SQL Server 数据库中提取数据并将其放入 Azure 数据湖中。一些数据库位于可用性组集群中。我们的 AG 配置为在辅助副本上运行备份。

因此，我的团队被告知该应用程序需要备份元数据才能在 AG 成员之间同步。换一种说法：

  • 服务器 A 每 15 分钟对数据库 foo 进行一次事务日志备份
  • 服务器 B 每 15 分钟对数据库 bar 进行一次事务日志备份
  • 服务器 A，在其备份完成后，从 B 中提取事务日志备份元数据并将其添加到 msdb
  • 服务器 B，在其备份完成后，从 A 中提取事务日志备份元数据并将其添加到 msdb

这样，供应商说，无论数据库在哪个副本上，他们的应用程序都能够访问事务日志备份，并在无法跟上更改数据捕获时填补它可能存在的任何空白。他们提供的脚本使用 RESTORE VERIFYONLY…WITH LOADHISTORY 将备份元数据加载到 msdb 中。幸运的是，它只是任何给定 AG 上一个数据库的最新 t-log 备份。最起码到现在。

我们的 AG 集群没有用于备份的共享存储，因此来自其他副本的备份将以 UNC 路径显示。根据我的经验，人们很少使用 UNC 路径进行备份，我认为这是有充分理由的。

  1. 我应该对此有多担心？
  2. 这会造成多少资源争用？我对我们的一个 TB 大小的数据库的 t-log 备份进行了测试验证，并在几秒钟内完成，但我觉得我应该对此感到疑惑。
  3. 如果我们需要运行恢复，数据库服务器真的会尝试接触其他副本上的备份文件吗？
  4. 如果 #3 的答案是肯定的，有没有办法标记记录以便应用程序可以使用它但 SQL Server 会忽略它？我们通常不会将备份保留超过 72 小时（它们会被 NetBackup 窃取），所以希望这不是问题？
  5. 有没有比 RESTORE VERIFYONLY…WITH LOADHISTORY 加载元数据更好的方法？
sql-server

1 个回答

  1. Best Answer

    根据我的经验，人们很少使用 UNC 路径进行备份

    使用 backup-from-secondary强烈建议让所有副本将其备份放在共享网络位置。所以 UNC 路径是我通常希望使用的路径（在 Azure 中除外，您可能会使用备份到 URL）。

    如果我们需要运行恢复，数据库服务器真的会尝试接触其他副本上的备份文件吗？

    这就是将备份文件放在网络共享上的原因：因此可以在不知道哪个副本进行备份或直接连接到副本的情况下运行恢复。

    至于其余部分，这就是“仅通过加载历史记录恢复验证”的目的。

    • 1

相关问题