Amazon RDS – Häufig gestellte Fragen

Man kann sich eine DB-Instance als eine Datenbank-Umgebung in der Cloud vorstellen, die über die vom Benutzer festgelegten Rechen- und Speicherressourcen verfügt. Mithilfe der AWS-Managementkonsole, der Amazon-RDS-APIs und der AWS-Befehlszeilenschnittstelle können Sie DB-Instances erstellen und löschen, Infrastrukturattribute der DB-Instance(s) definieren bzw. weiterentwickeln und Zugriff und Sicherheit steuern. Sie können eine oder mehrere DB-Instances ausführen. Jede DB-Instance kann je nach Engine-Typ ein(e) oder mehrere Datenbanken bzw. Datenbankschemas unterstützen.

DB-Instances sind einfach zu erstellen. Sie können hierfür entweder die AWS-Managementkonsole, Amazon RDS APIs oder die AWS-Befehlszeilenschnittstelle verwenden. Um eine DB-Instance über die AWS-Managementkonsole zu starten, klicken Sie auf „RDS“ und dann auf der Instances-Registerkarte auf „Launch DB Instance“. Hier können Sie die Parameter für Ihre DB-Instance festlegen, einschließlich der DB-Engine und -Version, des Lizenzmodells, Instance-Typs, Speichertyps und der Speichermenge sowie der Hauptbenutzer-Anmeldeinformationen.

Darüber hinaus haben Sie die Möglichkeit, die Backup-Aufbewahrungsrichtlinie, das bevorzugte Backup-Fenster und das Fenster für geplante Aktualisierungen für Ihre DB-Instance zu ändern. Alternativ können Sie Ihre DB-Instance auch mithilfe der API CreateDBInstance oder über den Befehl "create-db-instance" erstellen.

Sobald Ihre DB-Instance verfügbar ist, können Sie deren Endpunkt über die DB-Instance-Beschreibung in der AWS-Managementkonsole, in der DescribeDBInstances-API oder im describe-db-instances-Befehl abrufen. Mithilfe dieses Endpunkts können Sie die für eine direkte Verbindung zu Ihrer DB-Instance erforderliche Zeichenfolge erstellen und dabei Ihr bevorzugtes Datenbank-Tool bzw. Ihre bevorzugte Programmiersprache verwenden. Um für Ihre ausgeführte DB-Instance Netzwerkanfragen zu ermöglichen, müssen Sie den Zugriff autorisieren. Eine ausführliche Anleitung zur Erstellung der Verbindungszeichenfolge sowie Hinweise zu den ersten Schritten finden Sie im Handbuch Erste Schritte.

Standardmäßig können Kunden über bis zu 40 Amazon-RDS-DB-Instances verfügen. Von diesen 40 können bis zu 10 RDS-für-Oracle- oder RDS-für-SQL-Server-DB-Instances unter das Modell „Lizenz enthalten“ fallen. Alle 40 können für Amazon Aurora, RDS für PostgreSQL, RDS für MySQL, RDS für MariaDB und RDS für Oracle im Rahmen des Modells Bring Your Own Licence (BYOL) verwendet werden. Beachten Sie, dass RDS for SQL Server auf bis zu 100 Datenbanken pro DB-Instance beschränkt ist. Weitere Informationen finden Sie im Benutzerhandbuch von Amazon RDS für SQL Server.

• RDS für Amazon Aurora: Kein von der Software auferlegter Grenzwert
• RDS für MySQL: Kein von der Software auferlegter Grenzwert
• RDS für MariaDB: Kein von der Software auferlegter Grenzwert
• RDS for Oracle: 1 Datenbank pro Instance; kein von der Software auferlegter Grenzwert für die Anzahl der Schemas pro Datenbank
• RDS for SQL Server: Bis zu 100 Datenbanken pro Instance
• RDS für PostgreSQL: Kein von der Software auferlegter Grenzwert
• RDS für Db2: Bis zu 1 Datenbank pro Instance

Im Folgenden finden Sie eine Reihe von Möglichkeiten, Daten in Amazon RDS zu importieren:

• MySQL: Hilfsprogramme mysqldump oder mysqlimport
• Oracle: Data Pump, Import/Export oder SQL Loader
• SQL Server: Import-/Export-Assistent, vollständige Sicherungsdateien (.bak) oder Bulk Copy Program (BCP)
• PostgreSQL: pg_dump

Weitere Informationen zum Importieren und Exportieren von Daten finden Sie im Datenimporthandbuch für MySQL, Datenimporthandbuch für Oracle, Datenimporthandbuch für SQL Server oder Datenimporthandbuch für PostgreSQL oder Datenimporthandbuch für Db2.

Außerdem kann Ihnen der AWS Database Migration Service bei der einfachen und sicheren Migration von Datenbanken in AWS helfen.

Das Amazon-RDS-Wartungs- bzw. Aktualisierungsfenster bietet Ihnen die Möglichkeit, zu kontrollieren, wann Modifizierungen der DB-Instance, Upgrades der Datenbank-Engine-Version oder Software-Patches vorgenommen werden, wenn diese angefordert wurden oder notwendig sind. Wenn ein Wartungsereignis für eine bestimmte Woche geplant ist, wird es innerhalb des von Ihnen festgelegten Wartungs- bzw. Aktualisierungszeitfensters ausgelöst.

Wartungsarbeiten, bei denen Amazon RDS Ihre DB-Instance offline schalten muss, sind Skalierungen des Datenverarbeitungsbetriebs (die in der Regel nur wenige Minuten in Anspruch nehmen), Upgrades der Datenbank-Engine-Version sowie erforderliche Software-Patches. Erforderliche Software-Patches werden automatisch und nur für Patches, die relevant für die Sicherheit und Zuverlässigkeit sind, angesetzt. Diese Patches erfolgen in unregelmäßigen Abständen (in der Regel einmal alle paar Monate) und sollten selten mehr als einen Bruchteil Ihres Wartungs- bzw. Aktualisierungsfensters in Anspruch nehmen.

Falls Sie bei der Erstellung Ihrer DB-Instance kein bevorzugtes wöchentliches Wartungs- bzw. Aktualisierungsfenster festlegen, wird ein 30-minütiger Standardwert zugewiesen. Wenn Sie den Wartungszeitpunkt ändern möchten, können Sie dazu Ihre DB-Instance in der AWS-Managementkonsole, in der ModifyDBInstance-API oder im modify-db-instance-Befehl anpassen. Dabei haben Sie die Möglichkeit, für die einzelnen DB-Instances unterschiedliche bevorzugte Wartungsfenster anzugeben.

Wenn Sie Ihre DB-Instance als Multi-AZ-Bereitstellung ausführen, können Sie die Auswirkungen einer Wartung weiter verringern. Weitere Informationen zu Wartungsvorgängen finden Sie im Amazon RDS-Benutzerhandbuch.

Für Produktionsdatenbanken empfehlen wir die Aktivierung der Erweiterten Überwachung, die Zugriff auf über 50 CPU-, Speicher-, Dateisystem- und Festplatten-E/A-Metriken bereitstellt. Sie können diese Funktionen für jede Instance einzeln aktivieren und die Granularität (Minimalwert 1 Sekunde) auswählen. Eine erhöhte CPU-Auslastung kann die Abfrageleistung verringern. In diesem Fall könnte sich eine Skalierung Ihrer DB-Instance-Klasse anbieten. Weitere Informationen zur Überwachung der DB-Instance finden Sie im Amazon-RDS-Benutzerhandbuch.

Falls Sie RDS for MySQL oder MariaDB verwenden, können Sie auf die langsamen Abfrageprotokolle für die Datenbank zugreifen, um zu ermitteln, ob langsame SQL-Abfragen vorhanden sind und, falls dies der Fall ist, die Leistungsmerkmale der einzelnen Abfragen feststellen. Sie können den DB-Parameter "slow_query_log" bestimmen und die Tabelle "mysql.slow_log" abfragen, um die langsamen SQL-Abfragen zu überprüfen. Weitere Informationen finden Sie im Amazon-RDS-Benutzerhandbuch.

Falls Sie RDS for Oracle verwenden, können Sie die Oracle-Ablaufdateidaten verwenden, um langsame Abfragen zu identifizieren. Weitere Informationen zum Zugriff auf Nachverfolgungs-Dateidaten finden Sie im Amazon-RDS-Benutzerhandbuch. 

Falls Sie RDS for SQL Server verwenden, können Sie die Client-seitigen SQL Server-Ablaufverfolgungsprotokolle nutzen, um langsame Abfragen zu identifizieren. Weitere Informationen zum Zugriff auf die Daten in der Nachverfolgungs-Datei auf Serverseite finden Sie im Amazon-RDS-Benutzerhandbuch.

In der Dokumentation der einzelnen Engines finden Sie eine Liste der unterstützten Datenbank-Engine-Versionen:

• Amazon Aurora
• Amazon RDS for PostgreSQL
• Amazon RDS für MySQL
• Amazon RDS for MariaDB
• Amazon RDS für SQL Server
• Amazon RDS für Oracle
• Amazon RDS für Db2

Detaillierte Informationen zur Versionsnummerierung finden Sie auf der Seite für häufig gestellte Fragen der jeweiligen Amazon RDS-Datenbank-Engine:

• Amazon RDS für MySQL
• Amazon RDS for MariaDB
• Amazon RDS for PostgreSQL
• Amazon RDS for Oracle
• Amazon RDS for SQL Server
• Amazon Aurora
• Amazon RDS für Db2

Amazon RDS unterstützt mit der Zeit auch neue Haupt- und Nebenversionen von Datenbank-Engines. Die Anzahl der unterstützten neuen Versionen hängt von der Häufigkeit und den Inhalten der veröffentlichten Updates und Patches des Herstellers bzw. der Entwicklerorganisation der Engine ab, und selbstverständlich wird jede neue Version eingehend von unseren Datenbanktechnikern geprüft, bevor eine Unterstützung erfolgt. Als allgemeine Leitlinie können wir aber sagen, dass wir versuchen, neue Engine-Versionen innerhalb von 5 Monaten nach ihrer allgemeinen Verfügbarkeit zu unterstützen.

Sie können alle aktuell unterstützten (Haupt- oder Neben-)Versionen festlegen, wenn Sie eine neue DB-Instance über den Vorgang Launch DB Instance in der AWS-Managementkonsole oder der CreateDBInstance-API erstellen. Dabei ist zu beachten, dass nicht jede Version einer Datenbank-Engine in jeder AWS-Region verfügbar ist.

Amazon RDS bemüht sich, Ihre Datenbank-Instances auf dem neuesten Stand zu halten, indem Ihnen neuere Versionen der unterstützten Datenbank-Engines zur Verfügung gestellt werden. Nachdem eine neue Version einer Datenbank-Engine vom Hersteller oder von der Entwicklerorganisation veröffentlicht wurde, wird diese von unseren Datenbanktechnikern gründlich geprüft, bevor sie in Amazon RDS zur Verfügung gestellt wird.

Wir empfehlen Ihnen, Ihre Datenbank-Instance stets in der jeweils aktuellsten Nebenversion zu betreiben, da diese die neuesten Sicherheits- und Funktionsaktualisierungen enthält. Updates für Nebenversionen enthalten, anders als Updates für Hauptversionen, nur Datenbankänderungen, die mit älteren Nebenversionen (derselben Hauptversion) der Datenbank-Engine abwärtskompatibel sind. 

Wenn eine neue Nebenversion keine Aktualisierungen enthält, die Amazon-RDS-Kunden zugutekommen würden, entscheiden wir uns eventuell, diese nicht in Amazon RDS zur Verfügung zu stellen. Kurz nachdem eine neue Nebenversion in Amazon RDS zur Verfügung gestellt wurde, wird diese als bevorzugte Nebenversion für neue DB-Instances definiert. 

Um eine Datenbank-Instance manuell auf eine unterstützte Engine-Version zu aktualisieren, kann der Befehl „Modify DB Instance“ in der AWS-Managementkonsole oder die ModifyDBInstance-API verwendet und der DB-Engine-Versionsparameter auf die gewünschte Version eingestellt werden. Standardmäßig wird das Upgrade während des nächsten Wartungsfensters angewendet. Sie können das Upgrade jedoch auch sofort ausführen, indem Sie die Option Apply Immediately (Sofort anwenden) in der API der Konsole auswählen.

Wenn wir feststellen, dass eine neue Nebenversion für eine Engine im Vergleich zu einer zuvor veröffentlichten Nebenversion wichtige Bugfixes enthält, planen wir automatische Upgrades für DB-Instances, bei denen die Option Auto Minor Version Upgrade auf „Yes“ (Ja) gesetzt ist. Diese Updates werden so geplant, dass sie im Rahmen der von den Kunden festgelegten Wartungsfenster durchgeführt werden.

Wir planen diese so, dass Sie darum herum planen können. Denn für das Upgrade einer DB-Engine-Version ist eine gewisse Ausfallzeit erforderlich, auch bei Multi-AZ-Instances. Falls Sie automatische Versions-Upgrades für Nebenversionen lieber ausstellen möchten, können Sie dies tun, indem Sie die Option Auto Minor Version Upgrade auf „No“ (Nein) setzen.

Wenn ein Upgrade auf die nächste Nebenversion bei RDS for Oracle und RDS for SQL Server den Wechsel auf eine andere Edition erfordert, werden möglicherweise auch dann keine automatischen Upgrades geplant, wenn die Option Auto Minor Version Upgrade aktiviert ist. In diesen Fällen wird im Einzelfall entschieden, ob automatische Updates geplant werden sollten oder nicht.

Da Updates auf neue Hauptversionen gewisse Kompatibilitätsrisiken mit sich bringen, erfolgen diese nicht automatisch. Sie müssen von Ihnen eingeleitet werden (es sei denn, eine Hauptversion ist veraltet; siehe unten). Informationen zum Aktualisieren einer DB-Instance auf eine neue DB-Engine-Version finden Sie im Amazon-RDS-Benutzerhandbuch.

Ja. Erstellen Sie hierfür einen DB-Snapshot Ihrer bestehenden DB-Instance, erstellen Sie aus dem DB-Snapshot eine neue DB-Instance und initiieren Sie dann ein Versions-Upgrade für die neue DB-Instance. Nun können Sie ungefährdet mit der aktualisierten Kopie ihrer DB-Instance experimentieren, bevor Sie entscheiden, ob Sie Ihre ursprüngliche DB-Instance upgraden möchten oder nicht.

Weitere Informationen zur Wiederherstellung eines DB-Snapshots finden Sie im Amazon-RDS-Benutzerhandbuch.

• Wir versuchen, Hauptversionen (z. B. MySQL 5.6, PostgreSQL 9.6), über einen Zeitraum von mindestens drei Jahren ab der ersten Einführung für Amazon RDS zu unterstützen.
• Nebenversionen (z. B. MySQL 5.6.37, PostgreSQL 9.6.1) sollen nach ihrer ersten Einführung für Amazon RDS mindestens ein Jahr lang unterstützt werden.

Von Zeit zu Zeit stellen wir die Unterstützung für Haupt- oder Nebenversionen der Engines ein. Hauptversionen stehen mindestens bis zum Ende des Lebenszyklus der Community für die entsprechende Community-Version zur Verfügung oder wenn die Version keine Software-Fehlerbehebungen oder Sicherheits-Updates erhält. Bei Nebenversionen ist dies der Fall, wenn eine Nebenversion erhebliche Fehler oder Sicherheitsprobleme enthält, die in einer späteren Nebenversion entfernt wurden.

Wenngleich wir versuchen, diese Richtlinien einzuhalten, ist es mitunter möglich, dass bestimmte Haupt- und Nebenversionen schneller nicht mehr unterstützt werden, z. B. bei Sicherheitsproblemen. In einem solchen unwahrscheinlichen Fall aktualisiert Amazon RDS Ihre Datenbank-Engine automatisch, um das Problem zu beheben. Bestimmte Umstände können, je nach Problemstellung, andere Abläufe erforderlich machen.

