Häufig gestellte Fragen zu Amazon Aurora

Auf der Aurora-Preisseite finden Sie die aktuellen Preisinformationen.

Derzeit gibt es kein kostenloses AWS-Kontingent für Aurora. Aurora speichert Ihre Daten jedoch dauerhaft in drei Availability Zones in einer Region und berechnet nur eine Kopie der Daten. Backups von bis zu 100 % der Größe Ihres Datenbank-Clusters werden Ihnen nicht in Rechnung gestellt. Während des Backup-Aufbewahrungszeitraums, den Sie für Ihren Datenbank-Cluster konfiguriert haben, werden Ihnen auch keine Snapshots in Rechnung gestellt.

Nein. Die Aurora-Replikation ist im Paketpreis enthalten. Es wird auf Basis des Speichers verrechnet, den Ihre Datenbank in der Datenbankschicht nutzt, nicht auf Basis des in der virtualisierten Speicherebene von Aurora verbrauchten Speichers.

E/A-Vorgänge sind Ein- und Ausgabe-Operationen, die die Aurora-Datenbank-Engine in ihrer SSD-basierten virtualisierten Speicherschicht durchführt. Jeder Datenbank-Seiten-Lesevorgang zählt als ein E/A.
Die Aurora-Datenbank-Engine führt Lesevorgänge in der Speicherschicht aus, um Datenbankseiten abzurufen, die nicht im Speicher des Cache vorhanden sind:

• Wenn Ihr Abfrageverkehr vollständig aus dem Speicher oder dem Cache bedient werden kann, werden Ihnen keine Kosten für das Abrufen von Datenseiten aus dem Speicher berechnet.
• Wenn Ihr Abfrageverkehr nicht vollständig aus dem Speicher bedient werden kann, werden Ihnen Kosten für alle Datenseiten berechnet, die aus dem Speicher abgerufen werden müssen.
  Jede Datenbank in der Amazon-Aurora-MySQL-kompatiblen Edition ist 16 KB groß, jede Datenbank in der Aurora-PostgreSQL-kompatiblen Edition ist 8 KB groß.

Aurora ist so konzipiert, dass es unnötige E/A-Vorgänge eliminiert, so die Kosten senkt und sicherstellt, dass die Ressourcen für Lese-/Schreibvorgänge verfügbar sind. Schreib-E/As werden nur verbraucht, wenn Redo-Protokoll-Aufzeichnungen in Aurora-MySQL-kompatible Edition oder Write-Ahead-Protokoll-Aufzeichnungen in Aurora-PostgreSQL-kompatible Edition in der Speicherschicht persistiert werden, um Schreibvorgänge dauerhaft zu machen.

E/A-Schreibvorgänge werden in 4-KB-Einheiten gezählt. Eine Protokoll-Aufzeichnung mit 1,024 Bytes beispielsweise zählt als ein geschriebener E/A-Vorgang. Wenn die Protokoll-Aufzeichnung jedoch größer als 4 KB ist, ist mehr als ein Schreib-E/A-Vorgang erforderlich, um sie zu persistieren.

Gleichzeitige Schreibvorgänge, deren Transaktionsprotokoll weniger als 4 KB hat, können jedoch zur Optimierung der E/A-Nutzung durch die Aurora-Datenbank-Engine zusammengefasst werden. Im Gegensatz zu herkömmlichen Datenbank-Engines werden bei Aurora keine schmutzigen Datenseiten in den Speicher gespült.

Der Umfang der E/A-Anfragen, die Ihre Aurora-Instance nutzt, wird in der AWS-Managementkonsole angezeigt. Um Ihren E/A-Verbrauch zu ermitteln, gehen Sie in den Amazon-RDS-Bereich der Konsole, sehen Sie sich Ihre Liste der Instances an, wählen Sie Ihre Aurora-Instances aus und suchen Sie dann im Überwachungsbereich nach den Metriken „VolumeReadIOPs“ und „VolumeWriteIOPs“.

Weitere Informationen zur Preisgestaltung für E/A-Vorgänge finden Sie auf der Aurora-Preisseite. Wenn Sie Ihre Datenbank-Cluster für die Aurora-Standardkonfiguration konfigurieren, werden Ihnen Lese- und Schreib-E/A-Vorgänge in Rechnung gestellt. Wenn Sie Ihre Datenbank-Cluster für Amazon Aurora I/O-Optimized konfigurieren, fallen Ihnen keine Gebühren für Lese- und Schreibvorgänge an.

Aurora bietet Ihnen die Flexibilität, Ihre Datenbankausgaben zu optimieren, indem Sie je nach Ihren Anforderungen an Preisleistung und Preisvorhersehbarkeit zwischen zwei Konfigurationsoptionen wählen. Die beiden Konfigurationsoptionen sind Aurora Standard und Aurora I/O-Optimized. Keine der beiden Optionen erfordert E/A im Voraus oder Speicherbereitstellung, und beide können E/A-Vorgänge skalieren, um Ihre anspruchsvollsten Anwendungen zu unterstützen.

Aurora Standard ist eine Datenbank-Cluster-Konfiguration, die kostengünstige Preise für die überwiegende Mehrheit der Anwendungen mit geringer bis mäßiger E/A-Auslastung bietet. Mit Aurora Standard zahlen Sie für Datenbank-Instances, Speicher und Pay-per-Request-E/A.

Aurora I/O-Optimized ist eine Datenbank-Cluster-Konfiguration, die eine verbesserte Preisleistung für E/A-intensive Anwendungen wie Zahlungsverarbeitungssysteme, E-Commerce-Systeme und Finanzanwendungen bietet. Wenn Ihre E/A-Ausgaben 25 % Ihrer gesamten Aurora-Datenbankausgaben übersteigen, können Sie mit Aurora I/O-Optimized bis zu 40 % der Kosten für E/A-intensive Workloads sparen. Aurora I/O-Optimized bietet vorhersehbare Preise für alle Anwendungen, da keine Gebühren für Lese- und Schreib-E/A-Vorgänge anfallen. Somit ist diese Konfiguration ideal für Workloads mit hoher E/A-Variabilität.

Aurora I/O-Optimized ist die ideale Wahl, wenn Sie vorhersehbare Kosten für jede Anwendung benötigen. Es bietet eine verbesserte Preisleistung für E/A-intensive Anwendungen, die einen hohen Schreibdurchsatz erfordern oder analytische Abfragen zur Verarbeitung großer Datenmengen ausführen. Kunden, deren I/O-Ausgaben 25 % ihrer Aurora-Rechnung übersteigen, können mit Aurora I/O-Optimized bis zu 40 % der Kosten für I/O-intensive Workloads sparen.

Sie können die in der AWS-Managementkonsole verfügbare Ein-Klick-Funktion nutzen, um den Speichertyp Ihrer vorhandenen Datenbank-Cluster so zu ändern, dass er Aurora I/O-Optimized ist. Sie können auch die AWS-Befehlszeilenschnittstelle (AWS CLI) oder das AWS-SDK aufrufen, um diese Änderung vorzunehmen.

