Amazon RDS for MySQL – Häufig gestellte Fragen

Amazon Relational Database (Amazon RDS) für MySQL unterstützt derzeit die Versionen der MySQL Community Edition 5.7 und 8.0. Informationen zu den unterstützten Nebenversionen finden Sie im Amazon-RDS-Benutzerhandbuch.

Im Kontext von MySQL lauten Versionsnummern wie folgt:
MySQL-Version = X.Y.Z

X = Hauptversion, Y = Veröffentlichungsstufe, Z = Versionsnummer innerhalb einer Veröffentlichungsstufe.
Aus Sicht von Amazon RDS wird eine Versionsänderung als erheblich angesehen, wenn sich entweder die Hauptversion oder die Veröffentlichungsstufe ändert. Beispiel: Änderung von 5.6.X auf 5.7.X.

Als geringfügig wird eine Versionsänderung angesehen, wenn sich nur die Versionsnummer innerhalb der Veröffentlichung ändert. Beispiel: Änderung von 5.6.27 auf 5.6.29.

Ja. Informationen finden Sie unter Amazon RDS – Häufig gestellte Fragen.

Die Features zeitpunktbezogene Wiederherstellung, Snapshot-Wiederherstellung und Null-ETL-Integration in Amazon Redshift (Vorschau) von Amazon RDS für MySQL erfordern eine nach einem Ausfall wiederherstellbare Speicher-Engine und werden nur für die InnoDB-Speicher-Engine unterstützt. MySQL unterstützt zwar mehrere Speicher-Engines mit unterschiedlichen Fähigkeiten und Kapazitäten, jedoch sind nicht alle von ihnen für die Wiederherstellung nach Ausfall und für Datenbeständigkeit optimiert. Beispielsweise unterstützt die MyISAM-Speicher-Engine kein zuverlässiges Crash Recovery und könnte zu Datenverlust oder -beschädigung führen, wenn MySQL nach einem Ausfall neu gestartet wird. Daher können die Funktionen Point-In-Time-Restore oder Snapshot-Restore nicht wie beabsichtigt ausgeführt werden. Wenn Sie MyISAM trotzdem mit Amazon RDS verwenden möchten, befolgen Sie diese Schritte, die in bestimmten Szenarien der Funktion zur Wiederherstellung von DB-Snapshots hilfreich sein könnten. Die Federated Storage Engine wird zurzeit von RDS für MySQL nicht unterstützt.

Wenn Sie eine neue DB-Instance erstellen, erhält der von Ihnen verwendete primäre Standardbenutzer bestimmte Rechte. Eine Liste der Rechte finden Sie im Thema zu den Kontoberechtigungen des Master-Benutzers im Amazon-RDS-Benutzerhandbuch.

Lesereplikate von RDS für MySQL erfordern eine Transaktions-Speicher-Engine und werden nur für die InnoDB-Speicher-Engine unterstützt. Nicht-Transaktions-MySQL-Speicher-Engines wie MyISAM können verhindern, dass Lesereplikate ordnungsgemäß funktionieren. Wenn Sie MyISAM dennoch gemeinsam mit Lesereplikaten verwenden möchten, wird empfohlen, dass Sie die Amazon-CloudWatch-Metrik „Replica Lag“ sorgfältig überprüfen und das Lesereplikat erneut erstellen, wenn es aufgrund von Replikationsfehlern zu Verzögerungen kommt. (Die Metrik ist über die AWS-Managementkonsole oder über die Amazon-CloudWatch-APIs verfügbar.) Dieselben Überlegungen treffen für die Verwendung von temporären Tabellen und anderen Nicht-Transaktions-Engines zu.

Für MySQL (Version 5.6 und neuer) können Sie das binäre Protokollierungsformat auf zeilenbasiert festlegen. Standardmäßig ist die Replikation auf ein Mischformat (das sowohl die zeilen- als auch anweisungsbasierte Replikation umfasst) festgelegt, mit dem die Anforderungen der meisten Anwendungsfälle erfüllt werden sollten. Die MySQL-Dokumentation bietet weitere Informationen zum Unterschied zwischen der Mischformat- und zeilenbasierten Replikation.

Blau/Grün-Bereitstellungen von Amazon RDS sind in RDS für MySQL-Versionen 5.7 und höher verfügbar. Weitere Informationen zu verfügbaren Versionen finden Sie in der Dokumentation zu RDS für MySQL.

Amazon-RDS-optimierte Schreibvorgänge und RDS Blau/Grün-Bereitstellungen sind in den jeweiligen AWS-Regionen und AWS-GovCloud-Regionen verfügbar.

