Allgemeines

F: Was ist Amazon Aurora?

Amazon Aurora ist ein moderner relationaler Datenbankservice, der Leistung und Hochverfügbarkeit in großem Umfang, vollständig quelloffene MySQL- und PostgreSQL-kompatible Versionen sowie eine Reihe von Entwicklerwerkzeugen für die Erstellung von serverlosen und Machine Learning (ML)-gesteuerten Anwendungen bietet.

Aurora ist ein verteiltes, fehlertolerantes und selbstreparierendes Speichersystem, das von Rechenkapazitäten entkoppelt ist und automatisch bis zu 128 TB pro Datenbank-Instance skaliert. Es bietet hohe Leistung und Verfügbarkeit mit bis zu 15 Read Replicas mit geringer Latenzzeit, zeitpunktbezogener Wiederherstellung, kontinuierlicher Sicherung in Amazon Simple Storage Service (Amazon S3) und Replikation über drei Availability Zones (AZs).

Amazon Aurora ist auch ein voll verwalteter Service, der zeitaufwendige Verwaltungsaufgaben wie die Hardwarebereitstellung, die Einrichtung von Datenbanken, das Patchen und Backups automatisiert. Zugleich werden Ihnen Sicherheit, Verfügbarkeit und Verlässlichkeit Ihrer kommerziellen Datenbanken zu einem Zehntel der üblichen Kosten geboten.

F: Was versteht man unter „MySQL-kompatibel“?

Amazon-Aurora-Datenbank ist drop-in-kompatibel mit bestehenden MySQL-Open-Source-Datenbanken und bietet regelmäßig Unterstützung für neue Versionen. Dies bedeutet, dass Sie MySQL-Datenbanken einfach in Aurora importieren und aus Aurora exportieren können, indem Sie Standardwerkzeuge oder Snapshots verwenden. Auch die meisten der Codes, Anwendungen, Treiber und Werkzeuge, die Sie bereits heute mit Ihren MySQL-Datenbanken verwenden, können mit Aurora mit geringen oder keinen Änderungen verwendet werden. Wenn Sie Aurora mit MySQL vergleichen, ist es wichtig zu berücksichtigen, dass die Amazon-Aurora-Datenbank-Engine so konzipiert ist, dass sie mit MySQL 5.6 und 5.7 unter Verwendung der InnoDB-Speicher-Engine übertragungskompatibel ist. Somit ist es einfacher, Anwendungen zwischen den beiden Engines zu verschieben. Einige MySQL-Funktionen, etwa die MyISAM-Speicher-Engine, sind mit Amazon Aurora nicht verfügbar.

F: Was versteht man unter „PostgreSQL-kompatibel“?

Amazon-Aurora-Datenbank ist drop-in-kompatibel mit bestehenden PostgreSQL-Open-Source-Datenbanken und bietet regelmäßig Unterstützung für neue Versionen. Dies bedeutet, dass Sie PostgreSQL-Datenbanken einfach in Aurora importieren und aus Aurora exportieren können, indem Sie Standardwerkzeuge oder Snapshots verwenden. Es bedeutet auch, dass die meisten Codes, Anwendungen, Treiber und Tools, die Sie bereits heute mit Ihren PostgreSQL-Datenbanken verwenden, mit Aurora mit geringen oder gar keinen Änderungen genutzt werden können. 

F: Wie lässt sich Amazon Aurora mit Amazon Relational Database Service (Amazon RDS) vergleichen?

A: Amazon RDS ist eine vollständig verwaltete, sichere Datenbank mit hoher Verfügbarkeit, die es Ihnen erleichtert, eine von sieben relationalen Datenbank-Engines aufzusetzen und zu betreiben: PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, Amazon Aurora MySQL-kompatible Edition und Amazon Aurora PostgreSQL-kompatible Edition. 

Die Amazon Aurora MySQL-kompatible Edition und Amazon Aurora PostgreSQL-kompatible Edition nutzen die Vorzüge von Amazon RDS unter anderem aus, um zeitaufwendige administrative Datenbank-Aufgaben zu automatisieren sowie eine verbesserte Leistungsfähigkeit, Skalierbarkeit und Verfügbarkeit im Vergleich zu Community-Open-Source MySQL und PostgreSQL zu bieten.

F: Wie kann ich Amazon Aurora testen?

