3

好的，我们在 SQL Server 2008 中有关键事务数据库及其处于完全恢复模式。我们在两个不同时区的两个不同数据中心有两台不同的服务器。而且我正在尝试使用各种选项设置使数据库尽可能最新的最佳方法。数据库目前只有 1.5GB，预计每 6 个月增长 1GB。

我们使用了一个简单的解决方案，即在凌晨 1 点使用 SMO 创建 FULL Backup，然后每 15 分钟进行一次差异备份。我们将这些数据传输到作为从属服务器工作的其他服务器，并在从属服务器上恢复数据。因此，与当前 DB 相比，所有从站都运行了 15 分钟，所以在崩溃的情况下，我们将拥有直到最后 15 分钟的数据。

现在我想比较这个解决方案的复制和更改跟踪。

Replication 和 Change Tracking 都在 DB 中添加了一些额外的元数据来完成他们正在做的所有事情，并且很少额外使用 cpu。但是，与 Diff Backup 相比，它们不会在 CPU 上增加更多负载（据我所知）。我假设 Diff Backup 将使一些事务等待或增加一些待处理的队列，这可能会在用户使用它时造成延迟或信息丢失。

我需要知道 Diff Backup 每 15 分钟会增加服务器的负载吗？或者在处理事务时每 15 分钟使用一次差异备份真的不建议？

注意：事务仅在主服务器上应用，它们通过备份恢复应用到从属服务器。日志传送不传送架构更改，如果它停止工作，我们无法收到任何错误通知，在我们自己的自定义解决方案中，我们会通过电子邮件收到日志对我们有帮助。

4

2 回答 2

8

忘记复制或更改数据跟踪。那些不会复制模式，并且会增加大量开销。两者都不是高可用性或灾难恢复解决方案。它们可以这样使用，但与日志传送、数据库镜像或硬件镜像等专用解决方案相比显得苍白无力。

日志传送传输数据库中的所有内容，包括架构，以及用户、权限、索引、数据等。您没有指定何时传输日志备份。每 15 分钟做一次差异备份听起来有点矫枉过正。差异备份是累积的，它们包含自上次完整备份以来的所有更改，因此它们的大小会在一天中增加。15 分钟听起来像是定期日志备份的时间段，而不是差异备份。

日志传送依赖于 SQL 代理作业的文件复制操作。因此，它需要访问文件共享并且需要身份验证。在不同的域上，您需要直接访问或某种 VPN。

数据库镜像也在创建数据库的相同副本，但它的数据丢失窗口长达几秒钟，而不是日志传送中的日志备份间隔。数据库镜像保持两台服务器之间的特殊连接打开，并且主体将每个事务实时发送到镜像。由于镜像端点支持基于证书的身份验证，因此可以轻松设置跨域并且不需要VPN。DBM 可以是同步的（主体上的每个事务在提交之前等待镜像确认，也就是高安全模式）或异步（主体将在镜像之前写入并立即提交，也就是高性能模式）。如果连接丢失，主体将开始“暴露”运行，因此您不会丢失服务，但会使您自己面临数据丢失的风险。一旦恢复连接，主体将向镜像提供待处理的事务队列（即尚未传送的 LDF 文件部分），直到镜像恢复为最新状态。所有这些都是自动的，SSMS 中的监控工具可以设置为在连接丢失、主体运行暴露时、未发送队列增长超过预设大小时发送通知。

硬件镜像：您需要与硬件供应商或您的数据中心运营商交谈。这要花一大笔钱。

到目前为止，整体数据库镜像是您的最佳选择。

于 2009-09-05T17:32:58.320 回答
0

我们找到了自己的解决方案如下，

  1. 镜像和日志传送都需要 VPN 和高安全性所以我们抛弃了它们。
  2. SQL Server 的镜像和日志传送以及几乎所有的同步方法真的不关心网络带宽的使用，它们不压缩任何东西。

MSDN 说差异文件备份更快，我们选择了差异文件备份。是的 15 分钟，它看起来有点矫枉过正，但它们是最快和更可靠的。而 24 小时内，累积的变化只有几 MB。

备份由自定义 Windows 服务进行，并且它们也被压缩以节省网络传输。另外，我们会收到有关所有内容的适当电子邮件通知。

加上从数据库可以在互联网上的任何地方。备份是安全的并使用密码压缩。内置 Web 服务器中的小型 HTTP 将数据从一台机器传输到另一台机器，因此需要较少的配置开销。

当我们有很多服务器时，配置它们是巨大的痛苦。此外，每个网络管理员都可能犯错误并造成灾难。

于 2009-09-06T07:57:15.820 回答