Wenn eine Nebenversion einer Datenbank-Engine in Amazon RDS veraltet ist, beginnen wir drei (3) Monate nach der Ankündigung mit den automatischen Upgrades. Am Ende dieses Zeitraums werden alle Instances, auf denen immer noch die veraltete Nebenversion ausgeführt wird, im Rahmen der geplanten Wartungsfenster für das automatische Upgrade auf die neueste unterstützte Nebenversion eingeplant.

Wenn eine Hauptversion einer Datenbank-Engine in Amazon RDS als veraltet eingestuft wird, räumen wir Ihnen nach der Benachrichtigung über die Einstellung der Unterstützung einen Übergangszeitraum von mindestens sechs (6) Monaten ein, in dem Sie das Upgrade auf eine unterstützte Hauptversion initiieren können. Nach Ablauf dieses Zeitraums wird im Rahmen geplanter Wartungsfenster ein automatisches Upgrade auf die nächsthöhere Hauptversion auf alle Instances, auf denen noch die veraltete Version ausgeführt wird, angewendet.

In einigen Fällen könnten bestimmte Haupt- oder Nebenversionen ohne vorherige Ankündigung veralten, wie z. B. wenn eine Version entdeckt wird, die unsere Standards für hohe Qualität und Leistung oder Sicherheit erfüllt. Wenn solche unwahrscheinlichen Fälle auftreten, erstellt Amazon RDS weiterhin neue Datenbank-Instances und Cluster mit diesen Versionen. Bestehende Kunden können Ihre Datenbanken weiterhin ausführen. Bestimmte Umstände können, je nach Problemstellung, andere Abläufe erforderlich machen.

Sie zahlen nur für das, was Sie tatsächlich nutzen. Es gibt keine Mindest- oder Einrichtungsgebühren. Ihre Nutzung wird folgendermaßen abgerechnet:

• DB-Instance-Stunden – diese basieren auf der Klasse (z. B. db.t2.micro, db.m4.large) der genutzten DB-Instance. Teilweise DB-Instance-Stunden werden in Sekundenschritten mit einer Mindestgebühr von 10 Minuten nach einer abrechenbaren Statusänderung wie dem Anlegen, Starten oder Ändern der DB-Instance-Klasse abgerechnet. Weitere Informationen finden Sie in unserer Ankündigung zu Neuigkeiten.
• Speicher (pro GB und Monat) – die Speicherkapazität, die Sie Ihrer DB-Instance zur Verfügung gestellt haben. Bei einer Skalierung der zur Verfügung gestellten Speicherkapazität im laufenden Monat werden die Gebühren entsprechend anteilig erfasst.
• E/A-Anforderungen pro Monat – Gesamtanzahl Ihrer E/A-Speicheranforderungen (nur für Amazon-RDS-Magnetfestplatten und Amazon Aurora)
• Bereitgestellte IOPS pro Monat – Rate der bereitgestellten IOPS, unabhängig vom verbrauchten IOPS (nur für SSD-Speicher mit bereitgestellten IOPS von Amazon RDS)
• Backup-Speicher – der Backup-Speicher ist der Speicher für Ihre automatisierten Datenbank-Backups und jegliche von Kunden initiierten Datenbank-Snapshots. Wenn Sie den Aufbewahrungszeitraum Ihrer Backups erhöhen oder zusätzliche Datenbank-Snapshots erstellen, belegt Ihre Datenbank dementsprechend mehr Backup-Speicher.
• Datenübertragung – ein- und ausgehende Internet-Datenübertragung Ihrer DB-Instance.

Informationen zu den Preisen von Amazon RDS finden Sie auf der Amazon-RDS-Produktseite im Abschnitt zu den Preisen.

Die Fakturierung einer DB-Instance beginnt zu dem Zeitpunkt, ab dem die DB-Instance verfügbar ist. Die Fakturierung wird so lange fortgesetzt, bis die DB-Instance durch Löschen oder aufgrund eines Ausfalls beendet wird.

Die Abrechnung erfolgt für jede Stunde, in der die DB-Instance in einem verfügbaren Zustand ausgeführt wird. Wenn Sie für die DB-Instance keine Gebühren mehr zahlen möchten, müssen Sie sie anhalten oder löschen, damit Ihnen keine weiteren Instance-Stunden in Rechnung gestellt werden. Teilweise DB-Instance-Stunden werden in Sekundenschritten mit einer Mindestgebühr von 10 Minuten nach einer abrechenbaren Statusänderung wie dem Anlegen, Starten oder Ändern der DB-Instance-Klasse abgerechnet.

Während Ihre Datenbank-Instance angehalten ist, werden Ihnen der bereitgestellte Speicher (einschließlich bereitgestellte IOPS) und der Sicherungsspeicher (einschließlich manuelle Snapshots und automatische Sicherungen innerhalb des angegebenen Aufbewahrungsfensters), aber nicht die DB-Instance-Stunden in Rechnung gestellt.

Der kostenlose Backup-Speicher wird bis zur Höhe des gesamten für Ihr Konto bereitgestellten Datenbankspeichers in der gesamten Region bereitgestellt. Wenn Sie beispielsweise eine MySQL-DB-Instance mit 100 GB bereitgestelltem Speicherplatz über den Monat und eine PostgreSQL-DB-Instance mit 150 GB bereitgestelltem Speicherplatz über den Monat haben, die sich beide in derselben Region und demselben Konto befinden, stellen wir Ihnen 250 GB Backup-Speicher in diesem Konto und dieser Region ohne zusätzliche Kosten zur Verfügung. Es wird Ihnen nur der Speicherplatz für Backups berechnet, der diesen Betrag übersteigt.

Jeden Tag wird der gesamte bereitgestellte Datenbankspeicher Ihres Kontos in der Region mit dem gesamten Backup-Speicher in der Region verglichen, und nur der überschüssige Backup-Speicher wird berechnet. Wenn Sie z. B. jeden Tag genau 10 GB überschüssigen Backup-Speicher haben, werden Ihnen für den Monat 10 GB Backup-Speicher berechnet. Wenn Sie jedoch jeden Tag 300 GB Speicher zur Verfügung stellen und jeden Tag 500 GB sichern, aber nur für die Hälfte des Monats, dann werden Ihnen nur 100 GB pro Monat für den Sicherungsspeicher berechnet (nicht 200 GB pro Monat), da die Gebühr täglich (anteilig) berechnet wird und die Sicherungen nicht für den gesamten Monat vorhanden waren. Bitte beachten Sie, dass der kostenlose Backup-Speicher konto- und regionsspezifisch ist.

Die Größe Ihrer Backups ist direkt proportional zur Menge der Daten auf Ihrer Instance. Wenn Sie z. B. eine DB-Instance mit 100 GB bereitgestelltem Speicher haben, aber nur 5 GB Daten darauf speichern, wird Ihr erstes Backup nur etwa 5 GB umfassen (nicht 100 GB). Nachfolgende Backups sind inkrementell und speichern nur die geänderten Daten auf Ihrer DB-Instance. Bitte beachten Sie, dass die Größe des Backup-Speichers weder in der RDS-Konsole noch in der DescribeDBSnapshots-API-Antwort angezeigt wird.

Der Speicher, der Ihrer DB-Instance für Ihre primären Daten zur Verfügung gestellt wird, befindet sich in einer einzigen Availability Zone. Beim Backup Ihrer Datenbank werden die Backup-Daten (einschließlich der Transaktionsprotokolle) für eine höhere Datenbeständigkeit georedundant in mehreren Availability Zones repliziert. Der Preis für die Backup-Speicherung, der über die kostenlose Zuordnung hinausgeht, spiegelt diese zusätzliche Replizierung wider, die durchgeführt wird, um die Beständigkeit Ihrer kritischen Backups zu maximieren.

Wenn Sie festlegen, dass Ihre DB-Instance als Multi-AZ-Bereitstellung genutzt wird, wird entsprechend den Multi-AZ-Preisen, die auf der Seite zu den Amazon-RDS-Preisen einzusehen sind, abgerechnet. Der Multi-AZ-Abrechnung liegen folgende Faktoren zu Grunde:

• Multi-AZ-DB-Instance-Stunden – diese basieren auf der Klasse (z. B. db.t2.micro, db.m4.large) der genutzten DB-Instance. Ebenso wie Standard-Bereitstellungen in einer Availability Zone, werden teilweise konsumierte DB-Instance-Stunden in Sekundenschritten mit einer Mindestgebühr von 10 Minuten nach einer abrechenbaren Statusänderung wie dem Anlegen, Starten oder Ändern der DB-Instance-Klasse abgerechnet. Wenn Sie innerhalb einer angebrochenen Stunde zwischen der Standardbereitstellung und der Multi-AZ-Bereitstellung für Ihre DB-Instance wechseln, werden beide jeweils anwendbaren Gebühren für diese Stunde in Rechnung gestellt.
• Bereitgestellter Speicherplatz (für Multi-AZ-DB-Instance) – wenn Sie innerhalb einer beliebigen Stunde zwischen der Standardbereitstellung und der Multi-AZ-Bereitstellung für Ihre DB-Instance wechseln, wird die höhere Speichergebühr für diese Stunde in Rechnung gestellt.
• E/A-Anforderungen pro Monat – Gesamtanzahl Ihrer E/A-Speicheranforderungen. Bei Multi-AZ-Bereitstellungen werden mehr E/A-Anforderungen verbraucht als bei standardmäßigen DB-Instance-Bereitstellungen, wobei der genaue Verbrauch von den Schreib-/Leseraten Ihrer Datenbank abhängt. Die E/A-Vorgänge im Zusammenhang mit Datenbank-Updates werden verdoppelt, da Amazon RDS Ihre Daten synchron in der Standby-DB-Instance repliziert. Die E/A-Auslastung für Lesevorgänge bleibt unverändert.
• Backup-Speicher – der Bedarf an Backup-Speicher bleibt gleich, egal, ob Sie eine standardmäßige oder eine Multi-AZ-Bereitstellung für Ihre DB-Instance nutzen. Backups werden einfach vom Standby-Replikat angefertigt, um E/A-Unterbrechungen bei den primären Daten der DB-Instance zu vermeiden.
• Datenübertragung – der beim Replizieren der Daten zwischen Primär-Instanz und Replika anfallende Datenverkehr wird Ihnen nicht in Rechnung gestellt. Der Transfer von Daten Ihrer DB-Instance wird in beide Richtungen genauso abgerechnet wie bei standardmäßigen Bereitstellungen.

Falls nicht anders angegeben, gelten unsere Preise zuzüglich anfallender Steuern und Abgaben, u. a. MwSt. und Umsatzsteuer. Bei Kunden mit japanischer Rechnungsadresse unterliegt die Nutzung von AWS-Services der japanischen Verbrauchssteuer. Weitere Informationen

Mit dem kostenlosen AWS-Kontingent für Amazon RDS erhalten Sie kostenlose Single-AZ-Micro-DB-Instances, auf denen MySQL, MariaDB, PostgreSQL und SQL Server Express Edition ausgeführt wird. Das kostenlose Nutzungskontingent ist auf 750 Instance-Stunden pro Monat begrenzt. Kunden erhalten außerdem kostenlos 20 GB SSD-Mehrzweck-Datenbankspeicher und 20 GB Backup-Speicher pro Monat.

Neuen AWS-Kunden steht das kostenlose Kontingent von AWS 12 Monate zur Verfügung. Auf der Seite mit den häufig gestellten Fragen zum kostenlosen AWS-Kontingent finden Sie weitere Informationen.

Ja. AWS-Kunden können mehrere Single-AZ Micro-DB-Instances gleichzeitig ausführen und dafür das kostenlose Kontingent von AWS für Amazon RDS in Anspruch nehmen. Wenn die Nutzung jedoch für alle Single-AZ-Micro-DB-Instances von Amazon RDS für alle in Frage kommenden Datenbanktypen und Regionen 750 Instance-Stunden überschreitet, werden die üblichen Amazon-RDS-Gebühren in Rechnung gestellt.

Beispiel: Wenn Sie zwei Single-AZ-Micro-DB-Instances je 400 Stunden lang in einem Monat ausführen, kommen Sie auf eine Instance-Nutzungsdauer von 800 Stunden, von denen 750 Stunden kostenlos sind. Die verbleibenden 50 Stunden werden Ihnen zum Amazon RDS-Standardpreis in Rechnung gestellt.

Nein. Ein Kunde mit Berechtigung für das kostenlose Kontingent von AWS kann Micro-Instances, die entweder mit MySQL, PostgreSQL, oder SQL Server Express Edition ausgeführt werden, nur insgesamt bis zu 750 Stunden nutzen. Wenn die Nutzung für alle Single-AZ Micro-DB-Instances von Amazon RDS für alle in Frage kommenden Datenbank-Engines und Regionen 750 Instance-Stunden überschreitet, werden die üblichen Amazon-RDS-Gebühren in Rechnung gestellt.

Die Stunden, die das kostenlose Kontingent überschreiten, werden Ihnen zu Amazon RDS-Standardpreisen in Rechnung gestellt. Einzelheiten finden Sie auf der Seite mit den Amazon-RDS-Preisen.

Mit Amazon RDS Reserved Instances haben Sie die Option, eine DB-Instance für ein bis drei Jahre zu reservieren und im Gegenzug einen erheblichen Rabatt im Vergleich mit dem Preis für On-Demand-Instances für diese DB-Instance zu erhalten. Es gibt drei RI-Zahlungsoptionen (keine Vorauszahlung, teilweise Vorauszahlung, komplette Vorauszahlung), die es Ihnen ermöglichen, den Betrag Ihrer Vorauszahlung und Ihren effektiven Stundenpreis aufeinander abzustimmen.

Funktionell gesehen sind Reserved Instances und On-Demand-DB-Instances genau gleich. Der einzige Unterschied besteht in der Abrechnung Ihrer DB-Instance(s). Bei Reserved Instances erwerben Sie eine ein- oder dreijährige Reservierung und erhalten im Gegenzug für die Dauer der Laufzeit einen niedrigeren effektiven Stundensatz (im Vergleich zu On-Demand-DB-Instances). Soweit Sie Reserved Instances nicht in einer Region kaufen, werden alle DB-Instances zu den stündlichen On-Demand-Nutzungsgebühren verrechnet.

Sie können eine Reserved Instance im Bereich „Reserved Instance“ der AWS-Managementkonsole für Amazon RDS erwerben. Alternativ können Sie unter Verwendung der Amazon-RDS-API oder der AWS-Befehlszeilenschnittstelle eine Liste der zum Kauf verfügbaren Reservierungen aufrufen und anschließend eine DB-Instance-Reservierung kaufen.

Nach dem Kauf der Reservierung unterscheidet sich die Nutzung einer reservierten DB-Instance nicht von der Nutzung einer On-Demand-DB-Instance. Starten Sie eine DB-Instance unter Verwendung derselben Klasse, Engine und Region, die Sie bei der Reservierung abgegeben haben. Solange Ihre Reservierung aktiv ist, erhalten Sie von Amazon RDS den entsprechenden reduzierten Stundensatz für die neue DB-Instance.

Die Reserved Instances von Amazon RDS werden eher für eine Region als für eine bestimmte Availability Zone gekauft. Da RIs nicht spezifisch für eine Availability Zone sind, stellen sie keine Kapazitätsreservierungen dar. Das bedeutet, dass sogar wenn die Kapazität in einer Availability Zone begrenzt ist, können Reservierungen trotzdem in der Region gekauft werden und der Nachlass wird auf eine passende Nutzung in Availability Zones innerhalb dieser Region angewendet.