Mit Blau/Grün-Bereitstellungen von Amazon RDS können Sie Datenbankänderungen sicherer, einfacher und schneller vornehmen. Das sind z. B. Updates an Haupt- und Nebenversionen, Schemaänderungen, Instance-Skalierung, Änderungen an den Engine-Parametern und Wartungs-Updates.

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.

Ihnen wird der gleiche Preis für die Ausführung Ihres Workloads bei Grün-Instances wie bei Blau-Instances berechnet. Die Kosten der Ausführung auf Blau/Grün-Instances umfassen u. a. unsere aktuellen Standardpreise für DB-Instances, Speicherkosten, Kosten für das Lesen/Schreiben von E/As, und aktivierte Features wie Sicherungskosten und Amazon RDS Performance Insights. Effektiv zahlen Sie ca. 2x 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 führen gerade RDS für die Datenbank von MySQL 5.7 bei zwei r5.2xlarge db.Instances einer primären Datenbank-Instance und einem Lesereplikat in AWS-Region USA Ost 1 mit einer Multi-AZ (MAZ)-Konfiguration aus. Jede einzelne der r5.2xlarge db.Instances ist für 20 GB Allzweck-Speicher des Amazon Elastic Block Store (Amazon EBS) konfiguriert. Sie erstellen einen Klon der Blau-Instance-Topologie mit Blau/Grün-Bereitstellungen von Amazon RDS, führen ihn 15 Tage (360 Stunden) lang aus und Sie löschen anschließend die Blau-Instances nach erfolgreicher Umstellung. Die Blau-Instance kostet 1 387 USD für 15 Tage bei On-Demand-Rate von 1,926 USD/Std. (Instance + EBS-Kosten). Die Gesamtkosten für die Nutzung von Blau/Grün-Bereitstellungen für diese 15 Tage betragen 2 774 USD. Das ist doppelt so teuer wie die Ausführung von Blau-Instances für diesen Zeitraum.

Mit Blau/Grün-Bereitstellungen von Amazon RDS können Sie Datenbank-Änderungen sicherer, einfacher und schneller vornehmen. Das sind z. B. Updates an Haupt- und Nebenversionen, Schemaänderungen, Instance-Skalierung, Änderungen an den Engine-Parametern und Wartungs-Updates.

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

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.

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.

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.

Nein. Blau/Grün-Bereitstellungen von Amazon RDS unterstützen Amazon-RDS-Proxy, regionenübergreifende Lesereplikate oder kaskadierte Lesereplikate nicht.

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.

MySQL schützt Benutzer vor Datenverlust, indem es Daten in 16 KB-Seiten im Speicher zweimal in den dauerhaften Speicher schreibt – zuerst in den „Doublewrite-Buffer“ und dann in den Tabellenspeicher. Amazon-RDS-optimierte Schreibvorgänge schreiben Ihre 16 KiB großen Datenseiten direkt in Ihre Datendateien – zuverlässig und dauerhaft in einem Schritt mit dem Feature Torn Write Prevention von AWS Nitro System.

Amazon-RDS-optimierte Schreibvorgänge sind für MySQL-Hauptversion 8.0.30 und höher verfügbar.

Amazon-RDS-optimierte Schreibvorgänge sind in db.r6i- und db.r5b-Instances verfügbar. Sie sind in allen Regionen verfügbar, in denen diese Instances verfügbar sind, mit Ausnahme der AWS-China-Regionen.

Alle Nutzer von RDS für MySQL sollten Amazon-RDS-optimierte Schreibvorgänge implementieren, um den Durchsatz von Schreibtransaktionen um das Doppelte zu steigern. Für Workloads mit hohem Schreibaufkommen, z. B. digitale Zahlungen, Finanzhandel und Online-Spiele, ist dieses Feature ganz besonders hilfreich.

Nein. Die MySQL-kompatible Edition von Amazon Aurora vermeidet bereits die Verwendung des „Doublewrite-Buffers“. Aurora repliziert stattdessen Daten auf sechs Wegen über drei Availability Zones (AZs) und verwendet einen Quorum-basierten Ansatz, um Daten dauerhaft zu schreiben und danach korrekt zu lesen.

Zurzeit unterstützt diese erste Version nicht die Aktivierung von Amazon-RDS-optimierten Schreibvorgängen für Ihre bestehenden Datenbank-Instances, selbst wenn die Instance-Klasse optimierte Schreibvorgänge unterstützt.

Amazon-RDS-optimierte Schreibvorgänge sind für Kunden von RDS für MySQL ohne zusätzliche Kosten verfügbar.

