如何查询Redshift维护窗口相关记录及配置免打扰规则

问题1：如何在Redshift中查找证据确认报错是否由维护操作导致 #

• 优先查询Redshift Event记录：Redshift控制台的事件模块会完整记录所有官方运维操作的时间线，包括维护启动、集群重启、维护完成等核心事件，只要报错时间和维护重启的时间完全吻合，即可直接确认关联，你后续通过该方法验证得到的结论是准确的。
• 补充查询系统视图：如果svl_qlog中未找到aborted=1的有效记录，可以查询svl_statement_history视图，筛选执行时间落在维护窗口范围内、状态为FAILED或ABORTED的请求，结合事件时间进一步匹配；也可以查询stl_connection_log，核对对应时间点的连接断开、拒绝记录是否和集群重启时间对齐。
• 错误码特征匹配：你遇到的500051（查询执行失败）、500150（连接被拒绝）都是Redshift集群重启过程中的典型报错，维护触发的重启是这类错误的常见诱因。

问题2：是否可设置规则，存在运行中用户会话时自动跳过当前维护窗口 #

Redshift目前没有原生支持的自动检测运行中会话/查询、自动跳过维护窗口的规则，你可以通过以下方案降低维护对业务的影响：

• 开启可推迟维护功能：可将维护窗口最多推迟14天，你可以在维护窗口启动前主动检查集群当前的运行会话、长查询执行情况，手动决定是否推迟本次维护。
• 调整维护窗口至业务绝对低峰：将窗口设置为业务侧确认无长任务、无核心请求的时段，从根源上减少冲突概率。
• 维护前主动清理非必要会话：如果确认要执行本次维护，可提前通知业务侧，主动终止非核心的运行中查询和会话，避免出现异常报错。

内容的提问来源于stack exchange，提问作者Sachiko