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

Question

最近我们看到大量与 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 语句中使用该视图会有所帮助，如果有人对此有任何见解真的会有所帮助。

Answer 1

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

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

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

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

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