Aurora MySQL 8.4.8, 3. September 2026

Unterstützung für die Replikation von Binärprotokollen (Binärlog) aus mehreren Quellen hinzugefügt. Diese Funktion ermöglicht es einem Aurora MySQL-DB-Cluster, Daten aus mehreren MySQL-compatible Quelldatenbanken gleichzeitig zu replizieren. Jede Quellverbindung wird über einen dedizierten Replikationskanal mit eigenem Empfänger-Thread, Applier-Threads und Relay-Log verwaltet. Sie können Kanäle mithilfe neuer, pro Kanal gespeicherter Prozeduren konfigurieren und verwalten. Weitere Informationen finden Sie unter Verwenden der Replikation mit mehreren Quellen mit Aurora MySQL im Amazon Aurora-Benutzerhandbuch.

Unterstützung für verzögerte Binärlog-Replikation (Binlog) hinzugefügt, bei der ein Aurora MySQL-DB-Cluster, der als Binlog-Replikat fungiert, so konfiguriert werden kann, dass er eine bestimmte Anzahl von Sekunden wartet, bevor die von der Quelle empfangenen Transaktionen angewendet werden. Die verzögerte Replikation kann zum Schutz vor versehentlichen Datenänderungen wie unbeabsichtigten DROP TABLE oder DELETE Anweisungen verwendet werden. So haben Sie ein Wiederherstellungsfenster, in dem Sie Fehler identifizieren und korrigieren können, bevor sie auf das Replikat übertragen werden. Weitere Informationen finden Sie unter Konfiguration des Replikationsverzögerungsintervalls im Amazon Aurora-Benutzerhandbuch.

Der aurora_transaction_timeout Parameter wurde eingeführt. Dieser Parameter legt die maximale Dauer einer InnoDB-Transaktion in Sekunden fest. Sie können diesen Parameter verwenden, um zu verhindern, dass Transaktionen mit langer Laufzeit (aktiv oder inaktiv) die InnoDB-Bereinigung blockieren, was zu Leistungsproblemen führen kann. Weitere Informationen finden Sie unter Aurora MySQL-Transaktions-Timeout im Amazon Aurora-Benutzerhandbuch.

Unterstützung für den Post-Quantum-Hybrid-Schlüsselaustausch (X25519MLKEM768 und SECP256R1MLKEM768) für TLS 1.3-Verbindungen hinzugefügt. Clients, die den Post-Quantum-Schlüsselaustausch unterstützen, handeln automatisch ein quantenresistentes gemeinsames Geheimnis aus. Um zu bestätigen, welche Gruppe in der aktuellen Sitzung ausgehandelt wurde, fragen Sie die Statusvariable ab. Aurora_ssl_named_group Beispiel: SHOW STATUS LIKE 'Aurora_ssl_named_group';.

Es wurde ein Problem behoben, bei dem das Advanced Audit-Protokoll einen falschen Benutzer und Host für SQL-Anweisungen aufzeichnete, die innerhalb einer SQL SECURITY DEFINER-Routine (gespeicherte Prozedur, Funktion oder Trigger) ausgeführt wurden. In diesen Datensätzen wurden beispielsweise der Definer-Benutzer und der Host der Routine angezeigt, 'user'@'%' nicht der SQL-Client, der die Routine aufgerufen hat. Nach diesem Fix zeigen die Datensätze den Benutzer und den Host des aufrufenden SQL-Clients an.

Es wurde ein Problem behoben, bei dem Abfragen, die über vorbereitete Anweisungen ausgeführt wurden, doppelte Einträge im Advanced Audit-Protokoll generieren konnten.

Es wurde ein Problem behobenSET ROLE NONE, bei dem die Rechte einer zuvor aktiven Rolle in Sitzungen mithilfe der Schreibweiterleitung nicht korrekt gelöscht wurden. Dadurch konnten Operationen ermöglicht werden, die nach der Deaktivierung der Rolle hätten verweigert werden sollen.

CVE-2026-46863

CVE-2026-60163

CVE-2026-61094

CVE-2026-21936

CVE-2026-21937

CVE-2026-21941

CVE-2026-21948

CVE-2026-21968

CVE-2026-60585

CVE-2026-60332

CVE-2026-60331

CVE-2026-60747

CVE-2026-47023

CVE-2026-60186

CVE-2026-60184

