Redshift扩容及踩到的坑

下午发现redshift集群已经没有什么空间了，删掉一些不需要的临时表也只降到86%左右，为了能放下这两天的数据必须扩容了



在官方docs中，有两种扩容方案

1.在确定能很快扩容完成的情况或者init时候适合方案：
http://docs.aws.amazon.com/redshift/latest/mgmt/rs-tutorial-using-the-resize-operation.html

2.在不确定扩容耗时，并且不中断服务的要求下适合方案：
http://docs.aws.amazon.com/redshift/latest/mgmt/rs-tutorial-using-snapshot-restore-resize-operations.html

我们采取的是第二种：
If you are unsure how long your cluster takes to resize, you can use this procedure totake a snapshot, restore it into a new cluster, and then resize it to get
an estimate.

目前数据量400G
第一步：创建Snapshot
snapshot:id: red-snapshot-0608

第二步：根据snapshot进行restore出一个新集群
restore
id: red-restore-0608

第三步：验证数据
主要是看下restore的数据是否ok

第四步：进行扩容
将restore出来的集群扩容

第五步：将扩容过程中新旧两个集群的数据做同步
如果是query就没必要了，主要针对的是变更操作；一般EDW的设计都需要考虑ETL过程中任何任务都可以rerun,所以只需要将同一份数据装载到不同的存储介质上。(我们在扩容中间没有类似操作，我们就免去了)

第六步：重命名
新的集群Host/endpoint与旧的不一致，需要重命名到旧的上去，这样所有连接Redshift的Connection Url无需更改，无缝切换

操作步骤可以按照文档进行，不赘述

第七步：删除原有集群
按照AWS的收费规则，所有未deleted状态的机器都在收费范围内。

在生产环境下，建议在删除旧集群的同时，保留一个final snapshot

如此，便完成了redshift集群的扩展，可以vacuum某些表看下结果

踩坑：
1.老集群一定要先rename然后再shutdown，目前操作发现先shutdown以后再rename就不行了，直接报400 error。
因为同名的cluster不允许同时存在，这样的话Connection URL就得修改了