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 Entwicklertools für die Entwicklung von Serverless- 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 Lesereplikaten mit geringer Latenzzeit, zeitpunktbezogener Wiederherstellung, kontinuierlicher Sicherung in Amazon Simple Storage Service (Amazon S3) und Replikation über drei Availability Zones (AZs).

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.

Ist Amazon Aurora MySQL-kompatibel?

Amazon Aurora ist sofort 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 Standardtools zum Import/Export 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 Aurora-spezifischen Problemen an den AWS Premium Support wenden.

Was sind die ersten Schritte mit Aurora?

Wenn Sie Aurora ausprobieren möchten, melden Sie sich bei der AWS-Managementkonsole an und wählen Sie in der Datenbank-Kategorie RDS und dann Amazon Aurora als Datenbank-Engine. Ausführliche Anleitungen und Ressourcen finden Sie auf unserer Seite Erste Schritte mit Aurora.

In welchen AWS-Regionen ist Aurora verfügbar?

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

Wie kann ich von MySQL zu Aurora und umgekehrt migrieren?

Wenn Sie von MySQL zu 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.
  • Sie können auch das Migrationsfeature Amazon-RDS-DB-Snapshot verwenden, um einen Snapshot von Amazon RDS für MySQL DB über die AWS-Managementkonsole zu Aurora zu migrieren.

Die Migration nach Aurora 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 nach Aurora und umgekehrt migrieren?

Wenn Sie von PostgreSQL nach 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 Aurora – und umgekehrt.
  • Sie können auch das Migrationsfeature RDS-DB-Snapshot nutzen, um mit der AWS-Managementkonsole einen Snapshot von Amazon RDS für PostgreSQL DB nach Aurora zu migrieren.

Die Migration nach Aurora 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 zur PostgreSQL-kompatible Amazon-Aurora-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.

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

Nein, Aurora funktioniert mit Standard-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.

Fakturierung

Wie viel kostet Aurora?

Auf der Aurora-Preisseite finden Sie die aktuellen Preisinformationen.

Ist Aurora Teil des kostenlosen AWS-Kontingents?

Derzeit gibt es kein kostenloses AWS-Kontingent für Aurora. Aurora speichert Ihre Daten jedoch dauerhaft in drei Availability Zones in einer Region und berechnet nur eine Kopie der Daten. Backups von bis zu 100 % der Größe Ihres Datenbank-Clusters werden Ihnen nicht in Rechnung gestellt. Während des Backup-Aufbewahrungszeitraums, den Sie für Ihren Datenbank-Cluster konfiguriert haben, werden Ihnen auch keine Snapshots in Rechnung gestellt.

Aurora repliziert meine Daten in drei Availability Zones. Bedeutet das, dass der tatsächliche Preis für den Speicher das Dreifache sein wird, wie auf der Preisseite angezeigt?

Nein. Die 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 Aurora verbrauchten Speichers.

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

E/A-Vorgänge sind Ein- und Ausgabe-Operationen, die die Aurora-Datenbank-Engine in ihrer SSD-basierten virtualisierten Speicherschicht durchführt. Jeder Datenbank-Seiten-Lesevorgang zählt als ein E/A.
Die Aurora-Datenbank-Engine führt Lesevorgänge in der Speicherschicht 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 Amazon-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.

E/A-Schreibvorgänge werden in 4-KB-Einheiten gezählt. Eine Protokoll-Aufzeichnung mit 1,024 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 Transaktionsprotokoll weniger als 4 KB hat, können jedoch zur Optimierung der E/A-Nutzung durch die Aurora-Datenbank-Engine zusammengefasst 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. Um Ihren E/A-Verbrauch zu ermitteln, gehen Sie in den Amazon-RDS-Bereich der Konsole, sehen Sie sich Ihre Liste der Instances an, wählen Sie Ihre Aurora-Instances aus und suchen Sie dann im Überwachungsbereich nach den Metriken „VolumeReadIOPs“ und „VolumeWriteIOPs“.

Weitere Informationen zur Preisgestaltung für E/A-Vorgänge finden Sie auf der Aurora-Preisseite. Wenn Sie Ihre Datenbank-Cluster für die Aurora-Standardkonfiguration konfigurieren, werden Ihnen Lese- und Schreib-E/A-Vorgänge in Rechnung gestellt. Wenn Sie Ihre Datenbank-Cluster für Amazon Aurora I/O-Optimized konfigurieren, fallen Ihnen keine Gebühren für Lese- und Schreibvorgänge an.

Was sind Aurora Standard und Aurora I/O-Optimized?

Aurora bietet Ihnen die Flexibilität, Ihre Datenbankausgaben zu optimieren, indem Sie je nach Ihren Anforderungen an Preisleistung und Preisvorhersehbarkeit zwischen zwei Konfigurationsoptionen wählen. Die beiden Konfigurationsoptionen sind Aurora Standard und Aurora I/O-Optimized. Keine der beiden Optionen erfordert E/A im Voraus oder Speicherbereitstellung, und beide können E/A-Vorgänge skalieren, um Ihre anspruchsvollsten Anwendungen zu unterstützen.

Aurora Standard ist eine Datenbank-Cluster-Konfiguration, die kostengünstige Preise für die überwiegende Mehrheit der Anwendungen mit geringer bis mäßiger E/A-Auslastung bietet. Mit Aurora Standard zahlen Sie für Datenbank-Instances, Speicher und Pay-per-Request-E/A.

Aurora I/O-Optimized ist eine Datenbank-Cluster-Konfiguration, die eine verbesserte Preisleistung für E/A-intensive Anwendungen wie Zahlungsverarbeitungssysteme, E-Commerce-Systeme und Finanzanwendungen bietet. Wenn Ihre E/A-Ausgaben 25 % Ihrer gesamten Aurora-Datenbankausgaben übersteigen, können Sie mit Aurora I/O-Optimized bis zu 40 % der Kosten für E/A-intensive Workloads sparen. Aurora I/O-Optimized bietet vorhersehbare Preise für alle Anwendungen, da keine Gebühren für Lese- und Schreib-E/A-Vorgänge anfallen. Somit ist diese Konfiguration ideal für Workloads mit hoher E/A-Variabilität.

Wann sollte ich Aurora I/O-Optimized verwenden?

