问题标签 [replication]

我正在使用 SQL Server 2000，并且我有两个数据库，它们都复制（事务推送订阅）到单个数据库。我需要知道记录来自哪个数据库。

所以我想将发布中指定的固定列添加到我的表中，这样我就可以知道该行来自哪个数据库。

我该怎么做呢？

我想避免更改主数据库，主要是因为我需要这样做很多表。我希望有一些内置的复制功能可以在某些地方为我做到这一点。除此之外，我会采用视图的想法。

我正在构建一个解决方案，该解决方案将部署在全球多个地区的多个数据中心，每个数据中心都有一个在每个地区主动更新的数据副本。我将在每个数据中心拥有多个数据库和文件系统的组合，其状态必须保持一致（在数据中心内）。这些多个存储库将以 SOA 服务层为前端。

我可以容忍复制中的一些延迟，并且需要允许区域离线，然后再赶上。

鉴于数据的多个后端存储库，我不能轻易地依赖每个独立的复制解决方案来保持一致的状态。因此，我导致在应用层实现复制——通过以某种方式复制 SOA 请求。我需要确保不会发生复制循环，并且最后一个写入器条件已正确排序。

根据您的经验，解决此问题的最佳模式是什么，是否有值得研究的好产品（免费或其他）？

现在我在 PostgreSQL 中有一个数据库（大约 2-3 GB），它用作类似 RoR/Python LAMP 的应用程序的数据存储。

有哪些简单且强大的工具可以将主数据库复制到第二台机器？

我浏览了一些包（Slony-I 等），但如果能听到真实的故事也很棒。

现在我不关心负载平衡等。我现在正在考虑使用简单的 Write-Ahead-Log 策略。

我错误地从用于合并复制的 MS SQL 2000 表中删除了所有行（该表在发布者上）。然后，我使用 DTS 操作从备份数据库中检索行并重新填充表，从而使问题更加复杂。

这产生了以下问题：删除操作在客户端上将行标记为删除，但 DTS 操作绕过复制触发器，因此导入的行不会在订阅者上标记为插入。实际上，订阅者会丢失数据，尽管它在发布者上。

所以我认为“不用担心”我会再次删除这些行，然后通过插入语句正确添加它们，然后它们将被标记为在订阅者上插入。

这是我的问题：我无法删除 DTSed 行，因为我收到“无法在具有唯一索引 'uc1MSmerge_tombstone' 的对象'MSmerge_tombstone' 中插入重复的键行”。错误。我想做的是绕过合并复制触发器以某种方式从表中删除行。这可能吗？我不想删除并重做复制，因为订阅者是 50 多个 Windows 移动设备。

编辑：我已经尝试过 Truncate Table 命令。这会出现以下错误“无法截断表 xxxx，因为它是为复制而发布的”

Thinking about a Windows-hosted build process that will periodically drop files to disk to be replicated to several other Windows Servers in the same datacenter. The other machines would run IIS, and serve those files to the masses.

The total corpus size would be millions of files, 100's of GB of data. It'd have to deal with possible contention on the target servers, latent links e.g. over a WAN, cold-start clean servers

Solutions I've thought about so far :

• queue'd system and daemons either wake periodically and copy or run as services.
• SAN - expensive, complex, more expensive
• ROBOCOPY, on a timed job - simple but effective. Lots of internal/indeterminate state e.g. where its at in copying, errors
• Off the shelf repl. software - less expensive than SAN but still expensive
• UNC shared folders and no repl. Higher latency, lower cost - still need a clustering solution too.
• DFS Replication.

What else have other folks used?

我在 MySQL 5.0.45 上运行了几个数据库，并试图让我的旧数据库与修改后的模式同步，这样我就可以同时运行这两个数据库。我通过向新数据库添加触发器来做到这一点，但我遇到了复制问题。我的设置如下。

服务器“主”

• 数据库“legacydb”，复制到服务器“slave”。
• 数据库“newdb”，具有更新“legacydb”且没有复制的触发器。

服务器“奴隶”

• 数据库“legacydb”

我对“newdb”的更新运行良好，并触发了我的触发器。他们在“主”服务器上更新“legacydb”。但是，这些更改不会复制到从属服务器。MySQL 文档说，为简单起见，复制在"SELECT DATABASE();"决定复制哪些查询时会查看当前数据库上下文（例如），而不是查看查询的产品。我的触发器是从数据库“newdb”的上下文中运行的，因此复制会忽略更新。

我尝试将更新语句移动到“legacydb”中的存储过程。当我连接到“master”并手动运行时，这工作正常（即数据复制到从属）"USE newdb; CALL legacydb.do_update('Foobar', 1, 2, 3, 4);"。但是，当从触发器调用此过程时，它不会复制。

到目前为止，我对如何解决此问题的想法是以下之一。