Sie können Ihre vorhandenen Datenbank-Cluster alle 30 Tage auf Aurora I/O-Optimized umstellen. Sie können jederzeit wieder zu Aurora Standard wechseln.

Ja, Aurora I/O-Optimized funktioniert mit vorhandenen Aurora Reserved Instances. Aurora berücksichtigt automatisch den Preisunterschied zwischen Aurora Standard und Aurora I/O-Optimized mit Reserved Instances. Mit den Rabatten für Reserved Instances mit Aurora I/O-Optimized können Sie noch mehr Einsparungen bei Ihren E/A-Ausgaben erzielen.

Der Preis für Backtrack, Snapshot, Export oder kontinuierlichen Backup ändert sich mit Aurora I/O-Optimized nicht.

Ja, die Gebühren für die E/A-Vorgänge, die für die regionsübergreifende Datenreplikation erforderlich sind, fallen weiterhin an. Aurora I/O-Optimized berechnet keine Gebühren für Lese- und Schreib-E/A-Vorgänge, was sich von der Datenreplikation unterscheidet.

Für die optimierten Lesevorgänge von Amazon Aurora für Aurora PostgreSQL fallen neben dem Preis für Intel-basierte R6id- und Graviton-basierte R6gd-Instances keine zusätzlichen Kosten an. Weitere Informationen finden Sie auf der Preisübersicht für Aurora.

Es gibt ein unteres Speicherplatzlimit von 10 GB. Basierend auf Ihrer Datenbanknutzung wächst Ihr Amazon Aurora-Speicher automatisch in 10-GB-Schritten auf bis zu 128 TiB. Die Datenbankleistung wird dadurch nicht beeinträchtigt. Es besteht keine Notwendigkeit, Speicher im Voraus bereitzustellen.

Es gibt zwei Möglichkeiten, die mit meiner Amazon Aurora-DB-Instance verbundenen Rechenressourcen zu skalieren. Über Aurora Serverless und durch manuelle Anpassung.

Sie können Aurora Serverless, eine On-Demand-Konfiguration mit automatischer Skalierung für Amazon Aurora, verwenden, um Datenbank-Computing-Ressourcen basierend auf der Anwendungsnachfrage zu skalieren. Damit können Sie Ihre Datenbank in der Cloud ausführen, ohne sich Gedanken über die Verwaltung der Datenbankkapazität machen zu müssen. Sie können den gewünschten Kapazitätsbereich der Datenbank angeben und Ihre Datenbank wird basierend auf den Anforderungen Ihrer Anwendung skaliert. Lesen Sie mehr im Benutzerhandbuch zu Aurora Serverless.

Sie können Ihre mit Ihrer Datenbank verknüpften Computing-Ressourcen auch manuell skalieren, indem Sie den gewünschten DB-Instance-Typ in der AWS-Managementkonsole auswählen. Ihre angeforderte Änderung wird während Ihres angegebenen Wartungsfensters angewendet. Sie können auch das Flag „Sofort anwenden“ verwenden, um den DB-Instance-Typ sofort zu ändern.

Beide Optionen wirken sich ein paar Minuten lang auf die Verfügbarkeit aus, solange die Skalierung durchgeführt wird. Beachten Sie, dass in diesem Fall alle anderen noch ausstehenden Systemänderungen ebenfalls übernommen werden.

Automatisierte fortlaufende Backups sind auf Amazon-Aurora DB-Instances immer aktiviert. Backups wirken sich nicht auf die Leistung der Datenbank aus.

Ja. Das Erstellen von Snapshots wirkt sich nicht auf die Leistung aus. Die Wiederherstellung von Daten aus DB-Snapshots erfordert die Erstellung einer neuen DB Instance.

Amazon Aurora macht Ihre Daten automatisch über drei Availability Zones (AZs) in einer Region hinweg dauerhaft und versucht automatisch, Ihre Datenbank in einer fehlerfreien AZ ohne Datenverlust wiederherzustellen. Im unwahrscheinlichen Fall, dass Ihre Daten im Amazon-Aurora-Speicher nicht verfügbar sind, können Sie aus einem DB-Snapshot wiederherstellen oder eine zeitpunktbezogene Wiederherstellung auf eine neue Instance durchführen. Beachten Sie, dass der späteste wiederherstellbare Zeitpunkt für einen zeitpunktbezogenen Wiederherstellungsvorgang bis zu fünf Minuten in der Vergangenheit liegen kann.

Sie können vor dem Löschen Ihrer DB-Instance einen abschließenden DB-Snapshot erstellen. In diesem Fall können Sie diesen DB-Snapshot zum Wiederherstellen der gelöschten DB-Instance zu einem späteren Zeitpunkt nutzen. Amazon Aurora behält diesen letzten vom Benutzer erstellten DB-Snapshot zusammen mit allen anderen manuell erstellten DB-Snapshots bei, nachdem die DB-Instance gelöscht wurde. Nach dem Löschen der DB-Instance werden nur DB-Snapshots beibehalten (d. h. automatisierte Backups für zeitpunktbezogene Wiederherstellung werden nicht beibehalten).

Ja. Aurora bietet Ihnen die Möglichkeit, Snapshots Ihrer Datenbanken zu erstellen, die Sie später zum Wiederherstellen einer Datenbank verwenden können. Sie können einen Snapshot für ein anderes AWS-Konto freigeben und der Besitzer des Empfängerkontos kann Ihren Snapshot verwenden, um eine Datenbank wiederherzustellen, die Ihre Daten enthält. Sie können Ihre Snapshots sogar öffentlich zugänglich machen, sodass jeder eine Datenbank mit Ihren (öffentlichen) Daten wiederherstellen kann.

Sie können dieses Feature nutzen, um Daten zwischen Ihren unterschiedlichen Umgebungen (Produktion, Entwicklung/Tests, Staging usw.) zu teilen, die unterschiedliche AWS-Konten nutzen, sowie Sicherungen all Ihrer Daten in einem getrennten Konto aufzubewahren, falls einmal in Ihr AWS-Konto eingebrochen werden sollte.

Die Freigabe von Snapshots zwischen Konten ist kostenlos. Möglicherweise werden Ihnen aber die Snapshots selbst sowie die Datenbanken, die Sie über freigegebene Snapshots wiederherstellen, in Rechnung gestellt. Weitere Informationen über Aurora-Preise.

Die automatische Freigabe von DB-Snapshots wird nicht unterstützt. Um einen Snapshot freizugeben, müssen Sie manuell eine Kopie des Snapshots erstellen und diese Kopie dann freigeben.

Sie können manuelle Snapshots für bis zu 20 AWS-Konto-IDs freigeben. Wenn Sie den Snapshot für mehr als 20 Konten freigeben möchten, können Sie den Snapshot entweder öffentlich freigeben oder sich an den Support wenden, damit Ihr Kontingent erhöht wird.

Sie können Ihre Aurora-Snapshots für jede AWS-Region freigeben, in der Aurora verfügbar ist.

