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: 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?

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: 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 unter Bewährte Methoden für die Migration von MySQL-Datenbanken in Amazon Aurora

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.

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 Datenbank-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 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 die Sicherung 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 nutzen, um Daten zwischen Ihren unterschiedlichen Umgebungen (Produktion, Entwicklung/Tests, Staging usw.) zu teilen, die unterschiedliche AWS-Konten nutzen, sowie Sicherungen all Ihrer Daten in einem getrennten Konto aufzubewahren, falls einmal in Ihr AWS-Konto eingebrochen werden sollte.

F: Werden mir 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:

Merkmal 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: 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?

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?

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?

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: Kann ich Amazon Aurora mit Anwendungen verwenden, die dem HIPAA-Standard entsprechen müssen?

A: Ja, die MySQL- und PostgreSQL-kompatiblen Editionen von Aurora 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.

F: Was ist Amazon Aurora Serverless?

Amazon Aurora Serverless ist eine automatisch skalierbare On-Demand-Konfiguration für die MySQL-kompatible Edition von Amazon Aurora. Ein Aurora Serverless DB-Cluster kann abhängig von Ihren Anwendungsanforderungen automatisch starten, herunterfahren und die Kapazität steigern oder senken. Aurora Serverless stellt eine relativ einfache, kostengünstige Option für gelegentliche, unregelmäßige oder unvorhersehbare Workloads dar. Mehr erfahren Sie im Benutzerhandbuch für Amazon Aurora.

F: Welche Versionen von Amazon Aurora werden bei Aurora Serverless unterstützt?

Aurora Serverless ist aktuell für Aurora mit MySQL 5.6 verfügbar.

F: Kann ich einen bestehenden Aurora DB-Cluster zu Aurora Serverless migrieren?

Ja, Sie können einen Snapshot eines bestehenden bereitgestellten Aurora-Clusters auf einem Aurora Serverless DB-Cluster wiederherstellen (und umgekehrt).

F: Wie verbinde ich mich mit einem Aurora Serverless DB-Cluster?

Sie greifen auf einen Aurora Serverless DB-Cluster innerhalb einer Client-Anwendung zu, die in der gleichen Amazon Virtual Private Cloud (VPC) ausgeführt wird. Es ist nicht möglich, einem Aurora Serverless DB-Cluster eine öffentliche IP-Adresse zuzuweisen.

F: Kann ich die Kapazität eines Aurora Serverless-Clusters explizit festlegen?

Obwohl sich Aurora Serverless automatisch auf Basis des aktiven Datenbank-Workloads skaliert, erfolgt die Kapazitätsskalierung in einigen Fällen möglicherweise nicht schnell genug, um auf plötzliche Workload-Veränderungen wie eine große Anzahl neuer Transaktionen zu reagieren. In diesen Fällen können Sie die Kapazität explizit in der AWS-Managementkonsole, der AWS CLI oder der RDS API auf einen bestimmten Wert festlegen.

F: Warum skaliert sich mein Aurora Serverless DB-Cluster nicht automatisch?

Nach dem Beginn eines Skalierungsvorgang versucht Aurora Serverless, einen Skalierpunkt zu finden, also einen Zeitpunkt, zu dem die Datenbank die Skalierung sicher abschließen kann. Aurora Serverless findet möglicherweise keinen Skalierpunkt, wenn über längere Zeit Abfragen oder Transaktionen laufen oder vorübergehende Tabellen oder Tabellen den Vorgang unterbinden.

F: Wie erfolgt die Abrechnung für Aurora Serverless?

Bei Aurora Serverless wird die Datenbankkapazität in Aurora Capacity Units (ACUs) gemessen. Für die ACU-Nutzung zahlen Sie eine Flat-Rate pro Sekunde. Die Nutzungszeit muss bei jeder Aktivierung der Datenbank mindestens 5 Minuten betragen. Die Preise für den Speicher und die E/A-Vorgänge bei Amazon Aurora sind dieselben wie für die bereitgestellte und serverlose Konfiguration. Preisbeispiel für Aurora Serverless ansehen.