F: Was ist Amazon Aurora?

Amazon Aurora ist eine relationale Datenbank-Engine, die die Geschwindigkeit und Zuverlässigkeit einer hochwertigen kommerziellen Datenbank mit der Wirtschaftlichkeit einer Open Source-Datenbank verbindet. Amazon Aurora MySQL bietet bis zu fünfmal so viel Leistung wie MySQL und erfordert keine Änderungen an den meisten MySQL-Anwendungen. Analog dazu bietet Amazon Aurora PostgreSQL bis zu dreimal so viel Leistung wie PostgreSQL. Amazon RDS verwaltet Ihre Amazon Aurora-Datenbanken und verarbeitet zeitaufwendige Aufgaben wie Bereitstellung, Patches, Backup, Wiederherstellung, Fehlererkennung und Reparatur. Sie zahlen eine einfache Monatsgebühr für jede Amazon Aurora-Datenbank-Instance, die Sie verwenden. Es gibt keine Vorabkosten oder langfristige Verpflichtungen.

F: Was bedeutet "MySQL-kompatibel"?

"MySQL-kompatibel" bedeutet, dass der Großteil des Codes, der Anwendungen und der Tools, die Sie heute bei MySQL-Datenbanken verwenden, mit geringfügigen oder ohne Änderungen in Aurora eingesetzt werden können. Die Amazon Aurora-Datenbank-Engine ist so konzipiert, dass sie bei Verwendung der InnoDB-Speicher-Engine übertragungskompatibel mit MySQL 5.6 ist. Einige MySQL-Funktionen, etwa die MyISAM-Speicher-Engine, sind mit Amazon Aurora nicht verfügbar.

F: Was bedeutete "PostgreSQL-kompatibel"?

"PostgreSQL-kompatibel" bedeutet, dass der Großteil des Codes, der Anwendungen und der Tools, die Sie heute bei PostgreSQL-Datenbanken verwenden, mit geringfügigen oder ohne Änderungen in Aurora eingesetzt werden kann. Die Amazon Aurora-Datenbank-Engine ist so konzipiert, dass sie mit PostgreSQL 9.6 übertragungskompatibel ist. Sie unterstützt dieselben PostgreSQL-Erweiterungen, die von RDS für PostgreSQL 9.6 unterstützt werden. Dadurch können Anwendungen leicht zwischen den beiden Engines ausgetauscht werden.  

F: Wie kann ich Amazon Aurora testen?

Wenn Sie Amazon Aurora ausprobieren möchten, melden Sie sich bei der AWS-Konsole an und wählen Sie in der Kategorie Database die Option RDS und dann Amazon Aurora als Datenbank-Engine.

F: Wie viel kostet Amazon Aurora?

Auf unserer Seite mit der Preisübersicht finden Sie die aktuellen Preisinformationen.

F: Amazon Aurora repliziert jeden Block meines Datenbank-Volume sechsfach und in drei Availability Zones. Bedeutet das, dass der tatsächliche Preis für den Speicher drei- oder sechsmal so hoch sein wird, wie das auf der Seite mit der Preisübersicht Angezeigte?

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

F: In welchen AWS-Regionen ist Amazon Aurora verfügbar?

Aktuelle Informationen zu Regionen und Preisen finden Sie in unserer Preisübersicht.

F: Wie kann ich von MySQL zu Amazon Aurora migrieren, und umgekehrt?

Sie haben mehrere Möglichkeiten. Sie können das Standard-mysqldump-Hilfsprogramm für den Export von Daten aus MySQL verwenden, und das mysqlimport-Hilfsprogramm für den Import von Daten in Amazon Aurora – und umgekehrt. Bei Verwendung der AWS Management Console können Sie für die Migration eines RDS-MySQL-DB-Snapshots zu Amazon Aurora auch die DB-Snapshot-Migrationsfunktion von Amazon RDS nutzen. Die Migration ist bei den meisten Kunden innerhalb einer Stunde abgeschlossen. Die Dauer hängt jedoch vom Format und der Datenmenge ab. Weitere Informationen finden Sie im Amazon Aurora-Handbuch zum Datenexport und -import.

F: Wie kann ich von PostgreSQL zu Amazon Aurora migrieren und umgekehrt?

Sie haben mehrere Möglichkeiten. Sie können das Standard-pg_dump-Hilfsprogramm für den Export von Daten aus PostgreSQL verwenden, und das pg_restore-Hilfsprogramm für den Import von Daten in Amazon Aurora – und umgekehrt. Bei Verwendung der AWS-Managementkonsole können Sie für die Migration eines RDS-PostgreSQL 9.6-DB-Snapshots zu Amazon Aurora auch die DB-Snapshot-Migrationsfunktion von Amazon RDS nutzen. Die Migration ist bei den meisten Kunden innerhalb einer Stunde abgeschlossen. Die Dauer hängt jedoch vom Format und der Datenmenge ab. Weitere Informationen finden Sie im Amazon Aurora-Handbuch zum Datenexport und -import.

F: Ist Amazon Aurora Teil des kostenlosen AWS-Nutzungskontingents?

Nein, derzeit nicht. Das kostenlose AWS-Nutzungskontingent für Amazon RDS bietet Vorteile für Micro DB-Instances. Derzeit unterstützt Amazon Aurora Micro DB-Instances nicht. Auf unserer Seite mit der Preisübersicht finden Sie die aktuellen Preisinformationen.