Nein. Auf Ihre freigegebenen Aurora-Snapshots kann nur von Konten in derselben Region wie das freigebende Konto zugegriffen werden.

Ja, Sie können verschlüsselte Aurora-Snapshots freigeben.

Amazon Aurora trennt automatisch Ihr Datenbank-Volume in 10 GB-Segmente, die auf vielen unterschiedlichen Datenträgern untergebracht sind. Jeder 10 GB-Block Ihrer Datenbank wird sechsfach und in drei AZs repliziert. Amazon Aurora ist so konzipiert, dass es transparent den Verlust von bis zu zwei Kopien der Daten ohne Beeinträchtigung der Schreibverfügbarkeit, und bis zu drei Kopien ohne Beeinträchtigung der Verfügbarkeit von Leseleistung verarbeiten kann.

Außerdem behebt der Speicher von Amazon Aurora Probleme automatisch. Datenblocks und Datenträger werden laufend auf Fehler untersucht und automatisch repariert.

Anders als andere Datenbanken muss Amazon Aurora nach einem Datenbankabsturz und bevor es die Datenbank für Operationen zur Verfügung stellt, nicht das Redo Protokoll aus dem letzten Datenbank-Prüfpunkt wiedergeben (was normalerweise 5 Minuten dauert) und rückmelden, dass alle Änderungen angewendet wurden. Das reduziert in den meisten Fällen die Dauer des Neustarts auf weniger als 60 Sekunden.

Amazon Aurora löst den Puffercache der Datenbank vom Datenbankprozess und macht diesen sofort zum Zeitpunkt des Neustarts verfügbar. Das verhindert eine Drosselung des Zugriffs bis zur Neuauffüllung des Caches zur Vermeidung von Brownouts.

Amazon-Aurora-MySQL-kompatible Edition und Amazon-Aurora-PostgreSQL-kompatible Edition unterstützen Amazon Aurora Replikate, die das gleiche zugrunde liegende Volumen wie die primären Instance in derselben AWS-Region teilen. Durch die primäre Instance ausgeführte Updates sind in allen Amazon-Aurora-Replikaten sichtbar.

Mit Amazon-Aurora-MySQL-kompatible Edition können Sie auch unter Anwendung der Binlog-basierten MySQL-Replizierungs-Engine regionsübergreifende MySQL-Lesereplikate erstellen. Bei MySQL-Lesereplikaten werden Daten aus Ihrer primären Instance auf Ihrem Replikat als Transaktionen wiedergegeben. Für die meisten Anwendungsfälle, auch die Skalierung der Lesevorgänge und hohe Verfügbarkeit, empfehlen wir die Nutzung von Amazon-Aurora-Replikaten.

Sie können diese beiden Replikattypen je nach Anwendungsbedarf flexibel miteinander kombinieren:

Sie haben zwei weitere Replikationsoptionen, zusätzlich zu den oben aufgeführten. Sie können Aurora Global Database für eine schnellere physische Replikation zwischen Aurora-Clustern in verschiedenen Regionen verwenden. Und für Replikation zwischen Aurora und Datenbanken, die nicht auf Aurora-MySQL-kompatible Edition basieren (sogar außerhalb von AWS), können Sie Ihre eigene, selbstverwaltete Binlog-Replikation aufsetzen.

Ja, Sie können regionenübergreifende Aurora Replikate entweder mit logischer oder physischer Replikation einrichten. Die physische Replikation, die Amazon Aurora Global Database genannt wird, verwendet eine dedizierte Infrastruktur, die Ihre Datenbanken vollständig verfügbar macht, um Ihre Anwendung zu bedienen, und die in bis zu fünf sekundäre Regionen mit einer typischen Latenz von weniger als einer Sekunde repliziert werden kann. Sie steht sowohl für Aurora-MySQL-kompatible Edition als auch für Aurora-PostgreSQL-kompatible Edition zur Verfügung.

Für globale Lesezugriffe mit niedriger Latenz und Disaster Recovery empfehlen wir die Verwendung von Amazon Aurora Global Database.
Aurora unterstützt die native logische Replikation in jeder Datenbank-Engine (Binlog für MySQL- und PostgreSQL-Replikationsslots für PostgreSQL), so dass Sie auf Aurora- und Nicht-Aurora-Datenbanken replizieren können, sogar über Regionen hinweg.

Aurora-MySQL-kompatible Edition bietet auch ein einfach zu benutzendes logisches, regionenübergreifendes Reproduktionsfeature, das bis zu fünf sekundäre AWS-Regionen unterstützt. Sie basiert auf einer Einzel-Thread-MySQL-binlog-Replizierung; die Verzögerung bei der Replizierung wird durch die Änderungs-/Anwendungsrate und Verzögerungen bei der Netzwerkkommunikation zwischen den spezifischen ausgewählten Regionen beeinflusst.

Ja, Sie können bis zu 15 Aurora-Replikate zu jedem regionenübergreifenden Cluster hinzufügen, und sie teilen sich den gleichen zugrundeliegenden Speicherplatz wie das regionenübergreifende Replikat. Das regionsübergreifende Replikat fungiert als primäres im Cluster; die Aurora Replikate im Cluster liegen normalerweise mit einer Verzögerung im Zehntel-Millisekundenbereich hinter dem primären.

Ja, Sie können Ihr regionsübergreifendes Replikat über die Amazon-RDS-Konsole zum neuen primären machen. Für die logische (Binlog-)Replikation dauert der Promotion-Prozess in der Regel einige Minuten, abhängig von Ihrem Arbeitsaufkommen. Die regionsübergreifende Replizierung wird beendet, sobald Sie diesen Prozess starten.

Mit Amazon Aurora Global Database können Sie eine sekundäre Region hochstufen, um vollständige Lese-/Schreib-Workloads in weniger als einer Minute aufzunehmen.

Ja. Sie können jeder Instance auf dem Cluster ein Beförderungs-Prioritätskontingent zuweisen. Sollte die primäre Instance ausfallen, befördert Amazon RDS das Replikat mit der höchsten Priorität zur neuen primären Instance. Wenn zwei oder mehr Aurora-Replikate die gleiche Priorität aufweisen, befördert Amazon RDS das größte Replikat. Weisen zwei oder mehr Aurora-Replikate die gleiche Priorität und Größe auf, befördert Amazon RDS ein beliebiges Replikat in der gleichen Beförderungsstufe.

Weitere Informationen zur Failover-Logik finden Sie im Amazon-Aurora-Benutzerhandbuch.

Ja, Sie können das Prioritätskontingent für eine Instance jederzeit bearbeiten. Das Bearbeiten eines Prioritätskontingent löst keinen Failover aus.

Sie können den Replikate, die Sie nicht zur primären Instance befördern möchten, niedrigere Prioritätskontingente zuweisen. Wenn jedoch die Replikate auf dem Cluster mit höherer Priorität beschädigt oder aus irgendeinem Grund nicht verfügbar sind, befördert Amazon RDS die Replikat mit der niedrigeren Priorität.

