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.