F: Was sind E/A-Vorgänge in Amazon Aurora und wie werden sie berechnet?

E/A-Vorgänge sind Ein- und Ausgabe-Operationen, die die Aurora-Datenbank-Engine in ihrer SSD-basierten virtualisierten Speicherebene durchführt. Jede Seitenleseoperation zählt als E/A-Vorgang. Die Aurora-Datenbank-Engine führt Lesevorgänge in der Speicherebene aus, um Datenbankseiten abzurufen, die nicht im Puffercache vorhanden sind. Jede Datenbankseite entspricht 16 KB in Aurora MySQL und 8 KB in Aurora PostgreSQL.

Aurora ist so konzipiert, dass es unnötige E/A-Vorgänge eliminiert, so die Kosten senkt und sicherstellt, dass die Ressourcen für Lese-/Schreibvorgänge verfügbar sind. Schreib-E/A-Vorgänge werden nur genutzt, wenn Transaktionsprotokoll-Aufzeichnungen in die Speicherebene übertragen werden, um Schreibvorgänge dauerhaft zu machen. Schreib-E/A-Vorgänge werden in Einheiten von 4 KB gezählt. Eine Transaktionsprotokoll-Aufzeichnung mit 1024 Bytes beispielsweise zählt als ein E/A-Vorgang. Gleichzeitige Schreibvorgänge, deren Transaktionsprotokoll weniger als 4 KB hat, können jedoch zur Optimierung der E/A-Nutzung durch die Aurora-Datenbank-Engine zusammengefasst werden. Anders als herkömmliche Datenbank-Engines überträgt Amazon Aurora nie modifizierte Datenbankseiten zur Speicherebene, was die E/A-Nutzung weiter senkt.

Der Umfang der E/A-Vorgänge-Nutzung durch Ihre Aurora-Instance wird in der AWS-Konsole angezeigt. Sie finden die E/A-Nutzung im RDS-Abschnitt der Konsole. Wählen Sie in Ihrer Instance-Liste die Aurora-Instances und suchen Sie dann im Überwachungs-Abschnitt die Metriken "Billed read operations" (In Rechnung gestellte Lesevorgänge) und "Billed write operations" (In Rechnung gestellte Schreibvorgänge).

F: Muss ich Client-Treiber ändern, um Amazon Aurora PostgreSQL verwenden zu können?

Nein, Amazon Aurora funktioniert mit standardmäßigen PostgreSQL-Datenbanktreibern.

F: Was ist Amazon Aurora Serverless?

Bei der re:Invent 2017 haben wir die Vorschau von Amazon Aurora Serverless angekündigt, einer neuen Konfiguration der MySQL-kompatiblen Version, die Zeit, Aufwand und Kosten spart, indem die Datenbankkapazität je nach Anforderung Ihrer Anwendung vertikal herauf- oder herunterskaliert wird.

F: Was sind die ersten Schritte zum Start mit Amazon Aurora Serverless?

Amazon Aurora Serverless steht nun als Vorschau für die MySQL-kompatible Version von Amazon Aurora zur Verfügung. Registrieren Sie sich hier für die Teilnahme. Wann die Version allgemein verfügbar wird, wird zu einem späteren Zeitpunkt bekannt gegeben.

F: Was bedeutet "fünffache Leistung von MySQL"?

Durch die weitgehende Integration der Datenbank-Engine in eine SSD-gestützte virtualisierte Speicherebene, die eigens für Datenbankarbeitslasten geschaffen wurde, erzielt Amazon Aurora eine signifikant höhere Leistung als MySQL. Es reduziert Schreibvorgänge in das Speichersystem, minimiert Sperrkonflikte und eliminiert Verzögerungen aufgrund von Datenbankprozess-Threads. Unsere Tests mit SysBench auf r3.8xlarge-Instances haben ergeben, dass Amazon Aurora über 500 000 SELECTs/s und 100 000 Updates/s liefert. Das ist fünfmal so viel, wie MySQL bei Verwendung desselben Benchmarks auf derselben Hardware liefert. Detaillierte Anleitungen zu diesem Benchmark und seiner Replikation finden Sie im Amazon Aurora MySQL-Handbuch zum Leistungs-Benchmarking

F: Was bedeutet "dreifache Leistung von PostgreSQL"?

Durch die völlige Integration der Datenbank-Engine in eine SSD-gestützte virtualisierte Speicherebene, die eigens für Datenbankarbeitslasten geschaffen wurde, erzielt Amazon Aurora eine signifikant höhere Leistung als PostgreSQL. Es reduziert Schreibvorgänge in das Speichersystem, minimiert Sperrkonflikte und eliminiert Verzögerungen aufgrund von Datenbankprozess-Threads. Unsere Tests mit SysBench auf r4.16xlarge-Instances haben ergeben, dass Amazon Aurora mehr als dreimal so viele SELECTs/s und UPDATEs/s liefert wie PostgreSQL bei Verwendung desselben Benchmarks auf derselben Hardware. Detaillierte Anleitungen zu diesem Benchmark und seiner Replikation finden Sie im Amazon Aurora PostgreSQL-Handbuch zum Leistungs-Benchmarking.