Sie können bis zu 40 reservierte DB-Instances erwerben. Wenn Sie mehr als 40 DB-Instances ausführen möchten, füllen Sie das Anfrageformular für Amazon-RDS-DB-Instances aus.

Erwerben Sie einfach eine DB-Instance-Reservierung derselben DB-Instance-Klasse, derselben DB-Engine, derselben Multi-AZ-Option und demselben Lizenzmodell in derselben Region wie die DB-Instance, die Sie aktuell ausführen und reservieren möchten. Nach dem erfolgreichem Erwerb der Reservierung wendet Amazon RDS die neue stündliche Nutzungsgebühr automatisch auf Ihre bestehende DB-Instance an.

Preisänderungen für Reserved Instances werden aktiviert, sobald Ihr Antrag während der Zahlungsautorisierung eingegangen ist. Sie können den Status Ihrer Reservierung auf der Seite zu den AWS-Kontoaktivitäten oder über die DescribeReservedDBInstances-API oder den describe-reserved-db-instances-Befehl verfolgen. Falls die einmalige Zahlung nicht erfolgreich bis zur nächsten Abrechnungsperiode autorisiert werden kann, wird der rabattierte Preis nicht übernommen.

Nach Ablauf Ihres Reservierungszeitraums gilt für Ihre Reserved Instance wieder der entsprechende On-Demand-Nutzungstarif Ihrer DB-Instance-Klasse und -Region.

Die Amazon-RDS-Vorgänge zum Erstellen, Ändern und Löschen von DB-Instances sind für On-Demand-Instances und Reserved Instances identisch. Bei der Verarbeitung Ihrer Abrechnung wendet unser System automatisch Ihre Reservierung(en) an, sodass alle berechtigten DB-Instances nach dem reduzierten Stundentarif für reservierte DB-Instances abgerechnet werden.

Jede Reservierung ist mit den folgenden Attributen verknüpft: DB-Engine, DB-Instance-Klasse, Multi-AZ-Bereitstellungsoption, Lizenzmodell und Region.

Mit einer aktiven DB-Instance beliebiger Größe erhalten Sie innerhalb derselben Instance-Familie (z. B. M4, T2 oder R3) für die gleiche Datenbank-Engine und Region automatisch eine für die Größenflexibilität (MySQL, MariaDB, PostgreSQL, Amazon Aurora oder Oracle „Bring Your Own License“) anwendbare Reservierung für eine DB-Engine und ein Lizenzmodell. Diese Reservierung gilt darüber hinaus auch für DB-Instances in Single-AZ oder Multi-AZ-Bereitstellungen.

Gehen wir beispielsweise davon aus, dass Sie eine MySQL-Reservierung des Typs db.m4.2xlarge gekauft haben. Wenn Sie sich nun entscheiden, die aktive DB-Instance auf eine db.m4.4xlarge-Instance zu skalieren, wird die Hälfte der Nutzung der größeren DB-Instance bereits durch den Vorzugspreis für diese Reserved Instance abgedeckt.

Führen Sie dagegen eine DB-Engine oder ein Lizenzmodell aus, für die keine Größenflexibilität gilt (Microsoft SQL Server oder Oracle „License Included“), kann jede Reservierung für die Dauer des Vertrags nur auf eine DB-Instance mit den gleichen Merkmalen angewendet werden. Wenn Sie sich entscheiden, ein beliebiges Attribut Ihrer DB-Instance vor dem Ende des Reservierungszeitraums zu modifizieren, gelten wieder die normalen On-Demand-Tarifsätze für diese DB-Instance.

Weitere Informationen zur Größenflexibilität finden Sie im Amazon-RDS-Benutzerhandbuch.

Jede Reserved Instance ist an eine bestimmte Region gebunden, die für die Lebensdauer der Reservierung festgelegt ist und nicht geändert werden kann. Jede Reservierung kann jedoch in beliebigen AZs der zugeordneten Region verwendet werden.

Ja. Beim Kauf einer Reserved Instance können Sie in der zum Kauf verfügbaren DB-Instance-Konfiguration die Option für Multi-AZ auswählen. Wenn Sie darüber hinaus eine DB-Engine und ein Lizenzmodell verwenden, das Größenflexiblität für Reserved Instances unterstützt, kann die Reserved Instance mit Multi-AZ für zwei Single-AZ-DB-Instances verwendet werden.

Eine DB-Instance-Reservierung kann auch auf ein Lesereplikat angewandt werden, sofern DB-Instance-Klasse und -Region identisch sind. Bei der Verarbeitung Ihrer Abrechnung wendet unser System automatisch Ihre Reservierung(en) an, sodass alle berechtigten DB-Instances nach dem reduzierten Stundentarif für Reserved Instances abgerechnet werden.

Nein. Sie können Ihre reservierte DB-Instance nicht stornieren und die Einmalzahlung (falls durchgeführt) wird nicht zurückerstattet. Sie zahlen unabhängig von der tatsächlichen Nutzung weiter für jede Stunde Ihrer Vertragslaufzeit für die reservierte DB-Instance.

Wenn Sie eine RI mit der Zahlungsoption "Komplette Vorauszahlung" erwerben, zahlen Sie in einer Vorauszahlung für die gesamte Laufzeit der RI. Bei Wahl der Option "Keine Vorauszahlung" leisten Sie vorab keine Zahlung. Der gesamte Wert der RI vom Typ "Keine Vorauszahlung" wird auf alle Stunden in der Laufzeit verteilt und Ihnen wird jede Stunde der Laufzeit ungeachtet der Nutzung in Rechnung gestellt. Die dritte Zahlungsoption heißt "Teilweise Vorauszahlung". Sie leisten eine niedrige Vorauszahlung und anschließend wird Ihnen ein niedriger Stundentarif für die Dauer der Laufzeit in Rechnung gestellt.

Um Ihre anfängliche DB-Instance-Klasse und Speicherkapazität auszuwählen, sollten Sie den Rechen- und Speicherbedarf der betreffenden Anwendung abschätzen. Informationen zu den verfügbaren DB-Instance-Klassen finden Sie im Amazon-RDS-Benutzerhandbuch.

Sie können die Rechenressourcen und die Speicherkapazität, die Ihrer DB-Instance zugeordnet ist, skalieren, indem Sie die AWS-Managementkonsole (gewünschte DB-Instance auswählen und auf die Schaltfläche Modify klicken), die Amazon-RDS-API oder die AWS-Befehlszeilenschnittstelle verwenden. Speicher- und CPU-Ressourcen können durch eine Änderung der DB-Instance-Klasse modifiziert werden, und der verfügbare Speicher wird geändert, wenn Sie Ihre Speicherzuteilung ändern. 

Bitte beachten Sie, dass alle gewünschten Änderungen der DB-Instance-Klasse oder des zugeteilten Speichers während des festgelegten Wartungs- bzw. Aktualisierungsfensters durchgeführt werden. Alternativ können Sie ein "apply-immediately"-Flag setzen, um die angeforderte Skalierung sofort durchzuführen. Beachten Sie, dass in diesem Fall alle anderen noch ausstehenden Systemänderungen ebenfalls durchgeführt werden.

Ihre RDS for SQL Server-Instance ist für den skalierten Speicher nicht berechtigt. Mehr Informationen finden Sie bei den häufig gestellten Fragen zu RDS for SQL Server.

Amazon RDS verwendet EBS-Datenträger zum Speichern von Datenbank und Protokoll. Je nach der Größe des erforderlichen Speichers verteilt Amazon RDS Daten automatisch per Striping auf mehrere EBS-Datenträger, um die IOPS-Leistung zu verbessern. Bei einer vorhandenen MySQL- oder Oracle-DB-Instance stellen Sie eventuell eine Verbesserung der E/A-Kapazitäten fest, wenn Sie Ihren Speicherplatz hochskalieren. Sie können die der DB-Instance zugewiesene Speicherkapazität erweitern. Verwenden Sie hierfür die AWS-Managementkonsole, die ModifyDBInstance-API oder den modify-db-instance-Befehl.

Weitere Informationen finden Sie unter Speicher für Amazon RDS.

Ihre DB-Instance ist auch während einer Skalierung der ihr zugeteilten Speicherkapazität verfügbar. Bei einer Skalierung der zur Verfügung stehenden Rechenressourcen Ihrer DB-Instance ist die Datenbank jedoch während der Änderung der DB-Instance-Klasse vorübergehend nicht verfügbar. Der Zeitraum der Nichtverfügbarkeit dauert in der Regel nur wenige Minuten und liegt innerhalb des Aktualisierungsfensters für Ihre DB-Instance, es sei denn, Sie legen fest, dass die Änderung sofort durchgeführt werden soll.

Amazon RDS unterstützt eine Reihe verschiedener DB-Instance-Klassen und Speicherzuteilungen, die diverse Anwendungsanforderungen erfüllen. Wenn die von Ihrer Anwendung benötigten Rechenressourcen die höchste DB-Instance-Klasse bzw. die maximale Speicherzuteilung übersteigen, können Sie eine Partitionierung implementieren und so die Daten auf mehrere DB-Instances verteilen.

Amazon-RDS-Universalspeicher (SSD) ist für ein breites Spektrum von Datenbank-Workloads mit mäßigen E/A-Anforderungen geeignet. Mit der Basisleistung von 3 E/A\Sek./GB und der Fähigkeit kurzzeitiger Spitzenleistung von bis zu 3 000 E/A\Sek. bietet diese Speicheroption eine vorhersehbare Leistung, die die Anforderungen der meisten Anwendungen erfüllt.

Bereitgestellter IOPS-Speicher (SSD) in Amazon RDS ist eine durch SSD unterstützte Speicheroption, die so konzipiert wurde, dass sie eine schnelle, vorhersehbare und konsistente E/A-Leistung bietet. Bei bereitgestelltem IOPS-Speicher (SSD) in Amazon RDS geben Sie bei der Erstellung einer DB-Instance eine IOPS-Rate an und Amazon RDS stellt diese IOPS-Rate dann für die Lebensdauer dieser DB-Instance bereit. Bereitgestellter IOPS-Speicher (SSD) in Amazon RDS ist für E/A-intensive, transaktionale Datenbank-Workloads (OLTP) optimiert. Nähere Informationen finden Sie im Amazon-RDS-Benutzerhandbuch.

Amazon-RDS-Magnetspeicher ist bei kleinen Datenbank-Workloads nützlich, bei denen weniger häufig auf die Daten zugegriffen wird. Für Produktionsdatenbank-Instances ist Magnetspeicher nicht empfehlenswert.

Wählen Sie den Speichertyp, der für Ihre Arbeitslast am besten geeignet ist.

• Hochleistungs-OLTP-Workloads: Bereitgestellter IOPS-Speicher (SSD) in Amazon RDS
• Datenbanken mit mäßigen E/A-Anforderungen: Amazon RDS-Standardspeicher (SSD)

Die von Amazon RDS unterstützte IOPS-Kapazität hängt von der jeweiligen Datenbank-Engine ab. Nähere Informationen finden Sie im Amazon-RDS-Benutzerhandbuch.

Amazon RDS bietet zwei verschiedene Methoden zum Backup und zur Wiederherstellung Ihrer DB-Instance(s) an: automatische Backups und Datenbank-Snapshots (DB-Snapshots).

Die Amazon-RDS-Funktion für automatisierte Backups ermöglicht zeitpunktbezogene Wiederherstellungen Ihrer DB-Instance. Wenn automatisierte Backups für Ihre DB-Instance aktiviert sind, führt Amazon RDS täglich automatisch einen vollständigen Snapshot Ihrer Daten aus (im Rahmen Ihres festgelegten Backup-Fensters) und generiert Transaktionsprotokolle (zu den Updates Ihrer DB-Instance). Wenn Sie eine Wiederherstellung für einen bestimmten Zeitpunkt initiieren, werden die Transaktionsprotokolle für das passendste Backup angewandt, um Ihre DB-Instance zum gewünschten Zeitpunkt zurückzusetzen. 

Amazon RDS bewahrt Backups einer DB-Instance für einen begrenzten, benutzerdefinierten Zeitraum (den "Aufbewahrungszeitraum") auf. Dieser liegt standardmäßig bei sieben Tagen, kann aber auf bis zu 35 Tage verlängert werden. Sie können eine Wiederherstellung zu jeder beliebigen Sekunde Ihres Wiederherstellungszeitraums bis zum letztmöglichen Zeitpunkt initiieren. Sie können die API DescribeDBInstances verwenden, um den letztmöglichen Wiederherstellungszeitpunkt für Ihre DB-Instance zu nutzen. Dieser liegt in der Regel innerhalb der letzten fünf Minuten. 

Alternativ können Sie den letztmöglichen Wiederherstellungszeitpunkt für eine DB-Instance auch finden, indem Sie die Instance in der AWS-Managementkonsole auswählen und unter der Registerkarte „Description“ im unteren Arbeitsbereich der Konsole nachsehen.

DB-Snapshots werden vom Benutzer initiiert und ermöglichen es Ihnen, Ihre DB-Instance in einem bekannten Zustand beliebig oft zu sichern und dann diesen spezifischen Zustand jederzeit wiederherzustellen. DB-Snapshots können mit der AWS-Managementkonsole, der CreateDBSnapshot-API oder dem Befehl „create-db-snapshot“ erstellt werden. Sie werden so lange aufbewahrt, bis sie explizit von Ihnen gelöscht werden.

Die von Amazon RDS zur Aktivierung automatischer Backups ausgeführten Snapshots stehen zum Kopieren (über die AWS-Konsole oder den copy-db-snapshot-Befehl) oder für die Snapshot-Wiederherstellung zur Verfügung. Sie ermitteln sie anhand des "automatisierten" Snapshot-Typs. Außerdem können Sie den Zeitpunkt ermitteln, zu dem der Snapshot erstellt wurde, indem Sie das Feld "Zeitpunkt der Snapshot-Erstellung" anzeigen. 

Die Kennzeichnung des "automatisierten" Snapshots enthält alternativ ebenfalls die Zeit (UTC), zu der der Snapshot erstellt wurde.

Hinweis: Wenn Sie einen Wiederherstellungsvorgang zu einem bestimmten Zeitpunkt oder mithilfe eines DB-Snapshots durchführen, wird eine neue DB-Instance mit einem neuen Endpunkt erstellt (die alte DB-Instance kann auf Wunsch gelöscht werden). Auf diese Weise haben Sie die Möglichkeit, mehrere DB Instances aus einem bestimmten DB Snapshot oder zu einem bestimmten Zeitpunkt zu erstellen.

Automatische Backups Ihrer DB-Instance sind in Amazon RDS standardmäßig aktiviert. Es gilt ein Aufbewahrungszeitraum von sieben Tagen. Möchten Sie den Aufbewahrungszeitraum für Backups ändern, so können Sie dies tun, indem sie entweder die RDS-Konsole, die CreateDBInstance-API (bei der Erstellung einer neuen DB-Instance) oder die ModifyDBInstance-API (bei einer bestehenden DB-Instance) verwenden. Diese Methoden können Sie verwenden, um die Parameter des Aufbewahrungszeitraums von 0 (welches die automatischen Backups deaktiviert) auf die gewünschte Anzahl an Tagen zu ändern, bis zu 35. Der Wert kann nicht auf 0 gesetzt werden, wenn die DB-Instance eine Quelle für Lesereplikate ist. Weitere Informationen zu automatischen Backups finden Sie im Benutzerhandbuch zu Amazon RDS.

