Why is the classic resize of my Amazon Redshift cluster taking so long to complete?
I initiated a classic resize, but I don't see it progressing in my Amazon Redshift cluster or it's taking too long. How do I obtain a better estimate of the downtime to complete a classic resize?
The time required for your Amazon Redshift cluster to complete a classic resize might vary (from several hours to several days). The classic resize of your cluster can take longer for the following reasons:
- Read workload on the source cluster
- Number and size of the tables being transferred
- Table definition and its skew
- Node configuration (number and type of nodes) used in the source and target clusters
For more information, see Details of resizing a cluster in Resizing clusters in Amazon Redshift.
Reducing the downtime for a classic resize
To reduce the time required for a classic resize, consider the following approaches:
- Monitor the status of your resize operation using the Amazon Redshift console. Choose the Status tab on the cluster details page. The Status tab shows you the average rate of transfer, elapsed time, and remaining time.
- Fix skewed tables and choose an appropriate distribution key. For more information, see Amazon Redshift engineering’s advanced table design playbook: distribution styles and distribution keys.
- Remove unused tables. To identify unused tables, run the unscanned table summary.sql script on the GitHub website.
Note: The unscanned table summary shows only the recent history from the past few days. Use the SystemTablePersistence utility on the GitHub website to capture usage data over a longer period of time.
- Use elastic resize. Elastic resize adds or removes nodes on an existing Amazon Redshift cluster, automatically redistributing data to the new nodes. Because elastic resize does not create a new cluster, the downtime is significantly lower than the downtime for a classic resize. For more information about elastic resize, see Resizing clusters.
For more information about optimizing your resize performance, see Top 10 performance tuning techniques for Amazon Redshift.
Troubleshooting classic resize
- If your cluster has a status of "NONE" in the AWS Command Line Interface (AWS CLI), then the target cluster is still being provisioned. Wait until your target cluster is provisioned. After it has been copied over, the status changes to "IN_PROGRESS".
Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent AWS CLI version.
- If you receive an error message about insufficient disk space, then it indicates that your data does not fit into the target cluster. Resize your Amazon Redshift cluster with more nodes, a different distribution style, or a different node type. For more information, see Resizing clusters in Amazon Redshift.
- To cancel a resize operation before it completes, choose Cancel resize from the cluster details in the Amazon Redshift console. Alternatively, you can use the cancel-resize command from the AWS CLI.
Note: You won't be able to cancel the resize operation if it's in the final stage.
How do I resize an Amazon Redshift cluster?
Why does a table in an Amazon Redshift cluster consume more or less disk storage space than expected?
- Wie stelle ich mithilfe von Spark in meinem EMR-Cluster eine Verbindung zu einem Redshift-Cluster her?AWS OFFICIALAktualisiert vor 3 Monaten
- AWS OFFICIALAktualisiert vor 4 Monaten
- AWS OFFICIALAktualisiert vor 6 Monaten
- AWS OFFICIALAktualisiert vor 5 Monaten