Größenanpassung von Clustern

Wenn sich Ihre Data-Warehousing-Kapazität und Leistungsanforderungen ändern, können Sie die Größe Ihres Clusters anpassen, um die Rechen- und Speicheroptionen von Amazon Redshift optimal zu nutzen.

Es gibt zwei Arten von Größenanpassungsvorgängen:

• Elastische Größenanpassung – Sie können Knoten zu Ihrem Cluster hinzufügen oder daraus entfernen. Sie können auch den Knotentyp ändern, z. B. von DS2-Knoten zu RA3-Knoten. Eine elastische Größenanpassung erfolgt in der Regel schnell und dauert durchschnittlich zehn Minuten. Aus diesem Grund empfehlen wir es als erste Option. Wenn Sie eine elastische Größenanpassung durchführen, werden Daten-Slices neu verteilt, d. h. Partitionen, denen Speicher- und Festplattenspeicher in jedem Knoten zugewiesen wird. Elastische Größenanpassung ist geeignet, wenn Sie:

  • Hinzufügen oder Reduzieren von Knoten in einem bestehenden Cluster, ohne jedoch den Knotentyp zu ändern – dies wird allgemein als Größenanpassung vor Ort bezeichnet. Wenn Sie diese Art der Größenanpassung durchführen, werden einige laufende Abfragen erfolgreich abgeschlossen, andere können jedoch als Teil des Vorgangs entfernt werden.

  • Ändern des Knotentyps für einen Cluster – Wenn Sie den Knotentyp ändern, wird ein Snapshot erstellt und Daten werden vom Quell-Cluster an einen Cluster neu verteilt, der aus dem neuen Knotentyp besteht. Nach Abschluss werden laufende Abfragen entfernt. Wie die Größenanpassung vor Ort ist auch diese schnell abgeschlossen.

• Klassische Größenanpassung – Sie können den Knotentyp, die Anzahl der Knoten oder beides ähnlich wie bei der elastischen Größenänderung ändern. Die klassische Größenanpassung dauert länger, kann aber in Fällen nützlich sein, in denen die Änderung der Knotenanzahl oder des Knotentyps, zu dem migriert werden soll, nicht innerhalb der Grenzen für die elastische Größenänderung liegt. Dies kann zum Beispiel zutreffen, wenn die Änderung der Knotenanzahl sehr groß ist.

Elastic resize (Elastische Größenanpassung)

Eine Operation zur elastischen Größenanpassung beim Hinzufügen oder Entfernen von Knoten desselben Typs hat die folgenden Phasen:

1. Bei der elastischen Größenanpassung wird ein Cluster-Snapshot erstellt. Dieser Snapshot beinhaltet immer Tabellen ohne Backup für Knoten, bei denen es anwendbar ist. (Einige Knotentypen, wie RA3, haben keine Tabellen ohne Backup.) Wenn Ihr Cluster keinen aktuellen Snapshot hat, weil Sie automatische Snapshots deaktiviert haben, kann der Sicherungsvorgang länger dauern. (Um die Zeit bis zum Beginn des Größenanpassungsvorgangs zu minimieren, empfehlen wir, dass Sie automatische Snapshots aktivieren oder einen manuellen Snapshot erstellen, bevor Sie mit der Größenanpassung beginnen.) Wenn Sie eine elastische Größenanpassung starten und ein Snapshot-Vorgang ausgeführt wird, kann die Größenänderung fehlschlagen, wenn der Snapshot-Vorgang nicht innerhalb weniger Minuten abgeschlossen wird. Weitere Informationen finden Sie unter Amazon-Redshift-Snapshots und -Sicherungen.

2. Der Vorgang migriert Cluster-Metadaten. Der Cluster ist für einige Minuten nicht verfügbar. Die meisten Abfragen werden vorübergehend angehalten und Verbindungen offen gehalten. Es ist jedoch möglich, dass einige Abfragen entfernt werden. Diese Phase ist kurz.

3. Die Sitzungsverbindungen werden wiederhergestellt und die Abfragen fortgesetzt.

4. Bei der elastischen Größenanpassung werden Daten im Hintergrund auf Knoten-Slices umverteilt. Der Cluster ist für Lese- und Schreibvorgänge verfügbar, die Ausführung einiger Abfragen kann jedoch länger dauern.

5. Nachdem der Vorgang abgeschlossen ist, sendet Amazon Redshift eine Ereignisbenachrichtigung.

Wenn Sie die elastische Größenanpassung verwenden, um den Knotentyp zu ändern, funktioniert dies ähnlich wie beim Hinzufügen oder Entfernen von Knoten desselben Typs. Zunächst wird ein Snapshot erstellt. Ein neuer Ziel-Cluster wird mit den aktuellen Daten aus dem Snapshot bereitgestellt und die Daten werden im Hintergrund auf den neuen Cluster übertragen. Während dieser Zeit sind die Daten schreibgeschützt. Wenn die Größenanpassung kurz vor dem Abschluss steht, aktualisiert Amazon Redshift den Endpunkt so, dass er auf den neuen Cluster verweist, und alle Verbindungen zum Quell-Cluster werden getrennt.

Es ist unwahrscheinlich, dass eine elastische Größenänderung fehlschlägt. Im Falle eines Fehlers erfolgt das Rollback jedoch in den meisten Fällen automatisch, ohne dass ein manuelles Eingreifen erforderlich ist.

Wenn Sie reservierte Knoten haben, z. B. reservierte DS2-Knoten, können Sie bei einer Größenanpassung ein Upgrade auf reservierte RA3-Knoten durchführen. Sie können dies tun, wenn Sie eine elastische Größenanpassung durchführen oder die Konsole verwenden, um aus einem Snapshot wiederherzustellen. Die Konsole führt Sie durch diesen Prozess. Weitere Informationen zum Aktualisieren auf RA3-Knoten finden Sie unter Migration zu RA3-Knotentypen.

Bei der elastischen Größenanpassungen werden keine Tabellensortierungen durchgeführt und es wird kein Speicherplatz freigegeben. Daher ist sie kein Ersatz für eine Bereinigungsoperation. Weitere Informationen finden Sie unter Bereinigen von Tabellen.

Für die elastische Größenanpassung gelten die folgenden Einschränkungen:

• Cluster zur elastischen Größenänderung und Datenfreigabe – Wenn Sie Knoten in einem Cluster addieren oder subtrahieren, der ein Produzent für die Datenfreigabe ist, können Sie keine Verbindung von Verbrauchern mit diesem Cluster herstellen, während Amazon Redshift Cluster-Metadaten migriert. Wenn Sie eine elastische Größenänderung durchführen und einen neuen Knotentyp auswählen, ist die Datenfreigabe ebenfalls nicht verfügbar, während Verbindungen getrennt und auf den neuen Ziel-Cluster übertragen werden. Bei beiden Arten der elastischen Größenänderung ist der Produzent einige Minuten nicht verfügbar.

• Datenübertragung von einem freigegebenen Snapshot – Um eine elastische Größenanpassung auf einem Cluster auszuführen, der Daten von einem freigegebenen Snapshot überträgt, muss mindestens eine Sicherung für den Cluster verfügbar sein. Sie können Ihre Backups in der Konsolen-Snapshot-Liste von Amazon Redshift, im describe-cluster-snapshots-CLI-Befehl oder in der API-Operation DescribeClusterSnapshots anzeigen.

• Plattformeinschränkung – Elastische Größenanpassung ist nur für Cluster verfügbar, die die EC2-VPC-Plattform verwenden. Weitere Informationen finden Sie unter Verwenden von EC2-VPC beim Erstellen Ihres Clusters.

• Überlegungen zur Speicherung – Stellen Sie sicher, dass Ihre neue Knotenkonfiguration über genügend Speicherplatz für vorhandene Daten verfügt. Möglicherweise müssen Sie zusätzliche Knoten hinzufügen oder die Konfiguration ändern.

• Quell- versus Ziel-Cluster-Größe – Die Knotenanzahl und der Knotentyp, die für die Größenänderung mit der elastischen Größenanpassung infrage kommen, werden durch die Anzahl der Knoten im Quell-Cluster und den Knotentyp bestimmt, der für den in der Größe geänderten Clusters ausgewählt wurde. Zum Ermitteln der verfügbaren Konfigurationen können Sie die Konsole verwenden. Oder Sie können den describe-node-configuration-options AWS CLI Befehl mit der action-type resize-cluster Option verwenden. Weitere Informationen zur Größenanpassung mithilfe der Amazon-Redshift-Konsole finden Sie unter Größenanpassung eines Clusters.

  Der folgende CLI-Beispielbefehl beschreibt die möglichen Konfigurationsoptionen. In diesem Beispiel handelt es sich bei dem Cluster mycluster um einen dc2.large-Cluster mit acht Knoten.

  aws redshift describe-node-configuration-options --cluster-identifier mycluster --region eu-west-1 --action-type resize-cluster

  Dieser Befehl gibt eine Optionenliste mit empfohlenen Knotentypen, der Knotenanzahl und der Festplattennutzung für jede Option aus. Die zurückgegebenen Konfigurationen können basierend auf dem spezifischen Eingabe-Cluster variieren. Sie können eine dieser Konfigurationen auswählen, wenn Sie die Optionen des CLI-Befehls resize-cluster angeben.

• Limit für zusätzliche Knoten – Die elastische Größenanpassung hat Limits für die Knoten, die Sie einem Cluster hinzufügen können. Beispielsweise unterstützt ein dc2-Cluster die elastische Größenanpassung bis zur doppelten Anzahl der Knoten. Zur Veranschaulichung können Sie einem dc2.8xlarge-Cluster mit 4 Knoten einen Knoten hinzufügen, um daraus einen Cluster mit fünf Knoten zu machen, oder weitere Knoten hinzufügen, bis Sie acht erreichen.

  Anmerkung

  Die Wachstums- und Reduktionsgrenzen basieren auf dem ursprünglichen Knotentyp und der Anzahl der Knoten im ursprünglichen Cluster oder seiner letzten klassischen Größenanpassung. Wenn eine elastische Größenanpassung die Wachstums- oder Reduktionsgrenze überschreitet, verwenden Sie eine klassische Größenanpassung.

  Bei einigen ra3-Knotentypen können Sie die Anzahl der Knoten um das Vierfache der vorhandenen Anzahl erhöhen. Gehen wir davon aus, Ihr Cluster besteht aus ra3.4xlarge oder ra3.16xlarge Knoten. Anschließend können Sie die elastische Größenanpassung verwenden, um die Anzahl der Knoten in einem Cluster mit 8 Knoten auf 32 zu erhöhen. Oder Sie können einen Wert unter dem Limit auswählen. (Beachten Sie, dass die Möglichkeit, den Cluster um das Vierfache zu vergrößern, von der Größe des Quell-Clusters abhängt.) Wenn Ihr Cluster ra3.xlplus-Knoten hat, ist das Limit doppelt so hoch.

  Alle ra3-Knotentypen unterstützen eine Verringerung der Anzahl der Knoten auf ein Viertel der vorhandenen Anzahl. Beispielsweise können Sie die Größe eines Clusters mit ra3.4xlarge-Knoten von 12 Knoten auf 3 oder auf eine Zahl über dem Minimum verringern.

  In der folgenden Tabelle sind die Wachstums- und Reduktionsgrenzen für jeden Knotentyp aufgeführt, der die elastische Größenanpassung unterstützt.

  Original-Knotentyp	Grenzwert	Begrenzung der Reduzierung
  ra3.16xlarge	4x (von 4 bis 16 Knoten, zum Beispiel)	Auf ein Viertel der Zahl (z. B. von 16 auf 4 Knoten)
  ra3.4xlarge	4x	Auf ein Viertel der Zahl
  ra3.xlplus	2x (von 4 bis 8 Knoten, zum Beispiel)	Auf ein Viertel der Zahl
  dc2.8xlarge	2x	Auf die Hälfte der Zahl (z. B. von 16 auf 8 Knoten)
  dc2.large	2x	Auf die Hälfte der Zahl
  ds2.8xlarge	2x	Auf die Hälfte der Zahl
  ds2.xlarge	2x	Auf die Hälfte der Zahl

  Anmerkung

  Auswahl älterer Knotentypen beim Ändern der Größe eines RA3-Clusters – Wenn Sie versuchen, die Größe von einem Cluster mit RA3-Knoten auf einen anderen Knotentyp wie DC2 oder DS2 zu ändern, wird in der Konsole eine Überprüfungswarnung angezeigt und der Größenänderungsvorgang wird nicht abgeschlossen. Dies liegt daran, dass die Größenänderung älterer Knotentypen nicht unterstützt wird. Dies soll verhindern, dass ein Kunde die Größe auf einen Knotentyp ändert, der veraltet ist oder bald veraltet sein wird. Dies gilt sowohl für die elastische als auch die klassische Größenanpassung.

Classic resize (Klassische Größenanpassung)

Die klassische Größenanpassung behandelt Anwendungsfälle, in denen die Änderung der Cluster-Größe oder des Knotentyps nicht von der elastischen Größenanpassung unterstützt wird. Wenn Sie eine klassische Größenanpassung durchführen, erstellt Amazon Redshift einen Ziel-Cluster und migriert Ihre Daten und Metadaten aus dem Quell-Cluster dorthin.

Die klassische Größenanpassung an RA3 kann für eine bessere Verfügbarkeit sorgen

Die klassische Größenanpassung wurde verbessert, wenn der Zielknotentyp RA3 ist. Dies geschieht durch die Verwendung einer Backup- und Wiederherstellungsoperation zwischen dem Quell- und dem Ziel-Cluster. Wenn die Größenanpassung beginnt, wird der Quell-Cluster neu gestartet und ist für einige Minuten nicht verfügbar. Danach ist der Cluster für Lese- und Schreibvorgänge verfügbar, während die Größenanpassung im Hintergrund fortgesetzt wird.

Überprüfen Ihres Clusters

Füllen Sie diese Checkliste aus, um sicherzustellen, dass Sie bei einer klassischen Größenanpassung eines RA3-Clusters die beste Leistung und optimale Ergebnisse erzielen. Wenn Sie die Checkliste nicht befolgen, können Sie möglicherweise einige der Vorteile der klassischen Größenänderung mit RA3-Knoten nicht nutzen, z. B. die Fähigkeit, Lese- und Schreiboperationen durchzuführen.

1. Die Größe der Daten muss unter 2 Petabyte liegen. (Ein Petabyte entspricht 1 000 Terabyte.) Erstellen Sie einen Snapshot und überprüfen Sie dessen Größe, um die Größe Ihrer Daten zu validieren. Sie können auch die folgende Abfrage ausführen, um die Größe zu überprüfen:

   SELECT
   sum(case when lower(diststyle) like ('%key%') then size else 0 end) distkey_blocks,
   sum(size) as total_blocks,
   ((distkey_blocks/(total_blocks*1.00)))*100 as Blocks_need_redist
   FROM svv_table_info;

   Die Tabelle svv_table_info ist nur für Superuser sichtbar.

2. Bevor Sie eine klassische Größenanpassung einleiten, stellen Sie sicher, dass Sie über einen manuellen Snapshot verfügen, der nicht älter als 10 Stunden ist. Erstellen Sie andernfalls einen Snapshot.

3. Der Snapshot, der für die klassische Größenanpassung verwendet wird, kann nicht für eine Tabellenwiederherstellung oder für andere Zwecke verwendet werden.

4. Der Cluster muss sich in einer VPC befinden.

Sortier- und Verteilungsoperationen, die sich aus der klassischen Größenanpassung an RA3 ergeben

Während der klassischen Größenanpassung an RA3 werden Tabellen mit KEY-Verteilung, die als EVEN-Verteilung migriert werden, in ihren ursprünglichen Verteilungsstil umgewandelt. Die Dauer dieses Vorgangs hängt von der Größe der Daten und der Auslastung Ihres Clusters ab. Abfrage-Workloads erhalten eine höhere Priorität als die Datenmigration. Weitere Informationen finden Sie unter Verteilungsstile. Während dieses Migrationsprozesses funktionieren sowohl Lese- als auch Schreibvorgänge in der Datenbank, die Durchführung von Abfragen kann jedoch länger dauern. Eine Nebenläufigkeitsskalierung kann die Leistung in dieser Zeit jedoch steigern, indem Ressourcen für Abfrage-Workloads hinzugefügt werden. Sie können den Fortschritt der Datenmigration anhand der Ergebnisse in den Ansichten SYS_RESTORE_STATE und SYS_RESTORE_LOG verfolgen. Weitere Informationen zur Überwachung folgen.

Nachdem die Größe des Clusters vollständig angepasst wurde, tritt das folgende Sortierverhalten auf:

• Wenn die Größenanpassung dazu führt, dass der Cluster mehr Segmente hat, werden die KEY-Verteilungstabellen teilweise unsortiert, EVEN-Tabellen bleiben jedoch sortiert. Darüber hinaus sind die Informationen darüber, wie viele Daten sortiert sind, möglicherweise direkt nach der Größenanpassung nicht aktuell. Nach der Schlüsselwiederherstellung wird die Tabelle durch die automatische Bereinigung im Laufe der Zeit sortiert.

• Wenn die Größenanpassung dazu führt, dass der Cluster weniger Segmente hat, werden sowohl die KEY- als auch die EVEN-Verteilungstabellen teilweise unsortiert. Die Tabelle wird durch die automatische Bereinigung im Laufe der Zeit sortiert.

Weitere Informationen zur automatischen Tabellenbereinigung finden Sie unter Bereinigen von Tabellen. Weitere Informationen zu Segmenten von Datenverarbeitungsknoten finden Sie unter Data Warehouse-Systemarchitektur.

Schritte zur klassischen Größenanpassung, wenn der Ziel-Cluster RA3 ist

Die klassische Größenanpassung besteht aus den folgenden Schritten, wenn der Ziel-Cluster-Typ RA3 ist und Sie die im vorherigen Abschnitt beschriebenen Voraussetzungen erfüllt haben.

1. Die Migration wird vom Quell-Cluster zum Ziel-Cluster eingeleitet. Wenn der neue Ziel-Cluster bereitgestellt wird, sendet Amazon Redshift eine Ereignisbenachrichtigung, dass die Größenanpassung begonnen hat. Ihr vorhandener Cluster wird neu gestartet, wodurch alle Verbindungen geschlossen werden. Wenn es sich bei Ihrem vorhandenen Cluster um einen Producer-Cluster für den Datenaustausch handelt, werden Verbindungen zu Consumer-Clustern ebenfalls geschlossen. Der Neustart dauert einige Minuten.

   Beachten Sie, dass jede Datenbankbeziehung, z. B. eine Tabelle oder eine materialisierte Ansicht, die mit BACKUP NO erstellt wurde, bei der klassischen Größenanpassung nicht beibehalten wird. Weitere Informationen finden Sie unter CREATE MATERIALIZED VIEW.

2. Nach dem Neustart steht die Datenbank für Lese- und Schreibvorgänge zur Verfügung. Darüber hinaus wird der Datenaustausch wieder aufgenommen, was wiederum einige Minuten dauert.

3. Zunächst werden Daten zum Ziel-Cluster migriert. Wenn der Zielknotentyp RA3 ist, sind Lese- und Schreibvorgänge während der Datenmigration verfügbar.

4. Wenn der Prozess der Größenanpassung fast abgeschlossen ist, aktualisiert Amazon Redshift den Endpunkt auf den Ziel-Cluster und alle Verbindungen zum Quell-Cluster werden getrennt. Der Ziel-Cluster wird zum Produzenten für die Datenfreigabe.

5. Die Größenanpassung wird abgeschlossen. Amazon Redshift sendet eine Ereignisbenachrichtigung.

Sie können den Fortschritt der Größenanpassung auf der Amazon-Redshift-Konsole anzeigen. Die Zeit, die zum Ändern der Größe eines Clusters benötigt wird, hängt von der Datenmenge ab.

Anmerkung

Auswahl älterer Knotentypen beim Ändern der Größe eines RA3-Clusters – Wenn Sie versuchen, die Größe von einem Cluster mit RA3-Knoten auf einen anderen Knotentyp wie DC2 oder DS2 zu ändern, wird in der Konsole eine Überprüfungswarnung angezeigt und der Größenänderungsvorgang wird nicht abgeschlossen. Dies liegt daran, dass die Größenänderung älterer Knotentypen nicht unterstützt wird. Dies soll verhindern, dass ein Kunde die Größe auf einen Knotentyp ändert, der veraltet ist oder bald veraltet sein wird. Dies gilt sowohl für die elastische als auch die klassische Größenanpassung.

