Aurora MySQL 8.4.7, 21. Mai 2026

Unterstützung für Passwortverwaltungsfunktionen in Aurora MySQL 8.4 hinzugefügt, konfigurierbar mit den Cluster-Parametergruppeneinstellungen. Eine vollständige Beschreibung der Funktionen und Konfigurationsoptionen der MySQL-Passwortverwaltung finden Sie im MySQL 8.4-Referenzhandbuch, Abschnitt 8.2.15 — Passwortverwaltung.

Unterstützung für die validate_password Komponente zur Durchsetzung von Richtlinien zur Passwortstärke hinzugefügt, die über den Parameter aktiviert und über die aurora_enable_validate_password_component Cluster-Parametergruppe konfiguriert wurde.

Einführung der automatischen Speicherverwaltung für Aurora MySQL 8.4 mit dem neuen aurora_enable_memory_management Parameter. Wenn auf ON (Standard) gesetzt, verwaltet Aurora automatisch Speicherwiederherstellungsaktionen, um Neustarts von Out-of-Memory-Datenbanken (OOM) zu verhindern, und der aurora_oom_response Parameter wird ignoriert. Ist aurora_enable_memory_management auf eingestellt, OFF um Wiederherstellungsaktionen manuell zu steuern. aurora_oom_response Weitere Informationen finden Sie unter Amazon Aurora MySQL Out-of-Memory-Probleme im Amazon Aurora Aurora-Benutzerhandbuch.

Es wurde ein Problem behoben, das dazu führen kann, dass die Writer-Instanz wiederholt neu gestartet wird. Dies tritt auf, wenn der Writer beim Löschen eines Undo-Datensatzes für eine Tabelle mit Indizes für virtuelle Spalten neu gestartet wird.

Es wurde ein Problem behoben, das dazu führen konnte, dass die Erstellung eines neuen Datenbank-Clusters fehlschlagen konnte, sodass der Cluster gelöscht und neu erstellt werden musste.

Es wurde ein Problem behoben, bei dem die Datenbank-Writer-Instanz während eines globalen Datenbank-Switchover-Vorgangs unerwartet neu gestartet werden konnte. Der Neustart erfolgte beim Bereinigen temporärer Tabellen nach der Verarbeitung von SQL-Anweisungen. Dies könnte zu einer längeren Zeit bis zum Abschluss des Switchovers führen.

Die Leistung der physischen Aurora-Replikation wurde verbessert, indem Änderungen von der Writer-Instance auf Reader-Instances angewendet wurden, die mehrere Threads verwenden.

Es wurde ein Problem behoben, das dazu führen konnte, dass Read Replicas neu gestartet wurden, wenn die Writer-Instance eine große Transaktion mit aktiviertem Binlog festschreibt. Dieses Problem konnte auch zu Fehlern beim Lesen der Binlog-Datei führen, die die große Transaktion enthielt.

Es wurde ein Problem behoben, bei dem eine Verzögerung bei der Größenänderung des InnoDB-Pufferpools während Aurora Serverless v2-Skalierungsoperationen dazu führen konnte, dass die Datenbank-Instance nicht mehr reagierte und neu gestartet wurde.

Es wurde ein Problem mit dem Mechanismus zur Vermeidung von Speichermangel (OOM) behoben, das dazu führen konnte, dass eine Datenbank-Instance neu gestartet wurde, während versucht wurde, Speicher unter kritischem Speicherdruck wiederherzustellen.

Es wurde ein Problem behoben, bei dem eine Reader-Instanz wiederholt neu gestartet werden konnte, nachdem sie neu gestartet wurde, während die Writer-Instanz die Undo-Logs zwangsweise löschte.

Es wurde ein Problem behoben, das zu einem unerwarteten Datenbankneustart auf Reader-Instanzen führen kann, wenn Unterabfragen, die Parallele Query-Anfragen verwenden, nach Abschluss nicht korrekt geschlossen wurden.

Die Reihenfolge der Commits bei Binlog-Replikaten, bei denen Enhanced Binlog aktiviert war, wurde behoben, sodass die Einstellung korrekt berücksichtigt wurde. replica_preserve_commit_order Dieses Ordnungsverhalten hatte keinen Einfluss auf die Datenintegrität und verursachte auch keine Konflikte zwischen Transaktionen, da es nur für die Sequenzierung nicht abhängiger Transaktionen galt.

Es wurde ein Problem behoben, das dazu führen kann, dass Abfrageergebnisse in aufsteigender Reihenfolge statt in der angeforderten absteigenden Reihenfolge zurückgegeben wurden. Dieses Problem tritt auf, wenn ORDER BY DESC mit einem Bereichsvergleich und verwendet wird. LIMIT

Es wurde ein Problem behoben, bei dem der Reader bei bestimmten Online-DDL-Vorgängen auf dem Writer bei Verwendung des INPLACE-Algorithmus den Fehler 1146 (Tabelle nicht gefunden) meldet. Dies kann auftreten, wenn der Leser die Tabelle noch nicht geöffnet hat, bevor die DDL beginnt. Es kann auch auftreten, wenn das Lesegerät neu gestartet wird oder ein neues Lesegerät erstellt wird, während die DDL gerade läuft.

Es wurde ein Problem behoben, das zu Replikationsfehlern führen kann, wenn Binlog-Ereignisse verarbeitet werden, die größer als die aurora_in_memory_relaylog feste Cachegröße (128 MB) sind.

Es wurde ein seltenes Problem behoben, das dazu führen konnte, dass die Datenbankinstanz neu gestartet wurde, wenn bei Vorgängen zur Änderung der Größe des Pufferpools oder beim Löschen von Seiten fortlaufende SQL-Anweisungen aus temporären Tabellen gelesen wurden.

Leistungsproblem behoben, bei dem der Optimizer einen suboptimalen Abfrageausführungsplan mit Prepared Statements unter Verwendung von IN und parametrisierten Werten auswählt.

Es wurde ein Problem mit der Clusterverfügbarkeit behoben, das bei Datenbankserver-Upgrades auftreten konnte, wenn DML-Operationen in Systemtabellen auf veraltete automatische Inkrementwerte verwiesen.

Es wurde ein Problem behoben, das dazu führen kann, dass Abfragen, die Hash-Joins verwenden, falsche Ergebnisse zurückgeben, wenn die parallel Abfrage aktiviert ist und der Speicherbedarf für Hash-Joins den Grenzwert überschreitet.

Es wurde ein Problem behoben, das in einigen Fällen zu einer verzögerten Instanzverfügbarkeit während Patching- oder Neustartvorgängen ohne Ausfallzeit führen kann.

Es wurde ein Problem behoben, das zu einem Neustart der Engine führen konnte, wenn eine räumliche GIS-Abfrage einen Z-order räumlichen Index für eine Spalte verwendet, die mit einer expliziten SRID-Anmerkung deklariert wurde.