Sql Amazon红移中的可序列化隔离冲突错误

最近，我们看到了大量与表上的

可序列化隔离冲突相关的错误

我们有一些基表，这些基表构成了我们的核心数据，我们从这些表中提取值以在Lambda中运行我们的业务逻辑

情景：

• Lambda 1：每15分钟运行一次，并将源（RDBMS）中的最新数据转换为红移，红移形成我们的基表（是否执行

  删除

  和

  插入

  ）
• Lambda 2：在成功运行上述Lambda后触发，这是写入业务逻辑的地方，是正常的

  SELECT

  语句
• Lambda 3：每15分钟触发一次，也使用基表运行，并且只有

  SELECT

  语句

当Lambda 1在实例上被触发进行下一次运行时，我们看到它失败，出现了

可串行化隔离冲突

错误

根据大多数帖子，在表上加锁可能会解决这个问题，但会增加其他查询运行时间超过预期的等待时间，并且由于Lambda的限制，它会在15分钟后超时，这并不理想。我确实看到过一些帖子，上面说，上锁并不能完全解决这个问题，因为人们对此太过怀疑

---

因此，让我印象深刻的是，在基表的顶部创建一个

视图

，并在所有SELECT语句中使用该视图，这会有所帮助，如果有人对此有任何见解，将非常有帮助。

因此问题在于每个事务正在创建的锁，并且无法确定需要解决的锁的正确顺序。见：

现在，您的描述在飞行中没有足够的写操作，无法查看您是如何从Lambdas运行的一次过程中获得此信息的。因此，要么此描述不完整（多个Lambdas更新表），要么问题出现在Lambdas运行之间。一种可能性是事务没有关闭，Lambda调用有无法解析的锁。您是否有关闭交易记录？需要更多信息才能知道是哪个

您可以检查Lambda之间的pg_锁，以查看剩余的锁。XID是具有锁的事务。我猜你的未结交易比你预期的要多。Lambda会话是否处于自动提交模式？您正在从多个会话更新表吗？您正在提交更改吗？你在重复使用刮板吗

如果您知道为什么/哪些表会导致序列化问题，那么添加显式锁来序列化可以工作。这也不可能是最好的解决方案，当问题得到理解时，更好的方法可能会显而易见

---

向混合添加视图不会解决问题（尽管如果它更改了事件的时间，它可能会移动它）。

Commit->每个Lambda中都有一个Commit。表更新->否-只有一个Lambda对表进行更新和删除（有一个Vaccum作业，但每天只运行一次，这使其不成问题）如果您想问基础数据表是的，则可以使用临时表。它们几乎用于其他Lambda的所有部分，因为它们是我们的数据源。很抱歉响应延迟，因为无法查看所有代码和活动序列，所以很难确切知道发生了什么。提供的链接有助于理解此处的基本问题。我所期望的是一个Lambda正在读取表A并更改表B，而另一个正在读取表B并更改表A。如果这些与正确的时间重叠，您就有了它们所描述的依赖循环。这可能是正在发生的事情吗？