主页 / dba / 问题 / 25627
Accepted
billinkc
Asked: 2012-10-09 10:21:05 +0800 CST

SQL Server 数据库同步

  • 772

问题定义

我们的用户需要能够查询大部分是最新的数据库。数据最长可达 24 小时，这是可以接受的。使用生产副本获取第二个数据库并使其保持最新的成本最低的方法是什么？有没有我没有想到的方法？

工作量

我们有一个第三方应用程序用于监控股票交易活动。白天，作为各种工作流程的一部分，会发生许多小变化（是的，这笔交易是有效的。不，这是可疑的，等等）。晚上，我们执行基于大集合的操作（加载前一天的交易）。

当前的解决方案和问题

我们利用数据库快照。晚上 10 点，我们删除并重新创建快照。然后开始 ETL 处理。这显然对我们的磁盘造成了负担，但允许我们的用户在不锁定数据库的情况下查询数据库（他们使用 Access 前端）。他们在深夜和清晨使用它，因此他们会注意到停机时间。

这种方法的问题是双重的。第一个是如果夜间处理失败，这并不少见，我们要恢复数据库，这会导致快照被删除。另一个问题是我们的处理时间正在超过我们的 SLA。在发现查询写得不好和缺乏索引后，我们正试图通过与供应商合作来解决这个问题。数据库快照也是造成这种减速的罪魁祸首，当它存在与不存在时的速度差异就证明了这一点——我知道，这很令人震惊。

考虑的方法

聚类

我们打开了数据库集群，但这并不能满足使数据可用的需求，而且通常会使管理员的生活变得复杂。它已被关闭。

SQL Server 复制

我们上周开始研究复制。我们的理论是，我们可以建立第二个目录并与生产数据库同步。在 ETL 开始之前，我们将断开连接并仅在 ETL 过程完成后重新启用它。

管理员从快照复制开始，但他担心生成快照需要数天的高 CPU 使用率以及所需的磁盘消耗。他指出，它似乎在发送给订阅者之前将所有数据写入物理文件，因此我们的 .6TB 数据库将花费 1.8TB 的存储成本。此外，如果生成快照需要数天时间，则它不适合所需的 SLA。

在阅读了这篇精彩的文章之后，似乎 Snapshot 可能是初始化订阅者的方式，但之后我们想切换到事务复制以保持同步。我假设打开/关闭事务复制不会强制完全重新初始化？否则，我们将打破我们的时间窗口

数据库镜像

我们的数据库处于完全恢复模式，因此数据库镜像是一种选择，但我对它的了解甚至比复制还要少。我确实找到了表明“数据库镜像阻止直接访问数据，镜像数据只能通过数据库快照访问”的答案。

日志运输

听起来日志传送也可能是一种选择，但这是我一无所知的另一件事。它会是比其他任何解决方案（实施和维护）成本更低的解决方案吗？根据 Remus 的评论“日志传送允许对副本副本进行只读访问，但在应用收到的下一个备份日志时（例如每 15-30 分钟）将断开所有用户的连接。” 我不确定停机时间会转化为多长时间，这可能会导致用户有些焦虑。

微软同步

我只是在上周末听说过使用Sync，还没有调查过。我不想为像这个问题那样具有高知名度的东西引入新技术，但如果它是最好的方法，那就这样吧。

SSIS

我们在这里做了很多 SSIS，因此生成数百个 SSIS 包以保持辅助同步是我们的一种选择，尽管它很丑陋。我不喜欢这样做，因为我希望我的团队不要承担很多维护开销。

SAN“神奇”快照

过去，我听说我们的管理员使用一些 SAN 技术对整个磁盘进行即时备份。也许有一些 EMC 魔法可以用来制作 mdf/ldf 的超快速副本，然后我们可以分离/附加目标数据库。

备份还原

我认为我们每周进行一次完整备份，每晚进行一次差异，每 15 分钟进行一次 tlog。如果用户可以忍受 3-4 小时的完全恢复中断，我想这可能是一种方法。

约束

Windows 2008 R2、SQL Server 2008 R2（企业版）、VMWare v5 企业版、带有映射到 vmdk 文件的驱动器的 EMC SAN 存储、commvault 处理备份以及源目录中的 0.6TB 数据。这是我们内部托管的第三方应用程序。修改它们的结构通常是不受欢迎的。用户不能不查询数据库，并拒绝通过主动识别他们监控的表来完成工作而受到限制。

目前，我们的 DBA 纯粹是承包商。全职人员已经启航，我们还没有更换他们。应用程序管理员并不精通 SQL Server 事务，我们有一个存储/VM 管理员团队可以帮助/阻碍这项工作。开发团队目前不参与，但可以根据方法加入。因此，更易于实施和维护的解决方案将是可取的。

