Updates der Aurora MySQL-Datenbank-Engine 2025-05-14 (Version 3.09.0, kompatibel mit MySQL 8.0.40)

Optimierte Upgrade-Leistung für kleinere Versionen durch parallel Verarbeitung von Leistungsschema-Updates, wodurch die Upgradedauer reduziert wird, wenn Änderungen am Leistungsschema erforderlich sind.

Die globalen Aurora MySQL-Datenbanken wurden verbessert, sodass sekundäre Lesegeräte den Start abschließen und Leseanfragen bei ungeplanten Ereignissen (Hardwarefehler, Netzwerkunterbrechungen) bearbeiten können. Bisher konnten sekundäre Reader-Instances bei solchen Ereignissen nicht neu gestartet werden. Weitere Informationen finden Sie unter Regionsübergreifende Resilienz für sekundäre Cluster von Global Database im Amazon Aurora Aurora-Benutzerhandbuch.

Die Ausfallzeit des Schreibers bei regionsübergreifenden Switchovers von Aurora MySQL Global Database wurde auf typischerweise unter eine Minute reduziert, wodurch Ausfallzeiten bei geplanten regionalen Switches minimiert wurden.

CVE-2024-11053

CVE-2024-37371

CVE-2024-7264

CVE-2024-21193

CVE-2024-21194

CVE-2024-21196

CVE-2024-21197

CVE-2024-21198

CVE-2024-21199

CVE-2024-21201

CVE-2024-21203

CVE-2024-21207

CVE-2024-21212

CVE-2024-21213

CVE-2024-21218

CVE-2024-21219

CVE-2024-21230

CVE-2024-21236

CVE-2024-21238

CVE-2024-21239

CVE-2024-21241

CVE-2025-21494

CVE-2025-21504

CVE-2025-21525

CVE-2025-21534

CVE-2025-21536

Es wurde ein Problem behoben, bei dem Abfragen mit mehreren Anweisungen, die von Reader- an Writer-Instanzen weitergeleitet wurden, hängen blieben, wenn innodb_flush_log_at_trx_commit die Einstellung auf im Writer und 0 auf einen Wert ungleich Null im Reader gesetzt war, wodurch potenzielle Fehler bei der Schreibweiterleitung verhindert wurden.

Es wurde ein Deadlock-Problem behoben, bei dem Enhanced Binlog aktiviert war und das dazu führen konnte, dass Datenbanken neu gestartet wurden, wenn SHOW BINARY LOGS gleichzeitig entweder Transaktionen an BLACKHOLE-Engines übergeben oder XA PREPARE Anweisungen ausgeführt wurden, wodurch potenzielle blockierte Schreibvorgänge und Probleme mit der Instanzverfügbarkeit verhindert wurden.

Es wurden Race-Bedingungen bei der Schreibweiterleitung behoben, die dazu führen konnten, dass die Aurora-Writer-Instanz neu gestartet wurde, indem verhindert wurde, dass neue Anfragen akzeptiert wurden, bevor vorherige Anfragen vollständig abgeschlossen waren, wodurch die Stabilität von Schreibweiterleitungsvorgängen verbessert wurde.

Es wurde ein Problem mit dem Replikat behoben, bei dem eine Netzwerkunterbrechung die Verbindung mit dem Writer möglicherweise nicht korrekt wiederherstellte, wodurch die Replikation blockiert wurde und die Instanz möglicherweise neu gestartet wurde.

Die Aurora MySQL Out of Memory (OOM) -Antwort implementiert jetzt eine stufenweise Größenänderung des Pufferpools, wodurch die Speichernutzung basierend auf dem Systemspeicherstatus (LOW/RESERVED) schrittweise reduziert wird, wenn sie über den aurora_oom_response DB-Parameter aktiviert wird, wodurch eine bessere Speicherverwaltung in Situationen mit Speicherauslastung ermöglicht wird.

Die Wiederherstellungszeit der Binlog-Datei bei Datenbankneustarts wurde verbessert, indem der Wiederherstellungsprozess so optimiert wurde, dass er unabhängig von der Größe der Binlog-Datei eine konstante Zeit in Anspruch nimmt. Bisher war die Wiederherstellungszeit in einigen Fällen proportional zur Größe der letzten Binlog-Datei.

Es wurde ein Problem behoben, das zu unerwarteten Neustarts des MySQL-Servers führen konnte, wenn bei Abfragen gleichzeitig InnoDB-Tabellen gekürzt wurden. performance_schema.data_lock_waits

Es wurde ein Problem behoben, das dazu führen kann, dass eine Datenbank-Instance neu gestartet wird, wenn große Binlog-Ereignisse bei niedrigen Speicherbedingungen übertragen werden.

