Redshift无故进入resize模式无法执行写入操作，该如何排查？

可能的触发原因 #

• 非主动发起的resize操作：同AWS账号下其他具备Redshift操作权限的IAM身份（用户/角色/服务）发起过resize请求，操作中途取消或执行失败后，集群后台的resize模式标记未正常回滚，控制台状态显示为Available但实际仍处于只读限制状态
• AWS侧后台节点替换：单节点dc2.large集群无冗余节点，当AWS检测到宿主机存在硬件风险/故障时，会自动发起节点替换操作，该流程会触发集群进入resize模式，若替换过程中出现服务异常卡住，就会导致resize模式长期残留
• resize任务异常终止：无论主动或被动触发的弹性resize/经典resize任务，执行过程中如果出现网络波动、后台服务故障，都会导致集群状态同步失败，无法自动退出resize模式
• 控制台状态同步偏差：极个别场景下前端控制台展示的集群状态和后台实际运行状态存在同步延迟，前端显示Available但后台仍有未清理的resize状态标记

排查步骤 #

1. 查集群事件记录
   进入Redshift控制台对应集群的「事件」标签页，筛选过去7天的事件，重点查找Resize、Node replacement、Cluster maintenance类型的事件，确认是否存在相关操作的触发、失败、中止记录。
2. 审计IAM操作日志
   进入CloudTrail控制台，筛选过去7天的Redshift API调用记录，重点排查ResizeCluster、ModifyCluster、RebootCluster三个API的调用日志，确认是否有非预期的操作发起，以及对应的操作主体、操作时间。
3. 校验集群后台真实状态
   执行AWS CLI命令aws redshift describe-clusters --cluster-identifier <你的集群ID>，查看返回结果中的ResizeInfo字段，如果该字段存在非空的ResizeType、Status参数，即可确认后台残留了resize任务记录。
4. 查集群内部resize状态
   在Redshift中执行系统查询SELECT * FROM stv_resize_state;，如果查询返回非空结果，说明集群内部确实存在未完成的resize任务。

临时恢复方案 #

如果排查后未找到任何主动发起的操作记录，基本可以判定为AWS侧后台运维异常导致的状态残留，直接提交AWS支持工单，让运维人员手动清理集群的resize模式标记即可，无需重启集群，也不会造成数据丢失。

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