Sie können Amazon-Aurora-Replikate hinzufügen. Aurora-Replikate in der gleichen AWS-Region teilen sich den gleichen zugrunde liegenden Speicherplatz wie die primäre Instance. Jedes Aurora-Replikat kann ohne Datenverlust als primär hochgestuft werden. Damit kann man sie bei einem Ausfall der primären DB-Instance zur Verbesserung der Fehlertoleranz verwendet werden.

Zur Verbesserung der Datenbankverfügbarkeit können Sie einfach 1 bis 15 Replikate in einer der 3 AZs erstellen. Amazon RDS fügt diese automatisch zur Auswahl für einen Failover der primären Instance bei einem Datenbankausfall hinzu. Sie können die Amazon Aurora Global Database verwenden, wenn Sie möchten, dass Ihre Datenbank mehrere AWS-Regionen umfasst. Dadurch werden Ihre Daten repliziert, ohne die Datenbankleistung zu beeinträchtigen, und die Disaster Recovery nach regionalen Ausfällen wird ermöglicht.

Der Failover wird von Amazon Aurora automatisch durchgeführt, sodass Ihre Anwendungen den Datenbankbetrieb schnellstmöglich und ohne Verwaltungsaufwand wieder aufnehmen können.

• Wenn Sie ein Aurora-Replikat in derselben oder einer anderen AZ haben, wechselt Amazon Aurora den anerkannten Namensdatensatz (CNAME) für Ihre DB-Instance, sodass auf das fehlerfreie Replikat verwiesen wird, das zur neuen primären Instance hochgestuft wird. Das gesamte Failover ist in der Regel innerhalb von 30 Sekunden abgeschlossen. Für eine verbesserte Stabilität und schnellere Failover sollten Sie Amazon RDS Proxy verwenden, der automatisch eine Verbindung zur Failover-DB-Instance herstellt und gleichzeitig die Anwendungsverbindungen beibehält. Proxy macht Failover für Ihre Anwendungen transparent und reduziert die Failover-Zeiten um bis zu 66 %
• Wenn Sie Aurora Serverless Version 1 ausführen und die DB-Instance oder AZ nicht mehr verfügbar sind, erstellt Aurora die DB-Instance automatisch in einer anderen AZ. Aurora Serverless v2 funktioniert wie bereitgestellt für den Failover und sonstige hochverfügbare Features. Weitere Informationen finden Sie unter Aurora Serverless v2 und hohe Verfügbarkeit. 
• Verfügen Sie über keine Aurora-Replikate (d. h. über eine einzelne Instance), versucht Aurora Serverless zuerst, eine DB-Instance in der Availability Zone der ursprünglichen Instance zu erstellen. Dieser Austausch der ursprünglichen Instance wird nach bestem Bemühen durchgeführt, ist aber nicht immer erfolgreich, z. B. wenn ein Problem vorliegt, das sich allgemein auf die Availability Zone auswirkt.
  

Bei Verbindungsunterbrechung muss Ihre Anwendung versuchen, die Verbindung zur Datenbank wiederherzustellen. Disaster Recovery über Regionen hinweg ist ein manueller Prozess, bei dem Sie eine sekundäre Region fördern, um Workloads zum Lesen/Schreiben aufzunehmen.

Amazon Aurora erkennt automatisch, dass ein Problem mit Ihrer primären Instance vorliegt, und löst ein Failover aus. Wenn Sie den Cluster-Endpunkt verwenden, werden Ihre Lese-/Schreibverbindungen automatisch an ein Amazon-Aurora-Replikat weitergeleitet, das zur primären Instance hochgestuft wird.

Außerdem wird der Lesedatenverkehr Ihrer Amazon-Aurora-Replikate kurz unterbrochen. Wenn Sie den Cluster-Leser-Endpunkt verwenden, um Ihren Lesedatenverkehr an das Aurora-Replikat zu leiten, werden die schreibgeschützten Verbindungen an das neu hochgestufte Aurora-Replikat weitergeleitet, bis der alte primäre Knoten wieder als Replikat hergestellt wurde.

Da Amazon-Aurora-Replikate dasselbe Daten-Volume verwenden wie die primäre Instance in derselben AWS-Region, gibt es praktisch keine Verzögerung bei der Replizierung. Wir beobachten normalerweise Verzögerungen im Zehntel-Millisekundenbereich.

Bei der regionsübergreifenden Replikation kann die Binlog-basierte logische Replikationsverzögerung basierend auf der Änderungs-/Anwendungsrate sowie Verzögerungen bei der Netzwerkkommunikation unbegrenzt anwachsen. Unter normalen Umständen liegt die Verzögerung bei der Replizierung üblicherweise jedoch unter einer Minute. Regionsübergreifende Replikate, die physische Replikation der Amazon Aurora Global Database verwenden, haben eine typische Verzögerung von weniger als einer Sekunde.

Ja, Sie können binlog-Replikation zwischen einer Aurora-MySQL-kompatible Version-Instance und einer externen MySQL-Datenbank aufsetzen. Die andere Datenbank kann auf Amazon RDS, als selbst-verwaltete Datenbank auf AWS oder komplett außerhalb von AWS ausgeführt werden.

Wenn Sie Aurora-MySQL-kompatible Edition 5.7 verwenden, sollten Sie erwägen, eine GTID-basierte binlog-Replikation aufzusetzen. Dadurch erhalten Sie vollständige Einheitlichkeit, sodass Ihre Replikation keine Transaktionen verpasst oder Konflikte erstellen lässt, selbst nach einem Failover oder Downtime.

Amazon Aurora Global Database ist ein Feature, das es einer einzelnen Amazon-Aurora-Datenbank ermöglicht, mehrere AWS-Regionen abzudecken. Es repliziert Ihre Daten ohne Auswirkungen auf die Datenbankleistung, ermöglicht schnelle lokale Lesezugriffe in jeder Region mit einer typischen Latenzzeit von weniger als einer Sekunde und bietet Disaster Recovery nach regionalem Ausfall. Im unwahrscheinlichen Fall einer regionalen Verschlechterung oder eines Ausfalls kann eine sekundäre Region in weniger als einer Minute in die volle Lese-/Schreibfähigkeit versetzt werden. Dieses Feature steht sowohl für Aurora-MySQL-kompatible Edition als auch für Aurora-PostgreSQL-kompatible Edition zur Verfügung.

Sie können eine Aurora Global Database mit nur wenigen Klicks in der Amazon-RDS-Managementkonsole erstellen. Alternativ können Sie auch das AWS Software Development Kit (SDK) oder das AWS Command-Line Interface (CLI) nutzen. Sie müssen mindestens eine Instance pro Region in Ihrer Amazon Aurora Global Database bereitstellen.

Sie können bis zu fünf sekundäre Regionen für eine Amazon Aurora Global Database erstellen.

Ja. Wenn Ihr Ziel die Analyse der Datenbankaktivität ist, sollten Sie stattdessen Aurora Advanced Auditing, allgemeine Protokolle und langsame Abfrageprotokolle verwenden, um die Leistung Ihrer Datenbank nicht zu beeinträchtigen.