F: Wie kann ich meine Datenbankarbeitslast für Amazon Aurora MySQL optimieren?

Amazon Aurora ist so konzipiert, dass es mit MySQL 5.6 kompatibel ist. Daher können vorhandene MySQL-Anwendungen und -Tools ohne Änderung ausgeführt werden. Ein Bereich, in dem Amazon Aurora gegenüber MySQL deutlich bessere Leistung liefert, sind gleichzeitige Verarbeitungslasten. Zur Optimierung Ihres Verarbeitungslastdurchsatzes in Amazon Aurora empfehlen wir, Ihre Anwendungen so zu konstruieren, dass eine große Menge gleichzeitiger Abfragen und Transaktionen ausgeführt wird.

F: Wie kann ich meine Datenbankarbeitslast für Amazon Aurora PostgreSQL optimieren?

Amazon Aurora ist so konzipiert, dass es mit PostgreSQL 9.6 kompatibel ist. Daher können vorhandene PostgreSQL-Anwendungen und -Tools ohne Änderung ausgeführt werden. Ein Bereich, in dem Amazon Aurora gegenüber PostgreSQL deutlich bessere Leistung liefert, sind gleichzeitige Verarbeitungslasten. Zur Optimierung Ihres Verarbeitungslastdurchsatzes in Amazon Aurora empfehlen wir, Ihre Anwendungen so zu konstruieren, dass eine große Menge gleichzeitiger Abfragen und Transaktionen ausgeführt wird.

F: Was sind die unteren und oberen Speicherplatzlimits einer Amazon Aurora-Datenbank?

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

F: Wie skaliere ich die mit meiner Amazon Aurora-DB-Instance verbundenen Datenverarbeitungsressourcen?

Sie können die Ihrer DB-Instance zugewiesenen Rechenressourcen über die AWS-Managementkonsole skalieren, indem Sie die gewünschte DB-Instance auswählen und auf die Schaltfläche "Modify" klicken. Speicher- und CPU-Ressourcen können durch eine Änderung der DB-Instance-Klasse modifiziert werden.

Alle gewünschten Änderungen der DB-Instance-Klasse erfolgen während des von Ihnen festgelegten Wartungszeitfensters. Alternativ können Sie einen "ApplyImmediately"-Schalter setzen, um die angeforderte Skalierung sofort durchzuführen. Beide Optionen wirken sich ein paar Minuten lang auf die Verfügbarkeit aus, solange die Skalierung durchgeführt wird. Beachten Sie, dass in diesem Fall alle anderen noch ausstehenden Systemänderungen ebenfalls durchgeführt werden.

F: Wie aktiviere ich Backups für meine DB-Instance?

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

F: Kann ich DB-Snapshots erstellen und solange aufbewahren, wie ich möchte?

Ja. Das Erstellen von Snapshots wirkt sich nicht auf die Leistung aus. Beachten Sie, dass für die Datenwiederherstellung aus DB-Snapshots die Erstellung einer neuen DB-Instance erforderlich ist.

F: Was ist bei einem Ausfall meiner Datenbank mein Wiederherstellungspfad?

Amazon Aurora verwaltet automatisch 6 Kopien Ihrer Daten in drei verschiedenen Availability Zones und versucht automatisch, Ihre Datenbank in einer fehlerfreien AZ ohne Datenverlust wiederherzustellen. Im unwahrscheinlichen Fall, dass Ihre Daten im Amazon Aurora-Speicher nicht verfügbar sind, können Sie sie aus einem DB-Snapshot wiederherstellen oder eine zeitpunktbezogene Wiederherstellung auf eine neue Instance durchführen. Beachten Sie, dass der späteste wiederherstellbare Zeitpunkt bei einer zeitpunktbezogenen Wiederherstellung bis zu 5 Minuten zurückliegt.

F: Was passiert mit meinen automatisierten Sicherungen und DB-Snapshots, wenn ich meine DB-Instance lösche?

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

F: Kann ich meine Snapshots für andere AWS-Konten freigeben?

Ja. Aurora bietet Ihnen die Möglichkeit, Snapshots Ihrer Datenbanken zu erstellen, die Sie später zum Wiederherstellen einer Datenbank verwenden können. Sie können einen Snapshot für ein anderes AWS-Konto freigeben und der Besitzer des Empfängerkontos kann Ihren Snapshot verwenden, um eine Datenbank wiederherzustellen, die Ihre Daten enthält. Sie können Ihre Snapshots sogar öffentlich zugänglich machen, sodass jeder eine Datenbank mit Ihren (öffentlichen) Daten wiederherstellen kann. Sie können diese Funktion zum Freigeben von Daten für Ihre verschiedenen Umgebungen (Produktion, Entwicklung/Test, Staging usw.) verwenden, für die unterschiedliche AWS-Konten verwendet werden. Außerdem können Sie Sicherungskopien all Ihrer Daten sicher in einem separaten Konto speichern, falls es bei Ihrem AWS-Hauptkonto einmal zu Problemen kommt.

F: Werden mit freigegebene Snapshots in Rechnung gestellt?

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

F: Kann ich automatische Snapshots freigeben?

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

F: Für wie viele Konten kann ich meine Snapshots freigeben?

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

F: In welchen Regionen kann ich meine Aurora-Snapshots freigeben?