Aurora I/O-Optimized ist die ideale Wahl, wenn Sie vorhersehbare Kosten für jede Anwendung benötigen. Es bietet eine verbesserte Preisleistung für E/A-intensive Anwendungen, die einen hohen Schreibdurchsatz erfordern oder analytische Abfragen zur Verarbeitung großer Datenmengen ausführen. Kunden, deren I/O-Ausgaben 25 % ihrer Aurora-Rechnung übersteigen, können mit Aurora I/O-Optimized bis zu 40 % der Kosten für I/O-intensive Workloads sparen.

Wie migriere ich meinen bestehenden Datenbank-Cluster, um Aurora I/O-Optimized zu verwenden?

Sie können die in der AWS-Managementkonsole verfügbare Ein-Klick-Funktion nutzen, um den Speichertyp Ihrer vorhandenen Datenbank-Cluster so zu ändern, dass er Aurora I/O-Optimized ist. Sie können auch die AWS-Befehlszeilenschnittstelle (AWS CLI) oder das AWS-SDK aufrufen, um diese Änderung vorzunehmen.

Kann ich zwischen der Aurora I/O-Optimized- und der Aurora-Standardkonfiguration hin und her wechseln?

Sie können Ihre vorhandenen Datenbank-Cluster alle 30 Tage auf Aurora I/O-Optimized umstellen. Sie können jederzeit wieder zu Aurora Standard wechseln.

Funktioniert Aurora I/O-Optimized mit Reserved Instances?

Ja, Aurora I/O-Optimized funktioniert mit vorhandenen Aurora Reserved Instances. Aurora berücksichtigt automatisch den Preisunterschied zwischen Aurora Standard und Aurora I/O-Optimized mit Reserved Instances. Mit den Rabatten für Reserved Instances mit Aurora I/O-Optimized können Sie noch mehr Einsparungen bei Ihren E/A-Ausgaben erzielen.

Ändert sich der Preis für Backtrack, Snapshot, Export oder kontinuierlichen Backup mit Aurora I/O-Optimized?

Der Preis für Backtrack, Snapshot, Export oder kontinuierlichen Backup ändert sich mit Aurora I/O-Optimized nicht.

Bezahle ich mit Aurora Global Database mit Aurora I/O-Optimized weiterhin für die E/A-Vorgänge, die für die regionsübergreifende Replikation von Daten erforderlich sind?

Ja, die Gebühren für die E/A-Vorgänge, die für die regionsübergreifende Datenreplikation erforderlich sind, fallen weiterhin an. Aurora I/O-Optimized berechnet keine Gebühren für Lese- und Schreib-E/A-Vorgänge, was sich von der Datenreplikation unterscheidet.

Was sind die Kosten für optimierte Lesevorgänge von Amazon Aurora für Aurora PostgreSQL?

Für die optimierten Lesevorgänge von Amazon Aurora für Aurora PostgreSQL fallen neben dem Preis für Intel-basierte R6id- und Graviton-basierte R6gd-Instances keine zusätzlichen Kosten an. Weitere Informationen finden Sie auf der Preisübersicht für Aurora.

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 Backups 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 macht Ihre Daten automatisch über drei Availability Zones (AZs) in einer Region hinweg dauerhaft und versucht automatisch, Ihre Datenbank in einer fehlerfreien AZ ohne Datenverlust wiederherzustellen. Im unwahrscheinlichen Fall, dass Ihre Daten im Amazon-Aurora-Speicher nicht verfügbar sind, können Sie 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 dieses Feature 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-Replikaten sichtbar.

Mit Amazon-Aurora-MySQL-kompatible Edition können Sie auch unter Anwendung der Binlog-basierten MySQL-Replizierungs-Engine regionsübergreifende MySQL-Lesereplikate erstellen. Bei MySQL-Lesereplikaten 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-Replikaten.

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