Wenn Sie Amazon Aurora ausprobieren möchten, melden Sie sich bei der AWS-Managementkonsole 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 Aurora-Preisseite 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 auf der Seite mit der Preisübersicht steht?

Nein, die 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 Aurora-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-Managementkonsole können Sie für die Migration eines Amazon-RDS-for-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 Amazon-RDS-for-PostgreSQL-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. Sie können Babelfish for Aurora PostgreSQL verwenden, um SQL-Server-Anwendungen zur Aurora PostgreSQL-kompatiblen Edition zu migrieren. Besuchen Sie auch die Babelfish-Funktionsübersicht für weitere Informationen.

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 der Aurora-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 Solid-State-Drive (SSD)-basierten virtualisierten Speicherebene durchführt. Jede Datenbank-Seitenleseoperation zählt als ein E/A-Vorgang. Die Aurora-Datenbank-Engine führt Lesevorgänge in der Speicherebene aus, um Datenbankseiten abzurufen, die nicht im Speicher des Cache vorhanden sind. Wenn Ihr Abfrageverkehr vollständig aus dem Speicher oder dem Cache bedient werden kann, werden Ihnen keine Kosten für das Abrufen von Datenseiten aus dem Speicher berechnet. Wenn Ihr Abfrageverkehr nicht vollständig aus dem Speicher bedient werden kann, werden Ihnen Kosten für alle Datenseiten berechnet, die aus dem Speicher abgerufen werden müssen. Jede Datenbank in der Aurora-MySQL-kompatiblen Edition ist 16 KB groß, jede Datenbank in der Aurora PostgreSQL-kompatiblen Edition ist 8 KB groß. 

Aurora ist so konzipiert, dass es unnötige E/A-Vorgänge eliminiert, so die Kosten senkt und sicherstellt, dass die Ressourcen für Lese-/Schreibvorgänge verfügbar sind. Schreib-E/As werden nur verbraucht, wenn Redo-Protokoll-Aufzeichnungen in Aurora-MySQL-kompatible Edition oder Write-Ahead-Protokoll-Aufzeichnungen in Aurora PostgreSQL-kompatible Edition in der Speicherschicht persistiert werden, um Schreibvorgänge dauerhaft zu machen. Schreib-E/A-Vorgänge werden in Einheiten von 4 KB berechnet. Eine Protokoll-Aufzeichnung mit 1024 Bytes beispielsweise zählt als ein geschriebener E/A-Vorgang. Wenn die Protokoll-Aufzeichnung jedoch größer als 4 KB ist, ist mehr als ein Schreib-E/A-Vorgang erforderlich, um sie zu persistieren. Gleichzeitige Schreibvorgänge, deren Protokoll-Aufzeichnungen kleiner als 4 KB sind, können von der Aurora-Datenbank-Engine zur Optimierung des E/A-Verbrauchs zusammengeladen werden, wenn sie auf denselben Speicherschutzgruppen persistiert werden. Im Gegensatz zu herkömmlichen Datenbank-Engines werden bei Aurora keine schmutzigen Datenseiten in den Speicher gespült. Der Umfang der E/A-Anfragen, die Ihre Aurora-Instance nutzt, wird in der AWS-Managementkonsole angezeigt. Der Umfang der E/A-Anfragen, die Ihre Aurora-Instance nutzt, wird in der Konsole angezeigt. Sie finden die E/A-Nutzung im Amazon-RDS-Abschnitt der Konsole. Wählen Sie in Ihrer Instance-Liste die Aurora-Instances und suchen Sie dann im Überwachungs-Abschnitt die Metriken „In Rechnung gestellte Lesevorgänge“ und „In Rechnung gestellte Schreibvorgänge“.

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

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

Performance

F: Was bedeutet „fünffache Leistung von MySQL“?

Amazon Aurora bietet erhebliche Leistungssteigerungen gegenüber MySQL durch die enge Integration der Datenbank-Engine mit einer SSD-basierten virtualisierten Speicherebene, die speziell für Datenbank-Arbeitslasten entwickelt wurde, wodurch Schreibvorgänge in das Speichersystem reduziert, Sperrkonflikte minimiert und durch Datenbankprozess-Threads verursachte Verzögerungen beseitigt werden. Unsere Tests mit SysBench auf r3.8xlarge-Instances zeigen, dass Amazon Aurora über 500 000 SELECTs/Sek und 100 000 UPDATEs/Sek liefert, fünfmal mehr als MySQL, das denselben Benchmark auf derselben Hardware ausführt. Detaillierte Anweisungen zu diesem Benchmark und wie Sie ihn selbst replizieren können, finden Sie im Performance Benchmarking Handbuch für Amazon-Aurora-MySQL-kompatible Edition.

