Redshift扩容及踩到的坑，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就得修改了


相关内容