用户 ID 0 取消查询

Question

我们的一些查询被取消，并出现错误消息

Query (<query id>) cancelled on user's request

，但没有用户取消它们。

在表

SVL_TERMINATE

上查询，我对失败查询的

PID

进行了筛选，发现许多行的

type

列值为

CANCEL

。我还发现该行的确切时间戳与我们失败的查询之一的时间戳相匹配。

此

PID

的所有行都有

USERID

= 0。该用户是什么？我在网上找不到任何在 Redshift 中引用用户 ID 0 的内容。我显然猜到

userid

0 是 Redshift 取消了我用户的查询，但问题是为什么？

我们注意到，大约在同一时间，我们的 Redshift 集群拍摄了快照。 但快照不应该取消正在运行的查询，对吧？

还有哪些其他事件（除了重新启动/升级集群之外）会导致 Redshift 取消所有正在运行的查询？我会尝试检查这些事件是否发生过。

Answer 1

Amazon Redshift 中的 USERID 0 通常表示内部或系统进程，而不是特定的人类用户。系统使用此用户 ID 进行各种内部操作，包括由于系统级原因（例如超出 WLM 时间限制或内部处理错误）而取消查询

对于快照，它们不会直接导致查询被取消。但是，拍摄快照可能会暂时影响集群性能，如果系统负载较重，这可能会间接导致查询取消。 参考 - https://repost.aws/knowledge-center/redshift-query-abort

许多原因可能导致 Redshift 取消所有正在运行的查询，包括：

• 语句超时：如果查询超过statement_timeout值，Redshift将终止它
• 工作负载管理 (WLM) 查询监控规则：如果 WLM 查询监控规则设置为中止超过特定阈值的查询，则这些查询将被取消
• 网络问题：网络连接中断可能导致查询取消
• 集群维护升级：在维护时段内，Amazon Redshift 可能会取消查询以确保系统稳定性
• 内部处理错误：Redshift 处理内部的错误也可能导致查询取消
• ASSERT 错误：这些是由 Redshift 代码库中的断言触发的错误，可能导致查询取消

要管理和防止查询取消，您可以：

• 增加超时参数，让查询有更多时间完成。
• 更新您的 WLM QMR 规则以适应运行时间较长的查询。
• 在维护时段之外安排长时间运行的操作，以最大程度地减少中断