F: Was versteht man unter „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-kompatible Edition-Handbuch zum Leistungs-Benchmarking.

F: Wie kann ich meine Datenbank-Arbeitslast für Amazon-Aurora-MySQL-kompatible Edition optimieren?

Amazon Aurora ist so konzipiert, dass es mit MySQL 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-kompatible Edition optimieren?

Amazon Aurora ist so konzipiert, dass es mit PostgreSQL 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.

Hardware und Skalierung

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 128 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 Computing-Ressourcen?

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

Sie können Ihre mit Ihrer Datenbank verknüpften Computing-Ressourcen auch manuell skalieren, indem Sie den gewünschten DB-Instance-Typ in der AWS-Managementkonsole auswählen. Ihre angeforderte Änderung wird während Ihres angegebenen Wartungsfensters angewendet. Sie können auch das Flag „Sofort anwenden“ verwenden, um den DB-Instance-Typ sofort zu ändern. Beide Optionen wirken sich ein paar Minuten lang auf die Verfügbarkeit aus, solange die Skalierung durchgeführt wird. Beachten Sie, dass in diesem Fall alle anderen noch ausstehenden Systemänderungen ebenfalls übernommen werden.

Backup und Wiederherstellung

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 speichert automatisch sechs Kopien Ihrer Daten in drei Availability Zones (AZs) und versucht automatisch, Ihre Datenbank in einer gesunden 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 fünf 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.

Hohe Verfügbarkeit und Replikation

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 AZs repliziert. Amazon Aurora ist so konzipiert, dass es transparent den Verlust von bis zu zwei Kopien der Daten ohne Beeinträchtigung der Schreibverfügbarkeit, und bis zu drei Kopien ohne Beeinträchtigung der Verfügbarkeit von Leseleistung verarbeiten kann. Außerdem behebt der Speicher von Amazon Aurora Probleme automatisch. Datenblocks und Datenträger werden laufend auf Fehler untersucht und automatisch repariert.

F: Wie verbessert Aurora die Wiederherstellungsdauer nach einem Datenbankabsturz?

Anders als andere Datenbanken muss Amazon Aurora nach einem Datenbankabsturz und bevor es die Datenbank für Operationen zur Verfügung stellt, nicht das Redo 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 Replicas unterstützt Aurora?

Amazon-Aurora-MySQL-kompatible Edition und Amazon-Aurora-PostgreSQL-kompatible Edition unterstützen Amazon Aurora Replicas, die das gleiche zugrunde liegende Volumen wie die primären Instance in derselben AWS-Region teilen. Durch die primäre Instance ausgeführte Updates sind in allen Amazon Aurora Replicas sichtbar. Mit Amazon-Aurora-MySQL-kompatible Edition können Sie auch unter Anwendung der Binlog-basierten MySQL-Replizierungs-Engine regionsübergreifende 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
Replikat-Standort In der Region
Regionenübergreifend
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

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

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

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

Aurora unterstützt die native logische Replikation in jeder Datenbank-Engine (Binlog für MySQL- und PostgreSQL-Replikationsslots für PostgreSQL), so dass Sie auf Aurora- und Nicht-Aurora-Datenbanken replizieren können, sogar über Regionen hinweg.

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

F: Kann ich Aurora Replicas im regionsübergreifenden Replikat-Cluster erstellen?

Ja, Sie können bis zu 15 Aurora Replicas zu jedem regionenübergreifenden Cluster hinzufügen, und sie teilen sich den gleichen zugrundeliegenden Speicherplatz wie das regionenübergreifende Replikat. Das regionsübergreifende Replikat fungiert als primäres Replikat im Cluster; die Aurora Replicas 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 Amazon-RDS-Konsole zum neuen primären Replikat machen. Für die logische (Binlog-)Replikation dauert der Promotion-Prozess in der Regel einige Minuten, abhängig von Ihrem Arbeitsaufkommen. Die regionsübergreifende Replizierung wird beendet, sobald Sie diesen Prozess starten.

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