Feature Amazon-Aurora-Replikate
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 ein einfach zu benutzendes logisches, regionenübergreifendes Reproduktionsfeature, das 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-Replikate 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-Replikate hinzufügen. Aurora-Replikate in der gleichen AWS-Region teilen sich den gleichen zugrunde liegenden Speicherplatz wie die primäre Instance. Jedes Aurora-Replikat 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 ein Aurora-Replikat in derselben oder einer anderen AZ haben, wechselt Amazon Aurora den anerkannten Namensdatensatz (CNAME) für Ihre DB-Instance, sodass auf das fehlerfreie Replikat verwiesen wird, das zur neuen primären Instance hochgestuft wird. Das gesamte Failover ist in der Regel innerhalb von 30 Sekunden abgeschlossen. Für eine verbesserte Stabilität und schnellere Failover sollten Sie Amazon RDS Proxy verwenden, der automatisch eine Verbindung zur Failover-DB-Instance herstellt und gleichzeitig die Anwendungsverbindungen beibehält. Proxy macht Failover für Ihre Anwendungen transparent und reduziert die Failover-Zeiten um bis zu 66 %
  • 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 Features. Weitere Informationen finden Sie unter Aurora Serverless v2 und hohe Verfügbarkeit. 
  • Verfügen Sie über keine Aurora-Replikate (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 ein Amazon-Aurora-Replikat habe, das 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-Replikat weitergeleitet, das zur primären Instance hochgestuft wird.

Außerdem wird der Lesedatenverkehr Ihrer Amazon-Aurora-Replikate kurz unterbrochen. Wenn Sie den Cluster-Leser-Endpunkt verwenden, um Ihren Lesedatenverkehr an das Aurora-Replikat zu leiten, werden die schreibgeschützten Verbindungen an das neu hochgestufte Aurora-Replikat 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-Replikate dasselbe Daten-Volume 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 ein Feature, das 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. Dieses Feature 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.

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 CVE-Liste 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. Mit Aurora Serverless können Sie Ihre Datenbank in der Cloud ausführen, ohne die Datenbankkapazität verwalten zu müssen. Die manuelle Verwaltung der Datenbankkapazität kann zeitaufwändig sein und zu einer ineffizienten Nutzung der Datenbankressourcen führen. Mit Aurora Serverless können Sie eine Datenbank erstellen, den gewünschten Kapazitätsbereich der Datenbank angeben und Ihre Anwendungen 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-Features unterstützt Aurora Serverless v2?

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

Kann ich anfangen, Aurora Serverless v2 mit bereitgestellten Instances in meinem bestehenden Aurora-DB-Cluster zu verwenden?

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?

In Aurora Serverless wird die Datenbankkapazität in ACUs gemessen. Sie zahlen eine Pauschale pro Sekunde der ACU-Nutzung. Die Datenverarbeitungskosten für die Ausführung Ihrer Workloads auf Aurora Serverless hängen von der ausgewählten Datenbank-Cluster-Konfiguration ab: Aurora Standard oder Aurora I/O-Optimized. Besuchen Sie die Aurora-Preisseite für Informationen zu Preisen und regionaler Verfügbarkeit.

Parallele Abfrage

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

Welche Versionen von Amazon Aurora unterstützen Parallel Query?

Parallel Query ist für die MySQL-5.7- und MySQL-8.0-kompatiblen Versionen von Amazon Aurora verfügbar.

Ist Parallel Query mit allen anderen Aurora-Features kompatibel?

Parallel Query ist mit Aurora Serverless v2 und Backtrack kompatibel.

Wenn Parallel Query 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 ausgeschaltetem Feature 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.

Optimierte Lesevorgänge

Was sind optimierte Lesevorgänge von Amazon Aurora für Aurora PostgreSQL?

Optimierte Lesevorgänge für Amazon Aurora (verfügbar für Aurora PostgreSQL) ist eine neue Preis-Leistungs-Option, die eine bis zu 8-fache Verbesserung der Abfragelatenz und eine Kostenersparnis von bis zu 30 % im Vergleich zu Instances ohne diese Funktion ermöglicht. Sie ist ideal für Anwendungen mit großen Datenmengen, die die Speicherkapazität einer Datenbank-Instance überschreiten.

Wie verbessern die optimierten Lesevorgänge von Amazon Aurora für Aurora PostgreSQL die Abfrageleistung?

Optimized-Reads-Instances von Amazon Aurora verwenden lokale NVMe-basierte SSD-Blockspeicher, die auf Graviton-basierten r6gd- und Intel-basierten r6id-Instances verfügbar sind, um die Abfragelatenz von Anwendungen mit Datensätzen zu verbessern, die die Speicherkapazität einer Instance überschreiten. Optimierte Lesevorgänge umfassen Leistungsverbesserungen wie mehrstufiges Caching und temporäre Objekte.

Mehrstufiges Caching bietet eine bis zu achtmal verbesserte Abfragelatenz und Kosteneinsparungen von bis zu 30 % für leseintensive, E/A-intensive Anwendungen wie operative Dashboards, Anomalieerkennung und vektorbasierte Ähnlichkeitssuchen. Diese Vorteile werden durch die automatische Zwischenspeicherung von Daten, die aus dem Puffercache der In-Memory-Datenbank in den lokalen Speicher verdrängt werden, erzielt, um nachfolgende Zugriffe auf diese Daten zu beschleunigen. Mehrstufiges Caching ist nur für die Amazon-Aurora-PostgreSQL-Edition mit der E/A-optimierten Aurora Konfiguration verfügbar.

Temporäre Objekte ermöglichen eine schnellere Abfrageverarbeitung, indem temporäre Tabellen (die von Aurora PostgreSQL erstellt wurden) im lokalen Speicher platziert werden. Dadurch wird die Leistung von Abfragen verbessert, die Sortierungen, Hash-Aggregationen, Verbindungen mit hoher Last und andere datenintensive Operationen beinhalten.

Wann sollte ich Amazon Aurora Optimized Reads für Aurora PostgreSQL verwenden?

Amazon Aurora Optimized Reads für Aurora PostgreSQL bietet Kunden mit latenzempfindlichen Anwendungen und großen Arbeitssätzen eine überzeugende Preis-Leistungs-Alternative, um ihre geschäftlichen SLAs zu erfüllen und noch mehr mit ihren Instances anfangen zu können.

Welche Datenbank-Instance-Typen unterstützen Amazon-Aurora-optimierte Lesevorgänge für Aurora PostgreSQL? In welchen Regionen ist die Funktion verfügbar?

Amazon Aurora Optimized Reads sind auf Intel-basierten R6id- und Graviton-basierten R6gd-Instances verfügbar. Die regionale Verfügbarkeit für Aurora können Sie hier einsehen.

Welche Engine-Versionen von Amazon Aurora unterstützt Aurora Optimized Reads für Aurora PostgreSQL?

Amazon Aurora Optimized Reads ist für die PostgreSQL-kompatible Edition von Aurora in R6id- und R6gd-Instances verfügbar. Unterstützte Engine-Versionen sind 15.4 und höher sowie 14.9 und höher auf Aurora PostgreSQL.

Kann ich Amazon Aurora Optimized Reads für Aurora PostgreSQL mit Aurora Serverless v2 verwenden?

Amazon Aurora Optimized Reads ist in Aurora Serverless v2 (ASv2) nicht verfügbar.

Kann ich die Amazon Aurora Optimized Reads für Aurora PostgreSQL mit den Konfigurationen Aurora Standard und Aurora I/O-Optimized verwenden?

Ja, Amazon Aurora Optimized Reads ist in beiden Konfigurationen verfügbar. Bei beiden Konfigurationen ordnen die Instances, die optimierte Lesevorgänge aktivieren, temporäre Tabellen automatisch dem NVMe-basierten lokalen Speicher zu, um die Leistung von analytischen Abfragen und Index-Neuaufbauten zu verbessern.

Für E/A-intensive Workloads, die einen hohen Anteil an Lesevorgängen aufweisen, können Optimized-Reads-fähige Instances auf Aurora PostgreSQL, die so konfiguriert sind, dass sie Aurora I/O-Optimized verwenden, automatisch Daten, die aus dem Speicher verdrängt wurden, auf NVMe-basiertem lokalem Speicher zwischenspeichern, um eine bis zu 8-fach verbesserte Abfragelatenz und eine Kostenersparnis von bis zu 30 % im Vergleich zu Instances ohne diese Funktion zu erzielen – für Anwendungen mit großen Datensätzen, die die Speicherkapazität einer Datenbank-Instance übersteigen.

Wie kann ich mit Amazon Aurora Optimized Reads für Aurora PostgreSQL beginnen?

Kunden können mit Amazon Aurora Optimized Reads über die AWS-Managementkonsole, die CLI und das SDK loslegen. Optimized Reads ist standardmäßig auf allen R6id- und R6gd-Instances verfügbar. Um diese Funktion zu nutzen, können Kunden einfach ihre bestehenden Aurora-Datenbank-Cluster so modifizieren, dass sie R6id- und R6gd-Instances enthalten, oder neue Datenbank-Cluster mit diesen Instances erstellen. Lesen Sie die Dokumentation zu Amazon Aurora Optimized Reads, um loszulegen.

Wie viel des verfügbaren lokalen Speichers steht für Amazon Aurora Optimized Reads für Aurora PostgreSQL zur Verfügung?

Ungefähr 90 % des verfügbaren lokalen Speichers auf den R6id- und R6gd-Instances stehen für optimierte Lesevorgänge zur Verfügung. Aurora reserviert 10 % des NVMe-Speichers, um die Auswirkungen der SSD-Schreibverstärkung zu reduzieren. Die Zuweisung des verfügbaren Speichers hängt davon ab, welche optimierte Lesevorgangs-Funktionen aktiviert sind.

Wenn Sie Optimized Reads mit den Funktionen Temporäre Objekte und Mehrstufiges Caching verwenden, entspricht der für temporäre Objekte verfügbare Speicherplatz im lokalen Speicher der doppelten Größe des auf diesen Instances verfügbaren Speichers. Dies entspricht der aktuellen Größe des temporären Objektspeichers in Aurora PostgreSQL. Der verbleibende lokale Speicherplatz steht für das Zwischenspeichern von Daten zur Verfügung.

Wenn optimierte Lesevorgänge nur mit der Feature Temporäre Objekte verwendet wird, steht der gesamte verfügbare lokale Speicherplatz für temporäre Objekte zur Verfügung. Wenn Sie beispielsweise eine r6gd.8xlarge-Instance mit den Funktionen Temporäre Objekte und mehrstufiges Caching verwenden, sind 534 GiB (2x Speicherkapazität) für temporäre Objekte und 1054 GiB für mehrstufigen Cache reserviert.

Was passiert bei einem Ausfall des lokalen Speichers?

Wenn der lokale Speicher ausfällt, führt Aurora automatisch einen Host-Austausch durch. In einem Datenbank-Cluster mit mehreren Knoten löst dies ein regionsinternes Failover aus.

Wie wirkt sich Amazon Aurora Optimized Reads für Aurora PostgreSQL auf die Abfragelatenz im Falle eines Datenbank-Failovers aus?

Bei einem Failover der Datenbank wird die Abfragelatenz nach dem Failover vorübergehend zunehmen. Dieser Anstieg der Latenzzeit wird sich im Laufe der Zeit verringern und schließlich die Abfragelatenz vor dem Failover wieder erreichen. Diese Aufholdauer kann beschleunigt werden, indem das Cluster-Cache-Management (CCM) aktiviert wird. Mit CCM können Kunden eine bestimmte Aurora-PostgreSQL-Datenbank-Instance als Failover-Ziel bestimmen.

Wenn CCM aktiviert ist, spiegelt der lokale Speichercache des designierten Failover-Ziels den lokalen Speichercache der primären Instance genau wider, wodurch die Aufholzeit nach dem Failover reduziert wird. Die Aktivierung von CCM könnte sich jedoch auf die langfristige Effizienz des lokalen Speichercaches auswirken, wenn das designierte Failover-Ziel auch zur Bereitstellung eines Lese-Workloads verwendet wird, der von dem Workload auf der Writer-Instance getrennt ist.

Daher müssen Kunden, die Workloads ausführen, bei denen ein Reader als Standby-Failover bestimmt werden muss, CCM aktivieren, um die Wahrscheinlichkeit zu erhöhen, dass sie ihre Abfragelatenz nach dem Failover schnell wiederherstellen können. Kunden, die getrennte Workloads auf ihren designierten Failover-Zielen ausführen, sollten vor der Aktivierung von CCM ihre Anforderungen an die sofortige Wiederherstellung der Latenz nach dem Failover mit der langfristigen Effektivität der Cache-Leistung abwägen.

Generative KI

Was ist pgvector?

pgvector ist eine Open-Source-Erweiterung für PostgreSQL, die von der Amazon-Aurora-PostgreSQL-kompatiblen Edition unterstützt wird.

Welche Funktionen aktiviert pgvector für Aurora PostgreSQL?

Sie können pgvector verwenden, um Milliarden von Einbettungen zu speichern, zu suchen, zu indizieren und abzufragen, die aus Modellen für Machine Learning (ML) und künstliche Intelligenz (AI) in Ihrer Datenbank generiert werden, wie z. B. aus Amazon Bedrock oder Amazon SageMaker. Eine Vektoreinbettung ist eine numerische Darstellung, die die semantische Bedeutung von Inhalten wie Text, Bildern und Videos darstellt.
 
Mit pgvector können Sie Einbettungen in Ihrer Aurora-PostgreSQL-Datenbank abfragen, um effiziente semantische Ähnlichkeitssuchen dieser als Vektoren dargestellten Datentypen in Kombination mit anderen tabellarischen Daten in Aurora durchzuführen. Dies ermöglicht den Einsatz von generativer KI und anderen KI/ML-Systemen für neue Arten von Anwendungen wie personalisierte Empfehlungen auf der Grundlage ähnlicher Textbeschreibungen oder Bilder, Bewerberabgleiche auf der Grundlage von Gesprächsnotizen, Chatbots und Empfehlungen für die nächstbeste Aktion im Kundenservice auf der Grundlage erfolgreicher Transkripte oder Chat-Sitzungsdialoge und vieles mehr. 
 
Lesen Sie unseren Blogbeitrag über Funktionen von Vektordatenbanken und erfahren Sie, wie man Einbettungen mit der pgvector-Erweiterung in einer Aurora-PostgreSQL-Datenbank speichert, einen interaktiven Chatbot zur Beantwortung von Fragen erstellt und die native Integration zwischen pgvector und Aurora Machine Learning für Stimmungsanalyse verwendet.

Funktioniert pgvector mit Aurora Machine Learning?

Ja. Aurora Machine Learning (ML) stellt ML-Modelle als SQL-Funktionen zur Verfügung, so dass Sie Standard-SQL verwenden können, um ML-Modelle aufzurufen, ihnen Daten zu übergeben und Vorhersagen als Abfrageergebnisse zurückzugeben. pgvector erfordert, dass Vektoreinbettungen in der Datenbank gespeichert werden, was erfordert, dass das ML-Modell auf Quelltext- oder Bilddaten ausgeführt wird, um Einbettungen zu generieren, und dann die Einbettungen im Stapel in Aurora PostgreSQL verschoben werden.

Aurora ML kann dies zu einem Echtzeitprozess machen, der es ermöglicht, die Einbettungen in Aurora PostgreSQL auf dem neuesten Stand zu halten, indem periodische Aufrufe an Amazon Bedrock oder Amazon SageMaker gemacht werden, die die neuesten Einbettungen aus Ihrem Modell zurückgeben.

Inwiefern hilft Aurora Optimized Reads für Aurora PostgreSQL bei der Leistung von pgvector?

Amazon Aurora PostgreSQL Optimized Reads mit pgvector erhöht die Abfragen pro Sekunde für die Vektorsuche bei Workloads, die den verfügbaren Instance-Speicher übersteigen, um das bis zu 9-fache. Möglich wird dies durch die in Optimized Reads verfügbare mehrstufige Caching-Funktion, mit der Daten, die aus dem Puffercache der In-Memory-Datenbank entfernt wurden, automatisch im lokalen Speicher zwischengespeichert werden, um nachfolgende Zugriffe auf diese Daten zu beschleunigen.

Null-ETL-Integrationen

Wann sollte ich die Null-ETL-Integration von Aurora in Amazon Redshift verwenden?

Sie sollten die Null-ETL-Integration von Amazon Aurora in Amazon Redshift verwenden, wenn Sie nahezu in Echtzeit Zugriff auf Transaktionsdaten benötigen. Diese Integration ermöglicht es Ihnen, Amazon Redshift ML mit einfachen SQL-Befehlen zu nutzen.

Welche Engines und Versionen von Amazon Aurora unterstützen Null-ETL-Integrationen?

Die Null-ETL-Integration von Amazon Aurora in Amazon Redshift ist in der Aurora MySQL-Compatible Edition für Aurora MySQL 3.05 Version (kompatibel mit MySQL 8.0.32) und höher in den Regionen USA Ost (Ohio), USA Ost (Nord-Virginia), USA West (Oregon), Asien-Pazifik (Singapur), Asien-Pazifik (Sydney), Asien-Pazifik (Tokio), Europa (Frankfurt), Europa (Irland) und Europa (Stockholm) verfügbar. Die Null-ETL-Integration von Amazon Aurora in Amazon Redshift ist in der Aurora PostgreSQL-kompatiblen Edition für Aurora PostgreSQL 15.4 in der Region USA Ost (Ohio) verfügbar.

Welche Vorteile bietet die Null-ETL-Integration?

Durch die Null-ETL-Integration von Amazon Aurora in Amazon Redshift müssen Sie keine komplexen Datenpipelines mehr erstellen und verwalten. Sie können Daten aus einem oder mehreren Aurora-Datenbankclustern in einem einzigen Amazon Redshift-Datenbank-Cluster konsolidieren und mithilfe von Amazon Redshift nahezu in Echtzeit Analysen und ML für Petabyte an Transaktionsdaten von Aurora ausführen. 

Ist die Null-ETL-Integration mit Aurora Serverless v2 kompatibel?

Die Null-ETL-Integration von Aurora in Amazon Redshift ist mit Aurora Serverless v2 kompatibel. Wenn Sie sowohl Aurora Serverless v2 als auch Amazon Redshift Serverless verwenden, können Sie Analysen zu Transaktionsdaten nahezu in Echtzeit erstellen, ohne die Infrastruktur für Datenpipelines verwalten zu müssen.

Wie starte ich eine Null-ETL-Integration?

Sie können beginnen, indem Sie die Amazon-RDS-Konsole verwenden, um die Null-ETL-Integration zu erstellen, indem Sie die Aurora-Quelle und das Amazon Redshift-Ziel angeben. Sobald die Integration erstellt wurde, wird die Aurora-Datenbank auf Amazon Redshift repliziert, und Sie können mit der Abfrage der Daten beginnen, sobald das erste Seeding abgeschlossen ist. Weitere Informationen finden Sie im Handbuch Erste Schritte für Null-ETL-Integrationen von Aurora in Amazon Redshift.

Wie viel kostet die Null-ETL-Integration?

Null-ETL und die fortlaufende Verarbeitung von Datenänderungen werden ohne zusätzliche Kosten angeboten. Sie zahlen für vorhandene Amazon-RDS- und Amazon-Redshift-Ressourcen, die zur Erstellung und Verarbeitung der im Rahmen einer Null-ETL-Integration generierten Änderungsdaten verwendet werden. Zu diesen Ressourcen könnten gehören:

  • Zusätzliche E/A und Speicher, die durch die Aktivierung von Enhanced Binlog verwendet werden
  • Snapshot-Exportkosten für den ersten Datenexport zum Seed Ihrer Amazon-Redshift-Datenbanken
  • Zusätzlicher Amazon-Redshift-Speicher zum Speichern replizierter Daten
  • AZ-übergreifende Datenübertragungskosten für die Übertragung von Daten von der Quelle zum Ziel

Weitere Informationen finden Sie auf der Seite mit der Preisübersicht für Aurora.

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 ein Feature von Amazon DevOps Guru, das 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?

Amazon RDS Performance Insights ist ein Feature zum Einstellen und Überwachen der Datenbankleistung, das 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 Leistungsprobleme hat. Metriken werden analysiert, um Ihnen die Probleme und mögliche Lösungen darzulegen.

Daten-API

Wann sollte ich die Daten-API mit Aurora anstelle von Datenbanktreibern verwenden?

Sie sollten die Daten-API für neue moderne Anwendungen verwenden, insbesondere für solche, die mit AWS Lambda erstellt wurden und in einem Anforderungs-/Antwortmodell auf Aurora zugreifen müssen. Sie sollten Datenbanktreiber anstelle der Daten-API verwenden und persistente Datenbankverbindungen verwalten, wenn eine vorhandene Anwendung stark mit Datenbanktreibern gekoppelt ist, wenn es langlaufende Abfragen gibt oder wenn der Entwickler die Vorteile von Datenbankfunktionen wie temporären Tabellen nutzen oder Sitzungsvariablen nutzen möchte.

Welche Aurora-Engines und -Versionen unterstützen die Daten-API?

Die Verfügbarkeit der Daten-API, der AWS-Region und der Datenbankversion für Aurora Serverless v2 und von Aurora bereitgestellte Instances finden Sie in unserer Dokumentation. Kunden, die derzeit die Daten-API für Aurora Serverless v1 verwenden, wird empfohlen, auf Aurora Serverless v2 zu migrieren, um die Vorteile der neu gestalteten Daten-API und der differenzierten Skalierung von Aurora Serverless v2 zu nutzen.

Welche Vorteile bietet die Daten-API?

Die Daten-API ermöglicht es Ihnen, die moderne Anwendungsentwicklung zu vereinfachen und zu beschleunigen. Die Daten-API ist eine benutzerfreundliche, sichere HTTP-basierte API, die die Bereitstellung von Datenbanktreibern, die Verwaltung clientseitiger Verbindungspools oder die Einrichtung komplexer VPC-Netzwerke zwischen der Anwendung und der Datenbank überflüssig macht. Die Daten-API verbessert außerdem die Skalierbarkeit durch das automatische Pooling und gemeinsame Nutzung von Datenbankverbindungen, was den Rechenaufwand von Anwendungen reduziert, die häufig Verbindungen öffnen und schließen. 

Unterstützt die Daten-API Aurora Global Database oder Aurora Serverless v1?

Die vorhandene Daten-API für Aurora Serverless v1 bleibt ein Feature von Aurora Serverless v1 sowohl für die PostgreSQL-kompatible Edition als auch für die MySQL-kompatible Edition von Aurora. Die Daten-API für Aurora Serverless v2 und von Aurora bereitgestellte Instances unterstützt Aurora Serverless v1 nicht. Die Daten-API für Aurora Serverless v2 und von Aurora bereitgestellte Instances unterstützen Schreib-Instances von Aurora Global Database.

Wie authentifiziere ich mich mit der Daten-API bei der Datenbank?

Benutzer können Daten-API-Abläuffe nur aufrufen, wenn sie dazu berechtigt sind. Administratoren können einem Benutzer die Berechtigung zur Nutzung der Daten-API gewähren, indem sie eine Richtlinie von AWS Identity and Access Management (IAM) beifügen, die ihre Berechtigungen definiert. Sie können die Richtlinie auch an eine Rolle beifügen, wenn Sie IAM-Rollen verwenden. Wenn Sie die Daten-API aufrufen, können Sie Anmeldeinformationen für den Aurora-DB-Cluster mithilfe eines Geheimnisses in AWS Secrets Manager übergeben. 

Wie viel kostet die Daten-API?

Die Nutzung der Daten-API mit Aurora Serverless v1 ist weiterhin ohne zusätzliche Kosten verfügbar. Die Preise für die Daten-API für Aurora Serverless v2 und von Aurora bereitgestellte Instances werden nach dem API-Anforderungsvolumen berechnet, wie auf der Aurora-Preisseite beschrieben. Die Daten-API für Aurora Serveless v2 und von Aurora bereitgestellte Instances verwendet AWS-CloudTrail-Datenebenenereignisse zum Protokollieren von Aktivitäten anstelle von Verwaltungsereignissen, wie dies bei der Daten-API für Aurora Serverless v1 der Fall war.

Wenn Sie diese Aktivität verfolgen möchten, können Sie die Protokollierung von Datenereignissen über die CloudTrail-Konsole, die CLI oder das SDK aktivieren. Dafür fallen Gebühren an, wie auf der CloudTrail-Preisseite angegeben. Außerdem fallen für die Nutzung von AWS Secrets Manager Gebühren an, die auf der Preisseite von AWS Secrets Manager aufgeführt werden. 

Warum hat AWS damit begonnen, Datenebenenereignisse für die Daten-API anstelle von CloudTrail-Verwaltungsereignissen zu verwenden?

AWS CloudTrail erfasst AWS-API-Aktivitäten als Verwaltungsereignisse oder Datenereignisse. CloudTrail-Verwaltungsereignisse (auch bekannt als „Abläufe der Steuerebene“) zeigen Verwaltungsvorgänge an, die für Ressourcen in Ihrem AWS-Konto ausgeführt werden, z. B. das Erstellen, Aktualisieren und Löschen einer Ressource. CloudTrail-Datenereignisse (auch bekannt als „Datenebenenabläufe“) zeigen die Ressourcenvorgänge an, die auf oder innerhalb einer Ressource in Ihrem AWS-Konto ausgeführt werden.

Die Daten-API führt Abläufe auf Datenebene durch, da sie Abfragen für Daten in Ihrer Aurora-Datenbank durchführt. Daher werden die Daten-API-Aktivitäten als Datenereignisse protokolliert, da dies die korrekte Kategorisierung der Ereignisse ist. Gebühren fallen nur für CloudTrail-Datenereignisse an, wenn Sie die Protokollierung von Datenereignissen aktivieren.

Gibt es für die Daten-API ein kostenloses Kontingent?

Ja. Das kostenlose Kontingent für die Daten-API umfasst eine Million Anfragen pro Monat, aggregiert für alle AWS-Regionen, für die Nutzung im ersten Jahr. Nach einem Jahr müssen Kunden für die Daten-API bezahlen, wie auf der Aurora-Preisseite beschrieben.

Blau/Grün-Bereitstellungen von Amazon RDS

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

Blau/Grün-Bereitstellungen von Amazon RDS sind in den Amazon-Aurora-MySQL-kompatiblen Edition-Versionen 5.6 und höher sowie in den Amazon-Aurora-PostgreSQL-kompatiblen Edition-Versionen 11.21 und höher, 12.16 und höher, 13.12 und höher, 14.9 und höher sowie 15.4 und höher verfügbar. Erfahren Sie mehr über verfügbare Versionen in der Dokumentation für Aurora.

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

Blau/Grün-Bereitstellungen von Amazon RDS sind in allen AWS-Regionen und in den AWS-GovCloud-Regionen verfügbar.

Wann sollte ich Blau/Grün-Bereitstellungen von Amazon RDS verwenden?

Mit Blau/Grün-Bereitstellungen von Amazon RDS können Sie Datenbankänderungen sicherer, einfacher und schneller durchführen. Blau/Grün-Bereitstellungen eignen sich ideal für Anwendungsfälle wie Haupt- oder Nebenversions-Upgrades der Datenbank-Engine, Betriebssystemaktualisierungen, Schemaänderungen in Grün-Umgebungen, die die logische Replikation nicht unterbrechen, wie das Hinzufügen einer neuen Spalte am Ende einer Tabelle oder Änderungen der Datenbankparametereinstellungen.

Sie können Blau/Grün-Bereitstellungen verwenden, um mit einer einzigen Umstellung mehrere Datenbankaktualisierungen gleichzeitig vorzunehmen. Auf diese Weise können Sie über Sicherheitspatches auf dem Laufenden bleiben, die Datenbankleistung verbessern und mit kurzen, vorhersehbaren Ausfallzeiten auf neuere Datenbankfeatures zugreifen. Wenn Sie nur ein Nebenversions-Upgrade auf Aurora durchführen möchten, empfehlen wir Ihnen, Aurora Zero Downtime Patching (ZDP) zu verwenden.

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 Amazon RDS Performance Insights. 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 GiB 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 Upgrades an Haupt- und Nebenversionen, Schema-Änderungen, Instance-Skalierung, Änderungen an den Engine-Parametern und Wartungs-Updates.

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 Umstellung Ihre neue Produktionsumgebung wird.

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

Wenn Blau/Grün-Bereitstellungen von Amazon RDS eine Umstellung einleiten, blockieren sie Schreibvorgänge sowohl zur Blau-, als auch zur Grün-Umgebung, bis die Umstellung abgeschlossen ist. Während der Umstellung macht die Staging-Umgebung (oder Grün-Umgebung) Boden auf das Produktionssystem gut. Dadurch wird gewährleistet, dass Daten zwischen der Staging- und Produktionsumgebung beständig sind. Sobald die Produktions- und Staging-Umgebung komplett synchronisiert wurden, fördern die Blau/Grün-Bereitstellungen die Staging-Umgebung als die 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 Umstellung 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 Umstellung der Blau/Grün-Bereitstellungen von Amazon RDS?

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

Kann ich Blau/Grün-Bereitstellungen verwenden, wenn ich als Subscriber/Publisher für ein selbstverwaltetes logisches Replikat eine blaue Datenbank habe?

Wenn Ihre blaue Umgebung ein selbstverwaltetes logisches Replikat oder ein Subscriber ist, blockieren wir die Umstellung. Es wird empfohlen, zuerst die Replikation in die blaue Umgebung zu beenden, mit der Umstellung fortzufahren und dann die Replikation fortzusetzen. Wenn Ihre blaue Umgebung dagegen eine Quelle für ein selbstverwaltetes logisches Replikat oder einen Publisher ist, können Sie mit der Umstellung fortfahren. Sie müssen jedoch das selbstverwaltete Replikat aktualisieren, um es nach der Umstellung aus der grünen Umgebung zu replizieren.

Unterstützen Blau/Grün-Bereitstellungen von Amazon RDS Amazon Aurora Global Databases, Amazon-RDS-Proxy oder regionenübergreifende Lesereplikate?

Nein. Blau/Grün-Bereitstellungen von Amazon RDS unterstützen Amazon Aurora Global Databases, Amazon-RDS-Proxy oder regionenübergreifende Lesereplikate 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.

Erweiterter Amazon-RDS-Support

Kann ich erweiterten RDS-Support mit jeder Nebenversion verwenden?

Nein, erweiterter Amazon-RDS-Support ist nur für bestimmte Nebenversionen verfügbar. Einzelheiten finden Sie im Aurora-Benutzerhandbuch

Wie kann ich meine Gebühren für erweiterten RDS-Support abschätzen?

Die Gebühren für erweiterten Amazon-RDS-Support hängen von drei Faktoren ab: 1. Anzahl der vCPUs oder ACUs, die auf der Instance ausgeführt werden, 2. AWS-Region und 3. Anzahl der Jahre nach dem Ablauf des Standard-Supports.

Um Ihre Gebühren zu schätzen, ermitteln Sie die Anzahl der vCPUs auf Ihrer Instance und die entsprechenden Kalenderjahrespreise für Ihre Engine-Version. Wenn Ihre Version innerhalb der Preisspanne zwischen dem 1. und 2. Jahr liegt und Sie bereitgestellte Instances verwenden, werden Ihnen #vCPUs x die Preise für Jahr 1 und Jahr 2 pro Nutzungsstunde für die von Ihnen gewählte Region berechnet. Wenn für Ihre Version der Preis für das dritte Jahr gilt und Sie bereitgestellte Instances verwenden, wird Ihnen der Preis #vCPUs x Jahr 3 pro Nutzungsstunde für die von Ihnen gewählte Region berechnet.

Wenn Sie beispielsweise am 30. Dezember 2024, also innerhalb des ersten Jahres von erweiterter Support für RDS, eine Aurora-MySQL-kompatible Instance mit 2 db.r5.large in Nord-Virginia ausführen, werden Ihnen 0,200 USD pro Stunde oder 2 vCPUs x 0,100 USD pro vCPU-Stunde berechnet.

Wann beginnt Amazon Aurora damit, Gebühren für erweiterten Support für RDS zu erheben?

Die Kosten für den erweiterten Amazon-RDS-Support werden Ihnen ab dem Tag berechnet, an dem die Hauptversion der Aurora-MySQL-kompatiblen Edition das Ende des Standardsupports erreicht hat. Dies wird neben den Instance-, Speicher-, Backup- und/oder Datenübertragungsgebühren berechnet, die während der Lebensdauer der Instance anfallen.

Beispielsweise endet der Standardsupport für Aurora-MySQL-Compatible 2 am 30. November 2024. Wenn Sie nach dem 30. November 2024 eine Instance von Aurora-MySQL-Compatible 2 ausführen, wird Ihnen der erweiterte RDS-Support für diese Instance in Rechnung gestellt.

Muss ich für erweiterten RDS-Support für meine DB-Snapshots bezahlen?

Nein, die Preise für erweiterten Amazon-RDS-Support gelten nicht für DB-Snapshots. Wenn Sie jedoch einen Snapshot auf einer neuen DB-Instance wiederherstellen, die eine Version von erweiterten RDS-Support verwendet, werden für die Instance die Preise für erweiterten Amazon-RDS-Support berechnet, bis Sie sie auf eine Standard-Support-Version aktualisieren oder die Instance löschen.

Wann erhalte ich keine Gebühren mehr für erweiterten RDS-Support?

Wenn Sie Ihre Instance auf eine neuere Engine-Version aktualisieren, die im Standardsupport verfügbar ist, wird verhindert, dass für Ihre Instance die Preise für erweiterten RDS-Support berechnet werden. Die Gebühren für erweiterten RDS-Support enden automatisch, wenn Sie eine Instance herunterfahren oder löschen, auf der nach Ablauf des Standardsupports eine Hauptversion der Engine ausgeführt wird.

Für jede Engine-Version werden zwei verschiedene Preise aufgeführt. Woher weiß ich, welche davon mir in Rechnung gestellt werden?

Der Preis für erweiterten RDS-Support, der Ihnen berechnet wird, hängt von der Engine-Version, der AWS-Region und der Anzahl der Kalenderjahre ab, seit der Standardsupport für diese Version abgelaufen ist. In den ersten zwei Jahren nach dem Ende des Standardsupports werden Ihnen die Preise für das 1. und 2. Jahr in der von Ihnen ausgewählten Region pro vCPU-Stunde berechnet. Wenn erweiterter RDS-Support für ein drittes Jahr angeboten wird, wird Ihnen ab dem ersten Tag des dritten Jahres der Preis für das dritte Jahr in der von Ihnen ausgewählten Region pro vCPU-Stunde berechnet.

Zum Beispiel erreicht Aurora-PostgreSQL-Compatible 11 am 29. Februar 2024 das Ende des Standardsupports. Wenn Sie in USA Ost (Ohio) eingesetzt werden, werden Ihnen zwischen dem 1. April 2024 und dem 31. März 2026 0,100 USD pro vCPU-Stunde berechnet. Ab dem 1. April 2026 werden Ihnen 0,200 USD pro vCPU-Stunde berechnet.

Wie kann ich vermeiden, dass mir erweiterter RDS-Support in Rechnung gestellt wird?

Wir empfehlen, Ihre Instance so früh wie möglich auf eine Hauptversion der Engine zu aktualisieren, die innerhalb der Standardsupport-Laufzeit liegt. Auf diese Weise können Sie vermeiden, dass Gebühren für den erweiterten RDS-Support anfallen.

Kann ich Amazon-RDS-Blau/Grün-Bereitstellungen verwenden, um von erweitertem Amazon-RDS-Support zu einer Standardsupport-Version zu migrieren?

Sie können Amazon-RDS-Blau/Grün-Bereitstellungen verwenden, um Ihre Instances mithilfe von erweitertem RDS-Support zu migrieren, sofern Blau/Grün-Bereitstellungen die Engine, die Region und den Hauptversionstyp Ihrer Instance unterstützen. Blau/Grün-Bereitstellungen sind für Auroras MySQL-kompatible Edition verfügbar. Informationen zu verfügbaren Versionen finden Sie in der Dokumentation Blau/Grün-Bereitstellungen.

Gelten Reserved-Instance-Rabatte für erweiterten RDS-Support?

Nein, die Gebühren für erweiterten RDS-Support sind unabhängig von den Instance-Gebühren. Daher gelten Reserved-Instance-Rabatte nicht für Gebühren für erweiterten RDS-Support.

Wird mir erweiterter RDS-Support in Rechnung gestellt, auch wenn ich von RDS für MySQL 5.7 zu Aurora MySQL 2 (basierend auf MySQL 5.7) wechsle?

Wenn Sie vor dem 29. Februar 2024 von RDS für MySQL 5.7 auf Aurora MySQL 2 migrieren, wird Ihnen der erweiterte RDS-Support nicht in Rechnung gestellt. Wenn Sie nach dem 29. Februar 2024 und vor dem 30. November 2024 migrieren, wird Ihnen der erweiterte RDS-Support für die Anzahl der Stunden in Rechnung gestellt, in denen Sie MySQL 5.7 auf Amazon RDS ausgeführt haben.

Wenn Sie nach dem 30. November 2024 migrieren oder Aurora-MySQL-Compatible 2 nach dem 30. November 2024 verwenden, wird Ihnen auch der erweiterte RDS-Support für Ihre Aurora-Datenbank in Rechnung gestellt. Weitere Informationen finden Sie in der Dokumentation zu Amazon Aurora und Amazon RDS.

Was passiert mit DB-Snapshots, die ich mit einer Version erstellt habe, die nicht mehr standardmäßig unterstützt wird? Muss ich dafür den Preis für den erweiterten RDS-Support zahlen?

Nein, für DB-Snapshots fallen keine Gebühren für erweiterten RDS-Support an. Wenn Sie jedoch nach Ablauf des Standardsupports einen DB-Snapshot auf einer neuen DB-Instance wiederherstellen, werden Ihnen die Preise für den erweiterten RDS-Support für diese Instance berechnet.

Wenn Sie beispielsweise nach dem 30. November 2024 einen DB-Snapshot auf einer neuen DB-Instance auf Aurora-MySQL-Compatible 2 wiederherstellen, wird für die Instance der Preis für den erweiterten RDS-Support von Aurora-MySQL-Compatible 2 berechnet, bis Sie sie auf Aurora MySQL-kompatible Version 3 oder neuer aktualisieren oder die Instance löschen.

Wenn ich eine neue Instance auf einer Engine mit Hauptversion erstelle, nachdem der Standardsupport abgelaufen ist, wird mir dann der erweiterte RDS-Support in Rechnung gestellt?

Ja, wenn Sie eine Instance erstellen oder einen DB-Snapshot auf einer Instance wiederherstellen, die auf einer Version läuft, deren Standard-Support-Ende erreicht wurde, werden Ihnen zusätzlich zu den Instance-, Speicher-, Backup- und Datenübertragungsgebühren die Preise für erweiterten RDS-Support berechnet.

Weitere Informationen zu Preisen von Amazon Aurora

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