红移丢弃表卡住

Question

我有一个每天晚上都会启动的 cronjob，它涉及建立一个临时表，将当前表放到 Redshift 上，然后将临时表换成旧表。超过一半的时间，当删除现有表并表现得好像有一些挂起的事务正在阻止删除通过时，这个特定的作业会卡住。

这只是使用完全相同的脚本在一夜之间运行的数十个作业之一，没有一个曾经遇到过这个问题；但是，有一些细微差别：

• 运行此特定作业的机器与所有其他生产作业不同，因为该机器目前处于测试状态。
• 本机使用的 S3 密钥与其他机不同。

除了我从未在任何其他工作中看到此问题外，此问题很难解决，原因如下：

• 我无法通过在当前正在运行的同一机器上手动运行脚本来重现此问题；脚本按预期执行，表删除仅在几秒钟内发生。我在这里能想到的唯一区别是我以ubuntu 执行脚本，而cronjob 是从root 执行的。
• 我没有成功识别或终止导致drop 停止的会话；我在 Stack Overflow（这是最适用的问题，有答案 - redshift drop or truncate table very very slow）、Redshift 文档和其他方面都看过很多次，但我没有找到任何答案。当我看到作业停止时，我在 Redshift 上检查了以下表格，通常发现事情处于以下状态：
  • 临时表已创建，但旧版本的目标表仍然存在。
  • stv_locks 表显示有三个进程在运行，lock_status 分别为“Holding write lock”、“Holding delete lock”和“Holding insert lock”。与这些关联的进程 ID 不是与当前作业相关的 ID。
  • stv_tr_conflict 表没有显示任何内容。
  • stv_recents 表显示drop 的状态为Running。
  • 上面描述的应该创建锁的查询在 svl_qlog 中显示为已完成，因此这似乎与 stv_locks 表相矛盾。
  • 在查询stv_sessions 时，使用pg_terminate_backend 停止关联进程实际上并不会删除会话，但确实会释放一些允许作业完成的东西。

任何帮助弄清楚这里到底发生了什么，我们将不胜感激！

Answer 1

我遇到了同样的问题，我只是 rebot RS 然后它又可以正常工作了。