Nein. Wenn Ihre primäre Region nicht mehr verfügbar ist, können Sie eine sekundäre Region manuell aus einer Amazon Aurora Global Database entfernen und sie so hochstufen, dass sie vollständig gelesen und geschrieben wird. Außerdem müssen Sie Ihre Bewerbung auf die neu beworbene Region richten.

Optimierte Lesevorgänge für Amazon Aurora (verfügbar für Aurora PostgreSQL) ist eine neue Preis-Leistungs-Option, die eine bis zu 8-fache Verbesserung der Abfragelatenz und eine Kostenersparnis von bis zu 30 % im Vergleich zu Instances ohne diese Funktion ermöglicht. Sie ist ideal für Anwendungen mit großen Datenmengen, die die Speicherkapazität einer Datenbank-Instance überschreiten.

Optimized-Reads-Instances von Amazon Aurora verwenden lokale NVMe-basierte SSD-Blockspeicher, die auf Graviton-basierten r6gd- und Intel-basierten r6id-Instances verfügbar sind, um die Abfragelatenz von Anwendungen mit Datensätzen zu verbessern, die die Speicherkapazität einer Instance überschreiten. Optimierte Lesevorgänge umfassen Leistungsverbesserungen wie mehrstufiges Caching und temporäre Objekte.

Mehrstufiges Caching bietet eine bis zu achtmal verbesserte Abfragelatenz und Kosteneinsparungen von bis zu 30 % für leseintensive, E/A-intensive Anwendungen wie operative Dashboards, Anomalieerkennung und vektorbasierte Ähnlichkeitssuchen. Diese Vorteile werden durch die automatische Zwischenspeicherung von Daten, die aus dem Puffercache der In-Memory-Datenbank in den lokalen Speicher verdrängt werden, erzielt, um nachfolgende Zugriffe auf diese Daten zu beschleunigen. Mehrstufiges Caching ist nur für die Amazon-Aurora-PostgreSQL-Edition mit der E/A-optimierten Aurora Konfiguration verfügbar.

Temporäre Objekte ermöglichen eine schnellere Abfrageverarbeitung, indem temporäre Tabellen (die von Aurora PostgreSQL erstellt wurden) im lokalen Speicher platziert werden. Dadurch wird die Leistung von Abfragen verbessert, die Sortierungen, Hash-Aggregationen, Verbindungen mit hoher Last und andere datenintensive Operationen beinhalten.

Amazon Aurora Optimized Reads für Aurora PostgreSQL bietet Kunden mit latenzempfindlichen Anwendungen und großen Arbeitssätzen eine überzeugende Preis-Leistungs-Alternative, um ihre geschäftlichen SLAs zu erfüllen und noch mehr mit ihren Instances anfangen zu können.

Amazon Aurora Optimized Reads sind auf Intel-basierten R6id- und Graviton-basierten R6gd-Instances verfügbar. Die regionale Verfügbarkeit für Aurora können Sie hier einsehen.

Amazon Aurora Optimized Reads ist für die PostgreSQL-kompatible Edition von Aurora in R6id- und R6gd-Instances verfügbar. Unterstützte Engine-Versionen sind 15.4 und höher sowie 14.9 und höher auf Aurora PostgreSQL.

Amazon Aurora Optimized Reads ist in Aurora Serverless v2 (ASv2) nicht verfügbar.

Ja, Amazon Aurora Optimized Reads ist in beiden Konfigurationen verfügbar. Bei beiden Konfigurationen ordnen die Instances, die optimierte Lesevorgänge aktivieren, temporäre Tabellen automatisch dem NVMe-basierten lokalen Speicher zu, um die Leistung von analytischen Abfragen und Index-Neuaufbauten zu verbessern.

Für E/A-intensive Workloads, die einen hohen Anteil an Lesevorgängen aufweisen, können Optimized-Reads-fähige Instances auf Aurora PostgreSQL, die so konfiguriert sind, dass sie Aurora I/O-Optimized verwenden, automatisch Daten, die aus dem Speicher verdrängt wurden, auf NVMe-basiertem lokalem Speicher zwischenspeichern, um eine bis zu 8-fach verbesserte Abfragelatenz und eine Kostenersparnis von bis zu 30 % im Vergleich zu Instances ohne diese Funktion zu erzielen – für Anwendungen mit großen Datensätzen, die die Speicherkapazität einer Datenbank-Instance übersteigen.

Kunden können mit Amazon Aurora Optimized Reads über die AWS-Managementkonsole, die CLI und das SDK loslegen. Optimized Reads ist standardmäßig auf allen R6id- und R6gd-Instances verfügbar. Um diese Funktion zu nutzen, können Kunden einfach ihre bestehenden Aurora-Datenbank-Cluster so modifizieren, dass sie R6id- und R6gd-Instances enthalten, oder neue Datenbank-Cluster mit diesen Instances erstellen. Lesen Sie die Dokumentation zu Amazon Aurora Optimized Reads, um loszulegen.

Ungefähr 90 % des verfügbaren lokalen Speichers auf den R6id- und R6gd-Instances stehen für optimierte Lesevorgänge zur Verfügung. Aurora reserviert 10 % des NVMe-Speichers, um die Auswirkungen der SSD-Schreibverstärkung zu reduzieren. Die Zuweisung des verfügbaren Speichers hängt davon ab, welche optimierte Lesevorgangs-Funktionen aktiviert sind.

Wenn Sie Optimized Reads mit den Funktionen Temporäre Objekte und Mehrstufiges Caching verwenden, entspricht der für temporäre Objekte verfügbare Speicherplatz im lokalen Speicher der doppelten Größe des auf diesen Instances verfügbaren Speichers. Dies entspricht der aktuellen Größe des temporären Objektspeichers in Aurora PostgreSQL. Der verbleibende lokale Speicherplatz steht für das Zwischenspeichern von Daten zur Verfügung.

Wenn optimierte Lesevorgänge nur mit der Feature Temporäre Objekte verwendet wird, steht der gesamte verfügbare lokale Speicherplatz für temporäre Objekte zur Verfügung. Wenn Sie beispielsweise eine r6gd.8xlarge-Instance mit den Funktionen Temporäre Objekte und mehrstufiges Caching verwenden, sind 534 GiB (2x Speicherkapazität) für temporäre Objekte und 1054 GiB für mehrstufigen Cache reserviert.

Wenn der lokale Speicher ausfällt, führt Aurora automatisch einen Host-Austausch durch. In einem Datenbank-Cluster mit mehreren Knoten löst dies ein regionsinternes Failover aus.

Bei einem Failover der Datenbank wird die Abfragelatenz nach dem Failover vorübergehend zunehmen. Dieser Anstieg der Latenzzeit wird sich im Laufe der Zeit verringern und schließlich die Abfragelatenz vor dem Failover wieder erreichen. Diese Aufholdauer kann beschleunigt werden, indem das Cluster-Cache-Management (CCM) aktiviert wird. Mit CCM können Kunden eine bestimmte Aurora-PostgreSQL-Datenbank-Instance als Failover-Ziel bestimmen.

