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就得修改了

人情似纸张张薄,世事如棋局局新。

Redshift扩容及踩到的坑

相关文章:

你感兴趣的文章:

标签云: