Amazon Redshift unterstützt UDFs ab Patch 198 nicht mehr die Erstellung von neuem Python. Das bestehende Python UDFs wird bis zum 30. Juni 2026 weiterhin funktionieren. Weitere Informationen finden Sie im [Blog-Posting](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Cluster-Operationen
Nachdem Sie einen Cluster erstellt haben, können Sie Clustervorgänge ausführen, um die Leistung zu optimieren, die Kosten zu kontrollieren und eine hohe Verfügbarkeit sicherzustellen. Clustervorgänge ermöglichen Ihnen, die Größe von Clustern zu ändern, sie anzuhalten, fortzusetzen oder sogar neu zu erstellen, wenn sich Ihre Data Warehousing-Anforderungen weiterentwickeln.
Zu den häufigsten Anwendungsfällen gehören die Skalierung der Rechenkapazität für Spitzenauslastungen, das Anhalten von Clustern während inaktiver Zeiten, um die Kosten zu senken, und das Neuerstellen von Clustern mit unterschiedlichen Konfigurationen oder in verschiedenen Availability Zones für die Notfallwiederherstellung. In den folgenden Abschnitten werden die Einzelheiten der Ausführung verschiedener Cluster-Operationen zur effektiven Verwaltung Ihrer Amazon-Redshift-Umgebung behandelt.
# Einen Cluster erstellen
Mit Amazon Redshift können Sie einen bereitgestellten Cluster erstellen, um ein neues Data Warehouse zu starten. Ein bereitgestellter Cluster ist eine Sammlung von Datenverarbeitungsressourcen, den sogenannten Knoten, die zu einem einzigen MPP-System (Massively Parallel Processing) zusammengefasst werden.
Bevor Sie einen Cluster erstellen, lesen Sie [Von Amazon Redshift bereitgestellte Cluster](working-with-clusters.md) und [Cluster und Knoten in Amazon Redshift](working-with-clusters.md#rs-about-clusters-and-nodes).
**So erstellen Sie einen Cluster**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster) aus. Die Cluster für Ihr Konto in der aktuellen AWS Region werden aufgelistet. Eine Teilmenge der Eigenschaften jedes Clusters wird in den Spalten der Liste angezeigt.
1. Wählen Sie **Create cluster (Cluster erstellen)** aus, um einen Cluster zu erstellen.
1. Folgen Sie den Anweisungen auf der Konsolenseite, um die Eigenschaften für die **Cluster configuration (Clusterkonfiguration)** einzugeben.
Der folgende Schritt beschreibt eine Amazon Redshift Redshift-Konsole, die in einer läuft AWS-Region , die RA3 Knotentypen unterstützt. Eine Liste der AWS-Regionen unterstützten RA3 Knotentypen finden Sie unter [Überblick über RA3 Knotentypen](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-ra3-node-types) im *Amazon Redshift Management Guide*.
Wenn Sie nicht wissen, wie groß Ihr Cluster sein sollte, wählen Sie **Help me choose (Hilfe bei der Auswahl)** aus. Dadurch wird ein Größenbestimmungsrechner gestartet, der Ihnen Fragen zur Größe und zu Abfragemerkmalen der Daten stellt, die Sie in Ihrem Data Warehouse speichern möchten. Wenn Sie die erforderliche Größe Ihres Clusters kennen (d. h. den Knotentyp und die Anzahl der Knoten), wählen Sie **I'll choose** (Ich entscheide) aus. Wählen Sie den **Node type** (Knotentyp) und die Anzahl der **Nodes** (Knoten) aus, um die Größe Ihres Clusters für den Machbarkeitsnachweis zu bestimmen.
**Anmerkung**
Wenn Ihre Organisation berechtigt ist und Ihr Cluster in einer AWS-Region erstellt wird, in der Amazon Redshift Serverless nicht verfügbar ist, können Sie möglicherweise im Rahmen des kostenlosen Testprogramms von Amazon Redshift einen Cluster erstellen. Wählen Sie entweder **Produktion** oder **Kostenlose Testversion** als Antwort auf die Frage: **Wofür möchten Sie diesen Cluster verwenden?** Wenn Sie **Kostenlose Testversion** auswählen, erstellen Sie eine Konfiguration mit dem Knotentyp dc2.large. Weitere Informationen zur Auswahl einer kostenlosen Testversion finden Sie unter [Kostenloses Testprogramm für Amazon Redshift](https://aws.amazon.com/redshift/free-trial/). Eine Liste, AWS-Regionen wo Amazon Redshift Serverless verfügbar ist, finden Sie unter den für die [Redshift Serverless](https://docs.aws.amazon.com/general/latest/gr/redshift-service.html) API aufgelisteten Endpoints in der. *Allgemeine Amazon Web Services-Referenz*
1. Geben Sie im Bereich **Datenbankkonfiguration** einen Wert für **Administrator-Benutzername** ein. Für **Administratorpasswort** können Sie eine der folgenden Optionen auswählen:
+ **Ein Passwort erstellen** – Verwendung eines von Amazon Redshift generierten Passworts.
+ **Administratorpasswort manuell hinzufügen** – Verwendung Ihres eigenen Passworts.
+ **Administratoranmeldedaten verwalten in AWS Secrets Manager** — Amazon Redshift verwendet AWS Secrets Manager , um Ihr Administratorkennwort zu generieren und zu verwalten. Für AWS Secrets Manager die Generierung und Verwaltung Ihres Passworts fällt eine Gebühr an. Informationen zur AWS Secrets Manager Preisgestaltung finden Sie unter [AWS Secrets Manager Preise](https://aws.amazon.com/secrets-manager/pricing/).
1. (Optional) Befolgen Sie die Anweisungen auf der Konsolenseite, um Eigenschaften für **Cluster permissions (Clusterberechtigungen)** einzugeben. Geben Sie Cluster-Berechtigungen an, wenn Ihr Cluster für Sie auf andere AWS Dienste zugreifen muss, z. B. um Daten von Amazon S3 zu laden.
1. Wählen Sie **Create cluster (Cluster erstellen)** aus, um den Cluster zu erstellen. Es kann einige Minuten dauern, bis der Cluster zur Verwendung bereit ist.
## Zusätzliche Konfigurationen
Wenn Sie einen Cluster erstellen, können Sie zusätzliche Eigenschaften angeben, um ihn anzupassen. Weitere Details zu einigen dieser Eigenschaften finden Sie in der folgenden Liste.
**IP-Adresstyp**
Wählen Sie den IP-Adresstyp für Ihren Cluster aus. Sie können wählen, ob Ihre Ressourcen nur über das IPv4 Adressierungsprotokoll kommunizieren sollen, oder den Dual-Stack-Modus wählen, bei dem Ihre Ressourcen IPv4 sowohl IPv6 als auch kommunizieren können. Diese Funktion ist nur in den Regionen AWS GovCloud (USA-Ost) und AWS GovCloud (US-West) verfügbar. Weitere Informationen zu Regionen finden Sie unter AWS [Regionen und Availability Zones](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/).
**Virtual Private Cloud (VPC)**
Wählen Sie eine VPC mit einer Cluster-Subnetzgruppe aus. Nachdem der Cluster erstellt wurde, kann die Cluster-Subnetzgruppe nicht mehr geändert werden.
**Parametergruppen**
Wählen Sie eine Cluster-Parametergruppe aus, die dem Cluster zugeordnet werden soll. Wenn Sie keine auswählen, verwendet der Cluster die Standard-Parametergruppe.
**Verschlüsselung**
Wählen Sie, ob alle Daten in dem Cluster und seinen Snapshots verschlüsselt werden sollen. Wenn Sie die Standardeinstellung, **None (Keine)**, unverändert lassen, wird die Verschlüsselung nicht aktiviert. Wenn Sie die Verschlüsselung aktivieren möchten, wählen Sie aus, ob Sie AWS Key Management Service (AWS KMS) oder ein Hardware-Sicherheitsmodul (HSM) verwenden möchten, und konfigurieren Sie dann die entsprechenden Einstellungen. Weitere Informationen zur Verschlüsselung in Amazon Redshift finden Sie unter [Verschlüsselung von Amazon-Redshift-Datenbanken](working-with-db-encryption.md).
+ **KMS**
Wählen Sie **Verwenden AWS Key Management Service (AWS KMS)**, wenn Sie die Verschlüsselung aktivieren und AWS KMS zur Verwaltung Ihres Verschlüsselungsschlüssels verwenden möchten. Wählen Sie außerdem den zu verwendenden Schlüssel aus. Sie können einen Standardschlüssel, einen Schlüssel aus dem aktuellen Konto oder einen Schlüssel aus einem anderen Konto auswählen.
**Anmerkung**
Wenn Sie einen Schlüssel von einem anderen AWS Konto verwenden möchten, geben Sie den Amazon-Ressourcennamen (ARN) für den zu verwendenden Schlüssel ein. Sie müssen über die Berechtigung zur Verwendung des Schlüssels verfügen. Weitere Informationen zum Zugriff auf Schlüssel in AWS KMS finden Sie unter [Steuern des Zugriffs auf Ihre Schlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html) im *AWS Key Management Service Entwicklerhandbuch*.
Weitere Informationen zur Verwendung von AWS KMS Verschlüsselungsschlüsseln in Amazon Redshift finden Sie unter[Verschlüsselung mit AWS KMS](working-with-db-encryption.md#working-with-aws-kms).
+ **HSM**
Wählen Sie **HSM**, wenn Sie die Verschlüsselung aktivieren und ein Hardware Security Module (HSM) zur Verwaltung Ihres Verschlüsselungsschlüssels verwenden möchten.
Wenn Sie **HSM** auswählen, wählen Sie Werte aus **HSM Connection** und **HSM Client Certificate** aus. Diese Werte sind erforderlich, damit Amazon Redshift und das HSM eine Vertrauensverbindung eingehen können, über die der Cluster-Schlüssel weitergegeben werden kann. Die HSM-Verbindung und das Client-Zertifikat müssen in Amazon Redshift eingerichtet werden, bevor Sie einen Cluster starten. Für weitere Informationen zur Einrichtung von HSM-Verbindungen und Client-Zertifikaten vgl. [Verschlüsselung mit Hardwaresicherheitsmodulen](working-with-db-encryption.md#working-with-HSM).
**Maintenance track (Wartungs-Track**
Sie können auswählen, ob die verwendete Cluster-Version der Track **Current**, **Trailing** oder manchmal **Preview** ist.
**Überwachung**
Sie können wählen, ob Sie CloudWatch Alarme erstellen möchten.
**Configure cross-region snapshot (Regionsübergreifenden Snapshot konfigurieren**
Sie können auswählen, ob Sie regionsübergreifende Snapshots aktivieren möchten.
**Automated Snapshot Retention Period** (Automatisierter Snapshot-Aufbewahrungszeitraum)
Sie können die Anzahl der Tage (max. 35 Tage) auswählen, für die diese Snapshots aufbewahrt werden sollen. Wenn der Knotentyp ist DC2, können Sie Null (0) Tage wählen, um keine automatisierten Snapshots zu erstellen.
**Manual snapshot retention period** (Aufbewahrungszeitraum für manuelle Snaspshots)
Sie können die Anzahl der Tage, für die diese Snapshots aufbewahrt werden sollen, oder `Indefinitely` auswählen.
**Zusätzliche Rechenressourcen für automatische Optimierungen**
Sie können wählen, ob Sie zusätzliche Rechenressourcen für automatische Optimierungen zuweisen möchten, auch in Zeiten starker Nutzung. Weitere Informationen finden Sie unter [Zuweisen zusätzlicher Rechenressourcen für die automatische Datenbankoptimierung](https://docs.aws.amazon.com/redshift/latest/dg/t_extra-compute-autonomics.html) im *Amazon Redshift Database Developer Guide*.
# Erstellen eines Speicherplatzalarms
Sie können die Festplattenspeichernutzung überwachen und Alarme einrichten, so dass Sie benachrichtigt werden, wenn der Festplattenspeicher einen bestimmten Schwellenwert für einen Cluster überschreitet. Durch die Erstellung eines Alarms zur Speicherplatznutzung können Sie die Speicherkapazität proaktiv verwalten und Probleme verhindern, die durch unzureichenden Festplattenspeicher verursacht werden, wie z. B. Abfragefehler oder Datenerfassungsfehler. Mit den folgenden Schritten können Sie einen Alarm zur Speicherplatznutzung erstellen.
**So erstellen Sie einen Speicherplatzalarm für einen Cluster**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Alarms** (Alarme) aus.
1. Wählen Sie für **Actions (Aktionen)** **Create alarm (Alarm erstellen)** aus. Die Seite **Create alarm (Alarm erstellen)** wird angezeigt.
1. Folgen Sie den Anweisungen auf der Seite.
1. Wählen Sie **Create Alarm** (Alarm erstellen) aus.
# Anzeigen eines Clusters
Durch die Anzeige eines Clusters können Sie die Konfiguration, den Status und die Leistungsmetriken Ihres Clusters überwachen und verwalten. Durch die Anzeige der Cluster-Details erhalten Sie Einblicke in die Ressourcennutzung, die Ausführungszeiten von Abfragen und den Systemzustand. Das folgende Verfahren zeigt, wie Sie auf Cluster-Informationen zugreifen.
**So zeigen Sie einen Cluster an**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster) aus. Die Cluster für Ihr Konto in der aktuellen AWS Region werden aufgelistet. Eine Teilmenge der Eigenschaften jedes Clusters wird in den Spalten der Liste angezeigt. Wenn Sie keine Cluster haben, wählen Sie **Create cluster (Cluster erstellen)** aus, um einen Cluster zu erstellen.
1. Wählen Sie den Cluster-Namen in der Liste aus, um weitere Details zu einem Cluster anzuzeigen.
# Modifizieren eines Clusters
Wenn Sie einen Cluster modifizieren, werden Änderungen an den folgenden Optionen sofort angewendet:
+ **VPC-Sicherheitsgruppen**
+ **Publicly accessible** (Öffentlich zugänglich)
+ **Admin user password** (Passwort des Administratorbenutzers)
+ **HSM-Verbindung**
+ **HSM Client Certificate (HSM-Clientzertifikat**
+ **Maintenance detail (Wartungsdetails**
+ **Snapshot preferences (Snapshot-Voreinstellungen**
Änderungen an den folgenden Optionen werden erst nach dem Neustart des Clusters wirksam:
+ **Cluster Identifier (Cluster-Kennung**
Amazon Redshift startet den Cluster automatisch neu, wenn Sie **Cluster Identifier (Cluster-ID)** ändern.
+ **Enhanced VPC routing (Erweitertes VPC-Routing**
Amazon Redshift startet den Cluster automatisch neu, wenn Sie **Enhanced VPC Routing** ändern.
+ **Cluster-Parametergruppe**
+ **IP-Adresstyp**
Diese Funktion ist nur in den Regionen AWS GovCloud (USA-Ost) und AWS GovCloud (US-West) verfügbar. Weitere Informationen zu Regionen finden Sie unter AWS [Regionen und Availability Zones](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/).
Wenn Sie die Aufbewahrungszeit für automatisierte Snapshots verkürzen, werden automatisierte Snapshots, deren Einstellungen außerhalb des neuen Aufbewahrungszeitraums liegen, gelöscht. Weitere Informationen finden Sie unter [Amazon-Redshift-Snapshots und -Sicherungen](working-with-snapshots.md).
Weitere Informationen zu Cluster-Eigenschaften finden Sie unter [Zusätzliche Konfigurationen](create-cluster.md#cluster-create-console-configuration).
**So modifizieren Sie einen Cluster:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster) aus.
1. Wählen Sie den zu ändernden Cluster aus.
1. Wählen Sie **Edit**. Die Seite **Edit Cluster (Cluster bearbeiten)** wird angezeigt.
1. Aktualisieren Sie die Cluster-Eigenschaften. Nachfolgend sind einige der Eigenschaften aufgeführt, die Sie ändern können:
+ Cluster Identifier (Cluster-Kennung)
+ Snapshot-Aufbewahrung
+ Cluster relocation (Cluster-Verschiebung)
Die Konsole stellt Links zur entsprechenden Registerkarte mit Cluster-Details bereit, über die Sie die Einstellungen für **Netzwerk und Sicherheit**, **Wartung** und **Datenbankkonfigurationen** bearbeiten können.
1. Wählen Sie **Änderungen speichern ** aus.
# Größenanpassung eines Clusters
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.
Wenn Sie die Größe eines Clusters anpassen, geben Sie eine Anzahl von Knoten bzw. den Knotentyp an, die/der sich von der aktuellen Konfiguration des Clusters unterscheidet. Während der Größenänderung des Clusters können Sie keine Schreib- oder read/write Abfragen auf dem Cluster ausführen. Sie können nur Leseabfragen ausführen.
Für weitere Informationen zur Größenanpassung von Clustern, einschließlich einer Erläuterung des Vorgehens bei der Größenanpassung von Clustern mit verschiedenen Konzepten, vgl. [Größenanpassung eines Clusters](#resizing-cluster).
**So passen Sie die Größe eines Clusters an:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster) aus.
1. Wählen Sie den Cluster aus, dessen Größe geändert werden soll.
1. Wählen Sie für **Actions (Aktionen)** **Resize (Größe ändern)** aus. Die Seite **Resize cluster (Cluster-Größe ändern)** wird angezeigt.
1. Folgen Sie den Anweisungen auf der Seite. Sie können die Größe des Clusters jetzt, einmal zu einer bestimmten Zeit, ändern oder die Größe Ihres Clusters nach einem Zeitplan vergrößern und verkleinern.
1. Wählen Sie je nach Ihrer Auswahl die Option **Resize now** (Große jetzt ändern) oder **Schedule resize** (Größenänderung planen) aus.
Wenn Sie über reservierte Knoten verfügen, können Sie ein Upgrade auf RA3 reservierte Knoten durchführen. Sie können dies tun, wenn Sie über die Konsole eine Wiederherstellung von einem Snapshot oder eine elastische Größenanpassung durchführen. Sie können die Konsole verwenden, um sich durch den Prozess führen zu lassen. Weitere Informationen zum Upgrade auf RA3 Knoten finden Sie unter [Upgrade auf RA3 Knotentypen](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3).
Wenn Sie eine Größenänderung durchführen, um ein Upgrade von einem Knotentyp DC2 .large auf einen Knotentyp RA3 .large durchzuführen, konvertiert Amazon Redshift verschachtelte Sortierschlüssel automatisch in zusammengesetzte Sortierschlüssel. Diese Konvertierung ermöglicht den Zugriff auf das Feature zur Parallelitätsskalierung, die Abfragen von Tabellen mit verschachtelten Sortierschlüsseln nicht unterstützt. Diese automatische Konvertierung gewährleistet zwar die Kompatibilität mit RA3 Funktionen, kann sich jedoch auf Ihre vorhandenen Abfrageleistungsmuster auswirken.
Wenn Sie auch nach dem Upgrade auf RA3 Knoten verschachtelte Sortierschlüssel beibehalten möchten, können Sie Ihre Tabellen nach Abschluss der Größenänderung mit der gewünschten Sortierschlüsselkonfiguration neu erstellen. Wenn Sie diese Option auswählen, können Sie die Parallelitätsskalierung für diese Tabellen jedoch nicht verwenden.
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 DC2 Knoten zu Knoten. RA3 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.
**Topics**
+ [Elastic resize (Elastische Größenanpassung)](#elastic-resize)
+ [Classic resize (Klassische Größenanpassung)](#classic-resize-faster)
## 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. Tabellen ohne Backup werden nur für DC2 Knoten unterstützt. Bei allen anderen Cluster-Typen sind Tabellen ohne Backup im Snapshot enthalten. Weitere Informationen finden Sie unter [Ausschluss von Tabellen von Snapshots](working-with-snapshots.md#snapshots-no-backup-tables). 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](working-with-snapshots.md).
1. 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.
1. Die Sitzungsverbindungen werden wiederhergestellt und die Abfragen fortgesetzt.
1. 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.
1. 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 über reservierte Knoten verfügen, z. B. DC2 reservierte Knoten, können Sie bei einer Größenänderung auf RA3 reservierte Knoten umsteigen. 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 Upgrade auf RA3 Knoten finden Sie unter [Upgrade auf RA3 Knotentypen](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3).
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](https://docs.aws.amazon.com/redshift/latest/dg/t_Reclaiming_storage_space202.html).
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 zum Erstellen Ihres Clusters](working-with-clusters.md#cluster-platforms).
+ *Ü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](#resizing-cluster).
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.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/mgmt/resizing-cluster.html)
**Anmerkung**
**Auswahl älterer Knotentypen bei der Größenänderung eines RA3 Clusters** — Wenn Sie versuchen, die Größe von einem Cluster mit RA3 Knoten auf einen anderen Knotentyp zu ändern DC2, wird z. B. eine Bestätigungswarnung in der Konsole angezeigt und die Größenänderung 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ößenänderung kann für eine bessere Verfügbarkeit RA3 sorgen
Die klassische Größenänderung wurde verbessert, wenn der Zielknotentyp RA3 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
Um sicherzustellen, dass Sie bei der klassischen Größenänderung eines RA3 Clusters die beste Leistung und die besten Ergebnisse erzielen, füllen Sie diese Checkliste aus. 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 Möglichkeit, 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.
1. 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.
1. Der Snapshot, der für die klassische Größenanpassung verwendet wird, kann nicht für eine Tabellenwiederherstellung oder für andere Zwecke verwendet werden.
1. Der Cluster muss sich in einer VPC befinden.
#### Sortier- und Verteilungsoperationen, die sich aus der klassischen Methode ergeben, ändern die Größe auf RA3
Bei der klassischen Größenänderung auf werden Tabellen mit KEY-Verteilung RA3, die als EVEN-Verteilung migriert wurden, wieder in ihren ursprünglichen Verteilungsstil konvertiert. 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](https://docs.aws.amazon.com/redshift/latest/dg/c_choosing_dist_sort.html). 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\$1RESTORE\$1STATE](https://docs.aws.amazon.com/redshift/latest/dg/SYS_RESTORE_STATE.html) und [SYS\$1RESTORE\$1LOG](https://docs.aws.amazon.com/redshift/latest/dg/SYS_RESTORE_LOG.html) 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](https://docs.aws.amazon.com/redshift/latest/dg/t_Reclaiming_storage_space202.html). Weitere Informationen zu Segmenten von Datenverarbeitungsknoten finden Sie unter [Data Warehouse-Systemarchitektur](https://docs.aws.amazon.com/redshift/latest/dg/c_high_level_system_architecture.html).
#### Klassische Schritte zur Größenänderung, wenn der Zielcluster RA3
Die klassische Größenänderung besteht aus den folgenden Schritten, sofern der Zielclustertyp ist RA3 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.
1. 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.
1. Zunächst werden Daten zum Ziel-Cluster migriert. Wenn der Zielknotentyp ist RA3, sind Lese- und Schreibvorgänge während der Datenmigration verfügbar.
1. 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.
1. 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 bei der Größenänderung eines RA3 Clusters** — Wenn Sie versuchen, die Größe von einem Cluster mit RA3 Knoten auf einen anderen Knotentyp zu ändern DC2, wird z. B. eine Bestätigungswarnung in der Konsole angezeigt und die Größenänderung 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ößenänderung, wenn der Zielcluster RA3
Verwenden Sie [SYS\$1RESTORE\$1STATE](https://docs.aws.amazon.com/redshift/latest/dg/SYS_RESTORE_STATE.html), 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.
### Klassische Schritte zur Größenänderung, wenn der Zielcluster nicht RA3
Die klassische Größenänderung besteht aus den folgenden Schritten, wenn der Zielknotentyp ein anderer ist als RA3 DC2 beispielsweise.
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](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html).
1. Nach dem Neustart ist die Datenbank schreibgeschützt verfügbar. Der Datenaustausch wird wieder aufgenommen, was wiederum einige Minuten dauert.
1. Zunächst werden Daten zum Ziel-Cluster migriert. Die Datenbank bleibt schreibgeschützt.
1. 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.
1. 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 sogar Wochen dauern, die Größe eines Clusters mit einer großen Datenmenge zu ändern RA3, wenn der Zielcluster dies nicht tut oder er die im vorherigen Abschnitt beschriebenen Voraussetzungen für einen RA3 Zielcluster 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.
| 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. Bei der klassischen Größenänderung auf einen RA3 Cluster können Sie den Vorgang 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](#resizing-cluster), 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-action](https://docs.aws.amazon.com/cli/latest/reference/redshift/create-scheduled-action.html)in der *AWS CLI Befehlsreferenz* oder [CreateScheduledAction](https://docs.aws.amazon.com/redshift/latest/APIReference/API_CreateScheduledAction.html)in der *Amazon Redshift API-Referenz.*
### Snapshot, Wiederherstellung und Größenanpassung
Die [elastische Größenanpassung](#elastic-resize) 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.
1. 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.
1. 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.
1. Passen Sie die Größe des Zielclusters an. Wählen Sie den Knotentyp, die Anzahl der Knoten und andere Einstellungen für den Zielcluster.
1. 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.
1. 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\$1CANCEL\$1BACKEND](https://docs.aws.amazon.com/redshift/latest/dg/PG_CANCEL_BACKEND.html) und [PG\$1TERMINATE\$1BACKEND](https://docs.aws.amazon.com/redshift/latest/dg/PG_TERMINATE_BACKEND.html) verwenden. Der Neustart des Clusters ist die einfachste Möglichkeit, um sicherzustellen, dass der Cluster nicht verfügbar ist.
1. Benennen Sie den Quellcluster um. Beispielsweise von `examplecluster` zu `examplecluster-source`.
1. 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.
1. 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.
# Umbenennen von Clustern
Sie können einen Cluster nach Wunsch umbenennen. Da der Endpunkt Ihres Clusters den Clusternamen (auch als *Cluster-Kennung* bezeichnet) enthält, verwendet der Endpunkt nach der Umbenennung den neuen Namen. Zum Beispiel: Wenn Sie einen Cluster mit der Bezeichnung `examplecluster` haben und diesen in `newcluster` umbenennen, verwendet der Endpunkt die ID `newcluster`. Alle mit dem Cluster verbundenen Anwendungen müssen mit dem neuen Endpunkt aktualisiert werden.
Sie können einen Cluster umbenennen, wenn Sie den Cluster ändern möchten, mit dem sich Ihre Anwendungen verbinden, ohne dass der Endpunkt in diesen Anwendungen geändert werden muss. In diesem Fall müssen Sie zuerst den ursprünglichen Cluster umbenennen und dann den zweiten Cluster ändern, damit dieser den Namen des ursprünglichen Clusters vor der Umbenennung verwendet. Dies ist erforderlich, da die Cluster-ID innerhalb Ihres Kontos und Ihrer Region eindeutig sein muss und der ursprüngliche und der zweite Cluster daher nicht denselben Namen haben dürfen. Sie können dies tun, wenn Sie einen Cluster aus einem Snapshot wiederherstellen und die Verbindungseigenschaften der davon abhängigen Anwendungen nicht ändern möchten.
**Anmerkung**
Wenn Sie den ursprünglichen Cluster löschen, sind Sie für die Löschung aller nicht benötigten Cluster-Snapshots verantwortlich.
Wenn Sie einen Cluster umbenennen, wechselt dessen Status bis zum Abschluss des Vorgangs zu `renaming`. Der alte von dem Cluster verwendete DNS-Name wird sofort gelöscht, kann aber noch einige Minuten im Zwischenspeicher aufbewahrt werden. Der neue DNS-Name für den umbenannten Cluster wird nach etwa 10 Minuten wirksam. Der umbenannte Cluster ist erst verfügbar, wenn der neue Name wirksam ist. Der Cluster wird neu gestartet, und alle bestehenden Verbindungen zu dem Cluster werden getrennt. Wenn dies abgeschlossen ist, verwendet der Endpunkt den neuen Namen. Daher sollten Sie alle laufenden Abfragen anhalten, bevor Sie die Umbenennung beginnen, und diese nach Abschluss des Vorgangs neu starten.
Cluster-Snapshots werden beibehalten, und alle mit einem Cluster verbundenen Snapshot sind dies auch nach Abschluss der Umbenennung. Nehmen Sie beispielsweise an, Sie haben einen Cluster für Ihre Produktionsdatenbank, für den mehrere Snapshots vorliegen. Wenn Sie den Cluster umbenennen und dann in der Produktionsumgebung durch einen Snapshot ersetzen, sind dem umbenannten Cluster nach wie vor diese vorhandenen Snapshots zugeordnet.
CloudWatch Amazon-Alarme und Amazon Simple Notification Service (Amazon SNS) -Ereignisbenachrichtigungen sind mit dem Namen des Clusters verknüpft. Wenn Sie den Cluster umbenennen, müssen Sie diese entsprechend aktualisieren. Sie können die CloudWatch Alarme in der CloudWatch Konsole aktualisieren, und Sie können die Amazon SNS SNS-Ereignisbenachrichtigungen in der Amazon Redshift Redshift-Konsole im Bereich **Ereignisse** aktualisieren. Die Lade- und Abfragedaten für den Cluster zeigen nach wie vor Daten von vor und von nach der Umbenennung an. Die Leistungsdaten werden jedoch nach der Umbenennung zurückgesetzt.
Weitere Informationen finden Sie unter [Modifizieren eines Clusters](modify-cluster.md).
# Upgrade der Release-Version eines Clusters
Sie können ein Upgrade der Wartungsversion eines Clusters durchführen, bei dem der Wert für **Release Status (Versionsstatus)** **New release available (Neue Version verfügbar)** lautet. Wenn Sie die Wartungsversion upgraden, können Sie auswählen, ob Sie sofort upgraden oder im nächsten Wartungsfenster upgraden möchten.
**Wichtig**
Wenn Sie sofortige Aktualisierung auswählen, ist Ihr Cluster bis zum Abschluss der Aktualisierung offline.
**So aktualisieren Sie einen Cluster auf eine neue Release-Version:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster) aus.
1. Wählen Sie den zu aktualisierenden Cluster aus.
1. Wählen Sie für **Actions (Aktionen)** **Upgrade cluster version (Cluster-Version upgraden)** aus. Die Seite **Upgrade cluster version (Cluster-Version upgraden)** wird angezeigt.
1. Folgen Sie den Anweisungen auf der Seite.
1. Wählen Sie **Upgrade cluster version** (Clusterversion aktualisieren) aus.
# Anhalten und Fortsetzen eines Clusters
Wenn Sie über einen Cluster verfügen, der nur zu bestimmten Zeiten verfügbar sein muss, können Sie den Cluster anhalten und ihn später fortsetzen. Während der Cluster angehalten ist , wird die On-Demand-Abrechnung unterbrochen. Nur für den Speicher des Clusters fallen Gebühren an. Weitere Informationen zu Preisen finden Sie unter [Amazon Redshift – Preise](https://aws.amazon.com/redshift/pricing/).
Wenn Sie einen Cluster anhalten, erstellt Amazon Redshift einen Snapshot, beendet Abfragen und versetzt den Cluster in einen Pause-Status. Wenn Sie einen angehaltenen Cluster löschen, ohne einen endgültigen Snapshot anzufordern, können Sie den Cluster nicht wiederherstellen. Sie können eine Pausierungs- oder Fortsetzungsoperation nicht mehr abbrechen oder zurücksetzen, nachdem sie gestartet wurde.
Sie können einen Cluster auf der Amazon Redshift Redshift-Konsole, mit den oder mit den AWS CLI Amazon Redshift Redshift-API-Vorgängen anhalten und wieder aufnehmen.
Sie können Aktionen zum Anhalten und Fortsetzen eines Clusters planen. Wenn Sie die neue Amazon-Redshift-Konsole verwenden, um einen wiederkehrenden Zeitplan zum Anhalten und Fortsetzen zu erstellen, werden zwei geplante Aktionen für den ausgewählten Datumsbereich erstellt. Die Namen der geplanten Aktion werden mit `-pause` und `-resume` suffigiert. Die Gesamtlänge des Namens muss innerhalb der maximalen Größe eines geplanten Aktionsnamens liegen.
Die folgenden Clustertypen können nicht angehalten werden:
+ EC2-Classic-Cluster.
+ Cluster, die nicht aktiv sind, z. B. ein Cluster, der derzeit geändert wird.
+ HSM (Hardware Security Module-Cluster
+ Cluster, für die automatisierte Snapshots deaktiviert sind.
Berücksichtigen Sie bei der Entscheidung, einen Cluster anzuhalten, Folgendes:
+ Verbindungen oder Abfragen zum Cluster sind nicht verfügbar.
+ Die Informationen zur Abfrageüberwachung eines angehaltenen Clusters auf der Amazon-Redshift-Konsole können nicht angezeigt werden.
+ Sie können einen angehaltenen Cluster nicht ändern. Alle geplanten Aktionen auf dem Cluster werden nicht ausgeführt. Dazu gehören das Erstellen von Snapshots, die Größenanpassung von Clustern und Clusterwartungsoperationen.
+ Hardware-Metriken werden nicht erstellt. Aktualisieren Sie Ihre CloudWatch Alarme, wenn Sie Alarme für fehlende Messwerte eingerichtet haben.
+ Sie können die letzten automatisierten Snapshots eines angehaltenen Clusters nicht in manuelle Snapshots kopieren.
+ Wenn ein Cluster angehalten ist, kann er erst fortgesetzt werden, wenn die Pausierungsoperation abgeschlossen ist.
+ Wenn Sie einen Cluster anhalten, wird die Abrechnung unterbrochen. Die Pausierungsoperation wird jedoch in der Regel innerhalb von 15 Minuten abgeschlossen, je nach Größe des Clusters.
+ Prüfprotokolle werden archiviert und beim Fortsetzen nicht wiederhergestellt.
+ Nachdem ein Cluster angehalten wurde, sind Ablaufverfolgungen und Protokolle möglicherweise nicht für die Behandlung von Problemen verfügbar, die vor dem Anhalten aufgetreten sind.
+ Wenn Sie Ihre Administratoranmeldedaten mithilfe Ihres Clusters verwalten AWS Secrets Manager und diesen pausieren, wird der geheime Schlüssel Ihres Clusters nicht gelöscht und der geheime Schlüssel wird Ihnen weiterhin in Rechnung gestellt. Weitere Informationen zur Verwaltung Ihres Redshift-Admin-Passworts mit finden Sie AWS Secrets Manager unter[Verwaltung von Amazon Redshift Redshift-Administratorkennwörtern mit AWS Secrets Manager](redshift-secrets-manager-integration.md).
+ Tabellen ohne Backup auf dem Cluster werden bei der Wiederaufnahme für RA3 Instance-Typen wiederhergestellt. Sie werden bei der Wiederaufnahme für DC2 Instance-Typen nicht wiederhergestellt. Weitere Informationen zu Tabellen ohne Backup finden Sie unter [Ausschluss von Tabellen von Snapshots](working-with-snapshots.md#snapshots-no-backup-tables).
Wenn Sie einen Cluster fortsetzen, sollten Sie Folgendes beachten:
+ Die Clusterversion des fortgesetzten Clusters wird basierend auf dem Wartungsfenster des Clusters auf die Wartungsversion aktualisiert.
+ Wenn Sie das Subnetz löschen, das einem angehaltenen Cluster zugeordnet ist, haben Sie möglicherweise ein inkompatibles Netzwerk. Stellen Sie in diesem Fall den Cluster aus dem neuesten Snapshot wieder her.
+ Wenn Sie eine Elastic IP-Adresse löschen, während der Cluster angehalten ist, wird eine neue Elastic IP-Adresse angefordert.
+ Wenn Amazon Redshift den Cluster mit seiner vorherigen Elastic-Network-Schnittstelle nicht fortsetzen kann, versucht Amazon Redshift, einen neuen zu reservieren.
+ Wenn Sie einen Cluster fortsetzen, können sich die IP-Adressen des Knotens ändern. Möglicherweise müssen Sie Ihre VPC-Einstellungen aktualisieren, um diese neuen IP-Adressen für Funktionen wie COPY from Secure Shell (SSH) oder COPY from Amazon EMR zu unterstützen.
+ Wenn Sie versuchen, einen Cluster fortzusetzen, der nicht angehalten ist, gibt die Fortsetzungsoperation einen Fehler zurück. Wenn die Fortsetzungsoperation Teil einer geplanten Aktion ist, ändern oder löschen Sie die geplante Aktion, um zukünftige Fehler zu vermeiden.
+ Je nach der Größe des Clusters kann es einige Minuten dauern, bis ein Cluster bei seiner Fortsetzung wieder Abfragen verarbeiten kann. Darüber hinaus kann die Abfrageleistung für einen gewissen Zeitraum beeinträchtigt sein, während der Cluster nach Abschluss der Fortsetzungsoperation erneut hydriert wird.
# Neustart eines Clusters
Der Neustart eines Clusters ist eine Cluster-Operation, bei der der Cluster mit derselben Konfiguration wie vor dem Neustart neu gestartet wird. Sie können einen Cluster neu starten, um ausstehende Wartungsupdates anzuwenden, Konfigurationsänderungen zurückzusetzen, bestimmte Probleme zu korrigieren oder Cluster-Probleme zu beheben. Der Neustart eines Clusters kann dazu beitragen, die optimale Leistung, Sicherheit und Stabilität der Amazon-Redshift-Umgebung zu gewährleisten. Das folgende Verfahren enthält detaillierte Schritte für den Neustart eines Amazon-Redshift-Clusters.
Wenn Sie einen Cluster neu starten, wird sein Status auf `rebooting` gesetzt, und nach Abschluss des Neustarts wird ein Clusterereignis erstellt. Alle ausstehenden Cluster-Änderungen werden bei diesem Neustart angewendet.
**So starten Sie einen Cluster neu:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster) aus.
1. Wählen Sie den Cluster aus, den Sie neu starten möchten.
1. Wählen Sie für **Actions (Aktionen)** **Reboot cluster (Cluster neu starten)** aus. Die Seite **Reboot cluster (Cluster neu starten)** wird angezeigt.
1. Wählen Sie **Reboot cluster** (Cluster neu starten) aus.
# Verschieben eines Clusters
Durch Verwendung von *relocation* (Verschiebung) in Amazon Redshift ermöglichen Sie Amazon Redshift, einen Cluster ohne Datenverlust oder Änderungen an Ihren Anwendungen in eine andere Availability Zone (AZ) zu verschieben. Mit der Verschiebung können Sie den Betrieb mit minimalen Auswirkungen fortsetzen, wenn es eine Serviceunterbrechung für den Cluster gibt.
Wenn Clusterverschiebung aktiviert ist, kann Amazon Redshift in einigen Situationen entscheiden, Cluster zu verschieben. Das geschieht insbesondere, wenn Probleme in der aktuellen Availability Zone einen optimalen Clusterbetrieb verhindern, oder um die Serviceverfügbarkeit zu verbessern. Sie können die Verschiebungsfunktion auch aufrufen, wenn Clustervorgänge durch Ressourceneinschränkungen in einer bestimmten Availability Zone beeinträchtigt sind. Ein Beispiel ist die Möglichkeit, einen Cluster fortzusetzen oder zu skalieren. Amazon Redshift bietet die Verschiebungsfunktion ohne zusätzliche Kosten an.
Wenn ein Amazon-Redshift-Cluster in eine neue Availability Zone verschoben wird, hat der neue Cluster denselben Endpunkt wie der ursprüngliche Cluster. Ihre Anwendungen können sich wieder mit dem Endpunkt verbinden und den Betrieb ohne Datenänderungen oder -verlust fortsetzen. Aufgrund möglicher Ressourceneinschränkungen in einer bestimmten Availability Zone ist eine Verschiebung jedoch nicht immer möglich.
Die Amazon Redshift-Cluster-Verlagerung wird nur für die RA3 Instance-Typen unterstützt. RA3 Instanztypen verwenden Redshift Managed Storage (RMS) als dauerhafte Speicherebene. Die neueste Kopie der Daten eines Clusters ist immer in anderen Availability Zones in einer AWS Region verfügbar. Mit anderen Worten: Sie können einen Amazon-Redshift-Cluster ohne Datenverlust in eine andere Availability Zone verschieben.
Wenn Sie die Verschiebung für Ihren Cluster aktivieren, migriert Amazon Redshift Ihren Cluster so, dass er sich hinter einem Proxy befindet. Dadurch wird ein standortunabhängiger Zugriff auf die Rechenressourcen eines Clusters implementiert. Die Migration bewirkt, dass der Cluster neu gestartet wird. Wenn ein Cluster in eine andere Availability Zone verschoben wird, tritt ein Ausfall auf, bis der neue Cluster in der neuen Availability Zone wieder online ist. Sie müssen jedoch keine Änderungen an Ihren Anwendungen vornehmen, da der Clusterendpunkt auch nach dem Verschieben des Clusters in die neue Availability Zone unverändert bleibt.
Die Clusterverlagerung ist standardmäßig für neu erstellte oder wiederhergestellte RA3 Cluster aktiviert, deren Subnetzgruppe mehrere Availability Zones umfasst. Amazon Redshift weist beim Erstellen eines bereitgestellten Clusters 5439 als Standardport zu. Sie können zu einem anderen Port aus dem Portbereich 5431–5455 oder 8191–8215 wechseln. (Wechseln Sie nicht zu einem Port außerhalb der Bereiche. Dies führt zu einem Fehler.) Um den Standardport für einen bereitgestellten Cluster zu ändern, verwenden Sie die Amazon Redshift Redshift-Konsole oder die Amazon Redshift Redshift-API. AWS CLI Um den Standardport für eine serverlose Arbeitsgruppe zu ändern, verwenden Sie die AWS CLI oder die Amazon Redshift Serverless API.
Wenn Sie die Verschiebung aktivieren und derzeit für den Zugriff auf Ihren Cluster die IP-Adresse des Führungsknotens oder Enhanced VPC Routing verwenden, ändern Sie diesen Zugriff. Verwenden Sie stattdessen die IP-Adresse, die dem VPC-Endpunkt (Virtual Private Cloud) des Clusters zugeordnet ist. Um diese Cluster-IP-Adresse zu finden, suchen und verwenden Sie den VPC-Endpunkt im Bereich **Network and security (Netzwerk und Sicherheit)** auf der Cluster-Detailseite. Melden Sie sich bei der Amazon-VPC-Konsole an, um weitere Informationen zum VPC-Endpunkt zu erhalten.
Sie können auch den Befehl AWS Command Line Interface (AWS CLI) verwenden`describe-vpc-endpoints`, um die dem Endpunkt zugeordnete elastic network interface abzurufen. Sie können den Befehl `describe-network-interfaces` verwenden, um zugeordnete IP-Adresse abzurufen. Weitere Informationen zu Amazon Redshift AWS CLI Redshift-Befehlen finden Sie unter [Verfügbare Befehle](https://docs.aws.amazon.com/cli/latest/reference/redshift/index.html) in der *AWS CLI Befehlsreferenz.*
## Einschränkungen
Beachten Sie die folgenden Einschränkungen, wenn Sie die Amazon-Redshift-Verschiebung verwenden:
+ Aufgrund potenzieller Ressourceneinschränkungen in einer bestimmten Availability Zone ist die Clusterverschiebung unter Umständen nicht in allen Szenarien möglich. In diesem Fall verändert Amazon Redshift den ursprünglichen Cluster nicht.
+ Die Verlagerung wird für DC2 Instance-Produktfamilien nicht unterstützt.
+ Sie können keine regionsübergreifende AWS Verlagerung durchführen.
+ Die Amazon-Redshift-Verschiebung verwendet standardmäßig die Portnummer 5439. Sie können auch zu einem anderen Port in den Bereichen 5431–5455 oder 8191–8215 wechseln.
## Verwalten der Verschiebung über die Konsole
Sie können die Einstellungen für die Clusterverschiebung über die Amazon-Redshift-Konsole verwalten.
### Deaktivieren der Verschiebung beim Erstellen eines neuen Clusters
Gehen Sie wie folgt vor, um die Verschiebung beim Erstellen eines neuen Clusters zu aktivieren.
**So deaktivieren Sie die Verschiebung für einen neuen Cluster**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster) aus.
1. Wählen Sie **Create cluster (Cluster erstellen)**, um einen neuen Cluster zu erstellen. Weitere Informationen zum Erstellen eines Clusters finden Sie unter [Erste Schritte mit von Amazon Redshift bereitgestellten Data Warehouses](https://docs.aws.amazon.com/redshift/latest/gsg/new-user.html) im *Amazon Redshift Getting Started Guide*.
1. Wählen Sie unter **Backup** bei **Cluster-Verschiebung** **Deaktiviert** aus. Standardmäßig ist die Verschiebung aktiviert.
1. Wählen Sie **Create cluster (Cluster erstellen)**.
### Ändern der Verschiebung für einen vorhandenen Cluster
Gehen Sie wie folgt vor, um die Verschiebungseinstellungen eines vorhandenen Clusters zu ändern.
**So ändern Sie die Verschiebungseinstellungen für einen vorhandenen Cluster**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster) aus. Die Cluster für Ihr Konto in der aktuellen AWS Region werden aufgelistet. Eine Teilmenge der Eigenschaften jedes Clusters wird in den Spalten der Liste angezeigt.
1. Wählen Sie in der Liste den Namen des Clusters aus, den Sie ändern möchten. Die Cluster-Detailseite wird angezeigt.
1. Wählen Sie die Registerkarte **Maintenance (Wartung)** und dann im Bereich **Backup details (Backup-Details)** **Edit (Bearbeiten)**.
1. Wählen Sie unter **Backup** **Aktiviert** aus. Standardmäßig ist die Verschiebung aktiviert.
1. Wählen Sie **Modify Cluster (Cluster bearbeiten)**.
### Verschieben eines Clusters
Gehen Sie wie folgt vor, um einen Cluster manuell in eine andere Availability Zone zu verschieben. Das ist besonders dann nützlich, wenn Sie Ihre Netzwerkeinrichtung in sekundären Availability Zones testen möchten oder wenn in der aktuellen Availability Zone Ressourceneinschränkungen auftreten.
**So verschieben Sie einen Cluster in eine andere Availability Zone**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster) aus. Die Cluster für Ihr Konto in der aktuellen AWS Region werden aufgelistet. Eine Teilmenge der Eigenschaften jedes Clusters wird in den Spalten der Liste angezeigt.
1. Wählen Sie in der Liste den Namen des Clusters aus, den Sie verschieben möchten. Die Cluster-Detailseite wird angezeigt.
1. Wählen Sie unter **Actions (Aktionen)** die Option **Relocate (Verschieben)**. Die Seite **Relocate cluster (Cluster verschieben)** wird angezeigt.
1. (Optional) Wählen Sie eine **Availability Zone** aus. Wenn Sie keine Availability Zone auswählen, wählt Amazon Redshift diese für Sie aus.
Amazon Redshift startet die Verschiebung und zeigt den Cluster als „relocating“ (wird verschoben) an. Nach Abschluss der Verschiebung ändert sich der Clusterstatus zu „available“ (verfügbar).
## Verwalten der Verschiebung mit der Amazon-Redshift-CLI
Sie können die Einstellungen für die Clusterverschiebung über die AWS -Befehlszeilenschnittstelle (Command Line Interface, CLI) verwalten.
Mit der AWS CLI erstellt der folgende Beispielbefehl einen Amazon Redshift Redshift-Cluster mit dem Namen**mycluster**, für den Relocation aktiviert ist.
```
aws redshift create-cluster --cluster-identifier mycluster --number-of-nodes 2 --master-username enter a username --master-user-password enter a password --node-type ra3.4xlarge --port 5439 --no-availability-zone-relocation
```
Wenn Ihr aktueller Cluster einen anderen Port verwendet, müssen Sie die Einstellung so ändern, dass der Cluster einen Port aus dem Portbereich 5431–5455 oder 8191–8215 verwendet, bevor Sie ihn ändern, um die Verschiebung zu aktivieren. Der Standardwert ist 5439. Mit dem folgenden Beispielbefehl ändern Sie den Port, wenn Ihr Cluster keinen Port aus dem angegebenen Bereich verwendet.
```
aws redshift modify-cluster --cluster-identifier mycluster --port 5439
```
Der folgende Beispielbefehl enthält den availability-zone-relocation Parameter auf dem Amazon Redshift Redshift-Cluster.
```
aws redshift modify-cluster --cluster-identifier mycluster --availability-zone-relocation
```
Der folgende Beispielbefehl deaktiviert den availability-zone-relocation Parameter auf dem Amazon Redshift Redshift-Cluster.
```
aws redshift modify-cluster --cluster-identifier mycluster --no-availability-zone-relocation
```
Der folgende Beispielbefehl startet die Verschiebung für den Amazon-Redshift-Cluster.
```
aws redshift modify-cluster --cluster-identifier mycluster --availability-zone us-east-1b
```
# Ein Nutzungslimit für einen Cluster festlegen
Sie können bis zu vier Nutzungslimits hinzufügen, um die Nutzung für jeden der folgenden Bereiche zu kontrollieren:
+ Nebenläufigkeitsskalierung
+ Automatische Optimierungen werden mit zusätzlichen Rechenressourcen ausgeführt
+ Nutzung von Redshift Spectrum
+ Regionsübergreifender Datenaustausch
## Festlegung eines Nutzungslimits für einen bereitgestellten Cluster
Im Folgenden wird beschrieben, wie Sie ein Nutzungslimit für einen bereitgestellten Cluster festlegen:
**So legen Sie ein Nutzungslimit für einen Cluster fest**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Navigieren Sie zu dem bereitgestellten Cluster, für den Sie ein Limit festlegen möchten.
1. Wählen Sie auf der Detailseite des Clusters im Dropdownmenü **Aktionen** die Option **Nutzungslimit verwalten** aus. Sie können auch die Registerkarte **Wartung** für einen Cluster auswählen, dann nach unten scrollen und **Nutzungslimits erstellen** auswählen.
1. Wählen Sie für das **Nutzungslimit, das Sie festlegen möchten, die Option Limit hinzufügen** aus. Sie können bis zu 4 Grenzwerte für eine bestimmte Funktion hinzufügen.
1. Legen Sie einen **Zeitraum** für das Nutzungslimit fest, der entweder **täglich**, **wöchentlich** oder **monatlich** ist.
1. Legen Sie ein **Nutzungslimit** fest.
+ Für Parallelitätsskalierung und automatische Optimierungen, die unter Verwendung zusätzlicher Rechenressourcenlimits ausgeführt werden, ist das Nutzungslimit die Zeit, die Amazon Redshift im angegebenen Zeitraum mit der Nutzung der Funktion verbringt. In diesem Fall wird das Nutzungslimit in Stunden und Minuten festgelegt.
+ Für Redshift Spectrum ist das Nutzungslimit die Menge der von Amazon S3 gescannten Daten. In diesem Fall wird das Nutzungslimit in Terabyte (TB) festgelegt.
+ Beim regionsübergreifenden Datenaustausch entspricht das Nutzungslimit der Datenmenge, die von der Erzeugerregion zu den Verbraucherregionen übertragen wird und die Verbraucher abfragen können. In diesem Fall wird das Nutzungslimit in Terabyte (TB) festgelegt.
1. Legen Sie die **Aktion** fest, die Amazon Redshift ausführen soll, wenn Ihr Cluster das Limit erreicht. Zur Verfügung stehen folgende Optionen:
+ **In Systemtabelle protokollieren** — Fügt der Systemansicht [SYS\$1QUERY\$1HISTORY](https://docs.aws.amazon.com/redshift/latest/dg/SYS_QUERY_HISTORY.html) einen Datensatz hinzu. Sie können die Spalte usage\$1limit in dieser Ansicht abfragen, um festzustellen, ob eine Abfrage das Limit überschritten hat.
+ **Warnung** — Verwendet Amazon SNS, um Benachrichtigungsabonnements einzurichten und Benachrichtigungen zu versenden, wenn ein Limit überschritten wird. Sie können ein vorhandenes Amazon SNS SNS-Thema auswählen, ein neues Thema erstellen oder ohne eines weitermachen.
+ **Funktion deaktivieren** ‐ Deaktiviert die Funktion. Sie können sich auch dafür entscheiden, Amazon SNS zum Senden einer Benachrichtigung zu verwenden. Benutzer können den Cluster weiterhin für andere Aufgaben verwenden.
Die ersten beiden Aktionen sind informativ, aber die letzte deaktiviert die Verwendung der Funktion.
1. Wählen Sie unten auf der Seite **Änderungen speichern** aus, um das Limit zu speichern. Wenn Sie mehr als ein Limit gleichzeitig festlegen, werden mit dem Befehl **Änderungen speichern** alle auf einmal gespeichert.
# Schließen und Löschen eines Clusters
Sie können Ihren Cluster schließen, wenn er nicht weiter betrieben und Kosten verursachen soll. Wenn Sie dies tun, können Sie optional einen abschließenden Snapshot erstellen. Wenn Sie einen abschließenden Snapshot erstellen, erstellt Amazon Redshift einen manuellen Snapshot Ihres Clusters, bevor es ihn schließt. Wenn Sie die Bereitstellung eines neuen Clusters mit denselben Daten und derselben Konfiguration des Clusters planen, den Sie löschen, benötigen Sie einen manuellen Snapshot. Wenn Sie einen manuellen Snapshot verwenden, können Sie ihn später wiederherstellen und dann damit den Cluster weiter betreiben.
Wenn Sie Ihren Cluster und dessen Daten nicht mehr benötigen, können Sie ihn schließen, ohne einen abschließenden Snapshot zu erstellen. In diesem Fall werden Cluster und Daten dauerhaft gelöscht.
Unabhängig davon, ob Sie Ihren Cluster mit einem abschließenden Snapshot schließen, werden alle mit dem Cluster verbundenen automatisierten Snapshots nach dem Schließen des Clusters gelöscht. Alle mit dem Cluster verbundenen manuellen Snapshots werden beibehalten. Alle beibehaltenen manuellen Snapshots, einschließlich des optionalen abschließenden Snapshots, unterliegen der Speichergebühr von Amazon Simple Storage Service, wenn Sie beim Schließen des Clusters keine weiteren aktiven Cluster haben oder wenn Sie den zur Ausführung Ihrer Amazon-Redshift-Cluster bereitgestellten kostenlosen Speicherplatz überschreiten. Weitere Informationen zu den Gebühren für die Speicherung von Snapshots finden Sie auf der Seite [Amazon Redshift – Preise](https://aws.amazon.com/redshift/pricing/).
Durch das Löschen eines Clusters werden auch alle zugehörigen AWS Secrets Manager Geheimnisse gelöscht.
**So löschen Sie einen Cluster**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster) aus.
1. Wählen Sie den zu löschenden Cluster aus.
1. Klicken Sie bei ** Actions** auf **Delete**. Die Seite **Delete cluster (Cluster löschen)** wird angezeigt.
1. Wählen Sie **Delete cluster** (Cluster löschen) aus.
**Anmerkung**
Wenn Sie einen Cluster löschen und sich dafür entscheiden, einen endgültigen Snapshot zu erstellen, stoppt Amazon Redshift die Löschanforderung, wenn auf dem Cluster ein Wiederherstellungsvorgang läuft. In diesem Fall können Sie den Cluster ohne einen endgültigen Snapshot löschen, oder Sie können ihn nach Abschluss der Wiederherstellung mit einem endgültigen Snapshot löschen.
# Amazon-Redshift-Snapshots und -Sicherungen
Snapshots sind point-in-time Backups eines Clusters. Es gibt zwei Arten von Snapshots: *automatisierte* und *manuelle*. Amazon Redshift speichert diese Snapshots intern in Amazon S3 unter Verwendung einer verschlüsselten Secure Sockets Layer (SSL)-Verbindung.
Amazon Redshift erstellt in regelmäßigen Abständen inkrementelle Snapshots und verfolgt so Änderungen am Cluster seit dem letzten automatisierten Snapshot nach. Automatisierte Snapshots speichern alle Daten, die erforderlich sind, um einen Cluster anhand eines Snapshots wiederherzustellen. Sie können mit einem Snapshot-Zeitplan steuern, wann automatisierte Snapshots erzeugt werden, oder jederzeit einen manuellen Snapshot erstellen.
Wenn Sie anhand eines Snapshots eine Wiederherstellung durchführen, erstellt Amazon Redshift einen neuen Cluster und stellt diesen bereit, bevor alle Daten geladen werden, sodass Sie umgehend mit dem Abfragen des neuen Clusters beginnen können. Der Cluster streamt auf Anfrage Daten vom Snapshot als Reaktion auf aktive Abfragen und lädt danach die restlichen Daten im Hintergrund.
Wenn Sie einen Cluster starten, können Sie den Aufbewahrungszeitraum für automatische und manuelle Snapshots festlegen. Sie können den standardmäßigen Aufbewahrungszeitraum für automatisierte und manuelle Snapshots ändern, indem Sie den Cluster modifizieren. Sie können den Aufbewahrungszeitraum für manuelle Snapshots festlegen, wenn Sie den Snapshot erstellen, und ihn ändern, indem Sie den Snapshot modifizieren.
Sie können den Fortschritt von Snapshots überwachen AWS-Managementkonsole, indem Sie die Snapshot-Details in der anzeigen oder die CLI- oder [DescribeClusterSnapshots](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeClusterSnapshots.html)API-Aktion aufrufen [describe-cluster-snapshots](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-cluster-snapshots.html). Für einen Snapshot in Bearbeitung werden Informationen wie die Größe des schrittweisen Snapshot, die Übertragungsrate, die verstrichene Zeit und die geschätzte Restzeit angezeigt.
Amazon Redshift speichert Snapshots in einem intern verwalteten Amazon-S3-Bucket, der von Amazon Redshift verwaltet wird, um sicherzustellen, dass Ihre Backups dem Cluster immer zur Verfügung stehen. Um die Speichergebühren zu verwalten, schätzen Sie ab, wie viele Tage Sie automatisierte Snapshots behalten müssen, und konfigurieren Sie dann den Aufbewahrungszeitraum entsprechend. Löschen Sie manuelle Snapshots, die nicht mehr benötigt werden. Weitere Informationen zu den Kosten von Backup-Speicher finden Sie auf der Seite [Amazon Redshift – Preise](https://aws.amazon.com/redshift/pricing/).
Sie können Snapshots auch mithilfe eines vollständig verwalteten Dienstes erstellen und wiederherstellen AWS Backup, der Sie dabei unterstützt, den Datenschutz AWS dienstübergreifend, in der Cloud und vor Ort zu zentralisieren und zu automatisieren. Weitere Informationen finden Sie unter [AWS Backup Integration mit Amazon Redshift](managing-aws-backup.md). Informationen zu finden Sie AWS Backup unter [Was ist? AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) im *AWS Backup Entwicklerhandbuch*.
## Arbeiten mit Snapshots und Backups in Amazon Redshift Serverless
Amazon Redshift Serverless ermöglicht es Ihnen, wie ein bereitgestellter Cluster, ein Backup als point-in-time Repräsentation der Objekte und Daten im Namespace zu erstellen. Es gibt zwei Arten von Backups in Amazon Redshift Serverless: manuell erstellte Snapshots und Wiederherstellungspunkte, die Amazon Redshift Serverless automatisch für Sie erstellt. Weitere Informationen zur Arbeit mit Snapshots für Amazon Redshift Serverless finden Sie unter [Snapshots und Wiederherstellungspunkte](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-snapshots-recovery-points.html).
Sie können auch einen Snapshot von einem bereitgestellten Cluster in einem Serverless-Namespace wiederherstellen. Weitere Informationen finden Sie unter [Wiederherstellen eines Serverless-Namespace aus einem Snapshot](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-snapshot-restore.html).
## Automatisierte Snapshots
Wenn automatisierte Snapshots für einen Cluster aktiviert sind, erstellt Amazon Redshift in regelmäßigen Abständen Snapshots dieses Clusters. Standardmäßig erzeugt Amazon Redshift ungefähr alle acht Stunden oder nach 5 GB geänderten Daten pro Knoten einen Snapshot, je nachdem, was zuerst auftritt. Wenn Ihre Daten größer als 5 GB \$1 der Anzahl der Knoten sind, beträgt die kürzeste Zeitspanne zwischen der Erstellung von automatisierten Snapshots 15 Minuten. Sie können alternativ mit einem Snapshot-Zeitplan steuern, wann automatisierte Snapshots erzeugt werden. Wenn Sie benutzerdefinierte Zeitpläne verwenden, beträgt die Mindestzeit zwischen automatisierten Snapshots eine Stunde. Automatisierte Snapshots werden standardmäßig aktiviert, wenn Sie einen Cluster erstellen.
Automatisierte Snapshots werden nach Ablauf eines Aufbewahrungszeitraums gelöscht. Der Standard-Aufbewahrungszeitraum beträgt einen Tag. Sie können ihn jedoch mit der Amazon-Redshift-Konsole oder programmgesteuert mit der Amazon Redshift API oder CLI ändern.
Zum Deaktivieren von automatischen Snapshots setzen Sie den Wert für den Aufbewahrungszeitraum auf null. Wenn Sie automatisierte Snapshots deaktivieren, erstellt Amazon Redshift keine Snapshots mehr und löscht alle vorhandenen automatisierten Snapshots für den Cluster. Sie können automatische Snapshots für Knotentypen nicht deaktivieren. RA3 Sie können einen automatisierten Aufbewahrungszeitraum für einen RA3 Knotentyp von 1—35 Tagen festlegen.
Nur Amazon Redshift kann einen automatisierten Snapshot löschen. Sie können ihn manuell nicht löschen. Amazon Redshift löscht automatisierte Snapshots nach Ablauf ihres Aufbewahrungszeitraums, wenn Sie automatisierte Snapshots für den Cluster deaktivieren oder wenn Sie den Cluster löschen. *Amazon Redshift behält den neuesten automatisierten Snapshot, bis Sie automatisierte Snapshots deaktivieren oder den Cluster löschen.*
Wenn Sie einen automatisierten Snapshot für einen längeren Zeitraum behalten möchten, können Sie eine Kopie hiervon als einen manuellen Snapshot erstellen. Der automatisierte Snapshot wird bis zum Ende des Aufbewahrungszeitraums aufbewahrt, aber der entsprechende manuelle Snapshot wird aufbewahrt, bis Sie ihn manuell löschen oder das Ende des Aufbewahrungszeitraums erreicht ist.
## Zeitpläne für automatisierte Snapshots
Erstellen Sie einen Snapshot-Zeitplan und fügen ihn an einen oder mehrere Cluster an, um präzise zu steuern, wann Snapshots erzeugt werden. Wenn Sie einen Snapshot-Zeitplan ändern, wird der Zeitplan für alle verknüpften Cluster angepasst. Ein Cluster ohne angefügten Snapshot-Zeitplan verwendet den standardmäßigen Zeitplan für automatisierte Snapshots.
Ein *Snapshot-Zeitplan* besteht aus einer Reihe von Zeitplanregeln. Sie können einen einfachen Zeitplan definieren, indem Sie Abstände festlegen, beispielsweise alle 8 oder 12 Stunden. Sie können auch Regeln hinzufügen, damit an bestimmten Wochentagen, zu festgelegten Zeiten oder während bestimmter Zeiträume Snapshots erstellt werden. Die Regeln können auch mithilfe von Unix-ähnlichen Cron-Ausdrücken definiert werden.
## Format von Snapshot-Zeitplänen
Sie können in der Amazon-Redshift-Konsole einen Snapshot-Zeitplan erstellen. Fügen Sie einem Cluster einen Zeitplan an, um die Erstellung eines System-Snapshots auszulösen. Ein Zeitplan kann mehreren Clustern angefügt werden. Außerdem kann ein Zeitplan mehrere Cron-Definitionen zum Auslösen von Snapshots enthalten.
Sie können einen Plan für Snapshots mit einer Cron-Syntax definieren. Die Definition dieser Zeitpläne nutzt eine modifizierte, Unix-ähnliche [cron](http://en.wikipedia.org/wiki/Cron)-Syntax. Verwenden Sie die UTC-Zeitzone ([Coordinated Universal Time](http://en.wikipedia.org/wiki/Coordinated_Universal_Time)), um die Zeit anzugeben. Zeitpläne können mit einer maximalen Häufigkeit von einer Stunde und einer Mindestgenauigkeit von einer Minute erstellt werden.
Modifizierte cron-Ausdrücke für Amazon Redshift haben 3 Pflichtfelder, die durch Leerzeichen voneinander getrennt sind.
**Syntax**
```
cron(Minutes Hours Day-of-month Month Day-of-week Year)
```
| **Felder** | **Werte** | **Platzhalter** |
| --- | --- | --- |
| Minuten | 0-59 | , - \$1 / |
| Stunden | 0–23 | , - \$1 / |
| D ay-of-month | 1-31 | , - \$1 ? / L W |
| Monat | 1-12 oder JAN-DEZ | , - \$1 / |
| D ay-of-week | 1-7 oder SUN-SAT | , - \$1 ? / L \$1 |
| Jahr | 1970-2199 | , - \$1 / |
**Platzhalter**
+ Das Platzhalterzeichen **,** (Komma) schließt zusätzliche Werte ein. Im Feld `Day-of-week` würde `MON,WED,FRI` Montag, Mittwoch und Freitag abdecken. Die Gesamtwerte sind auf 24 pro Feld begrenzt.
+ Das Platzhalterzeichen **-** (Bindestrich) gibt einen Bereich an. Im Feld `Hour` steht 1–15 für die Stunden 1 bis 15 des angegebenen Tags.
+ Das Platzhalterzeichen **\$1** (Sternchen) steht für alle Werte im Feld. Im Feld `Hours` steht **\$1** für alle Stunden.
+ Das Platzhalterzeichen **/** (Schrägstrich) steht für schrittweise Steigerungen. Im Feld `Hours` können Sie **1/10** eingeben, um jede 10. Stunde anzugeben, beginnend mit der ersten Stunde des Tages (z. B. 01:00, 11:00 und 21:00).
+ Das Platzhalterzeichen **?** (Fragezeichen) steht für einen Wert. In das `Day-of-month` Feld könntest du **7** eingeben, und wenn es dir egal wäre, welcher Wochentag der siebte war, könntest du eingeben**?** auf dem Day-of-week Feld.
+ Das Platzhalterzeichen **L** in den Feldern für `Day-of-month` oder `Day-of-week` gibt den letzten Tag des Monats oder der Woche an.
+ Das Platzhalterzeichen **W** im Feld `Day-of-month` gibt einen Wochentag an. Im Feld `Day-of-month` gibt den `3W` den Tag an, der dem dritten Tag des Monats am nächsten ist.
+ Der Platzhalter **\$1** in dem Day-of-week Feld gibt eine bestimmte Instanz des angegebenen Wochentags innerhalb eines Monats an. Beispiel: 3\$12 steht für den zweiten Dienstag des Monats: Die 3 bezieht sich auf Dienstag, da dies der dritte Tag jeder Woche ist, und die 2 bezieht sich auf den zweiten Tag dieses Typs innerhalb des Monats.
**Anmerkung**
Wenn Sie das Zeichen '\$1' verwenden, können Sie nur einen Ausdruck in dem day-of-week Feld definieren. Beispielsweise ist "3\$11,6\$13" ungültig, da dies als zwei Ausdrücke interpretiert wird.
**Einschränkungen**
+ Es ist nicht möglich, die Felder `Day-of-month` und `Day-of-week` im gleichen Cron-Ausdruck anzugeben. Wenn Sie einen Wert in einem der Felder angeben, müssen Sie in dem anderen Feld ein **?** (Fragezeichen) eingeben.
+ Snapshot-Zeitpläne unterstützen folgende Häufigkeiten nicht:
+ Häufiger als einmal pro Stunde geplante Snapshots.
+ Seltener als einmal pro Tag (24 Stunden) geplante Snapshots.
Wenn Zeitpläne sich so überschneiden, dass Snapshots innerhalb eines Fensters von 1 Stunde geplant werden, wird ein Validierungsfehler erzeugt.
Wenn Sie einen Zeitplan erstellen, können Sie die folgenden Beispiel-Cron-Strings verwenden.
| Minuten | Stunden | Wochentag | Bedeutung |
| --- | --- | --- | --- |
| 0 | 14-20/1 | TUE | Jede Stunde zwischen 14:00 und 20:00 Uhr am Dienstag. |
| 0 | 21 | MO-FR | Von Montag bis Freitag jeden Abend um 21.00 Uhr. |
| 30 | 0/6 | SAT-SUN | Inkrementell alle 6 Stunden am Samstag und Sonntag, beginnend 30 Minuten nach Mitternacht (00:30) an diesem Tag. Das Ergebnis ist ein Snapshot um [00:30, 06:30, 12:30 und 18:30] Uhr am jeweiligen Tag. |
| 30 | 12/4 | \$1 | Inkrementell alle 4 Stunden jeden Tag, beginnend um 12:30 Uhr. Das ergibt [12:30, 16:30, 20:30] Uhr. |
Beispiel: Sie möchten einen Zeitplan jeden Tag beginnend um 15:15 Uhr inkrementell alle 2 Stunden ausführen. Das ergibt [15:15, 17:15, 19:15, 21:15, 23:15] Uhr. Geben Sie dafür Folgendes an:
```
cron(15 15/2 *)
```
Sie können einem Zeitplan mehrere Cron-Zeitplandefinitionen hinzufügen. Der folgende AWS CLI Befehl enthält beispielsweise zwei Cron-Zeitpläne in einem Zeitplan.
```
create-snapshot-schedule --schedule-identifier "my-test" --schedule-definition "cron(0 17 SAT,SUN)" "cron(0 9,17 MON-FRI)"
```
## Manuelle Snapshots
Sie können jederzeit einen manuellen Snapshot erstellen. Manuelle Snapshots werden standardmäßig sogar nach dem Löschen Ihres Clusters beliebig lange aufbewahrt. Sie können den Aufbewahrungszeitraum für manuelle Snapshots festlegen, wenn Sie den Snapshot erstellen, und ihn ändern, indem Sie den Snapshot modifizieren. Weitere Informationen zum Ändern des Aufbewahrungszeitraums finden Sie unter [Ändern des Aufbewahrungszeitraum für manuelle Snapshots](snapshot-manual-retention-period.md).
Nachdem Sie einen Snapshot gelöscht haben, können Sie keine neuen Operationen starten, die auf diesen Snapshot verweisen. Wenn jedoch ein Wiederherstellungsvorgang läuft, wird dieser Wiederherstellungsvorgang vollständig abgeschlossen.
Amazon Redshift hat ein Kontingent, das die Gesamtzahl der manuellen Snapshots begrenzt, die Sie erstellen können. Dieses Kontingent gilt pro AWS AWS Konto und Region. Das Standardkontingent ist unter [Kontingente und Limits in Amazon Redshift](amazon-redshift-limits.md) aufgeführt.
## Snapshot-Speicher
Da für Snapshots Speicherkosten anfallen, ist es wichtig, sie zu löschen, wenn Sie sie nicht mehr benötigen. Amazon Redshift löscht automatisierte und manuelle Snapshots nach Ablauf ihres jeweiligen Aufbewahrungszeitraums. Sie können manuelle Snapshots auch mit dem AWS-Managementkonsole oder mit dem [batch-delete-cluster-snapshots](https://docs.aws.amazon.com/cli/latest/reference/redshift/batch-delete-cluster-snapshots.html)CLI-Befehl löschen.
Sie können den Aufbewahrungszeitraum für einen manuellen Snapshots ändern, indem Sie die Einstellungen für manuelle Snapshots anpassen.
Informationen zu dem von Ihren Snapshots belegten Speicher erhalten Sie über die Amazon-Redshift-Konsole oder über den CLI-Befehl [describe-storage](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-storage.html).
## Ausschluss von Tabellen von Snapshots
Standardgemäß sind alle benutzerdefinierten, dauerhaften Tabellen in Snapshots enthalten. Wenn eine Tabelle wie die Staging-Tabelle nicht gesichert werden muss, können Sie die Zeit, die zum Erstellen von Snapshots und zum Wiederherstellen aus Snapshots erforderlich ist, beträchtlich reduzieren. Sie können auch den Speicherplatz auf Amazon S3 reduzieren, indem Sie keine Sicherungstabelle verwenden. Zum Erstellen einer Tabelle ohne Sicherung berücksichtigen Sie den BACKUP NO-Parameter beim Erstellen der Tabelle. Weitere Informationen finden Sie unter [CREATE TABLE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_NEW.html) und [CREATE TABLE AS](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_AS.html) im *Datenbankentwicklerhandbuch zu Amazon Redshift*.
**Anmerkung**
Tabellen ohne Backup werden für RA3 bereitgestellte Cluster und serverlose Amazon Redshift Workgroups nicht unterstützt. Eine Tabelle, die in einem RA3 Cluster oder einer serverlosen Arbeitsgruppe als „kein Backup“ gekennzeichnet ist, wird als permanente Tabelle behandelt, die bei der Erstellung eines Snapshots immer gesichert und bei der Wiederherstellung aus einem Snapshot immer wiederhergestellt wird. Um Snapshot-Kosten für Tabellen ohne Backup zu vermeiden, sollten Sie diese vor der Erstellung eines Snapshots kürzen.
# Erstellen eines manuellen Snapshot
Gehen Sie zum Erstellen eines manuellen Snapshots eines Clusters aus der Snapshotliste wie folgt vor. Bei einer alternative Methode zum Erstellen eines Clustersnapshots wird als Ausgangspunkt anstelle der Snapshotliste der Ausschnitt zur Konfigurierung der Cluster gewählt. Weitere Informationen finden Sie unter [Amazon-Redshift-Snapshots und -Sicherungen](working-with-snapshots.md).
**Anmerkung**
Tabellen ohne Backup werden für RA3 bereitgestellte Cluster und serverlose Amazon Redshift Workgroups nicht unterstützt. Eine Tabelle, die in einem RA3 Cluster oder einer serverlosen Arbeitsgruppe als „kein Backup“ gekennzeichnet ist, wird als permanente Tabelle behandelt, die bei der Erstellung eines Snapshots immer gesichert und bei der Wiederherstellung aus einem Snapshot immer wiederhergestellt wird. Um Snapshot-Kosten für Tabellen ohne Backup zu vermeiden, sollten Sie diese vor der Erstellung eines Snapshots kürzen.
**So erstellen Sie einen manuellen Snapshot**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster), **Snapshots** und dann **Create snapshot** (Snapshot erstellen) aus. Die Snapshot-Seite zum Erstellen eines manuellen Snapshots wird angezeigt.
1. Geben Sie die Eigenschaften der Snapshot-Definition ein und wählen Sie dann **Create snapshot (Snapshot erstellen)** aus. Es kann einige Zeit dauern, bis der Snapshot verfügbar ist.
# Erstellen eines Snapshot-Zeitplans
Amazon Redshift erstellt regelmäßig automatische inkrementelle Snapshots Ihrer Daten und speichert diese in Amazon S3. Sie können natürlich außerdem bei Bedarf jederzeit manuell Snapshots Ihrer Daten erstellen.
Ausgangspunkt aller Snapshot-Aufgaben in der Amazon-Redshift-Konsole ist die Snapshot-Liste. Sie können diese Liste nach einem Zeitbereich, dem Snapshottyp und dem Cluster des Snapshots filtern. Außerdem können Sie die Liste nach Datum, Größe und Snapshot-Typ sortieren. Abhängig vom ausgewählten Snapshot-Typ stehen Ihnen möglicherweise verschiedene Optionen für die Arbeit mit dem Snapshot zur Verfügung.
Erstellen Sie einen Snapshot-Zeitplan und fügen ihn an einen oder mehrere Cluster an, um präzise zu steuern, wann Snapshots erzeugt werden. Sie können einen Zeitplan anfügen, wenn Sie einen Cluster erstellen oder indem Sie den Cluster ändern. Weitere Informationen finden Sie unter [Zeitpläne für automatisierte Snapshots](working-with-snapshots.md#automated-snapshot-schedules).
**So erstellen Sie einen Snapshot-Zeitplan**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster), **Snapshots** und dann die Registerkarte **Snapshot schedules** (Snapshot-Zeitpläne) aus. Die Snapshot-Zeitpläne werden angezeigt.
1. Wählen Sie **Add schedule (Zeitplan hinzufügen)** aus, um die Seite zum Hinzufügen eines Zeitplans anzuzeigen.
1. Geben Sie die Eigenschaften der Zeitplandefinition ein und wählen Sie dann **Add schedule (Zeitplan hinzufügen)** aus.
1. Auf der angezeigten Seite können Sie Cluster an Ihren neuen Snapshot-Plan zuweisen und dann **OK** auswählen.
# Freigeben eines Snapshots
Sie können einen vorhandenen manuellen Snapshot mit anderen AWS Kundenkonten teilen, indem Sie den Zugriff auf den Snapshot autorisieren. Sie können bis zu 20 für jeden Snapshot und 100 für jeden AWS Key Management Service (AWS KMS) Schlüssel autorisieren. Das heißt, wenn Sie über 10 Snapshots verfügen, die mit einem einzigen KMS-Schlüssel verschlüsselt sind, können Sie 10 AWS Konten für die Wiederherstellung jedes Snapshots autorisieren oder andere Kombinationen, die bis zu 100 Konten hinzufügen und 20 Konten pro Snapshot nicht überschreiten. Eine Person, die als ein Benutzer in einem der genehmigten Konten angemeldet ist, kann dann den Snapshot beschreiben oder ihn wiederherstellen, um einen neuen Amazon-Redshift-Cluster unter ihrem Konto zu erstellen. Wenn Sie beispielsweise separate AWS Kundenkonten für Produktion und Test verwenden, kann sich ein Benutzer mit dem Produktionskonto anmelden und einen Snapshot mit Benutzern im Testkonto teilen. Jemand, der sich als Testkonto-Benutzer angemeldet hat, kann dann den Snapshot wiederherstellen, um einen neuen Cluster für Test- oder Diagnosearbeiten zu erstellen, der Eigentum des Testkontos ist.
Ein manueller Snapshot gehört dauerhaft dem AWS Kundenkonto, unter dem er erstellt wurde. Nur Benutzer im Konto, dem der Snapshot gehört, könnten anderen Konten die Berechtigung zum Zugriff auf den Snapshot gewähren oder solche Berechtigung wieder entziehen. Benutzer in den genehmigten Konten können nur einen Snapshot beschreiben oder wiederherstellen, der für sie freigegeben wurde; sie können keine Snapshots kopieren oder löschen, die für sie freigegeben wurden. Eine Berechtigung bleibt gültig, bis der Eigentümer des Snapshot sie widerruft. Wird eine Berechtigung widerrufen, verliert der zuvor autorisierte Benutzer die Sichtbarkeit für den Snapshot und kann keine neuen Aktionen starten, die auf den Snapshot verweisen. Wenn das Konto dabei ist, den Snapshot wiederherzustellen, wenn der Zugriff widerrufen wird, wird die Wiederherstellung vollständig abgeschlossen. Sie können keinen Snapshot löschen, während aktive Berechtigungen vorliegen; Sie müssen zuerst alle Berechtigungen widerrufen.
AWS Kundenkonten sind immer berechtigt, auf Snapshots zuzugreifen, die dem Konto gehören. Bei Versuchen, den Zugriff zum Eigentümerkonto zu genehmigen oder zu widerrufen, erscheint eine Fehlermeldung. Sie können einen Snapshot, der einem inaktiven AWS Kundenkonto gehört, nicht wiederherstellen oder beschreiben.
Nachdem Sie den Zugriff auf ein AWS Kundenkonto autorisiert haben, können Benutzer dieses Kontos keine Aktionen an dem Snapshot ausführen, es sei denn, sie übernehmen eine Rolle mit Richtlinien, die ihnen dies ermöglichen.
+ Benutzer im Snapshot-Besitzerkonto können nur dann den Zugriff auf einen Snapshot genehmigen oder widerrufen, wenn sie eine Rolle mit einer IAM-Richtlinie übernehmen, die ihnen die Durchführung solcher Aktionen mit einer Ressourcenspezifikation erlauben, die den Snapshot beinhaltet. Die folgende Richtlinie ermöglicht es beispielsweise einem Benutzer oder einer Rolle in einem AWS Konto, anderen Konten `012345678912` den Zugriff auf einen Snapshot mit dem Namen `my-snapshot20130829` zu autorisieren:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"redshift:AuthorizeSnapshotAccess",
"redshift:RevokeSnapshotAccess"
],
"Resource":[
"arn:aws:redshift:us-east-1:012345678912:snapshot:*/my-snapshot20130829"
]
}
]
}
```
------
+ Benutzer in einem AWS Konto, mit dem ein Snapshot geteilt wurde, können keine Aktionen für diesen Snapshot ausführen, es sei denn, sie verfügen über die entsprechenden Berechtigungen. Weisen Sie dazu die Richtlinie einer Rolle zu und übernehmen Sie die Rolle.
+ Um einen Snapshot aufzulisten oder zu beschreiben, muss eine IAM-Richtlinie vorliegen, die die `DescribeClusterSnapshots`-Aktion erlaubt. Der folgende Code zeigt ein Beispiel dafür:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"redshift:DescribeClusterSnapshots"
],
"Resource":[
"*"
]
}
]
}
```
------
+ Um einen Snapshot wiederherzustellen, muss ein Benutzer eine Rolle mit einer IAM-Richtlinie übernehmen, die die Aktion `RestoreFromClusterSnapshot` erlaubt, und über ein Ressourcenelement verfügen, das sowohl den Cluster, den er versucht zu erstellen, als auch den Snapshot abdeckt. Wenn beispielsweise ein Benutzer in einem Konto `012345678912` den Snapshot `my-snapshot20130829` für Konto `219876543210` freigegeben hat, um durch Wiederherstellen des Snapshot einen Cluster zu erstellen, muss ein Benutzer im Konto `219876543210` eine Rolle mit einer Richtlinie wie die folgende übernehmen:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"redshift:RestoreFromClusterSnapshot"
],
"Resource":[
"arn:aws:redshift:us-east-1:012345678912:snapshot:*/my-snapshot20130829",
"arn:aws:redshift:us-east-1:219876543210:cluster:from-another-account"
]
}
]
}
```
------
+ Nachdem einem AWS Konto der Zugriff auf einen Snapshot entzogen wurde, können keine Benutzer in diesem Konto auf den Snapshot zugreifen. Dies ist auch der Fall, wenn diese Konten über IAM-Richtlinien verfügen, die Aktionen für die zuvor freigegebene Snapshot-Ressource zulassen.
## Freigeben eines Cluster-Snapshots mit der Konsole
Sie können mit der Konsole anderen Benutzern die Berechtigung erteilen, auf ausgewählte manuelle Snapshots von Ihnen zuzugreifen, und Sie können diese Berechtigungen auch wieder entziehen, wenn sie nicht mehr benötigt werden.
**So geben Sie einen Snapshot für ein anderes -Konto frei**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster), **Snapshots** und dann den manuellen Snapshot aus, der freigegeben werden soll.
1. Wählen Sie für **Actions (Aktionen)** **Manual snapshot settings (Manuelle Snapshot-Einstellungen)** aus, um die Eigenschaften des manuellen Snapshots anzuzeigen.
1. Geben Sie im Abschnitt **Manage access (Zugriff verwalten)** das oder die Konten ein, für die Sie freigeben möchten. Wählen Sie dann **Save (Speichern)** aus.
## Sicherheitsüberlegungen für das Teilen verschlüsselter Snapshots
Wenn Sie Zugriff auf einen verschlüsselten Snapshot gewähren, erfordert Redshift, dass der vom Kunden verwaltete AWS -KMS-Schlüssel, der zum Erstellen des Snapshots verwendet wird, mit dem Konto bzw. den Konten geteilt wird, die die Wiederherstellung durchführen. Wenn der Schlüssel nicht freigegeben ist, führt der Versuch, den Snapshot wiederherzustellen, zu dem Fehler „Zugriff verweigert“. Das empfangende Konto benötigt keine zusätzlichen Berechtigungen, um einen freigegebenen Snapshot wiederherzustellen. Wenn Sie Snapshot-Zugriff autorisieren und den Schlüssel freigeben, muss die Identität, die den Zugriff autorisiert, über `kms:DescribeKey`-Berechtigungen für den Schlüssel verfügen, der zum Verschlüsseln des Snapshots verwendet wurde. Diese Berechtigung wird unter [AWS KMS -Berechtigungen](https://docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html) ausführlicher beschrieben. Weitere Informationen finden Sie [DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html)in der Referenzdokumentation zur Amazon Redshift Redshift-API.
Die vom Kunden verwaltete Schlüsselrichtlinie kann programmgesteuert oder in der AWS Key Management Service -Konsole aktualisiert werden.
**Anmerkung**
Wenn Sie einen Standard-KMS-Schlüssel verwenden, müssen Sie keine Maßnahmen ergreifen oder Änderungen in AWS KMS vornehmen, um einen Snapshot freizugeben.
### Erlaubt den Zugriff auf den AWS KMS-Schlüssel für einen verschlüsselten Snapshot
Um den vom Kunden verwalteten AWS KMS-Schlüssel für einen verschlüsselten Snapshot gemeinsam zu nutzen, aktualisieren Sie die Schlüsselrichtlinie, indem Sie die folgenden Schritte ausführen:
1. Aktualisieren Sie die KMS-Schlüsselrichtlinie mit dem Amazon-Ressourcennamen (ARN) des AWS -Kontos, für das Sie es freigeben, als `Principal` in der KMS-Schlüsselrichtlinie.
1. Erlauben Sie die `kms:Decrypt`-Aktion.
Im folgenden Beispiel für eine Schlüsselrichtlinie ist Benutzer `111122223333` der Besitzer des KMS-Schlüssels, und Benutzer `444455556666` ist das Konto, für das der Schlüssel freigegeben wird. Diese Schlüsselrichtlinie gewährt dem AWS Konto Zugriff auf den KMS-Beispielschlüssel, indem sie den ARN für die AWS Stammkontoidentität für den Benutzer `444455556666` als `Principal` für die Richtlinie einschließt und die `kms:Decrypt` Aktion zulässt.
------
#### [ JSON ]
****
```
{
"Id": "key-policy-1",
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:user/KeyUser",
"arn:aws:iam::444455556666:root"
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*"
}
]
}
```
------
Nachdem der Zugriff auf den vom Kunden verwalteten KMS-Schlüssel gewährt wurde, muss das Konto, das den verschlüsselten Snapshot wiederherstellt, eine AWS Identity and Access Management (IAM-) Rolle oder einen Benutzer, falls es noch keinen hat, erstellen. Darüber hinaus muss dieses AWS Konto dieser IAM-Rolle oder diesem IAM-Benutzer eine IAM-Richtlinie zuordnen, die es dem Benutzer ermöglicht, mithilfe Ihres KMS-Schlüssels einen verschlüsselten Datenbanksnapshot wiederherzustellen.
Weitere Informationen zur Gewährung des Zugriffs auf einen AWS KMS Schlüssel finden Sie [im AWS Key Management Service Entwicklerhandbuch unter Erlauben der Verwendung eines KMS-Schlüssels durch Benutzer mit anderen Konten](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html#cross-account-console).
Einen Überblick über die wichtigsten Richtlinien finden Sie unter [So verwendet AWS KMS Amazon Redshift](https://docs.aws.amazon.com/kms/latest/developerguide/services-redshift.html).
# Kopieren eines automatisierten Snapshot
Automatisierte Snapshots werden nach Ablauf ihrer Verwahrdauer automatisch gelöscht. Außerdem werden automatisierte Snapshots gelöscht, wenn Sie die Funktion zur automatischen Aufnahme von Snapshots deaktivieren oder wenn Sie den Cluster löschen, der sie enthält. Wenn Sie einen automatisierten Snapshot dauerhaft behalten möchten, kopieren Sie ihn in einen manuellen Snapshot.
**So kopieren Sie einen automatisierten Snapshot**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster), **Snapshots** und dann den zu kopierenden Snapshot aus.
1. Wählen Sie für **Actions (Aktionen)** **Copy automated snapshot (Automatischen Snapshot kopieren)** aus, um den Snapshot zu kopieren.
1. Aktualisieren Sie die Eigenschaften des neuen Snapshots und wählen Sie dann **Copy (Kopieren)** aus.
# Einen Snapshot in eine andere AWS Region kopieren
Sie können Amazon Redshift so konfigurieren, dass Snapshots (automatisiert oder manuell) für einen Cluster automatisch in eine andere AWS Region kopiert werden. Wenn ein Snapshot in der primären AWS Region des Clusters erstellt wird, wird er in eine sekundäre AWS Region kopiert. Die beiden AWS Regionen werden jeweils als * AWS Quellregion* und * AWS Zielregion* bezeichnet. Wenn Sie eine Kopie Ihrer Snapshots in einer anderen AWS Region speichern, können Sie Ihren Cluster aus aktuellen Daten wiederherstellen, falls sich etwas auf die primäre AWS Region auswirkt. Sie können Ihren Cluster so konfigurieren, dass Snapshots jeweils nur in eine AWS Zielregion kopiert werden. Die Liste der Amazon-Redshift-Regionen finden Sie unter [Regionen und Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html) in der *Allgemeine Amazon Web Services-Referenz*.
Wenn Sie Amazon Redshift aktivieren, um Snapshots automatisch in eine andere AWS Region zu kopieren, geben Sie die AWS Zielregion an, in die die Snapshots kopiert werden sollen. Für automatisierte Snapshots können Sie auch den Aufbewahrungszeitraum angeben, in dem sie in der Zielregion aufbewahrt werden sollen. AWS Nachdem ein automatisierter Snapshot in die AWS Zielregion kopiert wurde und dort den Aufbewahrungszeitraum erreicht hat, wird er aus der AWS Zielregion gelöscht. Dadurch bleibt Ihre Snapshot-Nutzung gering. Um die automatisierten Snapshots für einen kürzeren oder längeren Zeitraum in der AWS Zielregion aufzubewahren, ändern Sie diesen Aufbewahrungszeitraum.
Die Aufbewahrungsdauer, die Sie für automatische Snapshots festlegen, die in die AWS Zielregion kopiert werden, unterscheidet sich von der Aufbewahrungsdauer für automatische Snapshots in der Quellregion. AWS Der Standardaufbewahrungszeitraum für kopierte Snapshots beträgt sieben Tage. Dieser Zeitraum von sieben Tagen gilt nur für automatisierte Snapshots. Sowohl in der Quell- als auch in der AWS Zielregion werden manuelle Snapshots am Ende der Aufbewahrungsfrist für Snapshots oder wenn Sie sie manuell löschen, gelöscht.
Sie können die automatische Snapshot-Kopie für einen Cluster jederzeit deaktivieren. Wenn Sie diese Funktion deaktivieren, werden Snapshots nicht mehr von der AWS Quellregion in die AWS Zielregion kopiert. Alle automatisierten Snapshots, die in die AWS Zielregion kopiert wurden, werden gelöscht, sobald sie die Aufbewahrungsfrist erreicht haben, es sei denn, Sie erstellen manuelle Snapshot-Kopien von ihnen. Diese manuellen Snapshots und alle manuellen Snapshots, die aus der AWS Zielregion kopiert wurden, werden in der AWS Zielregion aufbewahrt, bis Sie sie manuell löschen.
Um die AWS Zielregion zu ändern, in die Sie Snapshots kopieren, deaktivieren Sie zunächst die automatische Kopierfunktion. Aktivieren Sie sie dann wieder unter Angabe der neuen AWS -Zielregion.
Nachdem ein Snapshot in die AWS Zielregion kopiert wurde, wird er aktiv und steht für Wiederherstellungszwecke zur Verfügung.
Um Snapshots für AWS KMS—verschlüsselte Cluster in eine andere AWS Region zu kopieren, gewähren Sie Amazon Redshift die Nutzung eines vom Kunden verwalteten Schlüssels in der Zielregion. AWS Wählen Sie dann diesen Zuschuss aus, wenn Sie das Kopieren von Snapshots in der Quellregion aktivieren. AWS Weitere Informationen zur Konfiguration von Erteilungen von Snapshots-Kopien finden Sie unter [Kopieren von —verschlüsselten Snapshots in einen anderen AWS KMS AWS-Region](working-with-db-encryption.md#configure-snapshot-copy-grant).
# Wiederherstellen eines Clusters aus einem Snapshot
Ein Snapshot enthält Daten aus Datenbanken, die auf Ihrem Cluster ausgeführt werden. Dazu enthält er Informationen zu Ihrem Cluster, darunter die Anzahl der Knoten, den Knotentyp und den Admin-Benutzernamen. Wenn Sie einen Cluster aus einem Snapshot wiederherstellen, verwendet Amazon Redshift die Cluster-Informationen zur Erstellung eines neuen Clusters. Dann werden alle Datenbanken aus den Snapshot-Daten wiederhergestellt.
**Anmerkung**
Tabellen ohne Backup werden für RA3 bereitgestellte Cluster und serverlose Amazon Redshift Workgroups nicht unterstützt. Eine Tabelle, die in einem RA3 Cluster oder einer serverlosen Arbeitsgruppe als „kein Backup“ gekennzeichnet ist, wird als permanente Tabelle behandelt, die bei der Erstellung eines Snapshots immer gesichert und bei der Wiederherstellung aus einem Snapshot immer wiederhergestellt wird.
Für den aus dem ursprünglichen Snapshot wiederhergestellten neuen Cluster können Sie die Konfiguration auswählen, etwa den Knotentyp und die Anzahl der Knoten. Der Cluster wird in derselben AWS -Region und in einer zufällig vom System ausgewählten Availability Zone wiederhergestellt, es sei denn, Sie geben in Ihrer Anforderung eine andere Availability Zone an. Wenn Sie einen Cluster anhand eines Snapshots wiederherstellen, können Sie optional eine kompatible Wartungsspur für den neuen Cluster auswählen.
**Anmerkung**
Wenn Sie einen Snapshot zu einem Cluster mit einer anderen Konfiguration wiederherstellen, muss der Snapshot auf einem Cluster mit Clusterversion 1.0.10013 oder höher erstellt worden sein.
Während eine Wiederherstellung ausgeführt wird, werden Ereignisse in der Regel in der folgenden Reihenfolge ausgegeben:
1. RESTORE\$1STARTED – REDSHIFT-EVENT-2008 wird gesendet, wenn der Wiederherstellungsprozess beginnt.
1. RESTORE\$1SUCCEEDED – REDSHIFT-EVENT-3003 wird gesendet, wenn der neue Cluster erstellt wurde.
Der Cluster ist für Abfragen verfügbar.
1. DATA\$1TRANSFER\$1COMPLETED — REDSHIFT-EVENT-3537 wird gesendet, wenn die Datenübertragung abgeschlossen ist.
**Anmerkung**
RA3 Cluster geben nur die Ereignisse RESTORE\$1STARTED und RESTORE\$1SUCCEED aus. Nach einem erfolgreichen RESTORE muss keine explizite Datenübertragung durchgeführt werden, da RA3 Knotentypen Daten im von Amazon Redshift verwalteten Speicher speichern. Bei RA3 Knoten werden Daten im Rahmen der normalen Abfrageverarbeitung kontinuierlich zwischen RA3 Knoten und dem von Amazon Redshift verwalteten Speicher übertragen. RA3 Knoten speichern heiße Daten lokal im Cache und speichern Blöcke, die seltener abgefragt werden, automatisch im von Amazon Redshift verwalteten Speicher.
Sie können den Fortschritt einer Wiederherstellung überwachen, indem Sie entweder den [DescribeClusters](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeClusters.html)API-Vorgang aufrufen oder die Cluster-Details in der anzeigen. AWS-Managementkonsole Für eine Wiederherstellung in Bearbeitung werden Informationen wie die Größe der Snapshot-Daten, die Übertragungsrate, die verstrichene Zeit und die geschätzte Restzeit angezeigt. Eine Beschreibung dieser Metriken finden Sie unter [RestoreStatus](https://docs.aws.amazon.com/redshift/latest/APIReference/API_RestoreStatus.html).
Sie können einen Snapshot nicht zum Wiederherstellen eines aktiven Clusters in einen vorherigen Status verwenden.
**Anmerkung**
Wenn Sie einen Snapshot in einen neuen Cluster wiederherstellen, werden die Standardsicherheitsgruppe und -parametergruppe verwendet, sofern Sie keine anderen Werte angeben.
Möglicherweise möchten Sie aus den folgenden Gründen einen Snapshot zu einem Cluster mit einer anderen Konfiguration wiederherstellen:
+ Wenn ein Cluster aus kleineren Knotentypen besteht und Sie ihn zu einem größeren Knotentyp mit weniger Knoten konsolidieren möchten.
+ Wenn Sie Ihre Workloads beobachtet haben und feststellen, dass Sie einen Knotentyp mit mehr CPU-Leistung und Speicherplatz benötigen.
+ Wenn Sie die Leistung von Test-Workloads mit anderen Knotentypen messen möchten.
Für die Wiederherstellung gelten die folgenden Einschränkungen:
+ Die neue Knotenkonfiguration muss über genügend Speicherplatz für vorhandene Daten verfügen. Auch wenn Sie Knoten hinzufügen, verfügt Ihre neue Konfiguration möglicherweise aufgrund der Verteilung der Daten nicht über ausreichend Speicherplatz.
+ Der Wiederherstellungsvorgang überprüft, ob der Snapshot auf einer Cluster-Version erstellt wurde, die mit der Cluster-Version des neuen Clusters kompatibel ist. Wenn die Versionsebene des neuen Clusters zu früh ist, schlägt der Wiederherstellungsvorgang fehl und weitere Informationen werden in einer Fehlermeldung ausgegeben.
+ Welche möglichen Konfigurationen (Knotenanzahl und Knotentyp) Sie wiederherstellen können, ist von der Anzahl der Knoten im ursprünglichen Cluster und dem Zielknotentyp des neuen Clusters abhängig. Um die möglichen verfügbaren Konfigurationen zu ermitteln, können Sie die Amazon Redshift Redshift-Konsole oder den `describe-node-configuration-options` AWS CLI Befehl mit `action-type restore-cluster` verwenden. Weitere Informationen zur Wiederherstellung mithilfe der Amazon-Redshift-Konsole finden Sie unter [Wiederherstellen eines Clusters aus einem Snapshot](#working-with-snapshot-restore-cluster-from-snapshot).
Die folgenden Schritte basieren auf einem Cluster mit zahlreichen Knoten und konsolidieren diesen zu einem größeren Knotentyp mit einer geringeren Zahl von Knoten mit AWS CLI. Für dieses Beispiel beginnen wir mit einem Quell-Cluster mit 24 -Knoten. Für diesen Fall nehmen wir an, dass wir bereits einen Snapshot dieses Clusters erstellt haben und diesen jetzt zu einem größeren Knotentyp wiederherstellen möpchten.
1. Führen Sie den folgenden Befehl aus, um die Details zu unserem 24-Knoten--Cluster abzurufen.
```
aws redshift describe-clusters --region eu-west-1 --cluster-identifier mycluster-123456789012
```
1. Führen Sie den folgenden Befehl aus, um die Details des Snapshots abzurufen.
```
aws redshift describe-cluster-snapshots --region eu-west-1 --snapshot-identifier mycluster-snapshot
```
1. Führen Sie den folgenden Befehl aus, um die für diesen Snapshot verfügbaren Optionen zu beschreiben.
```
aws redshift describe-node-configuration-options --snapshot-identifier mycluster-snapshot --region eu-west-1 --action-type restore-cluster
```
Dieser Befehl gibt eine Optionenliste mit empfohlenen Knotentypen, der Knotenanzahl und der Festplattennutzung für jede Option aus. Bei diesem Beispiel listet der obige Befehl die folgenden möglichen Knotenkonfigurationen auf. Wir entscheiden uns für die Wiederherstellung zu einem -Cluster mit drei Knoten.
```
{
"NodeConfigurationOptionList": [
{
"EstimatedDiskUtilizationPercent": 65.26134808858235,
"NodeType": "dc2.large",
"NumberOfNodes": 24
},
{
"EstimatedDiskUtilizationPercent": 32.630674044291176,
"NodeType": "dc2.large",
"NumberOfNodes": 48
},
{
"EstimatedDiskUtilizationPercent": 65.26134808858235,
"NodeType": "dc2.8xlarge",
"NumberOfNodes": 3
},
{
"EstimatedDiskUtilizationPercent": 48.94601106643677,
"NodeType": "dc2.8xlarge",
"NumberOfNodes": 4
},
{
"EstimatedDiskUtilizationPercent": 39.156808853149414,
"NodeType": "dc2.8xlarge",
"NumberOfNodes": 5
},
{
"EstimatedDiskUtilizationPercent": 32.630674044291176,
"NodeType": "dc2.8xlarge",
"NumberOfNodes": 6
}
]
}
```
1. Führen Sie den folgenden Befehl aus, um den Snapshot zu der von uns gewählten Clusterkonfiguration wiederherzustellen. Nach der Wiederherstellung dieses Clusters haben wir denselben Inhalt wie der Quell-Cluster, wobei die Daten aber in drei `dc2.8xlarge`-Knoten konsolidiert wurden.
```
aws redshift restore-from-cluster-snapshot --region eu-west-1 --snapshot-identifier mycluster-snapshot --cluster-identifier mycluster-123456789012-x --node-type dc2.8xlarge --number-of-nodes 3
```
Wenn Sie über reservierte Knoten verfügen, z. B. über DC2 reservierte Knoten, können Sie ein Upgrade auf RA3 reservierte Knoten durchführen. Sie können dies tun, wenn Sie eine Wiederherstellung von einem Snapshot oder eine elastische Größenänderung durchführen. Sie können die Konsole verwenden, um sich durch den Prozess führen zu lassen. Weitere Informationen zum Upgrade auf RA3 Knoten finden Sie unter [Upgrade auf RA3 Knotentypen](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3).
**So stellen Sie einen Cluster mit der Konsole aus einem Snapshot wieder her**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster), **Snapshots** und dann den wiederherzustellenden Snapshot aus.
1. Wählen Sie **Restore from snapshot (Aus Snapshot Wiederherstellen)** aus, um die Werte **Cluster configuration (Cluster-Konfiguration)** und **Cluster details (Cluster-Details)** des neuen zu erstellenden Clusters unter Verwendung der Snapshot-Informationen anzuzeigen.
1. Aktualisieren Sie die Eigenschaften des neuen Clusters und wählen Sie dann **Restore cluster from snapshot (Cluster aus Snapshot wiederherstellen)** aus.
Nach der Wiederherstellung Ihres Cluster-Snapshots wird das wiederhergestellte Data Warehouse mit demselben benutzerdefinierten AWS -KMS-Schlüssel verschlüsselt, den es zum Zeitpunkt der Snapshot-Erstellung verwendet hat. Wenn der Snapshot keinen benutzerdefinierten KMS-Schlüssel hatte, hängt die Backup-Verschlüsselungslogik von Amazon Redshift von den folgenden Faktoren ab:
+ Der Typ des Data Warehouses von Amazon Redshift, für den Sie den Snapshot wiederherstellen.
+ Der Verschlüsselungstyp des Clusters zum Zeitpunkt der Snapshot-Erstellung.
In der folgenden Tabelle erfahren Sie, wie Ihr Data Warehouse verschlüsselt wird, nachdem Sie es aus Ihrem Cluster-Snapshot wiederhergestellt haben:
| Zieltyp | Snapshot-Verschlüsselungstyp | Zielverschlüsselungstyp |
| --- | --- | --- |
| Bereitgestellter Cluster | Verschlüsselt mit einem Von AWS verwalteter Schlüssel | Verschlüsselt mit einem Von AWS verwalteter Schlüssel |
| Bereitgestellter Cluster | Verschlüsselt mit einem AWS-eigener Schlüssel | Verschlüsselt mit einem AWS-eigener Schlüssel |
| Serverless-Namespace | Verschlüsselt mit einem Von AWS verwalteter Schlüssel | Verschlüsselt mit einem AWS-eigener Schlüssel |
| Serverless-Namespace | Verschlüsselt mit einem AWS-eigener Schlüssel | Verschlüsselt mit einem AWS-eigener Schlüssel |
Wenn Sie das Admin-Passwort Ihres Clusters zum Zeitpunkt der Snapshot-Erstellung AWS Secrets Manager verwaltet haben, müssen Sie es weiterhin AWS Secrets Manager zur Verwaltung des Admin-Passworts verwenden. Sie haben die Möglichkeit, die Verwendung von Secrets nach der Wiederherstellung des Clusters durch Aktualisierung der Administratoranmeldeinformationen des Clusters auf der Seite mit den Cluster-Details zu deaktivieren.
Wenn Sie über reservierte Knoten verfügen, können Sie ein Upgrade auf RA3 reservierte Knoten durchführen. Sie können dies tun, wenn Sie eine Wiederherstellung von einem Snapshot oder eine elastische Größenänderung durchführen. Sie können die Konsole verwenden, um sich durch den Prozess führen zu lassen. Weitere Informationen zum Upgrade auf RA3 Knoten finden Sie unter [Upgrade auf RA3 Knotentypen](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3).
# Wiederherstellen einer Tabelle aus einem Snapshot
Sie können eine einzelne Tabelle aus einem Snapshot anstellen eines gesamten Clusters wiederherstellen. Wenn Sie eine einzelne Tabelle aus eine Snapshot wiederherstellen, geben Sie Quell-Snapshot, -Datenbank, -Schema und -Tabellennamen sowie Ziel-Datenbank und -Schema und einen neuen Tabellennamen für die wiederhergestellte Tabelle an.
**Anmerkung**
Tabellen ohne Backup werden für RA3 bereitgestellte Cluster und serverlose Amazon Redshift Workgroups nicht unterstützt. Eine Tabelle, die in einem RA3 Cluster oder einer serverlosen Arbeitsgruppe als „kein Backup“ gekennzeichnet ist, wird als permanente Tabelle behandelt, die bei der Erstellung eines Snapshots immer gesichert und bei der Wiederherstellung aus einem Snapshot immer wiederhergestellt wird. Die selektive Wiederherstellung von Tabellen ohne Backup wird jedoch nicht unterstützt.
Der neue Tabellenname kann nicht identisch sein mit dem Namen einer bestehenden Tabelle. Um eine bestehende Tabelle durch eine wiederhergestellte Tabelle aus einem Snapshot zu ersetzen, sollten Sie die Tabelle umbenennen oder die bestehende Tabelle ablegen, bevor Sie die Tabelle aus dem Snapshot wiederherstellen.
Die Zieltabelle wird mithilfe der Spaltendefinitionen, Tabellenattribute und Spaltenattribute der Quelltabelle erstellt. Eine Ausnahme gilt für Fremdschlüssel. Um Konflikte aufgrund von Abhängigkeiten zu vermeiden, übernimmt die Zieltabelle keine Fremdschlüssel von der Quelltabelle. Alle Abhängigkeiten, wie z. B. Ansichten oder Berechtigungen, die für die Quelltabelle gewährt wurden, gelten nicht für die Zieltabelle.
Wenn der Eigentümer der Quelltabelle existiert, dann ist der Datenbankbenutzer der Eigentümer der wiederhergestellten Tabelle, vorausgesetzt, dieser Benutzer verfügt über ausreichend Berechtigungen, um der Eigentümer einer Beziehung in der angegebenen Datenbank und dem Schema zu sein. Anderenfalls ist die wiederhergestellte Tabelle Besitz des Adminbenutzers, der beim Starten des Clusters angelegt wurde.
Die wiederhergestellte Tabelle wird wieder in den Status zurückgesetzt, in dem sie sich zum Zeitpunkt der Sicherung befunden hat. Dazu gehören Sichtbarkeitsregeln für die Transaktion, die durch die Einhaltung der [serialisierbaren Isolation](https://docs.aws.amazon.com/redshift/latest/dg/c_serial_isolation.html) durch Amazon Redshift definiert sind. Das heißt, dass Daten für derzeit übertragene Transaktionen, die nach dem Backup gestartet wurden, sofort sichtbar sind.
Die Wiederherstellung einer Tabelle aus einem Snapshot unterliegt folgenden Beschränkungen:
+ Sie können eine Tabelle aus dem aktuellen, aktiv laufenden Cluster und aus einem Snapshot wiederherstellen, der aus diesem Cluster erstellt wurde.
+ Sie können jeweils nur eine Tabelle wiederherstellen.
+ Sie können keine Tabelle aus einem Cluster-Snapshot wiederherstellen, der erstellt wurde, bevor die Größe des Clusters verändert wurde. Eine Ausnahme ist jedoch, dass Sie eine Tabelle nach einer elastischen Größenänderung wiederherstellen können, wenn sich der Knotentyp nicht geändert hat.
+ Alle Abhängigkeiten, wie z. B. Ansichten oder Berechtigungen, die für die Quelltabelle gewährt wurden, gelten nicht für die Zieltabelle.
+ Wenn die Sicherheit auf Zeilenebene für die Wiederherstellung einer Tabelle aktiviert ist, stellt Amazon Redshift die Tabelle wieder her, wobei die Sicherheit auf Zeilenebene aktiviert ist.
**So stellen Sie eine Tabelle aus einem Snapshot wieder her:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster) und dann den Cluster aus, den Sie zur Wiederherstellung einer Tabelle verwenden möchten.
1. Wählen Sie für **Actions (Aktionen)** **Restore table (Tabelle wiederherstellen)** aus, um die Seite **Restore table (Tabelle wiederherstellen)** anzuzeigen.
1. Geben Sie die Informationen darüber ein, welchen Snapshot, welche Quelltabelle und welche Zieltabelle Sie verwenden möchten. Wählen Sie dann **Restore table** (Tabelle wiederherstellen) aus.
**Example Beispiel: Wiederherstellen einer Tabelle aus einem Snapshot mithilfe des AWS CLI**
Im folgenden Beispiel wird der `restore-table-from-cluster-snapshot` AWS CLI Befehl verwendet, um die `my-source-table` Tabelle aus dem `sample-database` Schema in der wiederherzustellen`my-snapshot-id`. Sie können den AWS CLI Befehl verwenden`describe-table-restore-status`, um den Status Ihres Wiederherstellungsvorgangs zu überprüfen. Bei diesem Beispiel wird der Snapshot in das Cluster `mycluster-example` mit einem neuen Tabellennamen `my-new-table` wiederhergestellt.
```
aws redshift restore-table-from-cluster-snapshot --cluster-identifier mycluster-example
--new-table-name my-new-table
--snapshot-identifier my-snapshot-id
--source-database-name sample-database
--source-table-name my-source-table
```
# Wiederherstellen eines Serverless-Namespace aus einem Snapshot
Beim Wiederherstellen eines Serverless-Namespaces aus einem Snapshot werden alle Datenbanken des Namespaces durch Datenbanken im Snapshot ersetzt. Weitere Informationen zu Serverless-Snapshots finden Sie unter [Snapshots und Wiederherstellungspunkte](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-snapshots-recovery-points.html). Amazon Redshift wandelt Tabellen mit überlappenden Schlüsseln automatisch in zusammengesetzte Schlüssel um, wenn Sie einen Snapshot eines bereitgestellten Clusters in einem Namespace von Amazon Redshift Serverless wiederherstellen. Weitere Informationen zu Sortierschlüsseln finden Sie unter [Arbeiten mit Sortierschlüsseln](https://docs.aws.amazon.com/redshift/latest/dg/t_Sorting_data.html).
So stellen Sie einen Snapshot von Ihrem bereitgestellten Cluster in Ihrem Serverless-Namespace wieder her.
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster), **Snapshots** und dann den zu verwendenden Snapshot aus.
1. Wählen Sie **Restore from snapshot** (Aus Snapshot wiederherstellen), **Restore to serverless namespace** (In Serverless-Namespace wiederherstellen).
1. Wählen Sie den Namespace, in dem Sie wiederherstellen möchten.
1. Bestätigen Sie, dass Sie von Ihrem Snapshot aus wiederherstellen möchten. Wählen Sie **restore** (Wiederherstellen) aus. Diese Aktion ersetzt alle Datenbanken im Serverless-Namespace durch die Daten aus Ihrem bereitgestellten Cluster.
# Konfigurieren von regionenübergreifenden Snapshot-Kopien für nicht verschlüsselte Cluster
Sie können Amazon Redshift so konfigurieren, dass Snapshots für einen Cluster in eine andere AWS Region kopiert werden. Um die regionsübergreifende Snapshot-Kopie zu konfigurieren, müssen Sie diese Kopierfunktion für jeden Cluster aktivieren und konfigurieren, wo Snapshots kopiert werden sollen und wie lange kopierte automatische oder manuelle Snapshots in der Zielregion aufbewahrt werden sollen. AWS Wenn das regionsübergreifende Kopieren für einen Cluster aktiviert ist, werden alle neuen manuellen und automatisierten Snapshots in die angegebene Region kopiert. AWS Den Namen der kopierten Snapshots wird jeweils das Präfix vorangestellt **copy:**.
**So konfigurieren Sie einen regionenübergreifenden Snapshot**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster) und dann den Cluster aus, für den Sie Snapshots verschieben möchten.
1. Wählen Sie bei **Actions (Aktionen)** **Configure cross-region snapshot (Regionsübergreifenden Snapshot konfigurieren)** aus.
Das Dialogfeld „Configure cross-Region“ (Regionsübergreifenden Snapshot konfigurieren) wird angezeigt.
1. Wählen Sie bei **Copy snapshots (Snapshots kopieren)** **Yes (Ja)** aus.
1. Wählen Sie unter ** AWS Zielregion** die AWS Region aus, in die Snapshots kopiert werden sollen.
1. Wählen Sie **unter Aufbewahrungszeitraum für automatisierte Snapshots (Tage)** die Anzahl der Tage aus, für die automatische Snapshots in der AWS Zielregion aufbewahrt werden sollen, bevor sie gelöscht werden.
1. Wählen Sie **unter Aufbewahrungszeitraum für manuelle Snapshots** den Wert aus, der die Anzahl der Tage angibt, für die manuelle Snapshots in der AWS Zielregion aufbewahrt werden sollen, bevor sie gelöscht werden. Wenn Sie **Custom value (Benutzerdefinierter Wert)** auswählen, muss der Aufbewahrungszeitraum zwischen 1 und 3 653 Tagen liegen.
1. Wählen Sie **Speichern**.
# Konfiguration der regionsübergreifenden Snapshot-Kopie für einen AWS KMS—verschlüsselten Cluster
Wenn Sie einen Amazon-Redshift-Cluster starten, können Sie eine Snapshot-Kopie-Berechtigung für einen Root-Schlüssel in Ihrem Konto im Ziel AWS-Region konfigurieren. Wenn Sie keinen Grant konfigurieren, werden Snapshots in der Zielregion mit einem eigenen AWS Standardschlüssel verschlüsselt. Dadurch ermöglichen Sie Amazon Redshift die Durchführung von Verschlüsselungsvorgängen in der AWS -Zielregion.
Im folgenden Verfahren wird beschrieben, wie Sie die regionsübergreifende Snapshot-Kopie für einen AWS KMS-verschlüsselten Cluster aktivieren. Weitere Informationen zur Verschlüsselung in Amazon Redshift und zu Snapshot-Kopie-Berechtigungen finden Sie unter [Kopieren von —verschlüsselten Snapshots in einen anderen AWS KMS AWS-Region](working-with-db-encryption.md#configure-snapshot-copy-grant).
**So konfigurieren Sie einen regionsübergreifenden Snapshot für einen —verschlüsselten Cluster AWS KMS**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster) und dann den Cluster aus, für den Sie Snapshots verschieben möchten.
1. Wählen Sie bei **Actions (Aktionen)** **Configure cross-region snapshot (Regionsübergreifenden Snapshot konfigurieren)** aus.
Das Dialogfeld „Configure cross-Region“ (Regionsübergreifenden Snapshot konfigurieren) wird angezeigt.
1. Wählen Sie bei **Copy snapshots (Snapshots kopieren)** **Yes (Ja)** aus.
1. Wählen Sie unter ** AWS Zielregion** die AWS Region aus, in die Snapshots kopiert werden sollen.
1. Wählen Sie **unter Aufbewahrungszeitraum für automatisierte Snapshots (Tage)** die Anzahl der Tage aus, für die automatische Snapshots in der AWS Zielregion aufbewahrt werden sollen, bevor sie gelöscht werden.
1. Wählen Sie **unter Aufbewahrungszeitraum für manuelle Snapshots** den Wert aus, der die Anzahl der Tage angibt, für die manuelle Snapshots in der AWS Zielregion aufbewahrt werden sollen, bevor sie gelöscht werden. Wenn Sie **Custom value (Benutzerdefinierter Wert)** auswählen, muss der Aufbewahrungszeitraum zwischen 1 und 3 653 Tagen liegen.
1. Wählen Sie **Speichern**.
# Ändern des Aufbewahrungszeitraum für manuelle Snapshots
Sie können den Aufbewahrungszeitraum für einen manuellen Snapshots ändern, indem Sie die Einstellungen für Snapshots anpassen.
**So ändern Sie den Aufbewahrungszeitraum für manuelle Snapshots**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster), **Snapshots** und dann den manuellen Snapshot aus, der geändert werden soll.
1. Wählen Sie für **Actions (Aktionen)** **Manual snapshot settings (Manuelle Snapshot-Einstellungen)** aus, um die Eigenschaften des manuellen Snapshots anzuzeigen.
1. Geben Sie die überarbeiteten Eigenschaften der Snapshot-Definition ein und wählen Sie dann **Save (Speichern)** aus.
# Ändern des Aufbewahrungszeitraums für regionenübergreifende Snapshot-Kopien
Möglicherweise möchten Sie bestimmte Einstellungen ändern, nachdem Sie regionenübergreifende Snapshot-Kopien konfiguriert haben. Sie können die Aufbewahrungsfrist ganz einfach ändern, indem Sie eine andere Anzahl an Tagen auswählen und dann die Änderungen speichern.
**Warnung**
Sie können die AWS Zielregion nicht ändern, nachdem die regionsübergreifende Snapshot-Kopie konfiguriert wurde.
Wenn Sie Snapshots in eine andere AWS Region kopieren möchten, deaktivieren Sie zunächst das regionsübergreifende Kopieren von Snapshots. Aktivieren Sie es dann erneut mit einer neuen AWS Zielregion und einer neuen Aufbewahrungsfrist. Alle kopierten automatisierten Snapshots werden gelöscht, nachdem Sie die regionenübergreifende Snapshot-Kopie deaktiviert haben. Daher sollten Sie überlegen, ob es welche gibt, die Sie behalten möchten, und sie in manuelle Snapshots kopieren, bevor Sie die regionenübergreifende Snapshot-Kopie deaktivieren.
**So ändern Sie einen regionenübergreifenden Snapshot**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster) und dann den Cluster aus, für den Sie Snapshots ändern möchten.
1. Wählen Sie unter **Actions (Aktionen)** die Option **Configure cross-region snapshot (Regionsübergreifenden Snapshot konfigurieren)**, um die Eigenschaften des Snapshots anzuzeigen.
1. Geben Sie die überarbeiteten Eigenschaften der Snapshot-Definition ein und wählen Sie dann **Save (Speichern)** aus.
# Löschen eines manuellen Snapshots
Sie können manuelle Snapshots löschen, indem Sie einen oder mehrere Snapshots in der Liste der Snapshots auswählen.
**So löschen Sie einen manuellen Snapshot**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster), **Snapshots** und dann den zu löschenden Snapshot aus.
1. Wählen Sie für **Actions (Aktionen)** **Delete snapshot (Snapshot löschen)** aus, um den Snapshot zu löschen.
1. Bestätigen Sie das Löschen der aufgelisteten Snapshots und wählen Sie dann **Delete (Löschen)** aus.
# Registrierung eines Clusters bei AWS Glue Data Catalog
Sie können ganze Cluster bei der registrieren AWS Glue Data Catalog und Kataloge erstellen, die von verwaltet werden AWS Glue. Sie können mit jeder SQL-Engine, die die Apache Iceberg-REST-API unterstützt, auf diese Kataloge zugreifen. Weitere Informationen zum Erstellen von mit Apache Iceberg kompatiblen Katalogen aus Amazon Redshift finden Sie unter [Kompatibilität mit Apache Iceberg für Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/iceberg-integration_overview.html) im Datenbankentwicklerhandbuch für Amazon Redshift.
**Um einen Cluster bei der zu registrieren AWS Glue Data Catalog**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon Redshift Redshift-Konsole unter [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. Wählen Sie im Navigationsmenü **Clusters** (Cluster) aus. Die aktuellen Cluster für Ihr Konto AWS-Region sind aufgeführt. Eine Teilmenge der Eigenschaften jedes Clusters wird in den Spalten der Liste angezeigt. Wenn Sie keine Cluster haben, wählen Sie **Create cluster (Cluster erstellen)** aus, um einen Cluster zu erstellen.
1. Wählen Sie den Namen des Clusters, den Sie registrieren möchten.
1. Wählen Sie **unter Aktionen** die Option **Registrieren für** aus AWS Glue Data Catalog. Das Popup-Feld **Bei AWS Glue Data Catalog registrieren** wird angezeigt.
1. Geben Sie unter AWS **Zielkonto-ID die Konto-ID** ein, für die Sie den Cluster registrieren möchten. Dies ist die Konto-ID, in der der Katalog im AWS Glue Data Catalog gespeichert werden soll.
1. Geben Sie unter **Namespace registrieren als** einen Namen ein. Dies wird der Name des Clusters im Data Catalog sein.
1. Wählen Sie **Registrieren** aus. Sie werden zur AWS Lake Formation Konsole weitergeleitet.
1. Folgen Sie dem Prozess für die Katalogerstellung in AWS Lake Formation. Weitere Informationen zur Erstellung eines Katalogs finden Sie unter [Amazon-Redshift-Daten in den AWS Glue Data Catalog einführen](https://docs.aws.amazon.com/lake-formation/latest/dg/managing-namespaces-datacatalog.html) im AWS Lake Formation -Entwicklerhandbuch.