Sie können Ihre Aurora-Snapshots in allen AWS-Regionen freigeben, in denen Aurora verfügbar ist.

F: Kann ich meine Aurora-Snapshots in unterschiedlichen Regionen freigeben?

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

F: Kann ich verschlüsselte Aurora-Snapshots freigeben?

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

F: Wie verbessert Amazon Aurora die Fehlertoleranz meiner Datenbank bei Datenträgerfehlern?

Amazon Aurora trennt automatisch Ihr Datenbank-Volume in 10 GB-Segmente, die auf vielen unterschiedlichen Datenträgern untergebracht sind. Jeder 10 GB-Block Ihrer Datenbank wird sechsfach und in drei Availability Zones repliziert. Amazon Aurora ist so konzipiert, dass es transparent den Verlust von bis zu zwei Kopien der Daten ohne Beeinträchtigung der Schreibverfügbarkeit, und bis zu drei Kopien ohne Beeinträchtigung der Verfügbarkeit von Leseleistung verarbeiten kann. Außerdem behebt der Speicher von Amazon Aurora Probleme automatisch. Datenblocks und Datenträger werden laufend auf Fehler untersucht und automatisch repariert.

F: Wie verbessert Aurora die Wiederherstellungsdauer nach einem Datenbankabsturz?

Amazon Aurora muss nach einem Datenbankabsturz – anders als andere Datenbanken –, bevor es die Datenbank für Operationen zur Verfügung stellt, nicht das Redo Log aus dem letzten Datenbank-Prüfpunkt wiedergeben (was normalerweise 5 Minuten dauert) und rückmelden, dass alle Änderungen angewendet wurden. Das reduziert in den meisten Fällen die Dauer des Neustarts auf weniger als 60 Sekunden. Amazon Aurora löst den Puffercache der Datenbank vom Datenbankprozess und macht diesen sofort zum Zeitpunkt des Neustarts verfügbar. Das verhindert eine Drosselung des Zugriffs bis zur Neuauffüllung des Cache zur Vermeidung von Brownouts.

F: Welche Arten von Replikat unterstützt Aurora?

Amazon Aurora MySQL und Amazon Aurora PostgreSQL unterstützen Amazon Aurora Replicas, denen derselbe Volume zugrunde liegt wie der primären Instance. Durch die primäre Instance ausgeführte Updates sind in allen Amazon Aurora Replicas sichtbar. Bei Amazon Aurora MySQL können Sie auch unter Anwendung der binlog-basierten MySQL-Replizierungs-Engine MySQL-Read Replicas erstellen. Bei MySQL-Read Replicas werden Daten aus Ihrer primären Instance auf Ihrem Replikat als Transaktionen wiedergegeben. Für die meisten Anwendungsfälle, auch die Skalierung der Lesevorgänge und hohe Verfügbarkeit, empfehlen wir die Nutzung von Amazon Aurora Replicas.

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

Funktion Amazon Aurora Replicas MySQL-Replikate
Anzahl der Replikate Bis zu 15 Bis zu 5
Replikationstyp Asynchron (Millisekunden) Asynchron (Sekunden)
Auswirkungen auf die Leistung der primären Instance Niedrig Hoch
Fungiert als Failover-Ziel Ja (kein Datenverlust) Ja (möglicherweise ein paar Minuten Datenverlust)
Automatisierter Failover Ja Nein
Unterstützung für benutzerdefinierte Replikationsverzögerung Nein Ja
Unterstützung für von der primären Instance abweichende Daten oder ein anderes Schema Nein Ja

F: Kann ich mit Amazon Aurora Replikate in mehreren Regionen haben?

Ja, mit Aurora MySQL können Sie über die RDS Console Aurora Replicas in mehreren Regionen einrichten. Die regionsübergreifende Replizierung basiert auf einer Einzel-Thread-MySQL-binlog-Replizierung; die Verzögerung bei der Replizierung wird durch die Änderungs-/Anwendungsrate und Verzögerungen bei der Netzwerkkommunikation zwischen den spezifischen ausgewählten Regionen beeinflusst. Aurora PostgreSQL unterstützt zurzeit keine regionsübergreifenden Replikate.

F: Kann ich Aurora Read-Replikate im regionsübergreifenden Replikat-Cluster erstellen?
Ja, Sie können Aurora-Replikate im Cluster hinzufügen, der den gleichen zugrunde liegenden Speicher wie das regionsübergreifende Replikat verwendet. Das regionsübergreifende Replikat fungiert als primäres Replikat im Cluster; die Aurora-Replikate im Cluster liegen normalerweise mit einer Verzögerung im Zehntel-Millisekundenbereich hinter dem primären Replikat.

F: Kann ich für meine Anwendung von meinem aktuellen primären Replikat ein Failover zum regionsübergreifenden Replikat durchführen?
Ja, Sie können Ihr regionsübergreifendes Replikat über die RDS Console zum neuen primären Replikat machen. Dieser Prozess dauert je nach Arbeitslast normalerweise einige Minuten. Die regionsübergreifende Replizierung wird beendet, sobald Sie diesen Prozess starten.

F: Kann ich bestimmte Replicas als Failover-Ziele vor anderen priorisieren?