Wenn CCM aktiviert ist, spiegelt der lokale Speichercache des designierten Failover-Ziels den lokalen Speichercache der primären Instance genau wider, wodurch die Aufholzeit nach dem Failover reduziert wird. Die Aktivierung von CCM könnte sich jedoch auf die langfristige Effizienz des lokalen Speichercaches auswirken, wenn das designierte Failover-Ziel auch zur Bereitstellung eines Lese-Workloads verwendet wird, der von dem Workload auf der Writer-Instance getrennt ist.

Daher müssen Kunden, die Workloads ausführen, bei denen ein Reader als Standby-Failover bestimmt werden muss, CCM aktivieren, um die Wahrscheinlichkeit zu erhöhen, dass sie ihre Abfragelatenz nach dem Failover schnell wiederherstellen können. Kunden, die getrennte Workloads auf ihren designierten Failover-Zielen ausführen, sollten vor der Aktivierung von CCM ihre Anforderungen an die sofortige Wiederherstellung der Latenz nach dem Failover mit der langfristigen Effektivität der Cache-Leistung abwägen.

Sie sollten die Null-ETL-Integration von Amazon Aurora in Amazon Redshift verwenden, wenn Sie nahezu in Echtzeit Zugriff auf Transaktionsdaten benötigen. Diese Integration ermöglicht es Ihnen, Amazon Redshift ML mit einfachen SQL-Befehlen zu nutzen.

Die Null-ETL-Integration von Amazon Aurora in Amazon Redshift ist in der Aurora MySQL-Compatible Edition für Aurora MySQL 3.05 Version (kompatibel mit MySQL 8.0.32) und höher in den Regionen USA Ost (Ohio), USA Ost (Nord-Virginia), USA West (Oregon), Asien-Pazifik (Singapur), Asien-Pazifik (Sydney), Asien-Pazifik (Tokio), Europa (Frankfurt), Europa (Irland) und Europa (Stockholm) verfügbar. Die Null-ETL-Integration von Amazon Aurora in Amazon Redshift ist in der Aurora PostgreSQL-kompatiblen Edition für Aurora PostgreSQL 15.4 in der Region USA Ost (Ohio) verfügbar.

Durch die Null-ETL-Integration von Amazon Aurora in Amazon Redshift müssen Sie keine komplexen Datenpipelines mehr erstellen und verwalten. Sie können Daten aus einem oder mehreren Aurora-Datenbankclustern in einem einzigen Amazon Redshift-Datenbank-Cluster konsolidieren und mithilfe von Amazon Redshift nahezu in Echtzeit Analysen und ML für Petabyte an Transaktionsdaten von Aurora ausführen. 

Die Null-ETL-Integration von Aurora in Amazon Redshift ist mit Aurora Serverless v2 kompatibel. Wenn Sie sowohl Aurora Serverless v2 als auch Amazon Redshift Serverless verwenden, können Sie Analysen zu Transaktionsdaten nahezu in Echtzeit erstellen, ohne die Infrastruktur für Datenpipelines verwalten zu müssen.

Sie können beginnen, indem Sie die Amazon-RDS-Konsole verwenden, um die Null-ETL-Integration zu erstellen, indem Sie die Aurora-Quelle und das Amazon Redshift-Ziel angeben. Sobald die Integration erstellt wurde, wird die Aurora-Datenbank auf Amazon Redshift repliziert, und Sie können mit der Abfrage der Daten beginnen, sobald das erste Seeding abgeschlossen ist. Weitere Informationen finden Sie im Handbuch Erste Schritte für Null-ETL-Integrationen von Aurora in Amazon Redshift.

Null-ETL und die fortlaufende Verarbeitung von Datenänderungen werden ohne zusätzliche Kosten angeboten. Sie zahlen für vorhandene Amazon-RDS- und Amazon-Redshift-Ressourcen, die zur Erstellung und Verarbeitung der im Rahmen einer Null-ETL-Integration generierten Änderungsdaten verwendet werden. Zu diesen Ressourcen könnten gehören:

• Zusätzliche E/A und Speicher, die durch die Aktivierung von Enhanced Binlog verwendet werden
• Snapshot-Exportkosten für den ersten Datenexport zum Seed Ihrer Amazon-Redshift-Datenbanken
• Zusätzlicher Amazon-Redshift-Speicher zum Speichern replizierter Daten
• AZ-übergreifende Datenübertragungskosten für die Übertragung von Daten von der Quelle zum Ziel

Weitere Informationen finden Sie auf der Seite mit der Preisübersicht für Aurora.

Amazon DevOps Guru für RDS ist eine neue, auf ML basierende Funktion für Amazon RDS, (einschließlich Amazon Aurora) die automatisch Leistungs- und Betriebsprobleme von Datenbanken erkennt und diagnostiziert und es Ihnen ermöglicht, Herausforderungen innerhalb von Minuten statt Tagen zu bewältigen.

Amazon DevOps Guru für RDS ist ein Feature von Amazon DevOps Guru, das betriebliche- und Leistungsherausforderungen für alle Amazon-RDS-Engines und Dutzende anderer Ressourcentypen erkennt. DevOps Guru für RDS erweitert die Fähigkeiten von DevOps Guru, um eine Vielzahl von datenbankbezogenen Herausforderungen in Amazon RDS zu erkennen, zu diagnostizieren und zu beheben, wie z. B. Überbeanspruchung von Ressourcen und Fehlverhalten von SQL-Abfragen.

Wenn ein Problem auftritt, ist Amazon DevOps Guru für RDS darauf ausgelegt, Entwickler und DevOps-Techniker sofort zu benachrichtigen und Diagnoseinformationen bereitzustellen. Es bietet den Kunden außerdem Details zum Ausmaß des Problems und intelligente Empfehlungen zur Behebung datenbankbezogener Leistungs-Bottleneck- und operativer Probleme.

Amazon DevOps Guru für RDS ist darauf ausgelegt, den manuellen Aufwand zu verringern und die Zeit (von Stunden und Tagen auf Minuten) zu verkürzen, um schwer zu findende Leistungsengpässe in Ihrem relationalen Datenbank-Workload zu erkennen und zu beheben.

Sie können DevOps Guru für RDS für jede Amazon Aurora Datenbank aktivieren und es wird Leistungsherausforderungen für Ihre Workloads automatisch erkennen, Ihnen eine Alarmmeldung zu jedem Vorfall schicken, die Ergebnisse erläutern und Aktionen zur Behebung der Herausforderungen empfehlen.
DevOps Guru für RDS macht die Datenbank-Verwaltung zugänglicher für Nicht-Experten und unterstützt Datenbank-Experten, so dass sie sogar noch mehr Datenbanken verwalten können.

Amazon DevOps Guru für RDS nutzt ML, um telemetische Daten zu analysieren, die mit Amazon RDS Performance Insights (PI) gesammelt wurden. DevOps Guru für RDS nutzt jedoch für seine Analyse keinerlei Daten, die in Ihrer Datenbank gespeichert sind. PI misst die Auslastung der Datenbank, bietet eine Metrik, die von Anwendungen in der Datenbank genutzte Zeit darstellt sowie ausgewählte Metriken, die von der Datenbank erstellt werden, wie zum Beispiel Serverstatus-Variablen in MySQL- pg_stat-Tabellen in PostgreSQL.

