How do I resize an Amazon Redshift cluster, and how does that impact performance and billing?
There are three ways to resize an Amazon Redshift cluster:
- Elastic resize: To quickly add or remove nodes from an existing cluster, use elastic resize. Elastic resize operations usually take a few minutes to complete. The cluster will be unavailable during that time.
- Classic resize: To change the node type, the number of nodes, or both, use classic resize. A classic resize copies tables to a new cluster. The source cluster will be in read-only mode until the resize operation finishes.
- Snapshot, restore, and resize: To keep your cluster available during a classic resize, first make a copy of the existing cluster, then resize the new cluster. Keep in mind that all data written to the source cluster after the snapshot is taken must be manually copied to the target cluster after the migration.
Resize operation speed
Because the elastic resize operation doesn't create a new cluster, the operation usually completes quickly. The time required to complete a classic resize or a snapshot and restore operation might vary, based on the following factors:
- The workload on the source cluster.
- The number and size of the tables being transferred.
- How evenly data is distributed across the compute nodes and slices.
- The node configuration in the source and target clusters.
To reduce the time required for a classic resize or a snapshot and restore operation:
- Run the table inspector script from AWS Labs to identify skewed tables. To fix skewed tables, 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 script from AWS Labs.
Note: The unscanned table summary only shows recent history (2-5 days). Use the System Object Persistence Utility to capture usage data over a longer period. - For more ways to increase the speed of resize operations, see Top 10 Performance Tuning Techniques for Amazon Redshift.
To check the status of your resize operation using the Amazon Redshift console, choose the Status tab on the cluster details page. The Status tab shows the average rate of transfer, the elapsed time, and the remaining time.
Troubleshooting
- It's normal for tables to increase or decrease in size during a resize operation. For more information, see Why does a table in my Amazon Redshift cluster consume more disk storage space than expected?
- If your cluster has a status of NONE in the AWS Command Line Interface (AWS CLI), then the target cluster is still being provisioned and isn't copied over yet. After your target cluster is provisioned, the status changes to IN_PROGRESS.
- If you receive the error message "Please choose a larger target cluster. Your current selection does not have enough capacity for your data set," then your data does not fit into the target cluster. Resize with more nodes or a different node type.
- To cancel a resize operation before it completes, choose cancel resize from the cluster list in the Amazon Redshift console. For more information, see Snapshot, Restore, and Resize.
Billing for resized clusters
- During the resize operation, you're billed for the clusters that are available to you. For example, during the resize operation, you're billed for the source configuration. After the resize is complete, you're no longer billed for the source configuration. Billing starts for the target configuration as soon as the cluster status changes to available. When using the snapshot and restore method, you temporarily have an additional cluster, which you're billed for until you clean up your environment.
- Resizing smaller node types (large, xlarge) to larger node types (8xlarge) requires more storage per node. The more storage you have per node, the more metadata is written when you run COMMIT. This means that the base cost for a single commit operation is higher for larger nodes. If you run many small commit operations, you might see a decrease in performance. For better performance, group multiple changes into a single commit operation.
- If you purchased Reserved Instances, then billing depends on your resized cluster configuration, reserved node types, and the number of reserved nodes that are purchased. For more information, see How Reserved Nodes Work.
Did this page help you? Yes | No
Back to the AWS Support Knowledge Center
Need help? Visit the AWS Support Center
Published: 2017-11-06
Updated: 2019-02-07