Beim bevorzugten Backup-Fenster handelt es sich um den vom Benutzer festgelegten Zeitraum, in dem das Backup der DB-Instance durchgeführt wird. Amazon RDS nutzt diese regelmäßigen Daten-Backups in Verbindung mit Ihren Transaktionsprotokollen, um Ihnen die Möglichkeit zu geben, Ihre DB-Instance zu jeder Sekunde des Aufbewahrungszeitraums bis zum letztmöglichen Wiederherstellungszeitpunkt (üblicherweise innerhalb der letzten Minuten) wiederherzustellen. Während des Backup-Fensters kann die Speicher-E/A kurz unterbrochen werden, während der Backup-Prozess initialisiert wird (normalerweise innerhalb weniger Sekunden). Möglicherweise tritt auch kurzzeitig eine höhere Latenz auf. Bei Multi-AZ DB-Bereitstellungen gibt es keine E/A-Unterbrechungen, da das Backup aus dem Standby-Replikat angefertigt wird.

Amazon-RDS-DB-Screenshots und automatisierte Backups werden in S3 gespeichert.

Sie können die AWS-Managementkonsole, die ModifyDBInstance-API oder den modify-db-instance-Befehl verwenden, um den Aufbewahrungszeitraum für automatische Backups zu verwalten, indem Sie den RetentionPeriod-Parameter ändern. Wenn Sie automatische Sicherungen vollständig deaktivieren möchten (was nicht empfohlen wird), setzen Sie den Aufbewahrungszeitraum auf 0. Sie können Ihre benutzererstellten DB-Snapshots über den Bereich „Snapshots“ in der Amazon RDS-Konsole verwalten. Alternativ können Sie eine Liste der vom Benutzer für eine bestimmte DB-Instance erstellten DB-Snapshots anzeigen, indem Sie die API DescribeDBSnapshots oder den Befehl describe-db-snapshots verwenden und die Snapshots über die DeleteDBSnapshot-API oder den Befehl delete-db-snapshot löschen.

Es ist nicht ungewöhnlich, dass ein oder zwei automatisierte DB-Snapshots mehr als die Anzahl der Tage im Aufbewahrungszeitraum vorhanden sind. Es wird ein zusätzlicher automatisierter Snapshot beibehalten, um eine Wiederherstellung zu einem bestimmten Zeitpunkt für jeden Zeitpunkt im Aufbewahrungszeitraum ausführen zu können.

Wenn das Backup-Fenster z. B. auf einen Tag festgelegt wird, werden zwei automatisierte Snapshots benötigt, um Wiederherstellungen zu jedem Zeitpunkt in den vorhergehenden 24 Stunden zu ermöglichen. Außerdem wird möglichweise ein weiterer automatisierter Snapshot angezeigt, da immer erst ein neuer automatisierter Snapshot erstellt wird, bevor der älteste automatisierte Snapshot gelöscht wird.

Wenn Sie eine DB-Instance löschen, können Sie vor dem Löschvorgang einen letzten 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 RDS 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. Auf der Seite mit den Preisen finden Sie Details zu den Kosten des Backup-Speichers.

Wenn Sie eine DB-Instance löschen, können Sie automatische Backups bis zum Aufbewahrungszeitraum für Backups beibehalten. Weitere Informationen finden Sie unter Beibehaltung automatisierter Backups.

Mit Amazon VPC können Sie eine virtuelle Netzwerkumgebung in einem privaten, isolierten Bereich der AWS Cloud erstellen. Hier haben Sie die vollständige Kontrolle über private IP-Adressbereiche, Subnetze, Routing-Tabellen und Netzwerk-Gateways. Mit Amazon VPC definieren Sie eine virtuelle Netzwerktopologie und passen die Netzwerkkonfiguration an Ihre Bedürfnisse an, so dass sie einem herkömmlichen IP-Netzwerk ähnelt, das Sie in Ihrem eigenen Rechenzentrum betreiben könnten.

VPC eignet sich besonders, wenn Sie eine öffentlich zugängliche Webanwendung ausführen, aber nicht öffentlich zugängliche Backend-Server in einem privaten Subnetz beibehalten möchten. Sie können ein öffentlich zugängliches Subnetz für Ihre Webserver erstellen, das Zugang zum Internet hat, und Ihre Backend-Amazon-RDS-DB-Instances in einem nicht öffentlich zugänglichen Subnetz ohne Internetzugriff einrichten. Weitere Informationen zu Amazon VPC erhalten Sie im Benutzerhandbuch zu Amazon Virtual Private Cloud.

Wurde Ihr AWS-Konto vor dem 4. Dezember 2013 erstellt, können Sie Amazon RDS möglicherweise in einer Amazon Elastic Compute Cloud (EC2)-Classic-Umgebung ausführen. Die grundlegenden Funktionen von Amazon RDS sind dieselben, unabhängig davon, ob EC2-Classic oder EC2-VPC genutzt wird. Amazon RDS verwaltet Backups, Software-Patches, automatische Fehlererkennung, Lesereplikate und Wiederherstellungen unabhängig davon, ob Ihre DB-Instances innerhalb oder außerhalb einer VPC bereitgestellt werden. Weitere Informationen zu den Unterschieden zwischen EC2-Classic und EC2-VPC finden Sie in der EC2-Dokumentation.

Eine DB-Subnetzgruppe ist eine Sammlung von Subnetzen, die Sie für Ihre Amazon-RDS-DB-Instances in einer VPC verwenden können. Jede DB-Subnetzgruppe sollte mindestens über ein Subnetz für jede Availability Zone in einer bestimmten Region verfügen. Wenn Sie eine DB-Instance in VPC erstellen, müssen Sie eine DB-Subnetzgruppe auswählen. Amazon RDS verwendet diese DB-Subnetzgruppe und Ihre bevorzugte Availability Zone dann zur Auswahl eines Subnetzes und einer IP-Adresse in diesem Subnetz. Amazon RDS erstellt und ordnet Ihrer DB Instance eine Elastic-Netzwerkschnittstelle mit dieser IP-Adresse zu.

Es wird dringend empfohlen, dass Sie den DNS-Namen für die Verbindung mit Ihrer DB-Instance verwenden, da sich die zugrunde liegende IP-Adresse ändern kann (z. B während eines Failovers).

Bei Multi-AZ-Bereitstellungen kann Amazon RDS durch die Definition eines Subnetzes für alle Availability Zones in einer Region bei Bedarf eine neue Standby-Instance in einer anderen Availability Zone erstellen. Sie müssen dies sogar für Einzel-AZ-Bereitstellungen vornehmen, nur für den Fall, dass Sie sie zu einem späteren Zeitpunkt in Multi-AZ-Bereitstellungen umwandeln möchten.

Eine Schritt-für-Schritt-Anleitung zu diesem Prozess finden Sie im Amazon RDS-Benutzerhandbuch unter Creating a DB Instance in a VPC.

Im Benutzerhandbuch zu Amazon RDS finden Sie im Abschnitt Sicherheitsgruppe Informationen zu den verschiedenen Möglichkeiten, den Zugriff auf Ihre DB-Instances zu steuern.

Auf DB-Instances, die innerhalb einer VPC bereitgestellt werden, kann von in derselben VPC bereitgestellten EC2-Instances zugegriffen werden. Wenn diese EC2-Instances in einem öffentlichen Subnetz mit zugeordneten Elastic IP-Adressen bereitgestellt werden, können Sie auf die EC2-Instances über das Internet zugreifen. Auf in einer VPC bereitgestellte DB-Instances kann über das Internet oder von EC2-Instances außerhalb der VPC über VPN oder Bastion-Hosts zugegriffen werden, die Sie in Ihrem öffentlichen Subnetz oder über die Amazon-RDS-Option „Publicly Accessible“ starten können:

• Wenn Sie einen Bastion-Host verwenden möchten, müssen Sie ein öffentliches Subnetz mit einer EC2-Instance einrichten, die als SSH-Bastion fungiert. Dieses öffentliche Subnetz muss über ein Internet-Gateway und Routing-Regeln verfügen, die erlauben, dass der Datenverkehr über den SSH-Host gerichtet wird. Dieser muss dann Anforderungen an die private IP-Adresse Ihrer Amazon-RDS-DB-Instance weiterleiten.
• Erstellen Sie für eine öffentliche Anbindung Ihre DB-Instances mit auf „Yes“ festgelegter Option „Publicly Accessible“. Wenn "Publicly Accessible" aktiv ist, kann standardmäßig von außerhalb Ihrer VPC voll auf Ihre DB-Instances in der VPC zugegriffen werden. Das heißt, dass Sie kein VPN bzw. keinen Bastion-Host konfigurieren müssen, um den Zugriff auf Ihre Instances zuzulassen.

Sie können auch ein VPN-Gateway einrichten, durch das Ihr Unternehmensnetzwerk in Ihre VPC ausgedehnt wird und das einen Zugriff auf die Amazon-RDS-DB-Instance in dieser VPC ermöglicht. Weitere Informationen hierzu finden Sie im Benutzerhandbuch zu Amazon VPC.

Es wird dringend empfohlen, dass Sie den DNS-Namen für die Verbindung mit Ihrer DB Instance verwenden, da sich die zugrunde liegende IP-Adresse ändern kann (z. B während eines Failovers).

Falls sich Ihre DB-Instance nicht in einer VPC befindet, können Sie sie einfach mithilfe der AWS-Managementkonsole in eine VPC verschieben. Weitere Informationen hierzu finden Sie im Amazon-RDS-Benutzerhandbuch. Sie können auch einen Snapshot Ihrer DB-Instance außerhalb der VPC erstellen und ihn in der VPC wiederherstellen, indem Sie die gewünschte DB-Subnetzgruppe angeben. Sie können auch eine "Wiederherstellung zu einem bestimmten Zeitpunkt" vornehmen.

Die Migration von DB-Instances von innerhalb zu außerhalb der VPC wird nicht unterstützt. Aus Sicherheitsgründen kann ein DB-Snapshot einer DB-Instance in einer VPC nicht außerhalb der VPC wiederhergestellt werden. Dasselbe gilt für die Funktion "Wiederherstellung zu einem bestimmten Zeitpunkt". 

Sie müssen Routing-Tabellen und Netzwerk-ACLs in Ihrer VPC entsprechend ändern, um sicherzustellen, dass Ihre DB-Instance von Ihren Client-Instances in der VPC erreichbar sind. Bei Multi-AZ-Bereitstellungen befindet sich Ihre Client-EC2-Instance und die Amazon-RDS-DB-Instance nach einem Failover eventuell in verschiedenen Availability Zones. Sie sollten Ihre Netzwerk-ACLs so konfigurieren, dass eine übergreifende AZ-Kommunikation möglich ist.

Eine vorhandene DB-Subnetzgruppe kann aktualisiert werden, um weitere Subnetze für vorhandene Availability Zones oder für neue Availability Zones hinzuzufügen, die nach dem Erstellen der DB-Instance hinzugefügt wurden. Das Entfernen von Subnetzen aus einer vorhandenen DB-Subnetzgruppe kann eine Nichtverfügbarkeit für Instances bewirken, wenn diese in einer bestimmten Availability Zone ausgeführt werden, die aus der Subnetzgruppe entfernt wird. Weitere Informationen hierzu finden Sie im Amazon-RDS-Benutzerhandbuch.

Um Amazon RDS verwenden zu können, benötigen Sie ein AWS-Entwicklerkonto. Wenn Sie vor der Anmeldung für Amazon RDS kein Entwicklerkonto besitzen, werden Sie zu Beginn des Anmeldevorgangs zur Erstellung eines solchen Kontos aufgefordert. Ein Haupt-Benutzerkonto unterscheidet sich von einem AWS-Entwicklerkonto und wird ausschließlich im Rahmen von Amazon RDS verwendet, um den Zugriff auf Ihre DB-Instance(s) zu kontrollieren. Beim Haupt-Benutzerkonto handelt es sich um das Benutzerkonto einer nativen Datenbank, über das Sie auf Ihre DB-Instance zugreifen können. 

Bei Erstellung der einzelnen DB-Instances können Sie festlegen, welcher Haupt-Benutzername und welches Kennwort diesen zugewiesen werden sollen. Nach Erstellung Ihrer DB-Instance können Sie mithilfe der Haupt-Benutzerdaten auf die Datenbank zugreifen. Anschließend können Sie weitere Benutzerkonten erstellen, mit denen Sie den Zugriff auf Ihre DB Instance einschränken können.

Der Haupt-Benutzer verfügt über folgende Standardberechtigungen für MySQL: Erstellen, Entfernen, Referenzen, Ereignis, Ändern, Löschen, Index, Einfügen, Auswählen, Aktualisieren, temporäre Tabellen erstellen, Tabellen sperren, Auslösen, Ansicht erstellen, Ansicht anzeigen, Routine ändern, Routine erstellen, Ausführen, Auslösen, Benutzer erstellen, Verarbeiten, Datenbanken anzeigen, Option erteilen.

Der Haupt-Benutzer verfügt in Oracle über die „dba“-Rolle. Der Haupt-Benutzer übernimmt die meisten Berechtigungen, die der Rolle zugeordnet sind. Eine Liste mit den eingeschränkten Berechtigungen und den entsprechenden Alternativen, um administrative Aufgaben durchzuführen, die diese Berechtigungen eventuell erfordern, finden Sie im Amazon-RDS-Benutzerhandbuch.

Bei SQL Server wird dem Benutzer, der eine Datenbank anlegt, die Rolle "db_owner" zugewiesen. Eine Liste mit den eingeschränkten Berechtigungen und den entsprechenden Alternativen, um administrative Aufgaben durchzuführen, die diese Berechtigungen eventuell erfordern, finden Sie im Amazon-RDS-Benutzerhandbuch.

Nein, alles funktioniert so, wie Sie es von relationalen Datenbanken gewohnt sind, die Sie selbst verwalten.

Ja. Sie müssen den Zugriff auf Ihre Datenbank über das Internet manuell aktivieren, indem Sie Sicherheitsgruppen konfigurieren. Sie können den Zugriff nur für die spezifischen IP-Adressen, IP-Adressbereiche und Subnetze autorisieren, die Servern in Ihrem eigenen Rechenzentrum entsprechen.

Ja, diese Option wird für alle Amazon RDS-Engines unterstützt. Amazon RDS generiert für jede DB-Instance ein SSL-/TLS-Zertifikat. Nach dem Herstellen einer verschlüsselten Verbindung werden Daten zwischen der Datenbank-Instance und Ihrer Anwendung verschlüsselt übertragen.

Wenngleich SSL Sicherheitsvorteile bietet, sollten Sie daran denken, dass eine SSL-/TLS-Verschlüsselung sehr rechenintensiv ist und die Latenz Ihrer Datenbankverbindung erhöhen wird. Die Unterstützung für SSL/TLS in Amazon RDS dient zur Verschlüsselung der Verbindung zwischen Ihrer Anwendung und Ihrer DB-Instance. Sie sollte nicht zur Authentifizierung der DB-Instance selbst genutzt werden.

Einzelheiten zum Einrichten einer verschlüsselten Verbindung mit Amazon RDS finden Sie im MySQL-Benutzerhandbuch, MariaDB-Benutzerhandbuch, SQL-Server-Benutzerhandbuch, PostgreSQL-Benutzerhandbuch oder Oracle-Benutzerhandbuch von Amazon RDS. Weitere Informationen zur Funktionsweise von SSL/TLS mit diesen Engines finden Sie in der MySQL-Dokumentation, der MariaDB-Dokumentation, der MSDN-SQL-Server-Dokumentation, der PostgreSQL-Dokumentation oder der Oracle-Dokumentation.

Amazon RDS unterstützt Verschlüsselung im Ruhezustand für alle Datenbank-Engines mithilfe von Schlüsseln, die Sie mit AWS Key Management Service (KMS) verwalten. Bei einer mit Amazon RDS-Verschlüsselung ausgeführten DB-Instance sind die im zugrunde liegenden Speicher gespeicherten Daten verschlüsselt, was auch für deren automatisierte Sicherungen, Read Replicas und Snapshots gilt. Ver- und Entschlüsselung erfolgen transparent. Weitere Informationen zur Verwendung von KMS mit Amazon RDS finden Sie im Amazon-RDS-Benutzerhandbuch.

