Redshift扩容及踩到的坑
下午发现redshift集群已经没有什么空间了。删掉一些不须要的暂时表也仅仅降到86%左右，为了能放下这两天的数据必须扩容了
在官方docs中，有两种扩容方案
1.在确定能非常快扩容完毕的情况或者init时候适合方案：
2.在不确定扩容耗时。而且不中断服务的要求下适合方案：
我们採取的是另外一种：
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就得改动了
