Allgemeines

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 verfügt über ein verteiltes, fehlertolerantes und selbstheilendes Speichersystem, das von Rechenressourcen entkoppelt ist und automatisch auf bis zu 128 TiB pro Datenban-Instance skaliert. Es bietet hohe Leistung und Verfügbarkeit mit bis zu 15 Read Replikate 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 1/10tel der üblichen Kosten geboten.

Ist Amazon Aurora MySQL-kompatibel?

Amazon Aurora ist drop-in- kompatibel mit vorhandenen 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. Somit ist es einfacher, Anwendungen zwischen den beiden Engines zu verschieben.

Informationen zur Kompatibilität der aktuellen Version von Amazon Aurora MySQL finden Sie in der Dokumentation.

Ist Amazon Aurora 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.

Informationen zur Kompatibilität der aktuellen Version von Amazon Aurora PostgreSQL finden Sie in der Dokumentation.

Amazon unterstützt Aurora PostgreSQL und alle mit Aurora verfügbaren Erweiterungen vollständig. Wenn Sie Unterstützung für Aurora PostgreSQL benötigen, wenden Sie sich bitte an den AWS Support. Wenn Sie über ein aktives AWS-Premium-Support-Konto verfügen, können Sie sich bei Amazon-Aurora-spezifischen Problemen an den AWS Premium Support wenden.

Was sind die ersten Schritte mit Amazon Aurora?

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. Ausführliche Anleitungen und Ressourcen finden Sie auf unserer Seite Erste Schritte mit Aurora.

Wie viel kostet Amazon Aurora?

Für die Bereitstellung von Aurora können Sie On-Demand-Instances wählen und Ihre Datenbank stundenweise bezahlen, ohne langfristige Verpflichtungen oder Vorauszahlungen, oder Sie können Reserved Instances wählen, um zusätzlich zu sparen. Alternativ dazu kann Aurora Serverless automatisch starten, herunterfahren und die Kapazität je nach Bedarf Ihrer Anwendung skalieren. Sie zahlen dabei nur für die verbrauchte Kapazität.

Aktuelle Preisinformationen finden Sie auf unserer Aurora-Preisseite.

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 sechs Mal so hoch sein wird, wie auf der Preisseite angezeigt?

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.

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

Die regionale Verfügbarkeit für Amazon Aurora können Sie hier einsehen.

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

Wenn Sie von MySQL zu Amazon Aurora (und umgekehrt) migrieren möchten, haben Sie 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-für-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 Größe des Datensatzes ab. Weitere Informationen finden Sie unter Bewährte Methoden für die Migration von MySQL-Datenbanken in Amazon Aurora.

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

Wenn Sie von PostgreSQL zu Amazon Aurora (und umgekehrt) migrieren möchten, haben Sie 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-für-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 Größe des Datensatzes ab.

Um SQL-Server-Datenbanken auf die Aurora PostgreSQL-kompatible Edition zu migrieren, können Sie Babelfish für Aurora PostgreSQL verwenden. Ihre Anwendungen werden ohne Änderungen funktionieren. Weitere Informationen finden Sie in der Babelfish-Dokumentation.

Ist Amazon Aurora Teil des kostenlosen AWS-Kontingents?

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.
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.

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

E/A-Vorgänge sind Ein- und Ausgabe-Operationen, die Aurora-Datenbank-Engine in ihrer Solid State Drive (SSD)-basierten virtualisierten Speicherebene durchführt. Jeder Datenbank-Seiten-Lesevorgang zählt als ein E/A.

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. 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“.

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

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

Leistung

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-Workloads 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.

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 Datenbank-Workloads 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.

Wie kann ich meine Datenbank-Workload 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 Verarbeitungs-Workloads. Zur Optimierung des Durchsatzes Ihres Workloads in Amazon Aurora empfehlen wir, Ihre Anwendungen so zu konstruieren, dass eine große Menge gleichzeitiger Abfragen und Transaktionen ausgeführt wird.

Wie kann ich meine Datenbank-Workload 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 des Durchsatzes Ihres Workloads 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

Was sind die minimalen und maximalen Speichergrenzen einer Amazon Aurora-Datenbank?

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