CVE-2026-60185

CVE-2026-60187

CVE-2026-60188

CVE-2026-60189

CVE-2026-60191

CVE-2026-60190

Es wurde ein Problem behoben, das dazu führen kann, dass die Datenbankinstanz neu gestartet wird ALTER TABLE ... REORGANIZE PARTITIONDROP PARTITION, wenn ADD PARTITION sie ausgeführt wird oder wenn gleichzeitige Operationen (wie Performance-Schemaabfragen, Optimierung der Volltextsuche oder Erfassung von Statistiken) auf dieselbe Tabelle zugreifen.

Es wurde ein Problem behoben, das zu einem Neustart der Datenbankinstanz führen kann, wenn Abfragen an performance_schema.data_lock_waits oder gleichzeitig für Tabellen performance_schema.data_locks ausgeführt werden, denen mithilfe von Spalten hinzugefügt wurden. ALTER TABLE ... REORGANIZE PARTITION ALGORITHM=INSTANT

Es wurde ein Problem behoben, das dazu führen kann, dass die Writer-Instanz neu gestartet wird, während eine ALTER TABLE ... REORGANIZE PARTITION SQL-Anweisung verarbeitet wird, die die Reihenfolge der Unterpartitionen ändert.

Es wurde ein Problem behoben, bei dem DDL-Operationen auf der Writer-Instanz bestimmte SQL-Anweisungen auf Reader-Instanzen blockieren oder beenden konnten. Zu den betroffenen Anweisungen gehörten Schreiboperationen wie UPDATE oder TRUNCATE für performance_schema Tabellen sowie Schreiboperationen für temporäre Tabellen und JOIN Operationen.

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 einer SQL-Anweisung bereinigt wurden. Dieser Neustart könnte zu einer längeren Abschlusszeit des Switchovers führen.

Es wurde ein Problem behoben, das dazu führen konnte, dass die Schreibweiterleitung auf einer Reader-DB-Instance nicht mehr funktionierte und ein Neustart des Readers erforderlich war, um die Schreibweiterleitung wiederherzustellen. Dies konnte auftreten, wenn eine weitergeleitete Abfrage abgebrochen wurde oder das Zeitlimit überschritten wurde, während die globale Schreibweiterleitung oder die lokale Schreibweiterleitung verwendet wurde.

Es wurde ein Problem behoben, bei dem eine Verzögerung bei der Größenänderung kritischer Datenstrukturen während Aurora serverless Skalierungsvorgängen dazu führen konnte, dass die RDS-Zustandsüberwachung die Datenbankinstanz neu startete.

Es wurde ein Problem behoben, das dazu führen konnte, dass die Writer-Instance aufgrund eines internen Zeitkonflikts bei sehr gleichzeitigen Schreibvorgängen neu gestartet wurde.

Es wurde ein Problem behoben, das dazu führen konnte, dass eine Datenbankinstanz neu gestartet wurde, wenn das erweiterte Binlog aktiviert ist.

Es wurde ein Fehler behoben, der dazu führen konnte, dass das Replikat kurzzeitig die Verbindung zum Writer trennte und sich erneut mit dem Writer verband, was zu einer vorübergehenden Erhöhung der Replikationsverzögerung () führte. AuroraReplicaLag

Es wurde ein Problem im Aurora Storage Daemon behoben, das in seltenen Fällen zu einem unerwarteten Neustart der Datenbank führen konnte.

Es wurde ein Problem behoben, bei dem bei aktivierter Schreibweiterleitung eine Lesersitzung mit der aurora_replica_read_consistency Einstellung auf die letzten festgeschriebenen Änderungen nicht lesen global konnte.

Es wurde ein Problem behoben, das zum 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-Annotation deklariert wurde.

Es wurde ein Problem behoben, bei dem das Trennen von Lesegeräten Aborted_clients auf der Writer-Instanz fälschlicherweise erhöht werden konnte, wenn die Schreibweiterleitung aktiviert war.

Es wurde ein Problem behoben, bei dem in einigen Fällen der Verbindungsstatus nach einem Upgrade ohne Ausfallzeiten nicht erhalten blieb, was zu unerwartetem Verhalten führen konnte.

Es wurde ein Problem behoben, bei dem während der Schreibweiterleitung ein Neustart der Reader-Instanz zu einer verwaisten Weiterleitungssitzung auf der Writer-Instanz führen konnte und das Beenden dieser Sitzung dazu führen konnte, dass der Writer neu gestartet wurde.