A: Ja. Sie können jeder Instance auf dem Cluster ein Beförderungs-Prioritätskontingent zuweisen. Sollte die primäre Instance ausfallen, befördert Amazon RDS die Replica mit der höchsten Priorität zur neuen primären Instance. Wenn zwei oder mehr Replicas dasselbe Prioritätskontingent haben, befördert Amazon RDS die Replica, die dieselbe Größe wie die primäre Instance hat. Weitere Informationen zur Failover-Logik finden Sie im Amazon Aurora-Benutzerhandbuch.

F: Kann ich die Prioritätskontingente von Instances ändern, nachdem sie erstellt wurden?

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

F: Kann ich einstellen, dass gewisse Replicas niemals zur primären Instance befördert werden?

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

F: Wie kann ich die Verfügbarkeit einer einzelnen Amazon Aurora-Datenbank verbessern?

Sie können Amazon Aurora Replicas hinzufügen. Amazon Aurora Replicas nutzen denselben zugrunde liegenden Speicher wie die primäre Instance. Jede Amazon Aurora Replica kann ohne Datenverlust als primär hochgestuft werden. Damit kann man sie bei einem Ausfall der primären DB-Instance zur Verbesserung der Fehlertoleranz verwenden. Zur Verbesserung der Datenbankverfügbarkeit können Sie einfach 1 bis 15 Replikate in einer der 3 AZs erstellen. Amazon RDS fügt diese automatisch zur Auswahl für einen Failover der primären Instance bei einem Datenbankausfall hinzu.

F: Was geschieht während eines Failovers und wie lange dauert dieser Vorgang?

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

  • Wenn Sie eine Amazon Aurora Replica in derselben oder einer anderen Availability Zone haben, wechselt Amazon Aurora den anerkannten Namensdatensatz (CNAME) für Ihre DB-Instance, sodass auf das fehlerfreie Replikat verwiesen wird, das dadurch zur neuen primären Instance hochgestuft wird. Das gesamte Failover ist in der Regel innerhalb von 30 Sekunden abgeschlossen.
  • Verfügen Sie über keine Amazon Aurora Replica (d. h. über eine einzelne Instance), versucht Aurora zuerst, eine DB-Instance in der Availability Zone der ursprünglichen Instance zu erstellen. Gelingt das nicht, so versucht Aurora, eine neue DB-Instance in einer anderen Availability Zone zu erstellen. Ein Failover dauert von Anfang bis Ende normalerweise unter 15 Minuten.

Bei Verbindungsunterbrechung muss Ihre Anwendung versuchen, die Verbindung zur Datenbank wiederherzustellen.

F: Was geschieht, wenn ich eine primäre Datenbank und eine Amazon Aurora Replica habe, die aktiv Lesedatenverkehr übernimmt, und ein Failover stattfindet?

Amazon RDS erkennt Probleme bei Ihrer primären Instance automatisch und beginnt mit dem Routen Ihres Schreib-/Lesedatenverkehrs zu einer Amazon Aurora Replica. Dieses Failover ist im Durchschnitt innerhalb von 30 Sekunden abgeschlossen. Außerdem wird der Lesedatenverkehr Ihrer Amazon Aurora Replicas kurz unterbrochen.

F: Wie groß ist der Zeitunterschied zwischen der primären Instance und meinen Replikaten?

Da Amazon Aurora Replicas denselben Daten-Volume verwenden wie die primäre Instance, gibt es praktisch keine Verzögerung bei der Replizierung. Wir beobachten normalerweise Verzögerungen im Zehntel-Millisekundenbereich. Bei MySQL-Read Replicas kann die Verzögerung bei der Replizierung aufgrund der Change/Apply Rate oder von Verzögerungen in der Netzwerkkommunikation unbegrenzt anwachsen. Unter normalen Umständen liegt die Verzögerung bei der Replizierung üblicherweise jedoch unter einer Minute.

F: Was ist Amazon Aurora Multi-Master?

Bei der re:Invent 2017 haben wir die Vorschau für Amazon Aurora Multi-Master angekündigt. Hierbei handelt es sich um ein neues Feature der MySQL-kompatiblen Aurora-Version, das die Schreibleistung mehrerer Availability Zones horizontal nach oben skalieren kann. Dies ermöglicht Anwendungen, Lese-/Schreib-Workloads an mehrere Instances in einem Datenbank-Cluster zu verweisen und mit größerer Verfügbarkeit zu laufen.

F: Was sind die ersten Schritte zum Start mit Amazon Aurora Multi-Master?

Amazon Aurora Multi-Master steht nun als Vorschau für die MySQL-kompatible Version von Amazon Aurora zur Verfügung. Registrieren Sie sich hier für die Teilnahme. Wann die Version allgemein verfügbar wird, wird zu einem späteren Zeitpunkt bekannt gegeben.

F: Kann ich Amazon Aurora in Amazon Virtual Private Cloud (Amazon VPC) verwenden?

Ja. Alle Amazon Aurora-Instances müssen in einer VPC erstellt werden. Mit Amazon VPC können Sie eine virtuelle Netzwerkarchitektur definieren, die weitgehend einem herkömmlichen Netzwerk entspricht, wie Sie es in Ihrem Rechenzentrum betreiben. Dadurch haben Sie die uneingeschränkte Kontrolle über den Zugriff auf Ihre Amazon Aurora-Datenbanken.