Überwachung einer klassischen Größenanpassung, wenn der Ziel-Cluster RA3 ist

Verwenden Sie SYS_RESTORE_STATE, um den Fortschritt einer klassischen Größenanpassung eines bereitgestellten Clusters, einschließlich der KEY-Verteilung, zu überwachen. Es wird der Prozentsatz angezeigt, zu dem die Konvertierung der Tabelle abgeschlossen wurde. Sie müssen ein Superuser sein, um auf die Daten zugreifen zu können.

Löschen Sie Tabellen, die Sie nicht benötigen, wenn Sie eine klassische Größenanpassung durchführen. Dadurch können vorhandene Tabellen schneller verteilt werden.

Schritte zur klassischen Größenanpassung, wenn der Ziel-Cluster nicht RA3 ist

Die klassische Größenänderung besteht aus den folgenden Schritten, wenn der Zielknotentyp ein anderer als RA3 ist, beispielsweise DS2.

1. Die Migration wird vom Quell-Cluster zum Ziel-Cluster eingeleitet. Wenn der neue Ziel-Cluster bereitgestellt wird, sendet Amazon Redshift eine Ereignisbenachrichtigung, dass die Größenanpassung begonnen hat. Ihr vorhandener Cluster wird neu gestartet, wodurch alle Verbindungen geschlossen werden. Wenn es sich bei Ihrem vorhandenen Cluster um einen Producer-Cluster für den Datenaustausch handelt, werden Verbindungen zu Consumer-Clustern ebenfalls geschlossen. Der Neustart dauert einige Minuten.

   Beachten Sie, dass jede Datenbankbeziehung, z. B. eine Tabelle oder eine materialisierte Ansicht, die mit BACKUP NO erstellt wurde, bei der klassischen Größenanpassung nicht beibehalten wird. Weitere Informationen finden Sie unter CREATE MATERIALIZED VIEW.

2. Nach dem Neustart ist die Datenbank schreibgeschützt verfügbar. Der Datenaustausch wird wieder aufgenommen, was wiederum einige Minuten dauert.

3. Zunächst werden Daten zum Ziel-Cluster migriert. Die Datenbank bleibt schreibgeschützt.

4. Wenn der Prozess der Größenanpassung fast abgeschlossen ist, aktualisiert Amazon Redshift den Endpunkt auf den Ziel-Cluster und alle Verbindungen zum Quell-Cluster werden getrennt. Der Ziel-Cluster wird zum Produzenten für die Datenfreigabe.

5. Die Größenanpassung wird abgeschlossen. Amazon Redshift sendet eine Ereignisbenachrichtigung.

Sie können den Fortschritt der Größenanpassung auf der Amazon-Redshift-Konsole anzeigen. Die Zeit, die zum Ändern der Größe eines Clusters benötigt wird, hängt von der Datenmenge ab.

Anmerkung

Es kann Tage oder möglicherweise Wochen dauern, die Größe eines Clusters mit einer großen Datenmenge anzupassen, wenn der Ziel-Cluster nicht RA3 ist oder der Cluster die im vorherigen Abschnitt beschriebenen Voraussetzungen für einen RA3-Ziel-Cluster nicht erfüllt.

Beachten Sie auch, dass sich die genutzte Speicherkapazität für den Cluster nach einer klassischen Größenanpassung erhöhen kann. Dies entspricht dem normalen Systemverhalten, wenn der Cluster infolge der klassischen Größenanpassung über zusätzliche Daten-Slices verfügt. Diese Nutzung zusätzlicher Kapazität kann auch dann erfolgen, wenn die Anzahl der Knoten im Cluster gleich bleibt.

Elastische Größenanpassung im Vergleich zur klassischen Größenanpassung

In der folgenden Tabelle wird das Verhalten zwischen den beiden Größenanpassungstypen verglichen.