Die Ausfallzeiten beim Zero-Downtime Patching (ZDP) wurden reduziert, indem die Kommunikation zwischen der Datenbankinstanz und der Speicherebene nach dem Patchen optimiert wurde.

Es wurde ein Problem mit der Speicherverwaltung von Aurora MySQL behoben, bei dem Antwortaktionen aufgrund von Speichermangel (OOM) nach einer internen Zeitüberschreitung nicht zuverlässig deaktiviert wurden, wenn gleichzeitig der DB-Parameterwert geändert wurde. aurora_oom_response

Es wurde ein Problem in Enhanced Binlog behoben, das nach einer Snapshot-Wiederherstellung falsche Binärprotokollkoordinaten meldete. Bisher konnte dies zu einer ungültigen Binlog-Replikationseinrichtung führen, wenn Enhanced Binlog auf dem Quell-Cluster ausgeführt wurde und einige Transaktionen rückgängig gemacht wurden.

Es wurde ein Problem mit der Funktion zur automatischen Inkrementierung behoben, bei dem Autoinkrementwerte für partitionierte Tabellen nicht korrekt wiederhergestellt wurden, was zu potenziellen DUPLICATE KEY-Fehlern führen konnte.

Es wurde eine neue CloudWatch Metrik hinzugefügtAuroraTempTableVolumeTotalBytes, die die Gesamtzahl der Cluster-Volume-Bytes angibt, die sowohl von internen als auch von externen temporären InnoDB-Tablespaces auf Writer-Instanzen verwendet werden. Diese Metrik meldet den temporären Tablespace-Speicherverbrauch in allen aktiven Sitzungen. Sie können sie verwenden, um Wachstumstrends zu überwachen, speicherintensive Workloads zu identifizieren und Alarme auszulösen. CloudWatch Weitere Informationen zu dieser Metrik finden Sie unter CloudWatch Amazon-Metriken für Amazon Aurora im Amazon Aurora-Benutzerhandbuch. Weitere Informationen zu temporären Tabellen finden Sie unter Externe temporäre Tabellen und interne temporäre Tabellen auf der MySQL-Website.

Es wurde ein Problem behoben, bei dem die Durchsatz- und Latenzmetriken für die Schreibweiterleitung nach einem Failover-Ereignis auf Clustern mit aktivierter Schreibweiterleitung fälschlicherweise 0 meldeten. Diese Metriken geben jetzt genau die Schreibweiterleitungsaktivität nach einem Failover wieder:ForwardingReplicaDMLLatency, ForwardingReplicaDMLThroughputForwardingReplicaSelectLatency, und. ForwardingReplicaSelectThroughput

Es wurde ein Leistungsproblem behoben, bei dem der Optimierer einen suboptimalen Abfrageausführungsplan mit vorbereiteten Anweisungen auswählte, die IN parametrisierte Werte verwenden.

Es wurde ein Problem behoben, das dazu führen kann, dass Abfragen, die Hash-Joins verwenden, falsche Ergebnisse zurückgeben, wenn die parallele Abfrage aktiviert ist und der für einen Hash-Join benötigte Speicher das Limit überschreitet.

Es wurde ein Problem behoben, das dazu führen konnte, dass das Klonen von Datenbankclustern längere Zeit in Anspruch nahm.

Eine in MySQL 8.0.42 eingeführte Regression wurde behoben, bei der das Einfügen in eine partitionierte Tabelle mithilfe einer vorbereiteten Anweisung oder einer gespeicherten Prozedur mit ERROR 1748 („Es wurde eine Zeile gefunden, die nicht dem angegebenen Partitionssatz entspricht“) fehlschlagen konnte. Dies trat auf, als die Spalte mit dem Partitionsschlüssel verwendet wurde. DEFAULT CURRENT_TIMESTAMP Durch das Bereinigen der Partition zum Zeitpunkt der Vorbereitung wurde eine Partition auf der Grundlage des aktuellen Zeitstempels gesperrt. Bei einer späteren erneuten Ausführung konnte der Zeitstempel jedoch einer anderen Partition zugeordnet werden. Weitere Informationen zu diesem Fix finden Sie unter MySQL Upstream Bug #119784 auf der MySQL Bugs Website.