Wie skaliere ich die mit meiner Amazon-Aurora-DB-Instance verbundenen Computing-Ressourcen?

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

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

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

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

Backup und Wiederherstellung

Wie aktiviere ich die Sicherung für meine DB-Instance?

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

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

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

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 aus einem DB-Snapshot wiederherstellen oder eine zeitpunktbezogene Wiederherstellung auf eine neue Instance durchführen. Beachten Sie, dass der späteste wiederherstellbare Zeitpunkt für einen zeitpunktbezogenen Wiederherstellungsvorgang bis zu fünf Minuten in der Vergangenheit liegen kann.

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).

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.

Werden freigegebene Snapshots in Rechnung gestellt?

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

Kann ich automatisch Snapshots freigeben?

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

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.

In welchen Regionen kann ich meine Aurora-Snapshots freigeben?

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

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.

Kann ich verschlüsselte Aurora-Snapshots freigeben?

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

Hohe Verfügbarkeit und Replikation

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.

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 Protokoll aus dem letzten Datenbank-Prüfpunkt wiedergeben (was normalerweise 5 Minuten dauert) und rückmelden, dass alle Änderungen angewendet wurden. Das reduziert in den meisten Fällen die Dauer des Neustarts auf weniger als 60 Sekunden.

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

Welche Arten von Replikate unterstützt Aurora?

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

Kann ich mit Amazon Aurora regionenübergreifende Replikate 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.

Kann ich Aurora Replikate 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 im Cluster; die Aurora Replikate im Cluster liegen normalerweise mit einer Verzögerung im Zehntel-Millisekundenbereich hinter dem primären.

Kann ich für meine Anwendung von meinem aktuellen primären 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 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.

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 Amazon-Aurora-Benutzerhandbuch.

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.

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

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

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.

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 Version 1 ausführen und die DB-Instance oder AZ nicht mehr verfügbar sind, erstellt Aurora die DB-Instance automatisch in einer anderen AZ. Aurora Serverless v2 funktioniert wie bereitgestellt für den Failover und sonstige hochverfügbare Funktionen. Weitere Informationen finden Sie unter Aurora Serverless v2 und hohe Verfügbarkeit. 
  • 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.

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.

Wie groß wird der Zeitunterschied zwischen der primären Instance und meinen Replikaten sein?

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

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.

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.

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.

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.

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.

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.

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-Workloads an mehrere Instances in einem Datenbank-Cluster weiterzuleiten und mit größerer Verfügbarkeit zu laufen.

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

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.

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.

Kann ich eine bestehende unverschlüsselte Datenbank verschlüsseln?

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.

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 Handbuch zur Konnektivität von Amazon Aurora.

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-komform. Sie können sie nutzen, um HIPAA-konforme Anwendungen zu erstellen und gesundheitsbezogene Informationen zu speichern, einschließlich geschützter Gesundheitsinformationen (PHI) im Rahmen eines mit AWS abgeschlossenen Business Associate Addendum (BAA). Wenn Sie bereits eine BAA mit AWS abgeschlossen haben, sind keine weiteren Maßnahmen erforderlich, um diese Services für das/die von Ihrer BAA abgedeckte(n) Konto/Konten zu nutzen. Weitere Informationen über die Verwendung von AWS zur Erstellung konformer Anwendungen finden Sie unter Anbieter im Gesundheitswesen.

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 Liste von CVEs finden Sie in den Sicherheitsupdates für Amazon Aurora.

Wie kann ich Sicherheitsbedrohungen für meine Aurora-Datenbank erkennen?

Aurora ist mit Amazon GuardDuty integriert, um Sie bei der Erkennung potenzieller Bedrohungen für in Aurora-Datenbanken gespeicherte Daten zu unterstützen. GuardDuty RDS Protection profiliert und überwacht Anmeldeaktivitäten für bestehende und neue Datenbanken in Ihrem Konto und nutzt maßgeschneiderte ML-Modelle, um verdächtige Logins zu Aurora-Datenbanken genau erkennen zu können. Weitere Informationen finden Sie unter Überwachung von Bedrohungen mit GuardDuty-RDS-Schutz und dem Benutzerhandbuch zum GuardDuty-RDS-Schutz.