Sie können auch eine Verschlüsselung zu einer zuvor unverschlüsselten DB-Instance oder einem DB-Cluster hinzufügen, indem Sie einen DB-Snapshot erstellen, eine Kopie davon erzeugen und anschließend eine KMS-Verschlüsselung festlegen. Sie können dann eine verschlüsselte DB-Instance oder einen DB-Cluster aus dem verschlüsselten Snapshot wiederherstellen.

Amazon RDS for Oracle und SQL Server unterstützen die Transparent--Data-Encryption-Technologien (TDE) dieser Engines. Weitere Informationen finden Sie im Benutzerhandbuch für Amazon RDS für Oracle und SQL Server.

Sie können die Aktionen kontrollieren, die Ihre AWS-IAM -Benutzer und -Gruppen auf bestimmte Amazon-RDS-Ressourcen anwenden können. Dies erfolgt über Verweise auf die Amazon-RDS-Ressourcen in den AWS-IAM-Richtlinien, die Sie auf Ihre Benutzer und Gruppen anwenden können. Amazon-RDS-Ressourcen, auf die in einer AWS IAM-Richtlinie verwiesen werden kann, sind DB-Instances, DB-Snapshots, Lesereplikate, DB-Sicherheitsgruppen, DB-Optionsgruppen, DB-Parametergruppen, Ereignisabonnements und DB-Subnetzgruppen. 

Darüber hinaus können Sie diese Ressourcen markieren, um ihnen weitere Metadaten hinzuzufügen. Sie können so Ihren Ressourcen Kategorien zuweisen (z. B. „Entwicklung“-DB-Instances, „Produktion“-DB-Instances, „Test“-DB-Instances usw.) und AWS-IAM-Richtlinien festlegen, in denen die Berechtigungen für die Aktionen aufgeführt sind, die auf Ressourcen der jeweiligen Kategorie angewendet werden dürfen. Weitere Informationen finden Sie unter Tagging von Amazon-RDS-Ressourcen.

Ja. AWS CloudTrail ist ein Web-Service, der Aufrufe von AWS-APIs für Ihr Konto aufzeichnet und Protokolldateien an Sie übermittelt. Der AWS-API-Aufrufverlauf, der von CloudTrail generiert wird, ermöglicht eine Sicherheitsanalyse, Nachverfolgung von Ressourcenänderungen und Überwachung der Einhaltung von Vorschriften. 

Ja, alle Amazon-RDS-Datenbank-Engines sind HIPAA-fähig, Sie können damit daher HIPAA-konforme Anwendungen erstellen und gesundheitsbezogene Daten speichern, u. a. Protected Health Information (PHI) im Rahmen eines aktiven Business Associate Agreement (BAA) mit AWS.

Wenn Sie bereits ein aktives BAA haben, können Sie ohne weitere Maßnahmen diese Services mit den vom BAA abgedeckten Konten verwenden. Wenn kein aktives BAA mit AWS vorhanden ist oder Sie Fragen zu HIPAA-konformen Anwendungen in AWS haben, wenden Sie sich an uns.

Amazon RDS wählt standardmäßig die optimalen Konfigurationsparameter für Ihre DB-Instance aus und berücksichtigt dabei Instance-Klasse und Speicherkapazität. Wenn Sie die Parameter ändern möchten, können Sie hierfür die AWS-Managementkonsole, die Amazon RDS-APIs oder die AWS-Befehlszeilenschnittstelle verwenden. Bitte beachten Sie, dass eine Änderung der empfohlenen Werte der Konfigurationsparameter unbeabsichtigte Folgen haben kann, die von einer herabgesetzten Leistung bis hin zu Systemzusammenbrüchen reichen können. Derartige Änderungen sollten daher nur von erfahrenen Benutzern vorgenommen werden, die bereit sind, diese Risiken in Kauf zu nehmen.

Eine DB-Parametergruppe (Database Parameter Group) dient als eine Art "Behälter" für die Werte der Engine-Konfiguration, die für eine oder mehrere DB-Instances verwendet werden können. Falls Sie eine DB-Instance erstellen, ohne eine DB-Parametergruppe anzugeben, wird eine standardmäßige DB-Parametergruppe verwendet. Diese Standardgruppe enthält Engine-Standards und Systemstandards für Amazon RDS, die für die gerade ausgeführte DB-Instance optimiert sind.

Wenn Sie die DB-Instance jedoch mit benutzerdefinierten Werten für die Engine-Konfiguration ausführen möchten, können Sie einfach eine neue DB-Parametergruppe erstellen, die betreffenden Parameter ändern und festlegen, dass die DB-Instance die neue DB-Parametergruppe verwendet. Nach der Zuordnung der einzelnen DB Instances zu bestimmten DB-Parametergruppe werden alle DB Instances mit den Parametern der jeweiligen DB-Parametergruppe aktualisiert.

Weitere Informationen zur Konfiguration von DB-Parametergruppen finden Sie im Amazon-RDS-Benutzerhandbuch.

Sie können mithilfe von AWS Config kontinuierlich Konfigurationsänderungen erfassen, die an Amazon-RDS-DB-Instances, -DB-Subnetzgruppen, -DB-Snapshots, -DB-Sicherheitsgruppen und -Ereignisabonnements vorgenommen werden, und das System so konfigurieren, dass Sie über Amazon Simple Notification Service (SNS) eine Änderungsbenachrichtigung erhalten. Sie können auch AWS-Config-Regeln erstellen, um zu überprüfen, ob die Amazon-RDS-Ressourcen die gewünschte Konfiguration aufweisen.

Wenn Sie Ihre DB-Instance zur Ausführung als Multi-AZ-Bereitstellung erstellen oder modifizieren, erzeugt und unterhält Amazon RDS automatisch synchron ein „Standby“-Replikat in einer anderen Availability Zone. Updates Ihrer DB-Instance werden synchron über mehrere Availability Zones in der Standby-Datenbank repliziert, damit Ihre letzten Datenbank-Updates synchronisiert und gegen einen Ausfall der DB-Instance geschützt sind. 

Während bestimmten geplanten Wartungs- bzw. Aktualisierungsarbeiten oder im unwahrscheinlichen Fall eines Ausfalls der DB-Instance oder der Availability Zone führt Amazon RDS automatisch einen Failover zur Standby-Datenbank aus, sodass die Schreib- und Lesevorgänge in Ihrer Datenbank unmittelbar nach dem Wechsel fortgesetzt werden können. Da der Namensdatensatz für Ihre DB-Instance gleich bleibt, kann Ihre Anwendung den Datenbankbetrieb ohne manuellen administrativen Eingriff fortsetzen. Mit Multi-AZ-Bereitstellungen ist die Replikation transparent. Sie interagieren nicht direkt mit dem Standby, der nicht für den Verkehr verwendet werden kann. Weitere Informationen zu Multi-AZ-Bereitstellungen finden Sie im Amazon-RDS-Benutzerhandbuch.

Availability Zones sind isolierte Standorte innerhalb einer Region, d. h., sie sind bei Ausfällen in anderen Availability Zones nicht betroffen. Jede Availability Zone wird auf ihrer eigenen physisch getrennten, unabhängigen Infrastruktur ausgeführt und ist auf hohe Zuverlässigkeit ausgelegt. Übliche Fehlerquellen wie Generatoren und Kühlanlagen werden nicht von mehreren Availability Zones geteilt. Die physische Trennung sorgt außerdem dafür, dass sogar bei äußerst seltenen Katastrophen wie Bränden, Stürmen oder Überflutungen nur eine Availability Zone betroffen ist. Availability Zones innerhalb derselben Region profitieren von einer Netzwerkverbindung mit niedrigen Latenzen.

Wenn Sie eine DB-Instance als Multi-AZ-Bereitstellung betreiben, steht die primäre Datenbank für Schreib- und Lesevorgänge in der Datenbank zur Verfügung. Zusätzlich dazu stellt Amazon RDS im Hintergrund eine "Standby"-Instance zur Verfügung, die eine stets aktuelle Replica der Primär-Instance darstellt. Bei Failover-Szenarios wird die Standby-Instance "hochgestuft". Nach dem Failover wird also die Standby-Instance zur Primär-Instance und nimmt dann Ihre Datenbank-Operationen entgegen. Zu keinem Zeitpunkt vor der Hochstufung interagieren Sie direkt mit der Standby-Instance (etwa bei Lesevorgängen). Wenn Sie den Lesedatenverkehr über die Kapazitätseinschränkungen einer einzelnen DB-Instance hinaus skalieren möchten, finden Sie weitere Informationen in den häufig gestellten Fragen zu Read Replicas.

Die Hauptvorteile einer Ausführung Ihrer DB-Instance als Multi-AZ-Bereitstellung sind die erhöhte Zuverlässigkeit und Verfügbarkeit der Datenbank. Dank ihrer erhöhten Verfügbarkeit und Fehlertoleranz sind Multi-AZ-Bereitstellungen die ideale Lösung für wichtige Produktionsumgebungen.
 

Wenn Sie Ihre DB-Instance als Multi-AZ-Bereitstellung ausführen, sind Ihre Daten im unwahrscheinlichen Fall, dass eine DB-Instance-Komponente ausfällt oder der Dienst in einer Availability Zone unterbrochen wird, sicher. Wenn beispielsweise ein Speicher-Volume Ihrer Primär-Instance ausfällt, initiiert Amazon RDS automatisch einen Failover zur Standby-Instance, wo all Ihre Datenbank-Updates in intakter Form vorliegen. Dies bietet also zusätzliche Datenbeständigkeit im Vergleich zu Standard-Bereitstellungen in einer einzelnen AZ: Hier wäre eine vom Benutzer angestoßene Wiederherstellung erforderlich, und Updates, die nach dem letztmöglichen Wiederherstellungszeitpunkt (in der Regel in den letzten fünf Minuten) durchgeführt wurden, ständen nicht zur Verfügung.

Beim Betrieb Ihrer DB-Instance als Multi-AZ-Bereitstellung profitieren Sie darüber hinaus von einer verbesserten Datenbankverfügbarkeit. Bei einem Ausfall einer Availability Zone oder DB-Instance wird die Verfügbarkeit lediglich für den Zeitraum beeinträchtigt, der für das automatische Failover benötigt wird. Die Verfügbarkeitsvorteile von Multi-AZ kommen auch bei geplanten Wartungen bzw. Aktualisierungen zum Tragen.

So werden I/O-Vorgänge in Ihrer Primär-Instance beispielsweise bei automatisierten Backups im von Ihnen bestimmten Backup-Fenster nicht mehr unterbrochen, da die Backups vom Standby-Replikat angefertigt werden. Im Fall von Patches oder Skalierungen der DB-Instance-Klasse werden diese Operationen zunächst auf dem Standby-Replikat vorgenommen, bevor das automatische Failover erfolgt. Das Ergebnis: Es kommt lediglich für die Dauer, die der automatische Failover in Anspruch nimmt, zu Einschränkungen der Verfügbarkeit.

Ein weiterer Vorteil, den die Ausführung Ihrer DB-Instance als Multi-AZ-Bereitstellung mit sich bringt, liegt darin, dass das DB-Instance-Failover automatisch erfolgt und keinen Verwaltungsaufwand mit sich bringt. Im Hinblick auf Amazon RDS bedeutet das, dass Sie nicht die DB-Instance-Ereignisse überwachen und eine manuelle Wiederherstellung der DB-Instance (über die APIs "RestoreDBInstanceToPointInTime" oder "RestoreDBInstanceFromSnapshot") anstoßen müssen, wenn es zu einem Ausfall in einer Availability Zone oder zu einem DB-Instance-Ausfall kommen sollte.

Aufgrund der synchronen Datenreplikation, die in Ihrem Auftrag durchgeführt wird, kann es zu erhöhten Latenzen im Vergleich zur standardmäßigen Bereitstellung einer DB-Instance in einer einzigen Availability Zone kommen.

Nein, mit einer Standby-Replica mit Multi-AZ können keine Leseanforderungen bearbeitet werden. Der Zweck von Multi-AZ-Bereitstellungen ist eine Verbesserung der Datenbankverfügbarkeit und -zuverlässigkeit und nicht eine Skalierung der Lesevorgänge. Die Replikation zwischen Primär- und Standby-Instance erfolgt synchron. Durch unsere Implementierung wird sichergestellt, dass Primär- und Standby-Instance konstant synchronisiert werden, gleichzeitig ist die Standby-Instance aber von Lese- oder Schreibvorgängen ausgeschlossen. Wenn Sie sich für eine Lösung zur Skalierung der Lesevorgänge interessieren, lesen Sie die häufig gestellten Fragen zu Read Replicas.

Um eine Multi-AZ-Bereitstellung für eine DB-Instance einzurichten, klicken Sie einfach auf die Option „Ja“ für „Multi-AZ-Bereitstellung“, wenn Sie eine DB-Instance mit der AWS-Managementkonsole starten.

Wenn Sie die Amazon-RDS-APIs verwenden, können Sie die API CreateDBInstance nutzen und den Parameter „Multi-AZ“ auf „true“ setzen. Um eine bestehende, standardmäßige DB-Instance (Single-AZ) in eine Multi-AZ-Bereitstellung zu konvertieren, modifizieren Sie die DB-Instance in der AWS-Managementkonsole oder verwenden Sie die API ModifyDBInstance und setzen Sie den Parameter „Multi-AZ“ auf „true“.

Für die Datenbank-Engines RDS für PostgreSQL, RDS für MySQL, RDS für MariaDB, RDS für SQL Server, RDS für Oracle und RDS für Db2 passiert Folgendes, wenn Sie Ihre Amazon-RDS-Instance von Single-AZ in Multi-AZ konvertieren möchten:

• Ein Snapshot Ihrer Primär-Instance wird erstellt.
• Eine neue Standby-Instance wird aus dem Snapshot in einer anderen Availability Zone erstellt.
• Die synchrone Replikation wird zwischen Primär- und Standby-Instances konfiguriert.

Dadurch sollte es keine Ausfallzeiten geben, wenn eine Instance von Single-AZ in Multi-AZ konvertiert wird. Möglicherweise sehen Sie jedoch eine erhöhte Latenzzeit, während die Daten im Standby-Modus aktualisiert werden, um mit dem Primärsystem Schritt zu halten.

Bei Multi-AZ-Bereitstellungen erfolgt bei den meisten gängigen Ausfallszenarien nach deren Erkennen eine automatische Wiederherstellung durch Amazon RDS, sodass Sie ohne Verwaltungsaufwand Datenbankvorgänge schnellstmöglich fortsetzen können. Amazon RDS führt in den folgenden Szenarien automatisch ein Failover durch:

• Verlust der Verfügbarkeit in der primären Availability Zone
• Verlust der Netzwerkverbindung zur Primär-Instanz
• Ausfall einer Datenverarbeitungseinheit in der Primär-Instanz
• Speicherfehler in der Primär-Instanz

Hinweis: Wenn für Multi-AZ-Bereitstellungen Vorgänge wie die Skalierung von DB-Instances oder System-Upgrades wie das Einspielen von Betriebssystem-Patches ausgelöst werden, werden diese zur Optimierung der Verfügbarkeit vor einem automatischen Failover zunächst auf das Standby-Replikat angewendet. Es kommt deshalb lediglich für die Dauer, die das automatische Failover in Anspruch nimmt, zu Einschränkungen der Verfügbarkeit. Hinweis: Bei Multi-AZ-Bereitstellungen von Amazon RDS erfolgt kein automatisches Failover als Reaktion auf Datenbankvorgänge wie lang andauernde Abfragen, gegenseitige Sperren (Deadlocks) oder Fehler aufgrund von Datenbankbeschädigungen.