我，我在房子的开发方面，所以我只能提出方法，而不必处理管理方面的事情。因此，由于没有时间在管理鞍上，我不敢说一种方法优于另一种方法——根据论文，这一切看起来都很棒。我完全愿意按照你们建议的任何方向前进，因为在我看来，这只会让我作为一名 DB 专业人士更有价值。我有一辆独轮车，但没有可用的大屠杀斗篷。

相关问题

编辑

解决@onpnt 的问题

数据延迟接受

用户当前查看的数据最多滞后 24 小时。该数据仅是截至 2200 年的最新数据

给定一分钟、一小时和一天内的数据变化量 不确定如何量化。营业时间，可能每小时数百次更改。每晚处理，每个工作日数百万行

连接到二级

内部网络，独立的虚拟主机和专用存储

读取辅助实例的要求

Windows 组将具有对辅助所有表的读取权限

辅助实例的正常运行时间

没有对正常运行时间要求的严格定义。用户希望它始终可用，但他们愿意为此付费，可能不会那么多。实际上，我会说一天 23 小时就足够了。

对现有架构和所有对象的更改

不经常修改，对于表格对象可能每季度一次。对于代码对象，可能每月一次。

安全

没有特殊的安全需求。生产权限将匹配副本的权限。尽管在我看来，我们可以撤销用户对 prod 的读取权限，只允许他们读取副本……但这不是要求。

@darin海峡

恢复到快照可能是一种选择，但我认为他们没有追求它是有原因的。我会和管理员核对

@cfradenburg

我的假设是我们只会使用其中一种方法，但这是一个很好的点，恢复会破坏“其他”同步技术。他们正在研究使用 EMC 快照魔法。正如管理员所描述的，他们将在 1900 拍摄快照并将映像迁移到辅助节点的区域。这应该在 2200 年完成，然后他们将执行辅助数据库的分离和重新连接。

包起来

2012-10-29 我们评估了 EMC 快照魔法和其他一些复制选项，但 DBA 认为他们最能解决镜像问题。赞成答案，因为他们都提供了帮助并给了我很多选择以及“家庭作业”来调查。

sql-server sql-server-2008-r2

3 个回答

  1. Best Answer

    修改它们的结构通常是不受欢迎的

    复制很可能会被淘汰，在此之前我会放弃同步。（来自 Sync Framework 上的现实生活中的高事务性测试）

    如果 3-4 小时是您的数据延迟例外，那么日志传送可能是您在只读副本上的最佳选择。但是日志中发生了多少变化？发现要监控它，看看你需要多快和多少。

    如果您不能去镜像或升级到 2012 企业版，那将是一个不错的策略，如果您可以去企业版（如果没有的话）。

    SSIS 并不意味着只是转储数据，但它可以做到。但是，您在查找转换方面的研究太多了，而且该任务在时间和资源上会很昂贵。虽然，就像我说的，它可以做到。

    确实，基于回答几个问题，选择范围会明显缩小

    • 数据延迟接受
    • 给定分钟、小时和天的数据变化量 与辅助节点的连接
    • 读取辅助实例的要求
    • 辅助实例的正常运行时间
    • 对现有架构和所有对象的更改
    • 安全
    • 6

  2. 这将是您需要自己尝试以找到最有效的方法之一。复制可能很棘手，因此虽然可能没有直接的货币成本，但维护它会产生管理开销。

    要扩展日志传送，您不需要每 15-30 分钟恢复一次日志。如果您愿意，您可以每四个小时或每天一次。我实施的与此类似的解决方案是每周进行一次完整备份并还原到报告数据库（这可能需要一段时间，并且在周末发生）。在一周内进行差异备份，并且每晚将这些备份还原到报告数据库。用户需要在恢复之前启动，但由于报告数据库是一个营业时间应用程序，因此没有问题。数据是一天前的数据，根据您的要求，这应该不是问题。

    要为此使用数据库镜像，如果您尚未运行 Enterprise，您需要购买 Enterprise 才能使用快照。它也不会使数据 100% 保持最新，因为需要删除快照（意味着所有用户都需要退出）然后重新创建以获取新数据。但是，这将比日志恢复或我上面解释的方法更短。

    如果升级到 SQL 2012 是一个选项，则可以设置一个只读辅助数据库，该辅助数据库将与主数据库保持同步。我只提到这一点是因为它可能是最顺利的解决方案。

    • 4

  3. 尽管人们对事务复制很感兴趣，但这听起来很适合您的情况。几点注意事项：

    1. 您不必使用快照初始化订阅者。您可以备份发布者并使用它进行初始化。
    2. 您可以仅通过停止分发作业来暂停向订阅者传递命令（这只是分发者或订阅者处的普通 SQL 代理作业，具体取决于您将其设置为推送订阅还是拉取订阅）。请注意您在分销商处的保留，以便您保留足够的历史记录，以便您可以赶上。
    3. 您可以更改订阅者的索引以适应将在那里完成的工作负载（可能是报告类型），而不是根据需要接受来自发布者的索引（可能是 OLTP 类型）。
    • 4

相关问题