Workloads, die temporäre Objekte in MySQL zur Abfrageverarbeitung nutzen, profitieren von Amazon-RDS-optimierten Lesevorgängen. Optimierte Lesevorgänge legen temporäre Objekte auf dem NVMe-basierten Instance-Speicher der Datenbank-Instance ab, statt auf dem Volume von Amazon EBS. Dadurch kann die Bearbeitung komplexer Abfragen um bis zu 50 % beschleunigt werden.

Amazon-RDS-optimierte Lesevorgänge sind für RDS für MySQL in den MySQL-Versionen 8.0.28 und höher verfügbar.

Amazon-RDS-optimierte Lesevorgänge sind in allen Regionen verfügbar, in denen db.r5d-, db.m5d-, db.r6gd-, db.m6gd-, X2idn- und X2iedn-Instances verfügbar sind. Weitere Informationen finden Sie in der Dokumentation zu den DB-Instance-Klassen von Amazon RDS.

Kunden sollten Amazon-RDS-optimierte Lesevorgänge verwenden, wenn sie Workloads haben, die komplexe Abfragen, allgemeine Analysen oder komplizierte Gruppen, Sortierungen, Hash-Aggregationen, Joins mit hoher Last und Common Table Expressions (CTEs) erfordern. Solche Anwendungsfälle führen zur Erstellung temporärer Tabellen, die es optimierten Lesevorgängen ermöglichen, die Abfrageverarbeitung Ihrer Workloads zu beschleunigen.

Ja, Kunden können ihre bestehende Amazon-RDS-Datenbank konvertieren, um Amazon-RDS-optimierte Lesevorgänge zu verwenden, indem sie ihren Workload in eine Instance verschieben, für die Amazon-RDS-optimierte Lesevorgänge aktiviert sind. Optimierte Lesevorgänge sind auch standardmäßig für alle unterstützten Instance-Klassen verfügbar. Wenn Sie Ihren Workload auf db.r5d-, db.m5d-, db.r6gd-, db.m6gd-, X2idn- und X2iedn-Instances ausführen, profitieren Sie bereits von optimierten Lesevorgängen.

Sie sollten die Null-ETL-Integration von Amazon RDS für MySQL mit Amazon Redshift verwenden, wenn Sie den Aufbau und die Verwaltung komplexer Datenpipelines überflüssig machen möchten. Sobald sich die Daten in Amazon Redshift befinden, haben Sie Zugriff auf Analytik und Features für Machine Learning (ML) für Ihre Transaktionsdaten von RDS für MySQL nahezu in Echtzeit.

Die Null-ETL-Integration von RDS für MySQL mit Amazon Redshift ist für MySQL-Versionen 8.0.32 und höher in unterstützten AWS-Regionen verfügbar.

Die Null-ETL-Integration von RDS für MySQL mit Amazon Redshift ermöglicht Analytik und Machine Learning (ML) für Petabyte an Transaktionsdaten nahezu in Echtzeit, sodass Sie keine komplexen Datenpipelines erstellen und verwalten müssen. Innerhalb von Sekunden, nachdem die Daten in RDS für MySQL geschrieben wurden, werden sie auf Amazon Redshift repliziert. Sie können Daten aus mehreren Datenbanken und Tabellen von RDS für MySQL in Amazon Redshift konsolidieren. Die Datenfilterung spezifischer Datenbanken und Tabellen anhand Ihrer analytischen Anforderungen, hilft Ihnen dabei, Daten selektiv in Amazon Redshift einzubringen.

Sie zahlen für RDS-für-MySQL- und Amazon-Redshift-Ressourcen, die zur Erstellung und Verarbeitung der im Rahmen einer Null-ETL-Integration erstellten Änderungsdaten verwendet werden. Zu diesen Ressourcen gehören die Kosten für den Export von Amazon RDS-Snapshots für das Seed und die Resynchronisierung Ihrer Amazon Redshift Data Warehouses, die Kosten für die Change Data Capture (CDC)-Datenübertragung für die fortlaufende Replikation von Datenänderungen von der Quelle zum Ziel, reguläre RDS-E/A- und Speicherkosten für die replizierten Daten sowie die regulären Amazon-Redshift-Speicher- und Rechenkosten für die replizierten Daten. Weitere Informationen finden Sie auf der Preisübersicht von RDS für MySQL.

Beispiel: Sie haben eine RDS-Datenbank für MySQL 8.0.32 und ein Amazon Redshift Data Warehouse, das in der Region USA Ost (Nord-Virginia) ausgeführt wird. Diese RDS für MySQL DB-Instance verwendet derzeit 50 GB Allzweck-SSD-Speicherkapazität (gp3), einschließlich bereitgestellter Basis-IOPS, hat automatische Backups aktiviert und hat MySQL-Binärprotokollierung aktiviert.