Es wurde ein Problem behoben, bei dem Operationen zur Größenänderung des Pufferpools, die während der Vermeidung von Speichermangel (OOM) ausgelöst wurden, in Szenarien mit hoher Arbeitslast nicht mehr reagierten, was zu einem möglichen Neustart der Datenbank führte.

Es wurde ein Problem behoben, das beim Erstellen eines Triggers zu einer Neustartschleife der Datenbank führen kann. Das Problem kann auch auftreten, wenn eine neue Binlog- oder Relaylog-Datei hinzugefügt wird oder diese Dateien rotieren.

Es wurde ein Problem behoben, das dazu führen konnte, dass die Aurora-Reader-Instanz neu gestartet wurde, wenn Schreibweiterleitung mit Abfragen mit mehreren Anweisungen oder impliziten Commit-Abfragen verwendet wurde.

Es wurde ein Problem behoben, bei dem ALTER TABLE ... REBUILD / OPTIMIZE TABLE Operationen übermäßig viel Speicher verbrauchen konnten, indem innodb_ddl_buffer_size Byte pro DDL-Thread zugewiesen wurden, anstatt die Puffergröße auf die Threads aufzuteilen, wodurch eine potenzielle Speicherüberlastung bei DDL-Vorgängen verhindert wurde.

Der Standardwert für wurde für aurora_oom_response alle DB-Instance-Klassen mit mehr als 4 GiB Speicher von print auf print, decline, kill_connect geändert. Weitere Informationen finden Sie unter Amazon Aurora MySQL out-of-memory Issues im Amazon Aurora Aurora-Benutzerhandbuch.

Die folgenden Rechte wurden dem hinzugefügtrds_superuser_role:FLUSH_OPTIMIZER_COSTS,FLUSH_STATUS,FLUSH_TABLES,FLUSH_USER_RESOURCES. Informationen dazu finden Sie in der Dokumentation Amazon Master User Accounts with Amazon Aurora. rds_superuser_role Weitere Informationen zu diesen dynamischen Rechten finden Sie in der MySQL-Dokumentation.

Die schnelle Insert-Optimierung ist ab dieser Aurora MySQL-Version nicht mehr aktiviert. Weitere Informationen finden Sie unter Amazon-Aurora-MySQL-Leistungsverbesserungen im Amazon-Aurora-Benutzerhandbuch.

Ein Problem mit einer falschen Überschreitung des max_user_connections Schwellenwerts, was bei einigen Benutzern zu Verbindungsfehlern führte, wurde behoben. Dies tritt in einigen Randfällen auf, z. B. wenn Verbindungen fast sofort hergestellt und beendet werden.

Es wurde ein Problem mit der Auditprotokollierung behoben, das zu einer hohen CPU-Auslastung führte und dazu führte, dass die Datenbankserverinstanz nicht reagierte.

Es wurde ein Speicherverwaltungsproblem bei der Verwendung von XA-Transaktionen behoben, wodurch mögliche Instanzneustarts verhindert wurden, wenn Enhanced Binlog aktiviert war.

Es wurde ein Problem behoben, bei dem die Abfrageleistung nachließ, wenn der Optimizer falsche Kostenschätzungen vornahm, weil die Bufferpool-Indexstatistiken nach dem Neustart des Datenbankservers falsch aktualisiert wurden.

Es wurde ein Problem behoben, das Kunden daran hinderte, die lokale Schreibweiterleitung zu deaktivieren, weil der Worker-Thread nicht mehr funktionierte.

Es wurde ein Problem behoben, das dazu führte, dass die Ausführung des SHOW BINARY LOGS Befehls auf einem Cluster, auf dem Enhanced Binlog aktiviert ist oder zuvor aktiviert war, länger dauerte. Dieses Problem konnte auch zu einer erhöhten Commit-Latenz führen, wenn mehrere SHOW BINARY LOGS Befehle gleichzeitig ausgeführt wurden.

Es wurde ein Problem behoben, bei dem Zero Downtime Patching (ZDP) nicht erfolgreich sein konnte, wenn versucht wurde, die Verbindung aufrechtzuerhalten, die einem Benutzer gehörte, der gelöscht wurde. Weitere Informationen zu dem DROP USER Befehl und seinen Auswirkungen auf aktive Verbindungen finden Sie in der MySQL-Dokumentation.

Während große Transaktionen empfangen und angewendet wurden und eine Anfrage zum Stoppen des Replikationskanals gestellt wurdeSTOP REPLICA, hat MySQL dies nicht richtig gemacht und anschließend keine Kanalbefehle verarbeitet. Darüber hinaus wurde der Vorgang zum Herunterfahren des Servers nicht ordnungsgemäß abgeschlossen und erforderte entweder das Beenden des MySQL-Prozesses oder einen Neustart des Hostsystems. (Fehler #115966, Fehler #37008345)