Stellen Sie mit der RDS-Konsole sicher, dass Performance Insights aktiviert ist und aktivieren Sie dann einfach DevOps Guru für Ihre Amazon-Aurora-Datenbanken, um mit der Nutzung von DevOps Guru für RDS zu beginnen. Mit DevOps Guru können Sie Ihr gesamtes AWS-Konto als Analyseziel auswählen, spezifischeAWS CloudFormation-Stacks hierfür definieren oder AWS-Tags nutzen, um eine Ressourcengruppe zu erstellen, die DevOps Guru analysieren soll.

Amazon DevOps Guru für RDS unterstützt Sie bei der Identifizierung einer breiten Spanne von Performance-Problemen, die Anwendungs-Servicequalität beinträchtigen könnten wie zum Beispiel Pile-Ups, Connection Storms, SQL-Regressionen, CPU- und I/O-Konflikte und Speicherprobleme.

Amazon RDS Performance Insights ist ein Feature zum Einstellen und Überwachen der Datenbankleistung, das Amazon-RDS-Datenbankleistungs-Metriken gesammelt und visualisiert. So können Sie die Auslastung Ihrer Datenbank schnell beurteilen und ermitteln, wann und wo Sie eingreifen müssen. Amazon DevOps Guru für RDS ist darauf ausgelegt, diese Metriken zu überwachen und festzustellen, wenn Ihre Datenbank Leistungsprobleme hat. Metriken werden analysiert, um Ihnen die Probleme und mögliche Lösungen darzulegen.

Sie sollten die Daten-API für neue moderne Anwendungen verwenden, insbesondere für solche, die mit AWS Lambda erstellt wurden und in einem Anforderungs-/Antwortmodell auf Aurora zugreifen müssen. Sie sollten Datenbanktreiber anstelle der Daten-API verwenden und persistente Datenbankverbindungen verwalten, wenn eine vorhandene Anwendung stark mit Datenbanktreibern gekoppelt ist, wenn es langlaufende Abfragen gibt oder wenn der Entwickler die Vorteile von Datenbankfunktionen wie temporären Tabellen nutzen oder Sitzungsvariablen nutzen möchte.

Die Verfügbarkeit der Daten-API, der AWS-Region und der Datenbankversion für Aurora Serverless v2 und von Aurora bereitgestellte Instances finden Sie in unserer Dokumentation. Kunden, die derzeit die Daten-API für Aurora Serverless v1 verwenden, wird empfohlen, auf Aurora Serverless v2 zu migrieren, um die Vorteile der neu gestalteten Daten-API und der differenzierten Skalierung von Aurora Serverless v2 zu nutzen.

Die Daten-API ermöglicht es Ihnen, die moderne Anwendungsentwicklung zu vereinfachen und zu beschleunigen. Die Daten-API ist eine benutzerfreundliche, sichere HTTP-basierte API, die die Bereitstellung von Datenbanktreibern, die Verwaltung clientseitiger Verbindungspools oder die Einrichtung komplexer VPC-Netzwerke zwischen der Anwendung und der Datenbank überflüssig macht. Die Daten-API verbessert außerdem die Skalierbarkeit durch das automatische Pooling und gemeinsame Nutzung von Datenbankverbindungen, was den Rechenaufwand von Anwendungen reduziert, die häufig Verbindungen öffnen und schließen. 

Die vorhandene Daten-API für Aurora Serverless v1 bleibt ein Feature von Aurora Serverless v1 sowohl für die PostgreSQL-kompatible Edition als auch für die MySQL-kompatible Edition von Aurora. Die Daten-API für Aurora Serverless v2 und von Aurora bereitgestellte Instances unterstützt Aurora Serverless v1 nicht. Die Daten-API für Aurora Serverless v2 und von Aurora bereitgestellte Instances unterstützen Schreib-Instances von Aurora Global Database.

Benutzer können Daten-API-Abläuffe nur aufrufen, wenn sie dazu berechtigt sind. Administratoren können einem Benutzer die Berechtigung zur Nutzung der Daten-API gewähren, indem sie eine Richtlinie von AWS Identity and Access Management (IAM) beifügen, die ihre Berechtigungen definiert. Sie können die Richtlinie auch an eine Rolle beifügen, wenn Sie IAM-Rollen verwenden. Wenn Sie die Daten-API aufrufen, können Sie Anmeldeinformationen für den Aurora-DB-Cluster mithilfe eines Geheimnisses in AWS Secrets Manager übergeben. 

Die Nutzung der Daten-API mit Aurora Serverless v1 ist weiterhin ohne zusätzliche Kosten verfügbar. Die Preise für die Daten-API für Aurora Serverless v2 und von Aurora bereitgestellte Instances werden nach dem API-Anforderungsvolumen berechnet, wie auf der Aurora-Preisseite beschrieben. Die Daten-API für Aurora Serveless v2 und von Aurora bereitgestellte Instances verwendet AWS-CloudTrail-Datenebenenereignisse zum Protokollieren von Aktivitäten anstelle von Verwaltungsereignissen, wie dies bei der Daten-API für Aurora Serverless v1 der Fall war.

Wenn Sie diese Aktivität verfolgen möchten, können Sie die Protokollierung von Datenereignissen über die CloudTrail-Konsole, die CLI oder das SDK aktivieren. Dafür fallen Gebühren an, wie auf der CloudTrail-Preisseite angegeben. Außerdem fallen für die Nutzung von AWS Secrets Manager Gebühren an, die auf der Preisseite von AWS Secrets Manager aufgeführt werden. 

AWS CloudTrail erfasst AWS-API-Aktivitäten als Verwaltungsereignisse oder Datenereignisse. CloudTrail-Verwaltungsereignisse (auch bekannt als „Abläufe der Steuerebene“) zeigen Verwaltungsvorgänge an, die für Ressourcen in Ihrem AWS-Konto ausgeführt werden, z. B. das Erstellen, Aktualisieren und Löschen einer Ressource. CloudTrail-Datenereignisse (auch bekannt als „Datenebenenabläufe“) zeigen die Ressourcenvorgänge an, die auf oder innerhalb einer Ressource in Ihrem AWS-Konto ausgeführt werden.

Die Daten-API führt Abläufe auf Datenebene durch, da sie Abfragen für Daten in Ihrer Aurora-Datenbank durchführt. Daher werden die Daten-API-Aktivitäten als Datenereignisse protokolliert, da dies die korrekte Kategorisierung der Ereignisse ist. Gebühren fallen nur für CloudTrail-Datenereignisse an, wenn Sie die Protokollierung von Datenereignissen aktivieren.

Ja. Das kostenlose Kontingent für die Daten-API umfasst eine Million Anfragen pro Monat, aggregiert für alle AWS-Regionen, für die Nutzung im ersten Jahr. Nach einem Jahr müssen Kunden für die Daten-API bezahlen, wie auf der Aurora-Preisseite beschrieben.