Ja. Amazon RDS veranlasst ein DB-Instance-Ereignis, um Sie über den automatischen Failover zu informieren. Durch Klicken in den Bereich "Events" der Amazon RDS-Konsole oder mithilfe der API DescribeEvents können Sie Informationen zu Ereignissen in Verbindung mit Ihrer DB-Instance aufrufen. Sie können auch den Service Amazon RDS Event Notifications so konfigurieren, dass Sie bei Eintreten eines bestimmten DB-Ereignisses benachrichtigt werden.

Der Failover wird automatisch von Amazon RDS durchgeführt, damit Sie den Datenbankbetrieb schnellstmöglich und ohne Verwaltungsaufwand wieder aufnehmen können. Bei einem Failover wechselt Amazon RDS einfach den anerkannten Namensdatensatz (CNAME) für Ihre DB-Instance, sodass auf die Standby-Replica verwiesen wird, das dadurch zur neuen Primär-Instance hochgestuft wird. Wir empfehlen Ihnen, sich an bewährte Methoden zu halten und eine Funktion auf der Anwendungsebene zu implementieren, die gegebenenfalls erneut versucht, eine Datenbankverbindung herzustellen.

Failover-Vorgänge erfolgen entsprechend der Festlegung des Zeitraums zwischen dem Erkennen des Ausfalls auf der Primär-Instance und Fortsetzung von Transaktionen auf der Standby-Instance in der Regel binnen 1-2 Minuten. Die Dauer des Failovers kann auch davon abhängen, ob umfassende Transaktionen ohne Datenbank-Commit wiederhergestellt werden müssen. Für optimale Ergebnisse wird der Einsatz ausreichend großer Instance-Typen für Multi-AZ-Bereitstellungen empfohlen. AWS empfiehlt auch die Nutzung von bereitgestellten E/A-Sek.-Vorgängen mit Multi-AZ-Instances zum Sicherstellen einer schnellen, berechenbaren und einheitlichen Durchsatzleistung.

Amazon RDS führt bei einer Vielzahl von Fehlerbedingungen automatisch ein Failover durch, ohne dass Benutzer eingreifen müssen. Zusätzlich bietet Amazon RDS eine Option zum Initiieren eines Failovers beim Neustarten Ihrer Instance. Sie können auf diese Funktion über die AWS Management Console oder bei Verwendung des RebootDBInstance-API-Aufrufs zugreifen.

Bei Multi-AZ-Bereitstellungen setzen Sie einfach den Parameter „Multi-AZ“ auf „true“. Die Erstellung der synchronen Standby-Replikation und das Failover werden automatisch abgewickelt. Das bedeutet, dass Sie die Availability Zone nicht auswählen können, in der Ihre Standby-Replica bereitgestellt wird, und auch nicht die Anzahl der verfügbaren Standby-Instances verändern können (Amazon RDS erzeugt eine dedizierte Standby-Replica für jede primäre DB-Instance). Die Standby-Replica kann auch nicht für das Akzeptieren von Datenbankleseaktivitäten konfiguriert werden. Weitere Informationen zu Multi-AZ-Konfigurationen

Ja. Ihre Standby-Replica wird automatisch in einer anderen Availability Zone in derselben Region wie Ihre primäre DB-Instance bereitgestellt.

Ja, Sie können den Standort der aktuellen primären Instance mithilfe der AWS-Managementkonsole oder der DescribeDBInstances-API einsehen.

Availability Zones sind darauf ausgelegt, Netzwerkverbindungen mit niedrigen Latenzen für andere Availability Zones derselben Region bereitzustellen. Zusätzlich empfiehlt es sich eventuell, die Architektur Ihrer Anwendung und anderer AWS-Architekturen mit Redundanzen über mehrere Availability Zones anzulegen, damit Ihre Anwendung bei einem Ausfall einer einzelnen Availability Zone geschützt ist. Bei Multi-AZ-Bereitstellungen ist dies auf Datenbankebene der Fall, ohne dass hierfür ein administratives Zutun Ihrerseits erforderlich ist.

Die Interaktion mit automatisierten Backups und DB-Snapshot-Funktionalität ist bei Standardbereitstellungen in einer Single-AZ- oder Multi-AZ-Bereitstellung identisch. Wenn Sie eine Multi-AZ-Bereitstellung betreiben, werden automatisierte Backups und DB-Snapshots mithilfe der Standby-Replica erstellt, um eine E/A-Unterbrechung in der Primär-Instance zu vermeiden. Beachten Sie, dass es bei Single-AZ- oder Multi-AZ-Bereitstellungen im Verlauf von Sicherungen zu einer erhöhten E-/A-Latenz (für gewöhnlich wenige Minuten) kommen kann.

Auch das Auslösen von Wiederherstellungsvorgängen (zeitpunktbezogene Wiederherstellung oder Wiederherstellung aus einem DB-Snapshot) erfolgt bei standardmäßigen Single-AZ- und Multi-AZ-Bereitstellungen gleich. Neue DB-Instance-Bereitstellungen können mithilfe der APIs RestoreDBInstanceFromSnapshot oder RestoreDBInstanceToPointInTime erstellt werden. Diese neuen DB-Instance-Bereitstellungen können entweder Standard- oder Multi-AZ-Bereitstellungen sein, unabhängig davon, ob das Quell-Backup von einer standardmäßigen oder einer Multi-AZ-Bereitstellung aus initiiert wurde.

Lesereplikate sind eine einfachere Möglichkeit, die Vorteile der integrierten Replikationsfunktionen der unterstützten Engines zu nutzen, um bei leseintensiven Datenbank-Workloads elastisch über die Kapazitätseinschränkungen einer einzelnen DB-Instance hinaus aufzuskalieren.

Lesereplikate können mit wenigen Klicks in der AWS-Managementkonsole oder über die CreateDBInstanceReadReplica-API erstellt werden. Nach Erstellung der Read Replica werden Updates der Quell-DB-Instance unter Verwendung der nativen, asynchronen Replikation einer unterstützten Engine repliziert. Sie können mehrere Read Replicas für eine bestimmte Quell-DB-Instance erstellen und den Lesedatenverkehr Ihrer Anwendung auf diese verteilen.

Da Read Replicas die integrierte Replikation der unterstützten Engines verwenden, unterliegen sie auch deren Stärken und Einschränkungen. Das bedeutet insbesondere, dass Updates in Ihren Read Replica(s) übernommen werden, nachdem sie in der Quell-DB-Instance erfolgt sind, und dass die Verzögerung bei der Replikation erheblichen Schwankungen unterliegen kann. Lesereplikate können mit Multi-AZ-Bereitstellungen verbunden werden, um zusätzlich zu den Skalierungsvorteilen im Hinblick auf Lesevorgänge von der verbesserten Schreibverfügbarkeit der Datenbank und Datenbeständigkeit zu profitieren, die Multi-AZ-Bereitstellungen bieten.

Es gibt verschiedene Szenarien, in denen die Bereitstellung einer oder mehrerer Read Replicas für eine bestimmte Quell-DB-Instance sinnvoll ist. Häufige Gründe für die Bereitstellung einer Read Replica:

• Skalierung über die Rechen- oder E/A-Leistung einer einzelnen DB-Instance bei Datenbank-Arbeitslasten mit umfassenden Lesevorgängen. Dieser zusätzliche Lesedatenverkehr kann an eine oder mehrere Read Replicas geleitet werden.
• Unterstützung des Lesedatenverkehrs bei einer nicht verfügbaren Quell-DB-Instance. Wenn Ihre Quell-DB-Instance keine E/A-Anforderungen bearbeiten kann (z.B. aufgrund von E/A-Einschränkungen für Backups oder geplanten Wartungsarbeiten), können Sie den Lesedatenverkehr an Ihre Read Replica(s) leiten. Denken Sie in diesem Fall daran, dass die Daten in dem Lesereplikat „veraltet“ sein können, da die Quell-DB-Instance nicht verfügbar ist.
• Szenarien für Business Reporting oder Data Warehousing. Es empfiehlt sich eventuell, Anforderungen zur geschäftlichen Berichterstattung über ein Lesereplikat und nicht über Ihre primäre DB-Instance für die Produktion laufen zu lassen.
• Sie können ein Lesereplikat für die Wiederherstellung der Quell-DB-Instance verwenden, entweder in derselben AWS-Region oder in einer anderen Region.

Ja. Aktivieren Sie automatische Backups auf Ihrer DB-Instance, bevor Sie Lesereplikate hinzufügen, indem Sie den Aufbewahrungszeitraum für Backups auf einen Wert von größer als 0 setzen. Damit Lesereplikate funktionieren, müssen Backups aktiviert bleiben.

Amazon Aurora: Alle DB-Cluster.

Amazon RDS for MySQL: Alle DB-Instances unterstützen die Erstellung von Lesereplikaten. Automatische Backups müssen auf der Quell-DB-Instance für Lesereplikat-Vorgänge aktiviert sein und bleiben. Automatische Backups auf dem Replikat werden nur für Amazon-RDS-Lesereplikate mit MySQL 5.6 und höher unterstützt, jedoch nicht für Version 5.5 und darunter.

Amazon RDS for PostgreSQL: DB-Instances mit PostgreSQL Version 9.3.5 oder höher unterstützen das Erstellen von Lesereplikaten. Bestehende PostgreSQL-Instances vor Version 9.3.5 müssen auf PostgreSQL Version 9.3.5 aktualisiert werden, um die Vorteile von Amazon-RDS-Lesereplikaten nutzen zu können.

Amazon RDS for MariaDB: Alle DB-Instances unterstützen die Erstellung von Lesereplikaten. Automatische Backups müssen auf der Quell-DB-Instance für Lesereplikat-Vorgänge aktiviert sein und bleiben.

Amazon RDS für Oracle: Unterstützt für Oracle ab Version 12.1.0.2.v12 und für alle 12.2-Versionen, für die das Bring-Your-Own-License-Modell mit Oracle Database Enterprise Edition verwendet wird und die Option zur Aktivierung von Data Guard lizenziert ist.

Amazon RDS for SQL Server: Lesereplikate werden in der Enterprise Edition in der Multi-AZ-Konfiguration unterstützt, wenn die zugrunde liegende Replikationstechnologie Always-On-Verfügbarkeitsgruppen für SQL Server Version 2016 und 2017 verwendet.

Lesereplikate können binnen Minuten über die standardmäßige CreateDBInstanceReadReplica-API oder mit wenigen Schritten in der AWS-Managementkonsole erstellt werden. Beim Erstellen einer Read Replica können Sie sie durch das Spezifizieren eines SourceDBInstanceIdentifier als Read Replica kennzeichnen. Der SourceDBInstanceIdentifier ist die DB-Instance-Kennung der "Quell"-DB-Instance, aus der Sie Daten replizieren möchten. Wie bei einer standardmäßigen DB-Instance können Sie auch die Availability Zone, DB-Instance-Klasse und das bevorzugte Wartungsfenster festlegen. Die Engine-Version (z. B. PostgreSQL 9.3.5) und die Speicherzuweisung einer Read Replica werden aus der Quell-DB-Instance übernommen. 

Wenn Sie die Erstellung einer Read Replica anstoßen, fertigt Amazon RDS einen Snapshot Ihrer Quell-DB-Instance an und beginnt mit der Replikation. Das hat eine kurze Aussetzung des I/O-Datenverkehrs Ihrer Quell-DB-Instance zur Folge, wenn der Snapshot erscheınt. Diese I/O-Aussetzung dauert in der Regel nicht länger als eine Minute und wird vermieden, wenn es sich bei der DB-Instance um eine Multi-AZ-Bereitstellung handelt (bei Multi-AZ-Bereitstellungen werden Snapshots von der Standby-Instance angefertigt).

Amazon RDS arbeitet derzeit auch an einer weiteren (in Kürze verfügbaren) Optimierung, mit der Sie mehrere Read Replicas innerhalb eines 30-minütigen Fensters erstellen können, wobei alle denselben Quell-Snapshot nutzen, um die E/A-Beeinträchtigung zu minimieren (die "Aufhol"-Replizierung für jede Read Replica beginnt dann nach der Erstellung).

Verbindungen zu einem Lesereplikat können wie zu einer Standard-DB-Instance über die API DescribeDBInstance oder die AWS-Managementkonsole hergestellt werden, um den/die Endpunkt(e) für Ihr(e) Lesereplikat(e) abzurufen. Wenn Sie mehrere Read Replicas nutzen, muss Ihre Anwendung bestimmen, wie der Lesedatenverkehr auf diese verteilt wird.

Mit Amazon RDS für MySQL, MariaDB und PostgreSQL lassen sich derzeit bis zu 15 Read Replicas für eine bestimmte Quell-DB-Instance erstellen. Mit Amazon RDS für MySQL, Oracle und SQL Server lassen sich derzeit bis zu 5 Lesereplikate für eine bestimmte Quell-DB-Instance erstellen.

Ja, Amazon RDS (ausgenommen RDS for SQL Server) unterstützt jetzt Read Replicas zwischen Regionen. Die Zeitspanne zwischen dem Schreiben von Daten in die Quell-DB-Instance und dem Vorhandensein in der Read Replica hängt von der Netzwerklatenz zwischen den beiden Regionen ab.

Nein. Lesereplikate in Amazon RDS for MySQL, MariaDB, PostgreSQL, Oracle und SQL Server sind so implementiert, dass sie die native asynchrone Replikation dieser Engines verwenden. Amazon Aurora verwendet einen anderen, aber auch einen asynchronen Datenreplikationsmechanismus.

Wenn Sie mithilfe von Replikation die Schreibverfügbarkeit Ihrer Datenbank erhöhen und aktuelle Datenbank-Updates vor diversen Ausfallbedingungen schützen möchten, empfehlen wir Ihnen, Ihre DB-Instance als Multi-AZ-Bereitstellung auszuführen. Mit Read Replicas von Amazon RDS und der nativen, asynchronen Replikation der unterstützten Engines erfolgen die Schreibvorgänge in einer Read Replica erst, nachdem sie in der Quell-DB-Instance erfolgt sind, und diese Verzögerung bei der Replikation kann erheblichen Schwankungen unterliegen. 

Im Gegensatz dazu erfolgt die Replikation bei Multi-AZ-Bereitstellungen synchron, d. h., alle Datenbank-Schreibvorgänge erfolgen in der Primär- und der Standby-Instance gleichzeitig. Damit sind Ihre letzten Datenbank-Updates geschützt, da sie, falls ein Failover erforderlich wird, schon in der Standby-Instance verfügbar sind. 

Darüber hinaus ist die Replikation bei Multi-AZ-Bereitstellungen komplett verwaltet. Amazon RDS überwacht automatisch die DB-Instance auf Ausfallbedingungen oder einen Ausfall der Availability Zone hin und initiiert einen automatischen Failover zur Standby-Instance (oder im Fall von Amazon Aurora zu einer Read Replica), wenn es zu einem Ausfall kommt.

Ja. Da Multi-AZ-DB-Instances auf andere Bedürfnisse als Read Replicas ausgelegt sind, ist es durchaus sinnvoll, beide Komponenten kombiniert für Produktionsbereitstellungen zu nutzen und einer Multi-AZ-DB-Instance-Bereitstellung eine Read Replica zuzuweisen. Die Multi-AZ-"Quell"-DB-Instance bietet Ihnen eine erhöhte Schreibverfügbarkeit und eine höhere Datenbeständigkeit, während die zugeordnete Read Replica die Skalierbarkeit des Lesedatenverkehrs verbessert.

Ja. Amazon RDS for MySQL, MariaDB, PostgreSQL und Oracle ermöglichen Ihnen die Aktivierung der Multi-AZ-Konfiguration auf Read Replicas, um die Notfallwiederherstellung zu unterstützen und Ausfallzeiten durch Engine-Upgrades so kurz wie möglich zu halten.