Serverless

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.

Was ist der Unterschied zwischen Aurora Serverless v2 und v1?

Aurora Serverless v2 jede Art von Datenbank-Workload. Das Spektrum reicht von Entwicklungs- und Testumgebungen, Websites und Anwendungen mit seltenen, intermittierenden oder unvorhersehbaren Workloads bis hin zu den anspruchsvollsten geschäftskritischen Anwendungen, die eine hohe Skalierung und hohe Verfü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.

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.

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.

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.

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

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).

Wie stelle ich eine Verbindung zu einem Aurora-Serverless-DB-Cluster her?

Sie können auf einen Aurora-Serverless-DB-Cluster mithilfe einer Client-Anwendung zugreifen, die in der gleichen VPC ausgeführt wird. Sie können einer Aurora Serverless DB keine öffentliche IP-Adresse zuweisen.

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.

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.

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

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.

Was ist der angestrebte 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.

Welche Vorteile bietet 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.

Welche spezifischen Abfragen werden unter Parallel Query 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.

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 Möglichkeit, dass die Leistung langsamer wird?

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

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

Änderungen in der Abfragesyntax sind nicht 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.

Wie schalte ich die Funktion Parallel Query ein oder aus?

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

Fallen bei der Verwendung von Parallel Query zusätzliche Gebühren an?

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

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

Nein, die E/A-Kosten für Parallel Query für Ihre Abfrage werden auf der Speicherebene gemessen und sind bei aktivierter Parallel Query gleich oder höher. 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.

Weitere Informationen über Parallel Query finden Sie in der Dokumentation.

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.

Ist Parallel Query mit allen anderen Aurora-Funktionen kompatibel?

Anfangs nicht. 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.

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.

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.

Wenn Sie ein Cloud-Data-Warehouse im Exabyte-Bereich benötigen, erwägen Sie Amazon Redshift.

Amazon DevOps Guru für RDS

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, (einschließlich Amazon Aurora) die automatisch Leistungs- und Betriebsprobleme von Datenbanken erkennt und diagnostiziert und es Ihnen ermöglicht, Herausforderungen innerhalb von Minuten statt Tagen zu bewältigen.

Amazon DevOps Guru für RDS ist 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, Entwickler und DevOps-Techniker sofort zu benachrichtigen und Diagnoseinformationen bereitzustellen. Es bietet den Kunden außerdem Details zum Ausmaß des Problems und intelligente Empfehlungen zur Behebung datenbankbezogener Leistungs-Bottleneck- und operativer Probleme.

Warum sollte Ich DevOps Guru für RDS verwenden?

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

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

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 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.

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.

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 Anwendungs-Servicequalität beinträchtigen könnten wie zum Beispiel Pile-Ups, Connection Storms, SQL-Regressionen, CPU- und I/O-Konflikte und Speicherprobleme.

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

Erkenntnisse zur Amazon-RDS-Leistung 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.

Blau/Grün-Bereitstellungen von Amazon RDS

Welche Versionen unterstützen Blau/Grün-Bereitstellungen von Amazon RDS?

Blau/Grün-Bereitstellungen von Amazon stehen in den Versionen 5.6 der mit Amazon MySQL kompatiblen Edition zur Verfügung. Erfahren Sie mehr über verfügbare Versionen in der Dokumentation für Aurora.

Welche Regionen unterstützen Blau/Grün-Bereitstellungen von Amazon RDS?

Blau/Grün-Bereitstellungen von Amazon RDS sind in allen AWS-Regionen (Mit der Ausnahme von AWS-China-Regionen) und in den AWS-GovCloud-Regionen verfügbar.

Wie viel kostet die Nutzung von Blau/Grün-Bereitstellungen von Amazon RDS?

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

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

Welche Art Änderungen kann ich mit Blau/Grün-Bereitstellungen von Amazon RDS vornehmen?

Blau/Grün-Bereitstellungen von Amazon RDS helfen Ihnen dabei, Datenbank-Änderungen sicherer, einfacher und schneller vorzuehmen, wie große und kleine Updates an Versionen, Schema-Änderungen, Instance-Skalierung, Änderungen an den Engine-Parametern und Wartungs-Aktualisierungen.