Wenn Sie eine Null-ETL-Integration in Amazon Redshift für Ihre RDS für MySQL DB-Instance erstellen, wird ein Snapshot der Daten (50 GB) erstellt und exportiert, um ein Amazon-Redshift-Data-Warehouse zu starten. Am nächsten Tag ändern Sie den Primärschlüssel einer Tabelle in Ihrer RDS für MySQL DB-Instance, was zu einer Neusynchronisierung des Snapshot-Exports in Amazon Redshift führt. Innerhalb von 30 Tagen verarbeitet die Datenbank 5 GB an Datenänderungen.

In diesem Beispiel betragen die Kosten für die Verwendung von RDS für die MySQL Null-ETL-Integration in Amazon Redshift in der Region USA Ost (Nord-Virginia) in den 30 Tagen 50 GB x (0,10 USD/GB) beim ersten Export plus 50 GB x (0,10 USD/GB) Kosten für die Resynchronisierung plus 5 GB x (2,00 USD/GB) CDC-Datenübertragung, insgesamt also 20,00 USD. Zusätzlich zu diesen Kosten für die Null-ETL-Integration sind Sie für die Kosten verantwortlich, die sich aus der normalen Nutzung von Amazon RDS und Amazon Redshift zur Verarbeitung der replizierten Daten ergeben, wie z. B. E/A-, Speicher- und Datenverarbeitungskosten.

Ja, um den Ressourcenverbrauch auf der primären Instance zu reduzieren, können Sie eine Amazon RDS Read Replica als Amazon-RDS-Quell-Instance für eine Null-ETL-Integration mit Amazon Redshift verwenden.

Ja, Sie können AWS CloudFormation verwenden, um die Konfiguration und Bereitstellung von Ressourcen zu verwalten und zu automatisieren, die für eine Null-ETL-Integration von RDS für MySQL mit Amazon Redshift erforderlich sind. Weitere Informationen finden Sie im AWS-CloudFormation-Benutzerhandbuch.

Die Null-ETL-Integration von RDS für MySQL in Amazon Redshift repliziert Transaktionen atomar, um die Datenkonsistenz zwischen der Quell-RDS-für-MySQL-Datenbank und dem Amazon-Redshift-Zielcluster sicherzustellen.

Nachfolgend finden Sie einige wichtige Punkte zur Atomisierung von Transaktionen bei dieser Integration:

• Nur verbindliche Transaktionen in RDS für MySQL werden in Amazon Redshift repliziert. Unverbindliche oder rückgängig gemachte Transaktionen werden nicht berücksichtigt.
• Die Integration verwendet einen zweiphasigen Commit-Prozess, um jede Transaktion atomar auf Amazon Redshift anzuwenden. Entweder werden alle Datenänderungen in der Transaktion übernommen oder, wenn ein Fehler auftritt, werden keine übernommen.
• Die Transaktionskonsistenz zwischen Quelle und Ziel wird aufrechterhalten. Nach der Replikation sind die Daten für eine bestimmte Transaktion sowohl in RDS für MySQL als auch in Amazon Redshift konsistent.
• Schemaänderungen durch DDL oder DML werden ebenfalls atomar angewendet, um die Integrität aufrechtzuerhalten.
• Die atomare Anwendung von Transaktionen stellt sicher, dass keine teilweisen Transaktionen oder inkonsistente Datenzustände zwischen den Datenbanken auftreten können.

Die Null-ETL-Integration von RDS für MySQL mit Amazon Redshift gewährleistet die vollständige Transaktionskonsistenz zwischen der Quell-RDS-für-MySQL-Datenbank und dem Amazon-Redshift-Zielcluster.

Hier sind einige wichtige Punkte zur Handhabung von Schemaänderungen:

• DDL-Anweisungen wie CREATE TABLE, ALTER TABLE, DROP TABLE usw. werden automatisch von RDS für MySQL in Amazon Redshift repliziert.
• Die Integration nimmt die erforderlichen Prüfungen und Anpassungen in Amazon-Redshift-Tabellen für replizierte Schemaänderungen vor. Wenn Sie beispielsweise eine Spalte in RDS für MySQL hinzufügen, wird die Spalte in Amazon Redshift hinzugefügt.
• Die Replikation und Schemasynchronisierung erfolgen automatisch in nahezu Echtzeit mit minimaler Verzögerung zwischen Quell- und Zieldatenbanken.
• Die Schemakonsistenz bleibt erhalten, auch wenn DML-Änderungen parallel zu DDL-Änderungen erfolgen.