Elastische Größenanpassung im Vergleich zur klassischen Größenanpassung
Behavior	Elastic resize (Elastische Größenanpassung)	Classic resize (Klassische Größenanpassung)	Kommentare
Aufbewahrung von Systemdaten	Die elastische Größenanpassung behält die Systemprotokolldaten bei.	Die klassische Größenanpassung behält keine Systemtabellen und -daten bei.	Wenn Sie die Audit-Protokollierung in Ihrem Quell-Cluster aktiviert haben, können Sie nach einer Größenänderung weiterhin auf die Protokolle in Amazon S3 oder in CloudWatch zugreifen. Sie können diese Protokolle je nach Vorgabe Ihrer Datenrichtlinien behalten oder löschen
Ändern von Knotentypen	Elastische Größenanpassung, wenn sich der Knotentyp nicht ändert: Größenänderung vor Ort, und die meisten Abfragen werden gehalten. Elastische Größenanpassung mit einem neuen ausgewählten Knotentyp: Ein neuer Cluster wird erstellt. Abfragen werden entfernt, wenn der Größenanpassungsprozess abgeschlossen ist.	Klassische Größenanpassung: Ein neuer Cluster wird erstellt. Abfragen werden während des Größenanpassungsprozess entfernt.
Aufbewahrung von Sitzungen und Abfragen	Die elastische Größenanpassung behält Sitzungen und Abfragen bei, wenn der Knotentyp im Quellcluster und im Ziel identisch ist. Wenn Sie einen neuen Knotentyp auswählen, werden Abfragen entfernt.	Die klassische Größenanpassung behält keine Sitzungen und Abfragen bei. Abfragen werden entfernt.	Wenn Abfragen entfernt werden, müssen Sie mit einer gewissen Leistungsminderung rechnen. Am besten führen Sie eine Größenanpassung während einer Zeit mit geringer Nutzung durch.
Abbrechen einer Größenanpassung	Sie können eine elastische Größenanpassung nicht abbrechen.	Sie können eine klassische Größenanpassung abbrechen, bevor sie abgeschlossen ist. Wählen Sie dafür Cancel resize (Größenanpassung abbrechen) in den Clusterdetails in der Amazon-Redshift-Konsole.	Die zum Abbrechen einer Größenanpassung erforderliche Zeit hängt davon ab, in welcher Stufe sich die Größenanpassung gerade befindet, wenn sie abgebrochen wird. Wenn Sie dies tun, ist der Cluster nicht verfügbar, bis der Abbruchvorgang abgeschlossen ist. Wenn sich der Größenanpassungsvorgang in der Endphase befindet, können Sie ihn nicht abbrechen. Eine klassische Größenanpassung eines RA3-Clusters können Sie nicht abbrechen.

Planen einer Größenanpassung

Sie können Größenanpassungsvorgänge für Ihren Cluster so planen, dass er hochskaliert wird, um eine hohe Auslastung zu antizipieren, oder herunterskaliert wird, um Kosten zu sparen. Die Planung funktioniert sowohl für die elastische als auch für die klassische Größenanpassung. Sie können einen Zeitplan in der Amazon-Redshift-Konsole einrichten. Weitere Informationen finden Sie unter Größenanpassung eines Clusters, unter Managing clusters using the console (Verwalten von Clustern mithilfe der Konsole). Sie können auch unsere Amazon Redshift Redshift-API-Operationen verwenden AWS CLI , um eine Größenänderung zu planen. Weitere Informationen finden Sie create-scheduled-actionin der AWS CLI Befehlsreferenz oder CreateScheduledActionin der Amazon Redshift API-Referenz.

Snapshot, Wiederherstellung und Größenanpassung

Die elastische Größenanpassung stellt die schnellste Möglichkeit für die Anpassung der Größe eines Amazon-Redshift-Clusters dar. Wenn die elastische Größenanpassung keine Option für Sie darstellt und Sie einen annähernd konstanten Schreibzugriff auf Ihren Cluster benötigen, verwenden Sie die im folgenden Abschnitt beschriebene Snapshot- und Wiederherstellungsoperationen mit klassischer Größenanpassung. Dafür ist es erforderlich, dass alle Daten, die nach der Erstellung des Snapshots zum Quellcluster geschrieben werden, nach dem Wechsel manuell zum Zielcluster kopiert werden. Je nachdem, wie lange der Kopiervorgang dauert, müssen Sie dies möglicherweise mehrmals wiederholen, bis sich in beiden Clustern die gleichen Daten befinden. Anschließend können Sie den Wechsel zum Zielcluster durchführen. Dieser Prozess kann negative Auswirkungen auf bestehende Abfragen haben, bis alle Daten im Zielcluster verfügbar sind. Er minimiert jedoch den Zeitraum, in dem keine Schreibvorgänge in der Datenbank möglich sind.