F: Verschlüsselt Amazon Aurora meine Daten während der Übertragung und bei der Speicherung?

Ja. Amazon Aurora verwendet SSL (AES-256), um die Verbindung zwischen der Datenbank-Instance und der Anwendung abzusichern. Amazon Aurora ermöglicht das Verschlüsseln Ihrer Datenbanken mit Schlüsseln, die Sie mit dem AWS Key Management Service (KMS) verwalten. Bei einer mit Amazon Aurora ausgeführten Datenbank-Instance werden ruhende Daten sowie die automatischen Backups, Snapshots und Replikate desselben Clusters auf dem zugrunde liegenden Speicher verschlüsselt. Die Ver- und Entschlüsselung erfolgt nahtlos. Weitere Informationen zur Verwendung von KMS mit Amazon Aurora finden Sie im Amazon RDS-Benutzerhandbuch.

F: Kann eine bestehende unverschlüsselte Datenbank verschlüsselt werden?

Derzeit wird die Verschlüsselung einer bestehenden unverschlüsselten Aurora-Instance nicht unterstützt. Zum Verwenden der Amazon Aurora-Verschlüsselung für eine bestehende unverschlüsselte Datenbank müssen Sie eine neue DB-Instance mit aktivierter Verschlüsselung erstellen und Ihre Daten in diese Instance migrieren.

F: Wie greife ich auf meine Amazon Aurora-Datenbank zu?

Der Zugriff auf Amazon Aurora-Datenbanken muss über den Datenbank-Port erfolgen, der bei der Erstellung der Datenbank eingegeben wurde. Dies sorgt für eine zusätzliche Sicherheitsebene für Ihre Daten. Schritt-für-Schritt-Anweisungen zur Verbindung mit Ihrer Amazon Aurora-Datenbank finden Sie im Amazon Aurora-Handbuch zur Konnektivität.

F: Auf welchen Instance-Größen wird Performance Insights verfügbar sein?

Alle außer Micro-Instances. Im Zuge der Einführung neuer Instance-Größen bei RDS wird Performance Insights für diejenigen mit ausreichender Leistung zur Verfügung gestellt.

F: Wann wird Performance Insights für RDS für PostgreSQL, Aurora MySQL, RDS für MySQL, RDS für Oracle, RDS für SQL Server und RDS für MariaDB verfügbar sein?

Performance Insights wird zunächst unter Aurora PostgreSQL und bald darauf auch unter Aurora MySQL verfügbar sein. Mit der Zeit werden weitere Engines hinzukommen.

F: Wie zeigt Performance Insights die Ursache von Leistungsproblemen an?

Leistungsprobleme werden im Abschnitt "Performance Insights" der RDS-Konsole als Ausschläge im Datenbank-Ladediagramm angezeigt. Ein Blick auf dieses Diagramm reicht aus, um herauszufinden, welche für Arten von Ressourcen Ihre Anwendung in der Datenbank Zeit und Ressourcen aufgewendet hat. Sie können jeden beliebigen Zeitraum innerhalb des Speicherzeitraums heranzoomen. Wenn sie Zeiten mit hoher Auslastung auswählen, können sich die Kunden eine Liste mit SQL-Anweisungen anzeigen lassen, die nach ihrem Gesamtanteil an der Auslastung sortiert ist.

F: Woher bekommt Performance Insights die Informationen über die Auslastung meiner RDS DB-Instance?

Performance Insights fragt jede Sekunde den Status aller verknüpften Sitzungen in Ihrer DB-Instance ab. Falls eine Sitzung Zeit für einen datenbankbezogenen Vorgang aufwendet, zeichnet Performance Insights die Abfragezeit, den Vorgangstyp (I/O, CPU, Sperren usw.), die aktuelle SQL-Anweisung und verschiedene weitere Sitzungsattribute auf. Diese im Laufe der Zeit abgefragten Daten werden verwendet, um den Beitrag Ihrer Datenbank-Instances zur Auslastung zu charakterisieren.

F: Können Leistungsdaten von innerhalb der RDS-Instance abgefragt werden?

Nein. Beim Abfrageprozess von Performance Insights werden keine Tabellen in der Datenbank ausgefüllt oder Daten präsentiert, die über SQL aus der Datenbank abgerufen werden sollen.

F: Kann ich in Echtzeit sehen, was in meiner Instance geschieht?

Ja. Performance Insights zeigt standardmäßig ein bewegliches einstündiges Fenster mit Leistungsdaten an. Die Funktion ist so konzipiert, dass sie aktuelle Leistungsinformationen mit nur wenigen Sekunden Verzögerung anzeigt.

F: Wie viel kostet Performance Insights?

Performance Insights beinhaltet 24 Stunden Datenspeicherung und Konsolenzugriff. Während der Vorschau bietet Performance Insights ein kostenloses Nutzungskontingent, bei dem jeweils die Leistungsdaten der letzten 24 Stunden gespeichert werden. Die Preise für eine längerfristige Datenspeicherung werden noch bekannt gegeben.

F: Wie weit reichen die in Performance Insights gespeicherten Leistungsdaten zurück?

Es wird ein Leistungsverlauf über 24 Stunden angezeigt. Optionen für eine längere Speicherung werden zu einem späteren Zeitpunkt bekannt gegeben.

F: Kann ich Performance Insights für neue Instances deaktivieren, auch wenn es standardmäßig aktiviert ist?