• 强制触发器设置一个新的当前数据库。这将是最简单的，但我认为这是不可能的。这是我希望通过存储过程实现的。

• 复制两个数据库，并在主从中都有触发器。这是可能的，但设置起来很痛苦。

• 无论当前数据库上下文如何，强制复制获取对“legacydb”的所有更改。

• 如果复制运行的级别太高，它甚至不会看到我的触发器运行的任何更新，在这种情况下，再多的黑客攻击也无法实现我想要的。

任何有关如何实现这一目标的帮助将不胜感激。

最广泛的概述是什么？对不同复制方法和问题的最深入分析在哪里？

我有一个数据库，出于备份原因，我打算复制它（目前性能不是问题）。

我们已经正确设置了复制并对其进行了测试，一切都很好。

然后我们意识到它会将所有写入复制到临时表中，这实际上意味着对于空闲的从站而言，一天的数据复制需要将近两个小时。

原因是我们每 15 分钟通过 cronjob 重新计算数据库中的一些数据以确保它同步（总共需要大约 3 分钟，因此在 Web 请求期间执行这些操作是不可接受的；相反，我们只是在 Web 请求中存储修改而不尝试重新计算任何内容，然后批量完成所有工作）。为了有效地处理这些数据，我们使用临时表（因为有很多相互依赖关系）。

现在，第一个问题是，如果我们在从属服务器正在处理使用该临时表的事务时重新启动它，那么临时表不会持久存在。这可以通过不使用临时表来避免，尽管这有其自身的问题。

更严重的问题是，如果不是所有重新计算（它一个接一个地进行，所以每 15 分钟重建一次数据没有任何好处），奴隶可以在不到半小时的时间内轻松赶上......你可以从字面上看到它停留在 1115，只是为了快速赶上并停留在 1130 等）。

我们提出的一种解决方案是将所有重新计算从复制的数据库中移出，这样从站就不会复制它。但它的缺点是我们必须修剪它最终更新的表，使我们的奴隶实际上被“阉割”，即。在我们真正使用它之前，我们必须重新计算它上面的所有内容。

有没有人遇到过类似的问题和/或您将如何解决？我错过了一些明显的东西吗？

一年前我们开始了一些海外合并复制，到目前为止一切都很好。我的问题是，我们的系统中现在有如此多的数据，以至于订阅者的服务器上的任何崩溃都将是一场灾难：以标准方式重新初始化订阅将需要几天时间（我们的连接肯定很慢，但已经非常非常昂贵）！我一直在跟进的想法如下：

1. 制作原始数据库的副本，冻结它，通过飞机将文件发送给订阅者，然后在没有快照的情况下启动复制：这是传统上使用旧版本 SQL 完成的事情，但对我来说听起来有点混乱：我将不得不将我的发布者的数据置于只读模式并停止所有复制，直到操作完成。
2. 制作数据快照，将快照文件发送到国外，将它们安装在订阅服务器上，并在复制属性中将新快照位置指示为备用位置。这对我来说听起来很公平（没有必要暂停正在进行的复制，没有数据冻结），但是，在这一点上，微软的帮助没有......帮助。

我相信你们中的一些人已经经历过这样的情况。你的选择是什么？

编辑：当然，有人可以说“你为什么不尝试一下你的想法”，但这需要几个小时（sql-servers、虚拟机和所有这些东西的多个实例......），而我以为做这件事的人只需要 2 分钟就可以解释他的想法。如果有人愿意腾出 2 分钟的时间来为我节省数小时的辛勤工作，我将是最幸福的人……

如何在我的 OpenID 登录网站上支持冗余？

例如，我的用户要求 100% 的正常运行时间（是的，没错，但让我们尽可能接近）。

他们中的一些人使用较少可用的提供程序（即，他们自己网站上的 myphpid，或者经常停机的初创公司的 ID）。现在我可以把他们送到更可靠的供应商那里，但我也想有一些冗余。

我希望我可以部署的一种解决方案，但对 OpenID 了解不够，可以尝试：

在具有相同凭据（哈希/密钥/等）但不同域的不同托管服务上设置多个 phpmyid（理想情况下，我有一个循环 DNS 和相同名称，但我也想考虑它们不同的情况域）。

这行得通吗？换句话说，我在不同的服务器上拥有完全相同的 phpmyid 文件，包括凭据。我可以使用 example.com/id 和 example2.com/id 并期望它在我的终端看起来相同，这样我就不必将多个 OpenId 帐户链接到我系统中的每个用户？

虽然我使用 phpmyid 的示例，但问题更笼统 - 凭据是重要的，还是域/ip/？？？还以防止这种方式链接？

是否存在或是否存在一种标准，允许人们将自己的 OpenID 从一个提供商转移到另一个提供商，而不必在他们使用该 openid 的每个网站上断开和重新链接？

-亚当