问题描述 及 错误信息：

我们将AWS Redshift集群从dc2升级到了ra3类型，而后居然发现所有的物化视图都消失了???

这是道德的沦丧还是人性的扭曲？

当然都不是，下面来看我们应该怎样排查吧~~

分析过程 及 解决方案：

思路1： 首先排查是不是我们自己删了MV呢？

SELECT query_id,transaction_id,session_id,start_time,elapsed_time,queue_time,execution_time,returned_rows,returned_bytes
FROM sys_query_history
WHERE query_type = 'SELECT'
ORDER BY start_time DESC limit 10;

通过query_type来过滤查询类型，例如，SELECT、INSERT、UPDATE、UNLOAD COPY、COMMAND、DDL、UTILITY、CTAS 和 OTHER。

文档1：https://docs.amazonaws.cn/redshift/latest/dg/SYS_QUERY_HISTORY.html

然后我们惊讶地发现，我们没删MV呀哈哈哈。

思路2：

接下来我们就继续查看，创建这些Materialized View的DDL, 然后惊喜地发现，创建MV的语句都有parameter BACKUP NO 这样的字样

文档2：https://docs.amazonaws.cn/redshift/latest/dg/materialized-view-create-sql-command.html

根据文档2，BACKUP NO就意味着这些Materialized view，不会在Redshift备份中保留。以节省创建snapshot和 restore from snapshot的时间。

之后，我们通过查看CloudTrail记录，发现我们自己对dc2 - ra3的升级，是通过elastic resize的方式完成的：

CloudTrail中的记录如下：

ResizeCluster 
.........dc2.largenodeType    ra3.xlplus
numberOfNodes   4clusterStatus   resizing
clusterAvailabilityStatus   Modifying
masterUsername  admin
dBName  devNot classicresizeType  ElasticResize

根据下面文档3，使用 ElasticResize方式的是偶，如果目标节点类型与现有节点类型不同（比如此案例中的dc2和ra3）,那么Amazon Redshift 会先创建一个快照。然后，使用快照中的最新数据预置新的目标集群，并在后台将数据传输到新集群。

文档3：https://repost.aws/knowledge-center/redshift-elastic-resize

因此我们确定了，因为我们的所有Materialized View创建时都是BACKUP NO, 并且刚好是用了elastic resize方式将dc2集群升级到ra3类型，才导致了升级集群类型之后，MV的消失。

方案3： 在troubleshooting过程中，其实很多时候我们并不能很快锁定方案2里面涉及的这么多巧合的点。可能我们会考虑用snapshot恢复一个集群来进行模拟测试。

根据本案例的情况，用snapshot恢复其实也会发现这些MV都是丢失了的。那么此时再查询MV的DDL，以及文档中的定义，也是可以排查出原因的。