Amazon Redshift unterstützt ab Patch 198 nicht mehr die Erstellung neuer Python-UDFs. Bestehende Python-UDFs werden 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.
# Multi-AZ Einrichtung der Bereitstellung
Um eine Multi-AZ Bereitstellung einzurichten, wählen Sie die **Multi-AZ**Option aus und geben Sie die Anzahl der Rechenknoten an, die in jeder Availability Zone bereitgestellt werden sollen. Amazon Redshift stellt automatisch gleiche Rechenressourcen in zwei Availability Zones bereit. Alle Rechenressourcen sind dabei während des normalen Betriebs stets sowohl für die Lese- als auch für die Schreibverarbeitung verfügbar. Auf diese Weise kann eine Multi-AZ Bereitstellung als einzelnes Data Warehouse mit einem einzigen Endpunkt fungieren, sodass im Notfall keine Anwendungsänderungen erforderlich sind. Eine Multi-AZ Bereitstellung verarbeitet zwar eine einzelne Abfrage unter Verwendung der Rechenressourcen, die sich in nur einer Availability Zone befinden, kann aber die Verarbeitung mehrerer gleichzeitiger Abfragen automatisch auf beide Availability Zones verteilen, um den Gesamtdurchsatz bei Workloads mit hoher Parallelität zu erhöhen.
Sie können auch ein vorhandenes Single-AZ Data Warehouse in ein Multi-AZ Data Warehouse umwandeln oder umgekehrt. Alles bleibt gleich, es werden lediglich zusätzliche Rechenressourcen in der zweiten Availability Zone bereitgestellt. Wenn Sie zu Multi-AZ einem vorhandenen Single-AZ Cluster migrieren, müssen Sie möglicherweise die Anzahl der benötigten Clusterknoten verdoppeln, damit die Leistung einer einzelnen Abfrage erhalten bleibt. Bei den meisten Workloads ist mit einem Multi-AZ Data Warehouse ein Anstieg des Gesamtdurchsatzes bei der Abfrageverarbeitung zu beobachten, da doppelt so viele Rechenressourcen zur Verfügung stehen.
Im Falle eines Ausfalls in einer Availability Zone setzt Amazon Redshift den Betrieb fort und verwendet automatisch die Ressourcen in der verbleibenden Availability Zone. Benutzerverbindungen könnten jedoch getrennt werden und müssen erneut hergestellt werden. Darüber hinaus können Abfragen, die gerade in der ausgefallenen Availability Zone ausgeführt wurden, fehlschlagen und müssen wiederholt werden. Sie können jedoch erneut eine Verbindung zu Ihrem Cluster herstellen und Abfragen sofort neu planen und Amazon Redshift verarbeitet die Abfragen in der verbleibenden Availability Zone. Bei Abfragen, die bei oder nach dem Auftreten eines Fehlers ausgegeben werden, kann es zu Laufzeitverzögerungen kommen, während das Multi-AZ Data Warehouse wiederhergestellt wird.
**Anmerkung**
Um eine bessere Leistung und höhere Verfügbarkeit zu erzielen, empfehlen wir, SNAPSHOT ISOLATION mit Ihren Multi-AZ Clustern zu verwenden. Weitere Informationen finden Sie unter [CREATE DATABASE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_DATABASE.html).
## Einschränkungen
Ein Multi-AZ Data Warehouse hat dieselben funktionalen Funktionen wie ein Single-AZ Data Warehouse, mit Ausnahme der folgenden Einschränkungen, die für ein Multi-AZ Data Warehouse gelten:
+ Sie können kein unverschlüsseltes Multi-AZ Data Warehouse erstellen. Achten Sie darauf, eine Verschlüsselung hinzuzufügen, wenn Sie ein neues Multi-AZ Data Warehouse erstellen, ein Single-AZ Data Warehouse in ein Multi-AZ Data Warehouse konvertieren oder ein Single-AZ Data Warehouse in ein Multi-AZ Data Warehouse konvertieren.
+ Sie können für keinen der RG- oder RA3-Instance-Typen eine Multi-AZ Bereitstellung mit einem einzelnen Knoten erstellen. Wählen Sie bei der Erstellung einer Bereitstellung 2 oder mehr Knoten pro Availability Zone aus. Multi-AZ
+ Amazon Redshift erfordert keine Subnetzkonfiguration, die weniger als drei Availability Zones unterstützen kann. Mit anderen Worten: Die konfigurierte Subnetzgruppe benötigt drei oder mehr weitere Subnetze.
+ Sie können eine Multi-AZ Bereitstellung nicht in eine andere Availability Zone verlagern. Der Umzug wird automatisch von Amazon Redshift bestimmt und durchgeführt, wenn die Bereitstellung verwendet Multi-AZ wird.
+ Sie können eine Multi-AZ Bereitstellung nicht anhalten oder fortsetzen.
+ Sie können Ihre Multi-AZ Bereitstellung nicht außerhalb der unterstützten Portbereiche 5431 bis 5455 und 8191 bis 8215 ausführen.
+ Sie können STL-, SVCS-, SVL-, SVV- und STV-Ansichten nicht mit Multi-AZ Bereitstellungen verwenden, da sie nur Systemüberwachungsansichten (SYS\_\*-Ansichten) unterstützen. Ändern Sie Ihre Überwachungsanfragen so, dass sie Systemüberwachungsansichten (SYS\_\*-Ansichten) verwenden.
+ Sie können keine Elastic IP-Adresse an einen vorhandenen Cluster anhängen, wenn dieser aktiviert ist. Multi-AZ
+ Sie können einen Cluster mit einer angehängten Elastic IP-Adresse nicht von Single-AZ zu konvertieren Multi-AZ.
+ Die Amazon Redshift Multi-AZ Redshift-Bereitstellung ist in den folgenden AWS-Regionen Bereichen verfügbar:
**Anmerkung**
RG-Instances sind in ausgewählten Regionen verfügbar. Weitere Informationen finden Sie unter [Verfügbarkeit von RG-Knotentypen in AWS Regionen](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-cluster-considerations.html#rg-regions).
+ USA Ost (Ohio): (us-east-2)
+ USA Ost (Nord-Virginia): (us-east-1)
+ USA West (Oregon): (us-west-2)
+ Afrika (Kapstadt) (af-south-1)
+ Asien-Pazifik (Hongkong) (ap-east-1)
+ Asien-Pazifik (Taipei) (ap-east-2)
+ Asien-Pazifik (Hyderabad) (ap-south-2)
+ Asien-Pazifik (Jakarta) (ap-southeast-3)
+ Asien-Pazifik (Malaysia) (ap-southeast-5)
+ Asien-Pazifik (Melbourne) (ap-southeast-4)
+ Asien-Pazifik (Mumbai): (ap-south-1)
+ Asien-Pazifik (Osaka) (ap-northeast-3)
+ Asien-Pazifik (Seoul): (ap-northeast-2)
+ Asien-Pazifik (Singapur): (ap-southeast-1)
+ Asien-Pazifik (Sydney): (ap-southeast-2)
+ Asien-Pazifik (Neuseeland) (ap-southeast-6)
+ Asien-Pazifik (Thailand) (ap-southeast-7)
+ Asien-Pazifik (Tokyo) (ap-northeast-1)
+ Kanada (Zentral): (ca-central-1)
+ China (Peking) (cn-north-1)
+ China (Ningxia) (cn-northwest-1)
+ Europa (Frankfurt) (eu-central-1)
+ Europa (Irland) (eu-west-1)
+ Europa (London) (eu-west-2)
+ Europa (Mailand) (eu-south-1)
+ Europa (Paris) (eu-west-3)
+ Europa (Spanien) (eu-south-2)
+ Europa (Stockholm) (eu-north-1)
+ Europa (Zürich) (eu-central-2)
+ Israel (Tel Aviv) (il-central-1)
+ Mexiko (Zentral) (mx-central-1)
+ Naher Osten (Bahrain) (me-south-1)
+ Naher Osten (VAE) (me-central-1)
+ Südamerika (São Paulo) (sa-east-1)
+ AWS GovCloud (US-East) (us-gov-east-1)
+ AWS GovCloud () (US-Regierung West-1) US-West
+ Öffentlich zugängliche Multi-AZ Data Warehouses unterstützen 1 VPC-Sicherheitsgruppe weniger als Single-AZ privat zugängliche Multi-AZ Warehouses.