F: Kann ich bestimmte Replikate 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 das Replikat mit der höchsten Priorität zur neuen primären Instance. Wenn zwei oder mehr Aurora-Replikate die gleiche Priorität aufweisen, befördert Amazon RDS das größte Replikat. Weisen zwei oder mehr Aurora-Replikate die gleiche Priorität und Größe auf, befördert Amazon RDS ein beliebiges Replikat in der gleichen Beförderungsstufe. Weitere Informationen zur Failover-Logik finden Sie im Benutzerhandbuch von Amazon Aurora.

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

Ja, 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. Aurora Replicas in der gleichen AWS-Region teilen sich den gleichen zugrunde liegenden Speicherplatz wie die primäre Instance. Jede 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 verwendet werden. Zur Verbesserung der Datenbankverfügbarkeit können Sie einfach 1 bis 15 Replikate in einer der 3 AZs erstellen. Amazon RDS fügt diese automatisch zur Auswahl für einen Failover der primären Instance bei einem Datenbankausfall hinzu.

Sie können die Amazon Aurora Global Database verwenden, wenn Sie möchten, dass Ihre Datenbank mehrere AWS-Regionen umfasst. Dadurch werden Ihre Daten repliziert, ohne die Datenbankleistung zu beeinträchtigen, und die Disaster Recovery nach regionalen Ausfällen wird ermöglicht.

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. 
  • Wenn Sie Aurora Serverless ausführen und die DB-Instance oder AZ nicht mehr verfügbar sind, erstellt Aurora die DB-Instance automatisch in einer anderen AZ. 
  • Verfügen Sie über keine Amazon Aurora Replica (d. h. über eine einzelne Instance), versucht Aurora Serverless zuerst, eine DB-Instance in der Availability Zone der ursprünglichen Instance zu erstellen. Dieser Austausch der ursprünglichen Instance wird nach bestem Bemühen durchgeführt, ist aber nicht immer erfolgreich, z. B. wenn ein Problem vorliegt, das sich allgemein auf die Availability Zone auswirkt.

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

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

Amazon Aurora erkennt automatisch, dass ein Problem mit Ihrer primären Instance vorliegt, und löst ein Failover aus. Wenn Sie den Cluster-Endpunkt verwenden, werden Ihre Lese-/Schreibverbindungen automatisch an ein Amazon Aurora Replica weitergeleitet, das zur primären Instance hochgestuft wird. Außerdem wird der Lesedatenverkehr Ihrer Amazon Aurora Replicas kurz unterbrochen. Wenn Sie den Cluster-Leser-Endpunkt verwenden, um Ihren Lesedatenverkehr an das Aurora Replica zu leiten, werden die schreibgeschützten Verbindungen an die neu hochgestufte Aurora Replica weitergeleitet, bis der alte primäre Knoten wieder als Replikat hergestellt wurde.

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

Da Amazon Aurora Replicas denselben Daten-Volumen verwenden wie die primäre Instance in derselben AWS-Region, gibt es praktisch keine Verzögerung bei der Replizierung. Wir beobachten normalerweise Verzögerungen im Zehntel-Millisekundenbereich. Bei 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.

Regionalübergreifende Replikate mit logischer Replikation werden durch die Änderungs-/Anwendungsrate und Verzögerungen in der Netzwerkkommunikation zwischen den ausgewählten Regionen beeinflusst. Regionalübergreifende Replikate mit der Amazon Aurora Global Database haben eine typische Verzögerung von weniger als einer Sekunde.

F: Kann ich zwischen meiner Aurora-MySQL-kompatible-Edition-Datenbank und einer externen MySQL-Datenbank eine Replikation aufsetzen?

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

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

F: Was ist Amazon Aurora Global Database?

Amazon Aurora Global Database ist eine Funktion, die es einer einzelnen Amazon-Aurora-Datenbank ermöglicht, mehrere AWS-Regionen abzudecken. Es repliziert Ihre Daten ohne Auswirkungen auf die Datenbankleistung, ermöglicht schnelle lokale Lesezugriffe in jeder Region mit einer typischen Latenzzeit von weniger als einer Sekunde und bietet Disaster Recovery nach regionalem Ausfall. Im unwahrscheinlichen Fall einer regionalen Verschlechterung oder eines Ausfalls kann eine sekundäre Region in weniger als einer Minute in die volle Lese-/Schreibfähigkeit versetzt werden.