Im Falle eines Multi-AZ-Failovers sollten alle zugeordneten und verfügbaren Read Replicas automatisch die Replikation wiederaufnehmen, nachdem das Failover abgeschlossen wurde (d. h. sie beginnen mit dem Abrufen von Updates aus der neuen Primär-Instance).

Amazon Aurora, Amazon RDS für MySQL und MariaDB: Sie können drei Read-Replica-Stufen erstellen. Ein sekundäres Lesereplikat von einem bestehenden primären Lesereplikat und ein drittes Lesereplikat von sekundären Lesereplikaten. Durch Erstellen eines sekundären Lesereplikats und dritten Lesereplikats können Sie ggf. einen Teil der Replikationslast von einer Haupt-Datenbank-Instance zu verschiedenen Lesereplikat-Stufen basierend auf Ihre Anwendungsbedürfnisse verlagern.

Bitte beachten Sie, dass ein sekundäres Lesereplikat ggf. länger hinter der Haupt-DB-Instance zurückbleibt, da es zu weiterer Replikationslatenz kommt, wenn Transaktionen von der Haupt-DB-Instance in das primäre Lesereplikat und anschließend in das sekundäre Lesereplikat repliziert werden. In ähnlicher Weise könnte das dritte Lesereplikat hinter dem sekundären Lesereplikat zurückbleiben.

Amazon RDS für Oracle und Amazin RDS für SQL Server: Lesereplikate von Lesereplikaten werden zurzeit nicht unterstützt.

Read Replicas sind darauf ausgelegt, Lesedatenverkehr zu unterstützen. Es kann allerdings auch Nutzungsszenarios geben, in denen fortgeschrittene Nutzer DDL-SQL-Statements (Data Definition Language) für ein Lesereplikat ausfüllen möchten. Beispiele hierfür wären das Hinzufügen eines Datenbank-Indexes zu einem für geschäftliche Berichterstattungen genutzten Lesereplikat, ohne dass derselbe Index zur entsprechenden Quell-DB-Instance hinzugefügt wird.

Amazon RDS for MySQL kann so konfiguriert werden, dass DDL-SQL-Statements für ein Lesereplikat erlaubt werden. Wenn Sie andere Operationen als Lesevorgänge für ein bestimmtes Lesereplikat ermöglichen möchten, modifizieren Sie die aktive DB-Parametergruppe für das Lesereplikat und setzen den Parameter „read_only“ auf „0“.

Amazon RDS for PostgreSQL unterstützt die Ausführung von DDL-SQL-Statements für ein Lesereplikat zurzeit nicht.

Ja. Weitere Informationen hierzu finden Sie im Amazon-RDS-Benutzerhandbuch.

Updates an einer Quell-DB-Instance werden automatisch in allen zugeordneten Read Replicas repliziert. Bei der asynchronen Replikationstechnologie der unterstützten Engines kann es jedoch aus verschiedenen Gründen dazu kommen, dass eine Read Replica hinter ihrer Quell-DB-Instance "hinterherhinkt". Typische Gründe hierfür sind:

• Das Schreiben von E/A-Volumen auf die Quell-DB-Instance überschreitet die Rate, mit der Änderungen an der Read Replica vorgenommen werden können. Dieses Problem tritt insbesondere auf, wenn die Rechenleistung einer Read Replica geringer als die der Quell-DB-Instance ist.
• Komplexe oder lange andauernde Transaktionen auf die Quell-DB-Instance beeinträchtigen die Replikation auf die Read Replica.
• Netzwerk-Partitionen oder Latenzen zwischen der Quell-DB-Instance und einer Read Replica

Lesereplikate unterliegen den Stärken und Einschränkungen der nativen Replikation der unterstützten Engines. Wenn Sie Lesereplikate verwenden, sollten Sie sich über die potenziellen Verzögerungen (die so genannten „Inkonsistenzen“) zwischen einem Lesereplikat und ihrer Quell-DB-Instance bewusst sein.

Sie können die Standard-API DescribeDBInstances nutzen, um eine Liste aller von Ihnen bereitgestellten DB-Instances (inklusive Lesereplikate) ausgeben zu lassen, oder einfach in der Amazon-RDS-Konsole auf die Registerkarte „DB-Instances“ klicken.

Mit Amazon RDS können Sie sehen, wie weit ein Lesereplikat hinter ihre Quell-DB-Instance zurückgefallen ist. Die Anzahl der Sekunden, die das Lesereplikat hinter dem Primären zurückgefallen ist, wird als eine Amazon-CloudWatch-Metrik („Replica-Verzögerung“) veröffentlicht, die über die AWS-Managementkonsole oder Amazon CloudWatch APIs verfügbar ist.

Bei Amazon RDS für MySQL ist die Quelle dieser Daten die gleiche wie durch den MySQL-Standardbefehl „Show Slave Status“ für das Lesereplikat angezeigt wird. Bei Amazon RDS for PostgreSQL können Sie die pg_stat_replication-Ansicht auf der Quell-DB-Instance verwenden, um die Replikationsmetriken anzuzeigen.

Amazon RDS überwacht den Replikationsstatus Ihrer Lesereplikate und aktualisiert das Feld „Replication State“ in der AWS-Managementkonsole mit der Meldung „Error“, wenn die Replikation aus einem beliebigen Grund unterbrochen wird. (Beispielweise beim Versuch von DML-Anfragen auf Ihrer Replikation, die mit den an der primären Datenbank-Instance vorgenommenen Updates in Konflikt stehen, was zu einem Replikationsfehler führen könnte.) Die Details zu dem von der MySQL-Engine gemeldeten Fehler können Sie im Feld „Replication Error“ sehen und somit anschließend entsprechende Abhilfemaßnahmen ergreifen. Im Abschnitt Fehlerbehebung bei Replikationsproblemen des Benutzerhandbuchs für Amazon RDS für MySQL oder PostgreSQL finden Sie weitere Informationen zur Fehlerbehebung bei Replikationsproblemen. 

Wurde ein Replikationsfehler behoben, ändert sich das Feld "Replication State" in "Replicating".

Für eine effektiv funktionierende Replikation empfehlen wir, Read Replicas gleich viel oder mehr Rechen- und Speicherressourcen zuzuweisen wie ihren entsprechenden Quell-DB-Instances. Andernfalls ist es wahrscheinlich, dass es zu größeren Verzögerungen bei der Replikation kommt oder dass ihre Read Replica nicht über genügend Speicherplatz zur Speicherung replizierter Updates verfügt.

Sie können ein Lesereplikat mit wenigen Schritten in der AWS-Managementkonsole oder durch Weitergabe ihrer DB-Instance-Kennung an die DeleteDBInstance-API löschen. 

Ein Replikat von Amazon Aurora (MySQL) bleibt selbst dann aktiv und verarbeitet weiterhin Lesedatenverkehr, wenn ihre zugehörige Quell-DB-Instance gelöscht wurde. Eines der Replikate im Cluster wird automatisch zur neuen Haupt-Instance hochgestuft und beginnt mit der Verarbeitung des Schreibverkehrs.

Ein Lesereplikat von Amazon RDS for MySQL oder MariaDB bleibt selbst dann aktiv und verarbeitet weiterhin Lesedatenverkehr, wenn seine zugehörige Quell-DB-Instance gelöscht wurde. Wenn Sie die Read Replica zusätzlich zur Quell-DB-Instance löschen möchten, müssen Sie die Read Replica explizit über die API DeleteDBInstance oder die AWS-Managementkonsole löschen.

Wenn Sie eine Amazon RDS for PostgreSQL-DB-Instance löschen, die über Read Replicas verfügt, werden alle Read Replicas zu eigenständigen DB-Instances umgewandelt und können dann sowohl Lese- als auch Schreibverkehr verarbeiten. Die umgewandelten DB-Instances arbeiten unabhängig voneinander. Falls Sie diese DB-Instances zusätzlich zur ursprünglichen Quell-DB-Instance löschen möchten, müssen Sie dies explizit über die DeleteDBInstance-API oder die AWS Management Console tun.

Eine Read Replica wird als standardmäßige DB-Instance zu denselben Tarifen abgerechnet. Wie bei einer standardmäßigen DB-Instance wird der Tarif pro "DB-Instance-Stunde" für eine Read Replica durch die DB-Instance-Klasse der Read Replica bestimmt. Aktuelle Preisangaben finden Sie auf der Detailseite von Amazon RDS. Der bei der Replikation von Daten zwischen Ihrer Quell-DB-Instance und der Read Replica innerhalb der selben AWS Region anfallende Datenverkehr wird Ihnen nicht in Rechnung gestellt.

Die Fakturierung für eine Read Replica beginnt, sobald diese erfolgreich erstellt wurde (d. h., wenn der Status als „aktiv“ ausgewiesen ist). Die Read Replica wird so lange nach standardmäßigen DB-Instance-Stundensätzen von Amazon RDS abgerechnet, bis Sie den Befehl ausgeben, sie zu löschen.

Enhanced Monitoring für Amazon RDS bietet Ihnen bessere Einblicke in den Zustand Ihrer Amazon-RDS-Instances. Schalten Sie einfach die Option „Enhanced Monitoring“ für Ihre Amazon-RDS-DB-Instance ein und legen Sie die Granularität fest. Enhanced Monitoring erfasst wichtige Metriken des Betriebssystems und verarbeitet Daten mit der definierten Granularität.

Für eine noch umfassendere Diagnose und Visualisierung Ihrer Datenbanklast und eine längere Datenaufbewahrungsdauer können Sie Performance Insights ausprobieren.

Enhanced Monitoring erfasst Metriken Ihrer Amazon-RDS-Instance auf Systemebene, beispielsweise CPU, Arbeitsspeicher, Dateisystem, Festplatten-I/O usw. Die vollständige Liste der Metriken kann unter Dokumentation gefunden werden.

Enhanced Monitoring unterstützt alle Amazon-RDS-Datenbank-Engines.

Enhanced Monitoring unterstützt alle Instance-Typen außer t1.micro und m1.small. Die Software nutzt CPU, Arbeitsspeicher und I/O in geringem Umfang. Für eine allgemeine Überwachung empfehlen wir, für mittlere oder größere Instances höhere Granularitäten zu verwenden. Bei Nicht-Produktions-DB-Instances lautet die Standardeinstellung für Enhanced Monitoring „off“. Sie können die Option deaktiviert lassen oder die Granularität ändern, wenn die Option aktiviert ist.

Sie können in der Konsole alle Systemmetriken und Prozessinformationen zu Ihrer Amazon-RDS-DB-Instance in einem grafischen Format anzeigen. Sie können festlegen, welche Metriken Sie für jede Instance überwachen wollen, und das Dashboard an Ihre Anforderungen anpassen.

Nein. Sie können für jede einzelne DB-Instance in Ihrem Amazon-RDS-Konto unterschiedliche Granularitäten festlegen. Außerdem können Sie wählen, für welche Instances Enhanced Monitoring aktiviert werden soll, und Sie können die Granularität aller Instances jederzeit ändern.

Sie können die Leistungswerte aller Metriken bis zu 1 Stunde in der Vergangenheit und mit einer Granularität von bis zu 1 Sekunde sehen.

Die Metriken von Amazon RDS Enhanced Monitoring werden in Ihr CloudWatch-Logs-Konto übermittelt. Sie können in CloudWatch Metrikfilter aus CloudWatch Logs erstellen und die Grafiken auf dem CloudWatch-Dashboard anzeigen. Weitere Informationen finden Sie auf der Seite von Amazon CloudWatch.

Sie sollten CloudWatch verwenden, wenn Sie historische Daten anzeigen möchten, die im Dashboard der Amazon-RDS-Konsole nicht verfügbar sind. Sie können Ihre Amazon-RDS-Instances in CloudWatch überwachen, um den Zustand Ihres gesamten AWS-Stacks an einer zentralen Stelle zu diagnostizieren. Zurzeit unterstützt CloudWatch Granularitäten von bis zu einer Minute und für niedrigere Granularitäten werden Durchschnittswerte gebildet.

Ja. Sie können in CloudWatch einen Alarm einrichten, der eine Benachrichtigung versendet, wenn sich der Zustand einer Metrik ändert. Der Alarm überwacht eine Metrik über einen bestimmten, von Ihnen definierten Zeitraum und führt eine oder mehrere Aktionen durch, die vom Wert der Metrik im Vergleich zu einem bestimmten Schwellenwert in einer Reihe von Zeiträumen abhängt. Nähere Informationen zum Erstellen von CloudWatch-Alarmen finden Sie im Entwicklerhandbuch zu Amazon CloudWatch.

Amazon RDS Enhanced Monitoring sendet eine Reihe von Metriken in der Form von JSON-Inhalten, die in Ihr CloudWatch-Logs-Konto geliefert werden. Die JSON-Inhalte werden in der Granularität übermittelt, die zuletzt für die Amazon-RDS-Instance konfiguriert wurde.

Es gibt zwei Methoden, die Metriken über ein Dashboard oder eine Anwendung eines Drittanbieters zu beziehen. Überwachungs-Tools können CloudWatch-Logs-Abonnements verwenden, um für Metriken einen Feed fast in Echtzeit einzurichten. Als Alternative können Sie Filter in CloudWatch Logs verwenden, um Metriken an CloudWatch zu übertragen und Ihre Anwendung in CloudWatch zu integrieren. Weitere Informationen finden Sie in der Dokumentation zu Amazon CloudWatch.

Da Enhanced Monitoring JSON-Inhalte in ein Protokoll in Ihrem CloudWatch Logs-Konto übermittelt, können Sie den Aufbewahrungszeitraum ebenso wie bei jedem anderen CloudWatch Logs-Stream festlegen. Der Standardzeitraum für die Aufbewahrung beträgt für Enhanced Monitoring in CloudWatch Logs 30 Tage. Informationen zum Einstellen des Aufbewahrungszeitraums finden Sie im Amazon-CloudWatch-Entwicklerhandbuch.

Da die Metriken in CloudWatch Logs aufgenommen werden, sind die Kosten von den CloudWatch Logs-Gebühren für Datenübertragung und -speicherung abhängig, nachdem Sie das kostenlose Kontingent für CloudWatch Logs aufgebraucht haben. Preisinformationen finden Sie hier. Der Umfang der übertragenen Daten für eine Amazon-RDS-Instance ist direkt proportional zur definierten Granularität für Enhanced Monitoring. Administratoren können in ihren Konten unterschiedliche Granularitäten für unterschiedliche Instances einstellen.

Das ungefähre Volumen der durch Enhanced Monitoring für eine Instance in CloudWatch Logs übertragenen Daten ist wie folgt:

Amazon-RDS-Proxy ist eine vollständig verwaltete, hochverfügbare Datenbank-Proxy-Funktion für Amazon RDS. RDS Proxy macht Anwendungen skalierbarer, widerstandsfähiger gegen Datenbankausfälle und sicherer.

Amazon-RDS-Proxy ist eine vollständig verwaltete, hochverfügbare und anwenderfreundliche Datenbank-Proxy-Funktion von Amazon RDS, mit der sich folgende Aspekte Ihrer Anwendung verbessern lassen: 1) bessere Skalierbarkeit durch das Poolen und Teilen von Datenbankverbindungen; 2) höhere Verfügbarkeit durch das Reduzieren der Failover-Dauer für Datenbanken um bis zu 66 % und die Aufrechterhaltung von Datenbankverbindungen bei einem Failover; und 3) höhere Sicherheit durch das optionale Erzwingen der Authentifizierung mit AWS IAM für Datenbanken und das sichere Speichern von Anmeldedaten in AWS Secrets Manager.

Abhängig von Ihrer Workload kann Amazon RDS Proxy die Netzwerklatenz bei der Reaktion auf Abfragen oder Transaktionen um durchschnittlich 5 Millisekunden steigern. Wenn eine Latenz von 5 Millisekunden zu viel für Ihre Anwendung ist oder Sie die Verbindungsverwaltung und andere Funktionen von RDS Proxy nicht benötigen, ist eine direkte Verbindung Ihrer Anwendungen mit dem Datenbank-Endpunkt vorzuziehen.