Blau/Grün-Bereitstellungen von Amazon RDS sind in den Amazon-Aurora-MySQL-kompatiblen Edition-Versionen 5.6 und höher sowie in den Amazon-Aurora-PostgreSQL-kompatiblen Edition-Versionen 11.21 und höher, 12.16 und höher, 13.12 und höher, 14.9 und höher sowie 15.4 und höher verfügbar. Erfahren Sie mehr über verfügbare Versionen in der Dokumentation für Aurora.

Blau/Grün-Bereitstellungen von Amazon RDS sind in allen AWS-Regionen und in den AWS-GovCloud-Regionen verfügbar.

Mit Blau/Grün-Bereitstellungen von Amazon RDS können Sie Datenbankänderungen sicherer, einfacher und schneller durchführen. Blau/Grün-Bereitstellungen eignen sich ideal für Anwendungsfälle wie Haupt- oder Nebenversions-Upgrades der Datenbank-Engine, Betriebssystemaktualisierungen, Schemaänderungen in Grün-Umgebungen, die die logische Replikation nicht unterbrechen, wie das Hinzufügen einer neuen Spalte am Ende einer Tabelle oder Änderungen der Datenbankparametereinstellungen.

Sie können Blau/Grün-Bereitstellungen verwenden, um mit einer einzigen Umstellung mehrere Datenbankaktualisierungen gleichzeitig vorzunehmen. Auf diese Weise können Sie über Sicherheitspatches auf dem Laufenden bleiben, die Datenbankleistung verbessern und mit kurzen, vorhersehbaren Ausfallzeiten auf neuere Datenbankfeatures zugreifen. Wenn Sie nur ein Nebenversions-Upgrade auf Aurora durchführen möchten, empfehlen wir Ihnen, Aurora Zero Downtime Patching (ZDP) zu verwenden.

Ihnen wird der gleiche Preis für die Ausführung Ihres Workloads bei Grün-Instances wie bei Blau-Instances berechnet. Die Kosten für den Betrieb auf blauen und grünen Instances beinhalten unsere aktuellen Standardpreise für db.instances, Kosten für Speicher, Kosten für Lese-/Schreib-E/As und alle aktivierten Funktionen, wie z. B. Kosten für Backups und Amazon RDS Performance Insights. Effektiv zahlen Sie ca. doppelt so viel für die Ausführung von Workloads auf der DB-Instance für die Lebensdauer der Blau/Grün-Bereitstellung.

Zum Beispiel: Sie haben einen Cluster von Aurora MySQL-Compatible Edition 5.7, der auf zwei r5.2xlarge-db.instances, einer primären Writer-Instance und einer Reader-Instance in der AWS-Region us-east-1 läuft. Jede der r5.2xlarge-DB-Instances ist für 40 GiB Speicherplatz konfiguriert und hat 25 Millionen E/A pro Monat. Sie erstellen einen Klon der blauen Instance-Topologie mit Blau/Grün-Bereitstellungen von Amazon RDS, lassen ihn 15 Tage lang (360 Stunden) laufen und jede grüne Instance hat während dieser Zeit 3 Millionen E/A-Lesevorgänge. Die blauen Instances löschen Sie dann nach erfolgreicher Umstellung. Die Blau-Instances (Writer und Reader) kosten 849,20 USD für 15 Tage bei der On-Demand-Rate von 1 179 USD/Std. (Instance + Speicher + E/A). Die Grün-Instances (Writer und Reader) kosten 840,40 USD für 15 Tage bei der On-Demand-Rate von 1 167 USD/Std. (Instance + Speicher + E/A). Die Gesamtkosten für die Nutzung von Blau/Grün-Bereitstellungen für diese 15 Tage betragen 1 689,60 USD. Das ist doppelt so teuer wie die Ausführung von Blau-Instances für diesen Zeitraum.

Blau/Grün-Bereitstellungen von Amazon RDS helfen Ihnen dabei, Datenbank-Änderungen sicherer, einfacher und schneller vorzuehmen, wie Upgrades an Haupt- und Nebenversionen, Schema-Änderungen, Instance-Skalierung, Änderungen an den Engine-Parametern und Wartungs-Updates.

Bei Blau/Grün-Bereitstellungen von Amazon RDS ist die Blau-Umgebung Ihre aktuelle Produktionsumgebung. Die Grün-Umgebung ist Ihre Staging-Umgebung, die nach dem Abschluss der Umstellung Ihre neue Produktionsumgebung wird.

Wenn Blau/Grün-Bereitstellungen von Amazon RDS eine Umstellung einleiten, blockieren sie Schreibvorgänge sowohl zur Blau-, als auch zur Grün-Umgebung, bis die Umstellung abgeschlossen ist. Während der Umstellung macht die Staging-Umgebung (oder Grün-Umgebung) Boden auf das Produktionssystem gut. Dadurch wird gewährleistet, dass Daten zwischen der Staging- und Produktionsumgebung beständig sind. Sobald die Produktions- und Staging-Umgebung komplett synchronisiert wurden, fördern die Blau/Grün-Bereitstellungen die Staging-Umgebung als die neue Produktionsumgebung, indem der Datenverkehr an die kürzlich hochgestufte Umgebung umgeleitet wird.

Blau/Grün-Bereitstellungen von Amazon RDS aktivieren Schreibvorgänge in der Grün-Umgebung nach Abschluss der Umschaltung. Dadurch wird gewährleistet, dass keine Daten während der Umschaltung verloren gehen.

Blau/Grün-Bereitstellungen von Amazon RDS löschen Ihre alte Produktionsumgebung nicht. Sie können bei Bedarf darauf für zusätzliche Validierungen und Tests von Leistung/Regression zugreifen. Wenn die alte Produktionsumgebung nicht mehr benötigt wird. können Sie sie löschen. Es fallen Standard-Fakturierungsgebühren bei alten Produktions-Instances an, bis Sie sie löschen.

Wenn Ihre blaue Umgebung ein selbstverwaltetes logisches Replikat oder ein Subscriber ist, blockieren wir die Umstellung. Es wird empfohlen, zuerst die Replikation in die blaue Umgebung zu beenden, mit der Umstellung fortzufahren und dann die Replikation fortzusetzen. Wenn Ihre blaue Umgebung dagegen eine Quelle für ein selbstverwaltetes logisches Replikat oder einen Publisher ist, können Sie mit der Umstellung fortfahren. Sie müssen jedoch das selbstverwaltete Replikat aktualisieren, um es nach der Umstellung aus der grünen Umgebung zu replizieren.

Nein. Blau/Grün-Bereitstellungen von Amazon RDS unterstützen Amazon Aurora Global Databases, Amazon-RDS-Proxy oder regionenübergreifende Lesereplikate nicht. 

Nein. Es ist zu diesem Zeitpunkt nicht möglich, Blau/Grün-Bereitstellungen von Amazon RDS zu verwenden, um Änderungen rückgängig zu machen.