Amazon Redshift 中的可序列化隔离违规错误

Posted 2023-03-04

【中文标题】Amazon Redshift 中的可序列化隔离违规错误

【英文标题】：Serializable Isolation Violation Errors in Amazon Redshift

【发布时间】：2021-02-08 00:02:15

【问题描述】：

最近我们看到大量与 Serializable isolation violation on table 相关的错误，我们有一些基表构成我们的核心数据，我们从这些表中提取值以在 Lambda 中运行我们的业务逻辑。

场景：

Lambda 1：每 15 分钟运行一次，并将最新数据从源 (RDBMS) 获取到 Redshift，从而形成我们的基表（DELETE 和 INSERT） Lambda 2 : 成功运行上述 Lambda 后触发，这是编写业务逻辑的地方，是正常的 SELECT 语句 Lambda 3：每 15 分钟触发一次，也使用基表运行，并且只有 SELECT 语句

当在实例中触发 Lambda 1 以进行下一次运行时，我们看到它失败并出现 Serializable isolation violation 错误。

根据大多数帖子，在表上放置 LOCK 可能会解决问题，但会增加其他查询运行的等待时间比预期的更长，并且由于 Lambda 的约束，它会在 15 分钟后超时，即不理想。而且我确实看到帖子说放置一个 LOCK 并不能完全解决它，所以对使用它持怀疑态度。

所以让我印象深刻的是在基表顶部创建一个VIEW 并在所有 SELECT 语句中使用该视图会有所帮助，如果有人对此有任何见解真的会有所帮助。

【参考方案1】：

所以问题在于每个事务正在创建的锁，并且无法确定需要解决锁的正确顺序。请参阅：https://aws.amazon.com/premiumsupport/knowledge-center/redshift-serializable-isolation/

现在，您的描述没有足够的运行中写入，如所述，无法查看您如何从 Lambdas 运行的一次传递中获得此信息。因此，要么此描述不完整（多个 Lambda 更新表），要么问题出现在 Lambda 运行之间。一种可能性是事务没有被关闭，并且 Lambda 调用具有无法解析的锁。你有提交关闭交易吗？需要更多信息才能知道是哪一个。

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

如果您知道导致序列化问题的原因/哪些表，则添加显式 LOCK 来序列化事物可以工作。这也可能不是最好的解决方案，当问题被理解后，更好的方法可能会很明显。

将视图添加到组合中并不能解决问题（尽管如果它改变了事件的时间，它可能会移动它）。

【讨论】：

Commit -> 在每个已完成的 Lambda 中都有一个提交。表更新 - > 不只有一个 Lambda 对表进行更新和删除（有一个 Vaccum 作业，但每天只运行一次，这使得它不是可疑的）如果您要询问基本数据表，则暂存表是的，他们几乎在其他 lambda 的所有部分中都使用，因为它们是我们的数据源。抱歉回复延迟

因此无法查看所有代码和活动顺序，因此很难确切知道发生了什么。提供的链接有助于理解这里的基本问题。我期望的是一个 Lambda 正在读取表 A 并更改表 B，而另一个正在读取表 B 并更改 A。如果这些与正确的时间重叠，那么您就有了他们所描述的依赖循环。这可能是正在发生的事情吗？