多主 Oracle GoldenGate 复制的全局锁定

Question

这是一个非常复杂的场景，但我认为最先进的挑战可能会对 dba.se 的许多高端用户感兴趣。

问题

我正在使用 Oracle GoldenGate 为文档生产系统开发洲际数据复制解决方案，有点类似于 wiki。主要目标是在全球范围内提高应用程序性能和可用性。

该解决方案必须允许从多个位置同时读/写访问同一个数据池，这意味着我们需要一些聪明的方法来防止或解决没有用户交互的冲突更新。

专注于碰撞预防，我们必须允许全局锁定对象（文档、插图、一组元数据等），从而防止多个用户同时编辑来自不同位置的同一对象 - 最终导致冲突。

类似地，对象必须保持锁定状态，直到任何用户连接的数据库收到该对象的更新数据，否则用户可能会开始编辑没有最新更新的旧对象。

背景

该应用程序对延迟有些敏感，这使得从远程位置访问中央数据中心的速度变慢。像许多以内容为中心的系统一样，读/写比率在 4 比 1 的范围内，使其成为分布式架构的理想选择。如果管理得当，后者还将努力确保站点或网络中断期间的可用性。

我使用了一种有点非常规的多循环双向复制拓扑。这将复杂性保持在可管理的级别 { 2(n-1) 方式}，增加了站点中断的弹性，并允许相当简单地添加或删除站点。一个小缺点是，通过中央主数据库在最远程站点之间复制事务可能需要长达 30 秒的时间。

在所有站点之间直接复制的更传统的设计会将时间缩短一半，但也会显着增加配置 { n(n-1) 方式}的复杂性。

五个位置意味着 20 路复制，而不是我设计中的 8 路复制。

此图显示了我当前跨欧洲、亚洲和北美数据中心的测试环境。生产环境预计会有更多的位置。

所有数据库都是 Oracle 11.2.0.3 和 Oracle GoldenGate 11.2.1。

到目前为止我的想法

我一直在思考通过在中央数据库的数据库链接上将一行插入到“锁定”表中来进行锁定，同时让解锁（前面提到的行的更新或删除）与更新的行一起复制数据。

在获取锁和打开对象进行编辑之前，我们必须代表用户检查中央和本地数据库中锁的可用性。编辑完成后，我们必须释放本地数据库中的锁，然后通过中央数据库将更改和锁的释放复制到所有其他位置。

但是，对高​​延迟数据库链接的查询有时会非常慢（测试显示单个插入需要 1.5 秒到 7 秒），而且我不确定我们是否可以保证删除锁的更新或删除语句是要复制的最后一条语句。

调用远程 PL/SQL 过程进行检查和锁定至少会将操作限制为单个远程查询，但 7 秒仍然是很长的时间。像两秒钟这样的事情会更容易接受。我希望可以以某种方式优化数据库链接。

还可能存在其他问题，例如在从中央数据库成功复制本地锁定表中的行之前尝试删除或更新该行。

从好的方面来说，使用这种解决方案，如果与中央数据库的通信中断，让应用程序进入只读状态，或者在数据中心不可用时重定向客户端，应该相对简单。

有没有人做过类似的事情？解决这个问题的最佳方法是什么？

就像我最初说的那样，这是一个相当复杂的解决方案，请随时询问任何不清楚或遗漏的地方。

Answer 1

请记住，我所做的大部分工作都是使用 PostgreSQL 进行的，因此这可能会也可能不会 100% 赚钱，但我认为这应该足够接近以提供帮助。

基本问题是，在这样的环境中，管理锁会遇到很多麻烦。看来您可以在锁定级别上进行某种冲突解决或冲突预防。尽管存在性能困难，冲突预防似乎仍会显着降低用户的挫败感。

我在这里的方法确实是在 pl/sql 存储过程中对中央服务器进行锁定，如果可能的话，它会插入到锁定表中，返回一个指示成功的值，或者如果不可能，则返回一个指示的值失败，或者引发异常（例如，我过去所做的就是返回一些标识谁拥有锁（如果锁已经被锁定）的信息）。

我要省略的是实际检查本地服务器。如果您的读写比率较高，并且冲突的可能性相对较小，则无论如何您都必须在大多数情况下检查中央服务器，因此检查本地服务器也不会获得太多好处。当然，您不想同时写入本地和远程服务器以进行锁定。保持锁定简单。无论你做什么，它都可能成为痛苦的根源。

我在这里建议的第二件事是，我强烈建议像这样的过期锁，也许是在 2 小时或其他时间之后。这样做有两个主要原因。首先，代码应用程序层中的错误可能会导致锁无法释放，其次，如果这是通过 Web 界面进行的，则 HTTP 是无状态的，因此您无法真正知道状态已丢失。通过这种方式，您可以提供在一定时间内有效的锁定，可以预先更新（如果需要，在后台），并且如果个人关闭浏览器窗口并当天回家则超时。我还推荐某种释放锁的管理实用程序。

我同意你的看法，即 7 秒获取锁是一个巨大的性能成本，但最终我没有看到任何更好的方法来做到这一点。您的选择受到 CAP 定理的极大限制，并且可能需要一个中央锁定系统。

我想另一种选择是，可以让中央服务器仅锁定到分支位置，并在一段时间内没有持有有效锁时让分支位置释放锁定。这可能具有允许团队更快协作的优点，这意味着只有团队中的第一位编辑才需要承担该成本。