问题描述 及 错误信息:
我们将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.large
nodeType ra3.xlplus
numberOfNodes 4
clusterStatus resizing
clusterAvailabilityStatus Modifying
masterUsername admin
dBName dev
Not classic
resizeType 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,以及文档中的定义,也是可以排查出原因的。