Ja. Die Option für Performance Insights ist in der AWS-Konsole standardmäßig ausgewählt, wenn Sie den Assistenten zum Erstellen von Instances verwenden. Sie können die Auswahl der Option im Assistenten aufheben, um zu verhindern, dass Performance Insights aktiviert wird, oder die Instance bearbeiten, um Performance Insights für eine Instance, für die es aktiviert ist, zu deaktivieren.

F: Funktioniert Performance Insights bei RDS-Datenbank-Instances, die verschlüsselten Speicher verwenden?

Ja. Performance Insights liest die in Ihrer Datenbank gespeicherten Daten nicht.

F: Was ist die DB Load und warum ist dies die Hauptkennzahl, die in Performance Insights verwendet wird, um Leistungsprobleme zu erkennen?

Die DB-Auslastung (DB Load) ist eine Zeitreihe, aus der hervorgeht, wie viel Zeit die Anwendungen eines Kunden in der Datenbank verbringen und womit sie diese Zeit verbringen. Die DB Load wird in Einheiten durchschnittlicher aktiver Sitzungen (AAS, Average Active Sessions) gemessen. Eine aktive Sitzung ist eine Verbindung (Sitzung), die Aufgaben an die Datenbank-Engine gesendet hat und nun auf eine Antwort wartet. Wenn Sie beispielsweise eine SQL-Anweisung an eine Datenbank-Instance übermitteln, gilt die Sitzung während der Zeit, in der sie diese Anfrage verarbeitet, als " aktiv". Indem wir die Anzahl der Sitzungen ermitteln, die zu einem bestimmten Zeitpunkt in einer Instance aktiv waren, können wir eine Metrik angeben, aus deren Durchschnittswert über mehrere Zeiträume hinweg hervorgeht, wie stark eine Instance ausgelastet ist und wie viel Zeit Sitzungen damit verbringen, auf eine Antwort der Instance zu warten. Das ist die DB Load. Performance Insights zählt aktive Sitzungen und zeichnet die Attribute der einzelnen Sitzungen etwa einmal pro Sekunde mithilfe eines einfachen Abfragemechanismus auf. Die abgefragten Daten werden verschlüsselt und zu verschiedenen Granularitäten zusammengefasst, die im DB-Auslastungsdiagramm dargestellt werden. Die Benutzer der Konsole können den Zeitraum auswählen, den sie anzeigen möchten.

F: Muss ich Änderungen an meiner Datenbank vornehmen, um Performance Insights zu aktivieren?

Nein. Bei einigen Datenbank-Engines funktioniert Performance Insights jedoch noch besser, wenn eine zusätzliche Leistungserfassung aktiviert ist. Wenn etwa die pg_stat_statement-Erweiterung unter RDS PostgreSQL oder Aurora PostgreSQL aktiviert ist, verwendet Performance Insights die native SQL-Kennzeichnung von PostgreSQL, um die Anweisung zu identifizieren, und kann den vollständigen Text längerer Anweisungen erfassen. Wenn in MySQL das Performance Schema aktiviert ist, kann Performance Insights mehr und eingehendere Details zu Wait-Events erfassen, die Auswirkungen auf die Datenbank haben.

F: Wirkt es sich auf die Leistung meiner Datenbank aus, wenn ich Performance Insights aktiviere?

Der Performance Insights-Agent ist so konzipiert, dass er die Datenbankarbeitslasten nicht beeinflusst. Performance Insights wird mit einer niedrigeren Priorität ausgeführt als die anderen Prozesse in Ihrer Instance und überwacht den Zustand des Host und der Datenbank. Wenn Performance Insights hohe Arbeitslasten oder verringerte Ressourcen erkennt, verringert es die übliche Frequenz der Datenerfassung. Es werden zwar immer noch Daten erfasst, aber nur, wenn dies sicher ist. Datenbankoptionen, wie etwa pg_stat_statement in RDS PostgreSQL und Aurora Postgres, und Performance Schema in MySQL können Datenbankressourcen verwenden und sich möglicherweise auf die Leistung auswirken. Ob diese Optionen Auswirkungen auf ein bestimmtes System haben, hängt von der Arbeitslast der Anwendung ab. AWS empfiehlt, Datenbankoptionen zunächst in Verbindung mit Ihrer Arbeitslast zu testen, bevor Sie sie für ein Produktionssystem aktivieren.

F: Sollte ich Enhanced Monitoring weiter verwenden oder nur Performance Insights nutzen?

Kunden, die Enhanced Monitoring verwenden, um Betriebssystemmetriken zu überwachen, sollten diese Daten auch weiterhin mit Enhanced Monitoring erfassen. In den kommenden Monaten werden diese Daten, ebenso wie zahlreiche Datenbankmetriken, auch über die Performance Insights-Konsole und eine API verfügbar gemacht. Dann können die Kunden alle Leistungsdaten über Performance Insights ermitteln. Enhanced Monitoring wird weiterhin für Kunden zur Verfügung stehen, die lieber damit arbeiten, aber wir empfehlen den Kunden, ihre Datenbanküberwachung standardmäßig mit Performance Insights vorzunehmen.

F: Sind die in Performance Insights gespeicherten Daten verschlüsselt?

