I need to resize my Amazon Redshift cluster, but I have questions about performance, billing, and the speed of my resize operation. How do I resize an Amazon Redshift cluster?
There are two ways to resize an Amazon Redshift cluster:
- Using the Resize Operation to Resize a Cluster
- Using the Snapshot, Restore, and Resize Operations to Resize a Cluster
You can resize up or down to any of the supported node types if the target configuration has enough data storage space. The time to complete a resize depends on many factors, so we recommend first testing the resize using the snapshot and restore method to estimate the duration required to complete the operation.
Resize operations cannot be canceled by users, so consider the following before you begin:
- You will experience downtime equal to a cluster reboot when the source cluster reboots into read-only mode.
- Clusters can only be used in read-only mode during resizing. Using the source cluster during the resize operation can also cause the resize operation to take longer.
- Connections are terminated when all data is copied to the new cluster, but you can create new connections immediately that arrive at the new target cluster.
- Private or public clusters in a VPC will keep the same IP address for the leader node after resizing.
- Credentials remain the same after resizing.
If you require near-constant write access to your Redshift cluster, you can use a snapshot and restore to minimize downtime. This requires 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
To check the status of your resize operation, choose the Status tab in the Amazon Redshift console. The Status tab shows the average rate of transfer, the elapsed time, and the remaining time.
The estimated time to complete your resize operation might vary, based on the following factors:
- The read workload on the source cluster.
- The table definition and its skew.
- The node type that you are scaling to and from.
- The number of nodes in source/target configuration.
- The amount of data that needs to be copied.
- The read workload on the source cluster during the resize process. (Resources taken by your workload cannot be used by the resize process.)
- The load on the source cluster or the skew of your data.
Resizing smaller node types (large, xlarge) to larger node types (8xlarge) requires more storage per node, and increased storage has more metadata that needs to be managed and written upon COMMIT. This means that the base cost for a single commit is higher for larger nodes than smaller clusters. If your workload is characterized by small commits, you might see a degradation in performance. For the best performance, group multiple changes into a single commit when possible.
Tune Amazon Redshift for performance to be sure that your tables use compression and that they are not skewed before beginning a resize operation. You can also remove unused tables to reduce resize time and disk space used on the target cluster. You can identify unused tables by using the unscanned table summary script.
Note: The unscanned table summary only reflects recent history (2-5 days).
During a resize operation, you are changing your cluster configuration to have more or fewer resources by increasing or decreasing the number of nodes. Increasing your resources can increase performance, but performance improvement depends on your workload and table design. See Amazon Redshift advanced table design for performance best practices.
Resize troubleshooting
Table size shrink or growth is expected during a resize because of how Amazon Redshift manages table storage. For more information about Redshift table size, 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 CLI, the target cluster is still being provisioned and it has not yet been copied over. After your target cluster has been provisioned, the status changes to IN_PROGRESS.
If you need to cancel a resize, contact AWS Support for additional assistance. If your resize has failed, AWS Support will contact you to resolve the issue. In order for us to assist you, please be sure your contact information is up to date.
If you receive an error that states "Please choose a larger target cluster. Your current selection does not have enough capacity for your data set", your data size does not fit into the target cluster. Resize with more nodes or a different node type.
Billing for resized clusters
During the resize operation, you are billed for the clusters that are available to you. For example, during the resize, you can connect to the source cluster and therefore you are billed for this configuration. After the resize is complete, you are no longer billed for the source configuration and billing starts for the target configuration as soon as it is ACTIVE. If you use snapshots and restore to resize, you are billed at the same rate. However, when using the snapshot method, you temporarily have an additional cluster, which you will be billed for until you have cleaned up your environment.
If you have purchased reserved instances, then modified billing depends on your resized cluster configuration, reserved node types, and the number of reserved nodes being purchased. See How Reserved Nodes Work for more information.
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