Der Snapshot-, Wiederherstellungs- und klassische Größenanpassungsansatz verwendet den folgenden Prozess:

1. Erstellen Sie einen Snapshot des bestehenden Clusters. Der bestehende Cluster ist der Quellcluster.

2. Notieren Sie sich die Erstellungszeit des Snapshots. Auf diese Weise können Sie später den Punkt identifizieren, an dem Sie Extraktions-, Transaktions- und Lade-Prozesse (ETL) erneut ausführen müssen, um nach dem Snapshot entstandene Daten in die Zieldatenbank zu laden.

3. Stellen Sie den Snapshot in einem neuen Cluster wieder her. Dieser neue Cluster ist der Zielcluster. Prüfen Sie, ob sich die Beispieldaten im Zielcluster befinden.

4. Passen Sie die Größe des Zielclusters an. Wählen Sie den Knotentyp, die Anzahl der Knoten und andere Einstellungen für den Zielcluster.

5. Prüfen Sie die Ladungen aus Ihren ETL-Prozessen, die nach der Erstellung des Snapshots des Quellclusters aufgetreten sind. Achten Sie darauf, die Daten in der gleichen Reihenfolge erneut in den Zielcluster zu laden. Wenn Datenladevorgänge laufen, wiederholen Sie diesen Prozess mehrmals, bis die Daten im Quell- und Zielcluster identisch sind.

6. Halten Sie alle laufenden Abfragen auf dem Quellcluster an. Hierzu können Sie den Cluster erneut starten oder sich als Superuser anmelden und die Befehle PG_CANCEL_BACKEND und PG_TERMINATE_BACKEND verwenden. Der Neustart des Clusters ist die einfachste Möglichkeit, um sicherzustellen, dass der Cluster nicht verfügbar ist.

7. Benennen Sie den Quellcluster um. Beispielsweise von examplecluster zu examplecluster-source.

8. Geben Sie dem Zielcluster den vorherigen Namen des Quellclusters. Benennen Sie beispielsweise den Zielcluster als examplecluster. Von diesem Punkt an verbinden sich alle Anwendungen, die den Endpunkt mit examplecluster verwenden, mit dem Zielcluster.

9. Löschen Sie nach dem Wechsel zum Zielcluster den Quellcluster, und prüfen Sie, ob alle Prozesse wie erwartet ausgeführt werden.

Alternativ können Sie den Quell- und den Zielcluster umbenennen, bevor Sie Daten erneut in den Zielcluster laden. Dieser Ansatz funktioniert, wenn es nicht erforderlich ist, dass alle abhängigen Systeme und Berichte sofort denen des Ziel-Clusters entsprechen. In diesem Fall wird Schritt 6 an das Ende des oben beschriebenen Prozesses verschoben.

Die Umbenennung ist nur erforderlich, wenn die Anwendungen weiterhin den selben Endpunkt für die Verbindung zum Cluster verwenden müssen. Wenn dies nicht erforderlich ist, können Sie stattdessen alle Anwendungen, die sich mit dem Cluster verbinden, so aktualisieren, dass sie den Endpunkt des Zielclusters verwenden, ohne den Cluster umzubenennen.

Die Wiederverwendung eines Clusternamens bietet eine Reihe von Vorteilen. Zunächst müssen Sie dann keine Anwendungsverbindungszeichenfolgen aktualisieren, da der Endpunkt gleich bleibt, obwohl sich der zugrunde liegende Cluster ändert. Zweitens sind verwandte Elemente wie CloudWatch Amazon-Alarme und Amazon Simple Notification Service (Amazon SNS) -Benachrichtigungen an den Clusternamen gebunden. Durch diese Verknüpfung können Sie weiterhin die Alarme und Benachrichtigungen verwenden, die Sie für den Cluster eingerichtet haben. Diese fortgesetzte Verwendung ist besonders in Produktionsumgebungen relevant, in denen Sie die Flexibilität benötigen, die Größe des Clusters anzupassen, ohne zugehörige Elemente wie Alarme und Benachrichtigungen neu zu konfigurieren.