Ja. Performance Insights verschlüsselt alle potenziell sensiblen Daten mit Ihrem eigenen KMS-Schlüssel. Die Daten werden sowohl bei der Übertragung als auch bei der Speicherung verschlüsselt. Die Mitarbeiter von AWS können nicht auf potenziell sensible Leistungsdaten zugreifen oder sie anzeigen. Nur Benutzer Ihres AWS-Kontos mit vollem Zugriff auf RDS können Performance Insights anzeigen. Sie können die Freigabe Ihres KMS-Schlüssels für RDS, durch die wir Ihre Leistungsdaten verarbeiten und anzeigen können, jederzeit zurücknehmen.

F: Speichert AWS die Daten, wenn ich Performance Insights deaktiviere, oder werden sie gelöscht?

Die Speicherung der Leistungsdaten ist beim kostenlosen Nutzungskontingent auf einen Tag beschränkt. Wenn Sie Performance Insights für eine Instance deaktivieren, werden Ihre Leistungsdaten zu dieser Instance gelöscht.

F: Wie wirkt es sich auf die Speicherung von Daten durch Performance Insights aus, wenn ich meine RDS-Datenbank-Instance anhalte?

Wenn Sie eine RDS-Instance anhalten, für die Performance Insights aktiviert ist, hat dies keine Auswirkungen auf die Datenspeicherung oder die Möglichkeit, Verlaufsdaten dieser Instance einzusehen. Der Zeitraum, während dem die Instance angehalten war, enthält lediglich keine Daten.

F: Wie kann ich Performance Insights in meine vorhandenen Leistungstools einbinden?

In Zukunft wird Performance Insights eine öffentlich verfügbare API anbieten, über die Kunden und Dritte die wertvollen Daten in Performance Insights nutzen können.

F: Gibt es eine Möglichkeit, die Leistungstools von Drittanbietern mit Performance Insights zu integrieren?

In Zukunft wird Performance Insights eine öffentlich verfügbare API anbieten, über die Kunden und Dritte die wertvollen Daten in Performance Insights nutzen können.

F: Wird Performance Insights in allen AWS-Regionen verfügbar sein, in denen RDS verfügbar ist?

Ja. Performance Insights wird zunächst in vier Regionen verfügbar sein: USA Ost (Nord Virginia, Ohio), USA West (Oregon) und EU (Irland). Nach und nach wird die Funktion in allen Regionen zur Verfügung gestellt werden, in denen RDS unterstützt wird.

F: Kann ich Performance Insights auch für vorhandenen Instances aktivieren oder nur für neue?

Ja, Sie können Performance Insights für vorhandene Instances aktivieren. Dazu müssen Sie die Instance bearbeiten und Performance Insights aktivieren. Bei neuen Instances können Sie die Funktion aktivieren, indem Sie beim Erstellen der Instance festlegen, dass Performance Insights aktiviert sein soll.

F: Verwendet Performance Insights den Speicher meiner Datenbank-Instance?

Nein, Performance Insights verbraucht keinen Speicherplatz Ihrer RDS-Instance.

F: Bestehen Unterschiede, wenn Performance Insights für verschiedene Datenbank-Engines ausgeführt wird, und wenn ja, welche?

Performance Insights wurde so konzipiert, dass es einen einheitlichen Ansatz, ein einheitliches Erscheinungsbild und eine einheitliche Handhabung für alle Datenbank-Engines in RDS bietet. Da bestimmte Attribute wie Wait-Events und SQL-Kennzeichnungen je nach Engine-Typ unterschiedlich sind, unterscheiden sie sich natürlich auch in Performance Insights, wenn mit unterschiedlichen Datenbank-Engines gearbeitet wird. Einer der wichtigsten Grundsätze von Performance Insights ist, dass vorhandene Konzepte, Kennzeichnungen und Attribute in einer Datenbank-Engine intakt bleiben sollen. In der Regel wird Performance Insights Wait-Events und andere Engine-spezifische Attribute nicht neu interpretieren oder umbenennen, sondern sie genauso darstellen, wie sie von der Datenbank-Engine angegeben wurden.

F: Kann Performance Insights für Multi-AZ-Instances und Read Replica-Instances genutzt werden?

Ja. Wenn Performance Insights für eine RDS-Datenbank aktiviert ist, die Multi-AZ verwendet, bleibt Performance Insights auch weiterhin aktiviert, falls diese Instance im Zuge eines Failovers zur anderen Availability Zone wechselt. Weil Read Replicas unabhängige Instances sind, können die Kunden Performance Insight für diese Instances aktivieren oder deaktivieren.

F: Kann ich meine Daten aus Performance Insights exportieren?

Eine Funktion für den Datenexport wird zu einem späteren Zeitpunkt zu Performance Insights hinzugefügt werden.

F: Kann ich meine Daten später erneut in Performance Insights importieren, um eine Leistungsanalyse durchzuführen?

Nein. Performance Insights zeigt nur Daten an, die direkt von einer Instance erfasst wurden. Daten, die von Performance Insights stammen, werden in den kommenden Monaten über eine API verfügbar gemacht werden. Dann kann mithilfe eines der analyseorientierten Services von AWS, zum Beispiel Amazon Athena, Amazon Redshift, Amazon Redshift Spectrum oder Amazon Quicksight, eine Analyse durchgeführt werden.