Diese Funktion steht sowohl für Aurora-MySQL-kompatible Edition als auch für Aurora-PostgreSQL-kompatible Edition zur Verfügung.

F: Wie erstelle ich eine Amazon Aurora Global Database?

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

F: Wie viele sekundäre Regionen darf eine Amazon Aurora Global Database aufweisen?

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

F: Kann ich die logische Replikation (Binlog) auf der primären Datenbank verwenden, wenn ich die Amazon Aurora Global Database verwende?

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

F: Wird Aurora automatisch in eine sekundäre Region einer Amazon Aurora Global Database wechseln?

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

F: Was ist Amazon Aurora Multi-Master?

Bei Amazon Aurora Multi-Master handelt es sich um eine Funktion der MySQL-kompatiblen Aurora-Version, welche die Schreibleistung mehrerer Availability Zones horizontal nach oben skalieren kann. Dies ermöglicht Anwendungen, Lese-/Schreib-Arbeitslasten an mehrere Instanzen in einem Datenbank-Cluster weiterzuleiten 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 ist nun allgemein verfügbar. Weitere Informationen finden Sie in der Amazon-Aurora-Dokumentation. Sie können eine Aurora Multi-Master-Cluster mit nur wenigen Klicks in der Amazon-RDS-Konsole erstellen oder das aktuelle AWS SDK bzw. CLI herunterladen.

Sicherheit

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