Was ist die „Blau-Umgebung“ bei Blau-Grün-Bereitstellungen von Amazon RDS? Was ist die „Grün-Umgebung“?

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

Wie funktionieren Umschaltungen bei Blau/Grün-Bereitstellungen von Amazon RDS?

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

Was passiert nach der Umschaltung der Blau/Grün-Bereitstellungen von Amazon RDS mit meiner alten Produktionsumgebung?

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

Was überprüft der Integritätsschutz der Umschaltung der Blau/Grün-Bereitstellungen von Amazon RDS?

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

Unterstützen Blau/Grün-Bereitstellungen von Amazon RDS die Amazon-Aurora-Datenbanken?

Nein. Blau/Grün-Bereitstellungen unterstützen Amazon-Aurora-Datenbanken nicht.

Kann ich Blau/Grün-Bereitstellungen von Amazon RDS verwenden, um Änderungen rückgängig zu machen?

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

Trusted-Language-Erweiterungen für PostgreSQL

Warum sollte ich Trusted-Language-Erweiterungen für PostgreSQL verwenden?

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

Was sind herkömmliche Risiken der Ausführung von Erweiterungen auf PostgreSQL und wie mindert TLE für PostgreSQL diese Risiken?

PostgreSQL-Erweiterungen werden im gleichen Prozess-Zeitraum ausgeführt, um eine hohe Leistung sicherzustellen. Jedoch könnten Erweiterungen Software-Fehler haben, die einen Absturz der Datenbank verursachen können.
 
TLE für PostgreSQL bietet mehrere Schutzschichten zur Minderung dieses Risikos. TLE wurde entwickelt, um den Zugriff auf System-Ressourcen einzuschränken. Die Rolle rds_superuser kann festlegen, wer zur Installation von bestimmten Erweiterungen berechtigt ist. Jedoch können diese Änderungen nur über die TLE-API durchgeführt werden. TLE soll die Auswirkung eines Erweiterungsfehlers auf eine einzelne Datenbank-Verbindung begrenzen. Neben diesen Schutzmaßnahmen soll TLE den Datenbank-Administratoren (DBAs) in der Rolle rds_superuser präzise Online-Kontrolle darüber zur Verfügung stellen, wer Erweiterungen installieren kann und sie können ein Berechtigungsmodel für die Ausführung erstellen. Nur Nutzer mit ausreichenden Zugriffsrechten können Erweiterungen ausführen und erstellen, und zwar mit dem Befehl „CREATE EXTENSION (ERWEITERUNG ERSTELLEN)“ auf einer TLE-Erweiterung. DBAs können „PostgreSQL-Hooks“ zulassen, die für höher entwickelte Systeme erforderlich sind, welche die interne Verhaltensweise der Datenbank ändern und üblicherweise die höheren Zugriffsrechte erfordern.

Wie ist TLE für PostgreSQL mit anderen AWS-Services verbunden und wie funktioniert es mit diesen?

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

In welchen Versionen von PostgreSQL kann ich TLE für PostgreSQL ausführen?

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

In welchen Regionen sind Trusted-Language-Erweiterungen für PostgreSQL verfügbar?

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

Wie viel kostet es, TLE zu betreiben?

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

Wie unterscheidet sich TLE für PostgreSQL von Erweiterungen, die heute auf Amazon Aurora und Amazon RDS verfügbar sind?

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

Was sind einige Beispiele von Erweiterungen, die ich mit TLE für PostgreSQL ausführen könnte?

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

Welche Programmiersprachen kann ich verwenden, um TLE für PostgreSQL zu entwickeln?

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

Wie stelle ich eine TLE für PostgreSQL-Erweiterung bereit?

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

Wie kommunizieren TLE für PostgreSQL-Erweiterungen mit der PostgreSQL-Datenbank?

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

Wo kann ich mehr über das Open-Source-Projekt von TLE für PostgreSQL erfahren?

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

Weitere Informationen zu Preisen von Amazon Aurora

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