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, wenn die Writer-Instanz neu gestartet wird, während ein Undo-Datensatz für eine Tabelle mit Indizes für virtuelle Spalten gelöscht wurde.

Es wurde ein Problem behoben, das dazu führen konnte, dass die Erstellung eines neuen Datenbank-Clusters fehlschlug und 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, während temporäre Tabellen nach der Verarbeitung von SQL-Anweisungen bereinigt wurden. Dieser Neustart konnte 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 Skalierungsvorgängen von Aurora Serverless v2 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 nach einem Neustart wiederholt neu gestartet werden konnte, 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, wenn sie ORDER BY DESC mit einem Bereichsvergleich und verwendet wurden. LIMIT

Es wurde ein Problem behoben, bei dem der Reader bei bestimmten Online-DDL-Vorgängen auf dem Writer bei Verwendung des INPLACE-Algorithmus „FEHLER 1146" (Tabelle nicht gefunden) meldet. Dies kann auftreten, wenn entweder: 1) der Reader die Tabelle noch nicht geöffnet hat, bevor die DDL beginnt, oder 2) der Reader neu gestartet wird oder ein neuer Reader erstellt wird, während die DDL läuft.

Es wurde ein Problem behoben, das bei der Verarbeitung von Binlog-Ereignissen, die größer als die aurora_in_memory_relaylog feste Cachegröße (128 MB) waren, zu Replikationsfehlern führen kann.

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 für einen Hash-Join benötigte Speicher das Limit ü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.