User guide

4. Resize the target cluster. Select the new node type, number of nodes, and other settings for the target
cluster.
5. Review the loads from your ETL processes that occurred after you took a snapshot of the source
cluster.You’ll need to reload the same data in the same order into the target cluster. If you have ongoing
data loads, you’ll need to repeat this process several times until the data is the same in both the source
and target clusters.
6. Stop all queries running on the source cluster. To do this, you can reboot the cluster, or you can log
in as a super user and use the PG_CANCEL_BACKEND and the PG_TERMINATE_BACKEND
commands. Rebooting the cluster is the easiest way to make sure that the cluster is unavailable.
7. Rename the source cluster. For example, rename it from examplecluster to
examplecluster-source.
8. Rename the target cluster to use the name of the source cluster prior to the rename. For example,
rename the target cluster from preceding to examplecluster. From this point on, any applications
that use the endpoint containing examplecluster will be connecting to the target cluster.
9. Delete the source cluster after you switch to the target cluster, and verify that all processes work as
expected.
Alternatively, you can rename the source and target clusters before reloading data into the target cluster
if you do not have a requirement that any dependent systems and reports be immediately up-to-date with
those for the target cluster. In this case, step 6 would be moved to the end of the process described
preceding.
The rename process is only required if you want applications to continue using the same endpoint to
connect to the cluster. If you do not require this, you can instead update any applications that connect to
the cluster to use the endpoint of the target cluster without renaming the cluster.
There are a couple of benefits to reusing a cluster name. First, you do not need to update application
connection strings because the endpoint does not change, even though the underlying cluster changes.
Second, related items such as Amazon CloudWatch alarms and Amazon Simple Notification Service
(Amazon SNS) notifications are tied to the cluster name, so you can continue using the same alarms and
notifications that you’ve set up for the cluster. This continued use is primarily a concern in production
environments where you want to have the freedom to resize the cluster without having to reconfigure
related items, such as alarms and notifications.
To walk through the process of resizing an Amazon Redshift cluster using the snapshot, restore, and
resize operations, see Tutorial: Using the Snapshot, Restore, and Resize Operations to Resize a
Cluster (p. 228).
Tutorial: Using the Resize Operation to Resize
a Cluster
This section walks you through the process of resizing a cluster by using the resize operation in Amazon
Redshift. In this example, you’ll scale your cluster out by resizing from a single node cluster to a multinode
cluster.
Complete this tutorial by performing the steps in the following:
• Prerequisites (p. 227)
• Step 1: Resize the Cluster (p. 227)
• Step 2: Delete the Sample Cluster (p. 228)
API Version 2012-12-01
226
Amazon Redshift Management Guide
Tutorial: Using the Resize Operation to Resize a Cluster