Ja. Alle Amazon-Aurora-DB-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 (AWS 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 problemlos. Weitere Informationen zur Verwendung von AWS 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 Standard von HIPAA entsprechen müssen?

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. Weitere Informationen zum Erstellen von Anwendungen in AWS finden Sie unter Gesundheitsdienstleister und Versicherer in der Cloud.

F: Wo finde ich eine CVE-Liste (Common Vulnerabilities and Exposures; Häufige Schwachstellen und Risiken) für bekannte Sicherheitslücken bei Amazon Aurora-Releases?

Eine aktuelle CVE-Liste finden Sie in den Sicherheitsupdates für Amazon Aurora.

Serverless

F: Was ist Amazon Aurora Serverless?

Bei Amazon Aurora Serverless handelt es sich um eine On-Demand-Konfiguration mit automatischer Skalierung für Amazon Aurora. Sie können damit Datenbanken in der Cloud ausführen, ohne dafür Datenbankkapazitäten verwalten zu müssen. Die manuelle Verwaltung der Datenbankkapazität nimmt wertvolle Zeit in Anspruch und kann zu einer ineffizienten Nutzung der Datenbankressourcen führen. Mit Aurora Serverless können Sie einfach eine Datenbank erstellen, den gewünschten Kapazitätsbereich der Datenbank angeben und Ihre Anwendung verbinden. Aurora passt die Kapazität innerhalb des von Ihnen angegebenen Bereichs automatisch an die Anforderungen Ihrer Anwendung an. Die Abrechnung erfolgt pro Sekunde verbrauchter Datenbankkapazität bei aktiver Datenbank. Erhalten Sie weitere Informationen über Aurora Serverless und starten Sie mit wenigen Klicks in der Amazon-RDS-Managementkonsole.

F: Was ist der Unterschied zwischen Aurora Serverless v2 und v1?

Aurora Serverless v2 unterstützt alle Arten von Datenbank-Workloads. Das Spektrum reicht von Entwicklungs- und Testumgebungen, Websites und Anwendungen mit seltenen, unregelmäßigen oder unvorhersehbaren Workloads bis hin zu den anspruchsvollsten, geschäftskritischen Anwendungen, die hohe Skalierbarkeit und Hochverfügbarkeit erfordern. Die Skalierung erfolgt durch das Hinzufügen von mehr CPU und Speicher, ohne dass ein Failover der Datenbank auf eine größere oder kleinere Datenbank-Instance erforderlich ist. Dadurch kann auch bei lang laufenden Transaktionen, Tabellensperren usw. skaliert werden. Darüber hinaus kann auch die Datenbankkapazität in kleinen Schritten von nur 0,5 Aurora Capacity Units (ACUs) skaliert werden, sodass Ihre Datenbankkapazität genau den Anforderungen Ihrer Anwendung entspricht.

Aurora Serverless v1 stellt eine einfache, kostengünstige Option für gelegentliche, unregelmäßige oder unvorhersehbare Workloads dar. Es startet automatisch, skaliert die Rechenkapazität entsprechend der Nutzung Ihrer Anwendung und fährt herunter, wenn es nicht verwendet wird. Weitere Informationen finden Sie im Aurora-Benutzerhandbuch.

F: Welche Aurora-Funktionen unterstützt Aurora Serverless v2?

Aurora Serverless v2 unterstützt alle Funktionen von bereitgestelltem Aurora, einschließlich Lesereplikat, Multi-AZ-Konfiguration, Global Database, RDS-Proxy und Performance Insights.

F: Kann ich mit der Verwendung von Aurora Serverless v2 mit meinem vorhandenen Aurora-DB-Cluster starten?

Ja, Sie können mit der Verwendung von Aurora Serverless v2 starten, um die Datenbank-Rechenkapazität in Ihrem vorhandenen Aurora-DB-Cluster zu verwalten. Ein Cluster, der sowohl bereitgestellte Instances als auch Aurora Serverless v2 enthält, wird als Cluster mit gemischter Konfiguration bezeichnet. Sie können eine beliebige Kombination aus bereitgestellten Instances und Aurora Serverless v2 in Ihrem Cluster haben. Um Aurora Serverless v2 zu testen, fügen Sie Ihrem Aurora-DB-Cluster einen Reader hinzu und wählen Serverless v2 als Instance-Typ aus. Sobald der Reader erstellt und verfügbar ist, können Sie ihn für Workloads mit Lesezugriff verwenden. Sobald Sie bestätigt haben, dass der Reader wie erwartet funktioniert, können Sie ein Failover initiieren, um mit der Verwendung von Aurora Serverless v2 sowohl für Lese- als auch für Schreibvorgänge zu starten. Diese Option bietet eine minimale Ausfallzeit, um mit Aurora Serverless v2 zu starten.

F: Kann ich von Aurora Serverless v1 zu Aurora Serverless v2 migrieren?

Ja, Sie können von Aurora Serverless v1 zu Aurora Serverless v2 migrieren. Weitere Informationen finden Sie im Aurora-Benutzerhandbuch.

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

Aurora Serverless v2 ist für die MySQL-kompatible Edition von Amazon Aurora ab Version 8.0 und für die PostgreSQL-kompatible Edition ab Version 13.5 verfügbar. Aurora Serverless v1 ist für Aurora MySQL 5.6 und 5.7 und Aurora PostgreSQL 10.14 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 können auf einen Aurora-Serverless-DB-Cluster mithilfe einer Client-Anwendung zugreifen, die in der gleichen 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 Amazon RDS API auf einen bestimmten Wert festlegen.

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

Sobald ein Skalierungsvorgang eingeleitet wird, versucht Aurora Serverless, einen Skalierungspunkt zu finden, d. h. einen Zeitpunkt, an dem die Datenbank die Skalierung sicher abschließen kann. Aurora Serverless findet möglicherweise keinen Skalierungspunkt, 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. Sie zahlen eine Pauschale pro Sekunde der ACU-Nutzung. Die Preise für den Speicher und die I/O-Vorgänge bei Amazon Aurora sind dieselben wie für die bereitgestellte und Serverless-Konfigurationen. Besuchen Sie die Aurora-Preisseite für aktuelle Informationen zu Preisen und zur Verfügbarkeit in AWS-Regionen.

Parallel Query

F: Was ist die Parallel Query von Amazon Aurora?

Amazon Aurora Parallel Query bezieht sich auf die Fähigkeit, die Rechenlast einer einzelnen Abfrage auf Tausende von CPUs in Auroras Speicherschicht zu verteilen. Ohne Parallel Query würde eine Abfrage, die gegen eine Amazon Aurora-Datenbank durchgeführt wird, vollständig innerhalb einer Instance des Datenbank-Clusters ausgeführt; dies wäre vergleichbar mit der Funktionsweise der meisten Datenbanken.

F: Was ist der beabsichtigte Anwendungsfall?

Parallel Query ist eine gute Lösung für analytische Workloads, die neue Daten und eine gute Abfrageleistung erfordern, selbst bei großen Tabellen. Solche Workloads sind oft operativer Art.

F: Welche Vorteile erhalte ich durch Parallel Query?

Mit Parallel Query können analytische Abfragen um bis zu 2 Größeneinheiten schneller durchgeführt werden. Sie erreichen so auch Operative Einfachheit und Datenfrische, da Sie eine Abfrage direkt über die aktuellen Transaktionsdaten in Ihrem Aurora-Cluster durchführen können. Parallel Query ermöglichst außerdem transaktionale und analytische Workloads auf derselben Datenbank, in dem es Aurora ermöglicht, einen hohen Transaktionsdurchsatz bei gleichzeitigen analytischen Abfragen aufrechtzuerhalten.

F: Welche Abfragen werden mit Parallel Query im Spezifischen verbessert?

Die meisten Abfragen über große Datensätze, die sich nicht bereits im Pufferpool befinden, werden davon profitieren. Die erste Version von Parallel Query kann die Verarbeitung von mehr als 200 SQL-Funktionen, Equijoins und Projektionen nach unten drücken und ausdehnen.

F: Welche Leistungsverbesserungen kann ich erwarten?

Die Verbesserung der Leistung einer bestimmten Abfrage hängt davon ab, wie viel des Abfrageplans auf die Aurora-Speicherschicht übertragen werden kann. Kunden haben eine Verbesserung der Abfrage-Latenzzeit in Höhe von mehr als einer Größenordnung gemeldet.

Besteht die Chance, dass sich die Leistung verschlechtern wird?

Ja, aber wir gehen davon aus, dass diese Fälle selten sein werden.

F: Welche Änderungen muss ich an meiner Abfrage vornehmen, um die Vorteile von Parallel Query zu nutzen??

Es sind keine Änderungen in der Abfragesyntax erforderlich. Der Abfrageoptimierer entscheidet automatisch, ob er Parallel Query für Ihre spezifische Abfrage verwendet. Um zu überprüfen, ob eine Abfrage Parallel Query verwendet, können Sie den Ausführungsplan der Abfrage anzeigen, indem Sie den Befehl EXPLAIN ausführen. Wenn Sie die Heuristiken umgehen und Parallel Query zu Testzwecken erzwingen möchten, verwenden Sie die Sitzungsvariable aurora_pq_force.

F: Wie oft muss ich die Funktion aktivieren oder deaktivieren?

Parallel Query kann sowohl auf globaler Ebene als auch auf Sitzungsebene mit dem Parameter aurora_pq dynamisch aktiviert und deaktiviert werden.

F: Gibt es zusätzliche Kosten bei der Verwendung von Parallel Query?

Nein. Es wird Ihnen nichts anderes berechnet, als das, was Sie bereits für Instances, E/A und Speicher bezahlen.

F: Werden auch meine Aurora E/A-Gebühren reduziert, da Parallel Query die E/A reduziert?

Nein, die E/A-Kosten für Ihre Abfrage werden auf der Speicherschicht gemessen und sind bei eingeschalteter Parallel Query gleich oder größer. Ihr Vorteil ist die Verbesserung der Abfrageleistung. Es gibt zwei Gründe für potenziell höhere E/A-Kosten bei Parallel Query. Erstens, selbst wenn sich einige der Daten in einer Tabelle im Pufferpool befinden, erfordert Parallel Query, dass alle Daten auf der Speicherschicht gescannt werden, was zu E/A führt. Zweitens ist ein Nebeneffekt der Vermeidung von Konflikten im Pufferpool, dass das Ausführen einer Abfrage mit Parallel Query den Pufferpool nicht anlaufen lässt. Infolgedessen entstehen bei aufeinander folgenden Durchläufen derselben Abfrage mit Parallel Query die vollen E/A-Kosten.

F: Welche Versionen von Amazon Aurora unterstützen Parallel Query?

Parallel Query ist für die mit MySQL 5.6 kompatible Version von Amazon Aurora ab v1.18.0 verfügbar. Wir planen, Parallel Query auf Aurora mit MySQL 5.7-Kompatibilität und auf Aurora PostgreSQL-kompatible Edition zu erweitern.

F: Ist Parallel Query für alle Instance-Typen verfügbar?

Nein. Aktuell können Sie Parallel Query mit Instances in der R*-Instance-Familie verwenden.

F: Ist Parallel Query mit allen anderen Aurora-Funktionen kompatibel?

Anfänglich ist dies nicht möglich. Derzeit können Sie sie nur für Datenbank-Cluster aktivieren, die nicht die Funktionen Serverless oder Backtrack ausführen. Außerdem werden keine Aurora-spezifischen Funktionen mit MySQL 5.7-Kompatibilität unterstützt.

F: Wenn die Parallelabfrage Abfragen mit nur wenigen Leistungseinbußen beschleunigt, sollte ich sie dann einfach immer einschalten?

Nein. Obwohl wir erwarten, dass Parallel Query in den meisten Fällen die Latenzzeiten verbessert, können Ihnen höhere E/A-Kosten entstehen. Wir empfehlen, dass Sie Ihren Workload mit ein- und ausgeschalteter Funktion jeweils gründlich testen. Wenn Sie überzeugt sind, dass Parallel Query die richtige Wahl ist, können Sie sich darauf verlassen, dass der Abfrageoptimierer automatisch entscheidet, welche Abfragen Parallel Query verwenden sollen. In den seltenen Fällen, in denen der Optimierer nicht die optimale Entscheidung trifft, können Sie die Einstellung überschreiben.

F: Kann ich mit Parallel Query von Aurora mein Data Warehouse ersetzen?

Aurora Parallel Query ist kein Data Warehouse und bietet nicht die in solchen Produkten übliche Funktionalität. Es wurde entwickelt, um die Abfrageleistung Ihrer relationalen Datenbank zu beschleunigen, und eignet sich für Anwendungsfälle wie die operative Analyse, wenn Sie schnelle analytische Abfragen auf neue Daten in Ihrer Datenbank durchführen müssen.

Amazon DevOps Guru für RDS

F: Was ist Amazon DevOps Guru für RDS?

Amazon DevOps Guru für RDS ist eine neue, auf ML basierende Funktion für Amazon RDS, die automatisch Leistungs- und Betriebsprobleme von Datenbanken erkennt und diagnostiziert und es Ihnen ermöglicht, Herausforderungen innerhalb von Minuten statt Tagen zu bewältigen. Amazon DevOps Guru für RDS ist eine Funktion von Amazon DevOps Guru, die betriebliche- und Leistungsherausforderungen für alle Amazon-RDS-Engines und Dutzende anderer Ressourcentypen erkennt. DevOps Guru für RDS erweitert die Fähigkeiten von DevOps Guru, um eine Vielzahl von datenbankbezogenen Herausforderungen in Amazon RDS zu erkennen, zu diagnostizieren und zu beheben, wie z. B. Überbeanspruchung von Ressourcen und Fehlverhalten von SQL-Abfragen. Wenn ein Problem auftritt, ist Amazon DevOps Guru für RDS darauf ausgelegt, sofort Entwickler und DevOps-Techniker zu benachrichtigen und Diagnoseinformationen bereitzustellen. Es bietet den Kunden außerdem Details zum Ausmaß des Problems und intelligente Empfehlungen zur Behebung datenbankbezogener Leistungs-Bottleneck- und operativer Probleme.

F: Warum sollte Ich DevOps Guru für RDS verwenden?

Amazon DevOps Guru für RDS ist darauf ausgelegt, den manuellen Aufwand und die benötigte Zeit (Minuten statt Tage und Stunden) zu reduzieren, die für das Aufspüren und Beheben schwer zu findender Leistungs-Flaschenhälse in Ihrem Relationalen-Datenbank-Workload benötigt wird. Sie können DevOps Guru für RDS für jede Amazon Aurora Datenbank aktivieren und es wird Leistungsherausforderungen für Ihre Workloads automatisch erkennen, Ihnen eine Alarmmeldung zu jedem Vorfall schicken, die Ergebnisse erläutern und Aktionen zur Behebung der Herausforderungen empfehlen. DevOps Guru für RDS macht die Datenbank-Verwaltung zugänglicher für Nicht-Experten und unterstützt Datenbank-Experten, so dass sie sogar noch mehr Datenbanken verwalten können.

F: Wie funktioniert Amazon DevOps Guru für RDS?

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

F: Was sind die ersten Schritte beim Einstieg in Amazon DevOps Guru für RDS?

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

F: Welche Arten von Problemen kann Amazon DevOps Guru für RDS aufspüren?

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

F: Wie unterscheidet sich DevOps Guru für RDS von Amazon RDS Performance Insights?

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

Weitere Informationen zu Amazon Aurora Preisen

Zur Seite mit den Preisen
Bereit zum Entwickeln?
Erste Schritte mit Amazon Aurora
Haben Sie noch Fragen?
Kontaktieren Sie uns