Amazon-RDS-Proxy ermöglicht neue Ansätze bei der Entwicklung zeitgemäßer Serverless-Anwendungen, welche die Leistung und Einfachheit relationaler Datenbanken ausnutzen. Erstens ermöglicht RDS-Proxy die effiziente Skalierung serverloser Anwendungen durch das Poolen und Wiederverwenden von Datenbankverbindungen. Zweitens müssen Anmeldedaten für die Datenbank bei RDS Proxy nicht mehr über Ihren Lambda-Code gehandhabt werden. Sie können die mit Ihrer Lambda-Funktion verknüpfte IAM-Ausführungsrolle für die Authentifizierung bei RDS Proxy und Ihrer Datenbank verwenden. Drittens müssen Sie keine neue Infrastruktur oder neuen Code verwalten, um das volle Potenzial serverloser Anwendungen in Verbindung mit relationalen Datenbanken zu nutzen. RDS Proxy ist vollständig verwaltet und skaliert seine Kapazität automatisch auf Basis der Anforderungen Ihrer Anwendung.

RDS Proxy ist verfügbar für Amazon Aurora mit MySQL-Kompatibilität, Amazon Aurora mit PostgreSQL-Kompatibilität, Amazon RDS für MariaDB, Amazon RDS für MySQL, Amazon RDS für PostgreSQL und Amazon RDS für SQL Server. Eine Liste unterstützter Regionen und Engine-Versionen finden Sie im Benutzerhandbuch von Amazon Aurora oder im Benutzerhandbuch von Amazon RDS.

Amazon RDS Proxy lässt sich mit nur wenigen Klicks in der Amazon-RDS-Konsole für Ihre Amazon-RDS-Datenbank aktivieren. Bei der Aktivierung von RDS Proxy geben Sie die VPC und Subnetze an, von denen aus Sie auf RDS Proxy zugreifen möchten. Als Lambda-Nutzer können Sie mit nur wenigen Klicks in der Lambda-Konsole Amazon-RDS-Proxy für Ihre Amazon-RDS-Datenbank aktivieren und eine Lambda-Funktion für den Zugriff einrichten.

Ja. Sie können Amazon RDS Proxy APIs verwenden, um einen Proxy zu erstellen, und dann Zielgruppen festlegen, über die Sie den Proxy mit bestimmten Datenbank-Verbindungen oder Clustern verknüpfen. Beispiel:

aws rds create-db-proxy 
        --db-proxyname '...' 
        --engine-family <mysql|postgresql>       
        --auth [{}, {}] 
        --role-arn '...'
        --subnet-ids {}
        --require-tls <true|false>
        --tags {}
aws rds register-db-proxy-targets 
        --target-group-name '…'
        --db-cluster-identifier  '…'
        --db-instance-identifier '…'

Trusted-Language-Erweiterungen (TLE) für PostgreSQL ermöglichen es den Entwicklern, leistungsstarke PostgreSQL-Erweiterungen zu erstellen und sie sicher auf Amazon Aurora und Amazon RDS auszuführen. Auf diese Weise verkürzt TLE die Zeit bis zur Markteinführung und entlastet Datenbankadministratoren bei der Zertifizierung von benutzerdefiniertem und Code von Drittanbietern für die Verwendung in produktiven Datenbank-Workloads. Sie können weitergehen, sobald Sie entschieden haben. dass eine Erweiterung Ihre Bedürfnisse erfüllt. Mit TLE können unabhängige Softwareanbieter (ISV) den Kunden neue PostgreSQL-Erweiterungen anbieten, die auf Aurora und Amazon RDS ausgeführt werden.

PostgreSQL-Erweiterungen werden im gleichen Prozess-Zeitraum ausgeführt, um eine hohe Leistung sicherzustellen. Jedoch könnten Erweiterungen Software-Fehler haben, die einen Absturz der Datenbank verursachen können.

TLE für PostgreSQL bietet mehrere Schutzschichten zur Minderung dieses Risikos. TLE wurde entwickelt, um den Zugriff auf System-Ressourcen einzuschränken. Die Rolle rds_superuser kann festlegen, wer zur Installation von bestimmten Erweiterungen berechtigt ist. Jedoch können diese Änderungen nur über die TLE-API durchgeführt werden. TLE soll die Auswirkung eines Erweiterungsfehlers auf eine einzelne Datenbank-Verbindung begrenzen. Neben diesen Schutzmaßnahmen soll TLE den Datenbank-Administratoren (DBAs) in der Rolle rds_superuser präzise Online-Kontrolle darüber zur Verfügung stellen, wer Erweiterungen installieren kann und sie können ein Berechtigungsmodel für die Ausführung erstellen.

Nur Nutzer mit ausreichenden Zugriffsrechten können Erweiterungen ausführen und erstellen, und zwar mit dem Befehl „CREATE EXTENSION (ERWEITERUNG ERSTELLEN)“ auf einer TLE-Erweiterung. DBAs können „PostgreSQL-Hooks“ zulassen, die für höher entwickelte Systeme erforderlich sind, welche die interne Verhaltensweise der Datenbank ändern und üblicherweise die höheren Zugriffsrechte erfordern.

TLE für PostgreSQL ist für die PostgreSQL-kompatible Edition von Amazon Aurora und Amazon RDS auf PostgreSQL in den Versionen 14.5 und höher verfügbar. TLE selbst wird als eine PostgreSQL-Erweiterung implementiert und Sie können sie von der Rolle rds_superuser ähnlich wie andere Erweiterungen aktivieren, die auf Aurora und Amazon RDS unterstützt werden.

Sie können TLE für PostgreSQL in PostgreSQL 14.5 oder höher in Amazon Aurora und Amazon RDS ausführen.  

TLE für PostgreSQL ist derzeit in allen AWS-Regionen (mit Ausnahme der AWS-China-Regionen) und in den AWS-GovCloud-Regionen verfügbar.

TLE für PostgreSQL steht Aurora- und Amazon-RDS-Kunden ohne Zusatzkosten zur Verfügung.

Aurora und Amazon RDS unterstützen über 85 kuratierte PostgreSQL-Erweiterungen. AWS verwaltet die Sicherheitsrisiken für jede einzelne dieser Erweiterungen unter dem AWS-Modell der geteilten Verantwortung. Die Erweiterung, die TLE für PostgreSQL implementiert, ist Teil dieser Erweiterungen. Erweiterungen, die Sie schreiben oder von Drittanbietern erhalten und in TLE installieren, werden als Teil Ihres Anwendungscodes angesehen. Sie sind für die Sicherheit Ihrer Anwendungen verantwortlich, die TLE-Erweiterungen verwenden.

Sie können Entwicklerfunktionen erstellen, wie eine Bitmap-Komprimierung und differenzierten Datenschutz (wie öffentlich zugängliche statistische Anfragen, die die Privatsphäre der Einzelpersonen schützen).

TLE für PostgreSQL unterstützt derzeit JavaScript, PL/pgSQL, Perl, und SQL.

Sobald die Rolle rds_superuser TLE für PostgreSQL aktiviert, können Sie TLE-Erweiterungen mit dem SQL-Befehl ERWEITERUNG ERSTELLEN von einem beliebigen PostgreSQL-Kunden aus (wie psql) bereitstellen. Das ist so ähnlich wie die Erstellung einer benutzerdefinierten Funktion, die in einer prozeduralen Sprache wie PL/pgSQL oder PL/Perl geschrieben wurde. Sie können kontrollieren, welche Benutzer die Berechtigung zur Bereitstellung von TLE-Erweiterungen haben und bestimmte Erweiterungen verwenden dürfen.

TLE für PostgreSQL greift auf Ihre PostgreSQL-Datenbank nur über die TLE-API zu. Zu den von TLE unterstützen vertrauenswürdigen Sprachen gehören alle Funktionen der Programmierschnittstelle des PostgreSQL-Servers (SPI) und die Unterstützung für PostgreSQL-Hooks, einschließlich des Hooks „Passwort überprüfen“.

Sie können mehr über das Projekt von TLE für PostgreSQL auf der offiziellen TLE-GitHub-Website erfahren.

Blau/Grün-Bereitstellungen von Amazon RDS sind verfügbar in Amazon Aurora MySQL-Compatible Edition, Amazon Aurora PostgreSQL-Compatible Edition, Amazon RDS for MySQL, Amazon RDS for MariaDB, and Amazon RDS for PostgreSQL. 

Blau/Grün-Bereitstellungen von Amazon RDS stehen in Versionen 5.6 und höher für die Amazon-Aurora-MySQL-kompatiblen Edition, Versionen 5.7 und höher von RDS für MySQL, und RDS für Versionen MariaDB 10.2 und höher zur Verfügung. Blue/Green-Bereitstellungen werden auch für Amazon Aurora PostgreSQL-Compatible Edition und Amazon RDS for PostgreSQL für die 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 unterstützt. Erfahren Sie mehr über verfügbare Versionen in der Amazon Aurora und Amazon-RDS-Dokumentation. 

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.

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. 2x so viel für die Ausführung von Workloads auf der DB-Instance für die Lebensdauer der Blau/Grün-Bereitstellung.

Beispiel: Sie führen gerade RDS für die Datenbank von MySQL 5.7 bei zwei r5.2xlarge db.Instances einer primären Datenbank-Instance und eine Read Replica in AWS-Region USA-Ost-1 mit einer Multi-AZ-Konfiguration (MAZ) aus. Jede einzelne der r5.2xlarge db.Instances ist für 20 GB Allzweck-Speicher des Elastic Block Storage (EBS) von Amazon konfiguriert. Sie erstellen einen Klon der Blau-Instance-Topologie mit Blau/Grün-Bereitstellungen von Amazon RDS, führen ihn 15 Tage (360 Stunden) lang aus und Sie löschen anschließend die Blau-Instances nach erfolgreicher Umschaltung. Die Blau-Instance kostet 1 387 USD für 15 Tage bei On-Demand-Rate von 1,926 USD/Std. (Instance + EBS-Kosten). Die Gesamtkosten für die Nutzung von Blau/Grün-Bereitstellungen für diese 15 Tage betragen 2 774 USD. Das ist doppelt so teuer wie die Ausführung von Blau-Instances für diesen Zeitraum.

Mit Blau/Grün-Bereitstellungen von Amazon RDS können Sie Datenbank-Änderungen sicherer, einfacher und schneller vornehmen. Das sind z. B. Updates 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 Produktionsumgebung, indem der Datenverkehr an die kürzlich hochgestufte Umgebung umgeleitet wird. Blau/Grün-Bereitstellungen aktivieren Schreibvorgänge in der Grün-Umgebung nach Abschluss der Umstellung. Dadurch wird gewährleistet, dass während der Umstellung keine Daten verloren gehen.

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.

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.

Der Integritätsschutz der Umschaltung der Blau/Grün-Bereitstellungen von Amazon RDS blockiert Schreibvorgänge bei Ihrer Blau- und Grün-Umgebung bis Ihre Grün-Umgebung vor der Umschaltung aufholt. Die Blau/Grün-Bereitstellungen führen auch Zustandsprüfungen Ihrer primären Umgebung und den Replikaten in Ihrer Blau- und Grün-Umgebung durch. Sie führen auch Zustandsprüfungen der Replikate durch. Zum Beispiel, um festzustellen, ob das Replikat den Betrieb eingestellt hat oder ob irgendwelche Fehler aufgetreten sind. Sie erkennen lang laufende Transaktionen zwischen Ihren blauen und grünen Umgebungen. Sie können die maximal tolerierbare Ausfallzeit festlegen, die bis zu 30 Sekunden betragen kann. Wenn Ihre laufende Transaktion diesen Wert überschreitet, wird die Umstellung abgebrochen.

Nein, Blau/Grün-Bereitstellungen von Amazon RDS unterstützen keine globalen Datenbanken, Amazon-RDS-Proxy, regionenübergreifende Lesereplikate oder kaskadierte Lesereplikate.

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.

MySQL schützt Benutzer vor Datenverlust, indem es Daten in 16 KB-Seiten im Speicher zweimal in den dauerhaften Speicher schreibt – zuerst in den „Doublewrite-Buffer“ und dann in den Tabellenspeicher. Amazon-RDS-optimierte Schreibvorgänge schreiben Ihre 16 KiB großen Datenseiten direkt in Ihre Datendateien – zuverlässig und dauerhaft in einem Schritt mit dem Feature Torn Write Prevention von AWS Nitro System.

Amazon RDS Optimized Writes sind für MySQL-Hauptversion 8.0.30 und höher verfügbar.

Amazon RDS Optimized Writes sind in db.r6i- und db.r5b-Instances verfügbar. Sie sind in allen Regionen verfügbar, in denen diese Instances verfügbar sind, mit Ausnahme der AWS-China-Regionen.

Nein. Die MySQL-kompatible Edition von Amazon Aurora vermeidet bereits die Verwendung des „Doublewrite-Buffers“. Amazon Aurora repliziert stattdessen Daten auf sechs Wegen über drei Availability Zones (AZs) und verwendet einen Quorum-basierten Ansatz, um Daten dauerhaft zu schreiben und danach korrekt zu lesen.

Zurzeit unterstützt diese erste Version nicht die Aktivierung von Amazon-RDS-optimierten Schreibvorgängen für Ihre bestehenden Datenbank-Instances, selbst wenn die Instance-Klasse optimierte Schreibvorgänge unterstützt.

Amazon-RDS-optimierte Schreibvorgänge sind für Kunden von RDS für MySQL ohne zusätzliche Kosten verfügbar.

Workloads, die temporäre Objekte in MySQL und MariaDB zur Abfrageverarbeitung nutzen, profitieren von Amazon RDS Optimized Reads. Optimized Reads legt temporäre Objekte auf dem NVMe-basierten Instance-Speicher der Datenbankinstance ab, statt auf dem Amazon-Elastic-Block-Store-Volume. Dadurch kann die Bearbeitung komplexer Abfragen um bis zu 2x beschleunigt werden.

Amazon RDS Optimized Reads ist für RDS für MySQL in den MySQL-Versions 8.0.28 und höher und in RDS für MariaDB in den MariaDB-Versionen 10.4.25, 10.5.16, 10.6.7 und höher verfügbar.

Amazon RDS Optimized Reads ist in allen Regionen verfügbar, in denen db.r5d-, db.m5d-, db.r6gd- und db.m6gd-, X2idn- und X2iedn-Instances verfügbar sind. Weitere Informationen finden Sie in der Dokumentation zu den DB-Instance-Klassen von Amazon RDS.

Kunden sollten Amazon-RDS-optimierte Lesevorgänge verwenden, wenn sie Workloads haben, die komplexe Abfragen, allgemeine Analysen oder komplizierte Gruppen, Sortierungen, Hash-Aggregationen, Joins mit hoher Last und Common Table Expressions (CTEs) erfordern. Solche Anwendungsfälle führen zur Erstellung temporärer Tabellen, die es optimierten Lesevorgängen ermöglichen, die Abfrageverarbeitung Ihrer Workloads zu beschleunigen.

Ja, Kunden können ihre bestehende Amazon-RDS-Datenbank konvertieren, um Amazon-RDS-optimierte Lesevorgänge zu verwenden, indem sie ihren Workload in eine Instance verschieben, für die Amazon-RDS-optimierte Lesevorgänge aktiviert sind. Optimized Reads ist auch standardmäßig für alle unterstützten Instance-Klassen verfügbar. Wenn Sie Ihre Workload auf db.r5d-, db.m5d-, db.r6gd-, db.m6gd-, X2Idn- und X2iedn-Instances ausführen, profitieren Sie bereits von optimierten Lesevorgängen.