Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Updates der Aurora MySQL-Datenbank-Engine 2025-05-14 (Version 3.09.0, kompatibel mit MySQL 8.0.40) **Version**: 3.09.0 Aurora MySQL 3.09.0 ist allgemein verfügbar. Aurora MySQL 3.09-Versionen sind mit MySQL 8.0.40 kompatibel. Weitere Informationen zu Community-Änderungen, die von 8.0.23 zu 8.0.28 vorgenommen wurden, finden Sie in den [Versionshinweisen zu MySQL 8.0](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/). Details zu den neuen Features in Aurora MySQL Version 3 finden Sie unter [Aurora MySQL Version 3, kompatibel mit MySQL 8.0](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.MySQL80.html). Zu den Unterschieden zwischen Aurora MySQL Version 3 und Aurora MySQL Version 2 siehe [Vergleich von Aurora MySQL Version 2 und Aurora MySQL Version 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Compare-v2-v3.html). Einen Vergleich von Aurora MySQL Version 3 und MySQL 8.0 Community Edition finden Sie unter [Vergleich von Aurora MySQL Version 3 und MySQL 8.0 Community Edition](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Compare-80-v3.html) im *Amazon Aurora Aurora-Benutzerhandbuch*. Sie können ein direktes Upgrade durchführen, das einen Snapshot nutzt [zero-downtime-patch](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.ZDP.html), einen Snapshot wiederherstellt oder ein verwaltetes blue/green Upgrade mithilfe von [Amazon RDS Blue/Green Deployments](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-overview.html) von jedem aktuell unterstützten Aurora MySQL Version 2-Cluster auf einen Aurora MySQL Version 3.09.0-Cluster initiiert. Informationen zur Planung eines Upgrades auf Aurora MySQL Version 3 finden Sie unter [Planung eines Hauptversions-Upgrades für einen Aurora MySQL-Cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.MajorVersionUpgrade.html#AuroraMySQL.Upgrading.Planning). Allgemeine Informationen zu Aurora-MySQL-Upgrades finden Sie unter [Upgrade von Amazon-Aurora-MySQL-DB-Clustern](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Upgrading.html) im *Amazon-Aurora-Benutzerhandbuch*. Informationen zur Fehlerbehebung finden Sie unter [Problembehandlung für das direkte Upgrade von Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.MajorVersionUpgrade.html#AuroraMySQL.Upgrading.Troubleshooting) im *Amazon Aurora Aurora-Benutzerhandbuch*. Wenn Sie Fragen oder Bedenken haben, steht Ihnen der AWS Support in den Community-Foren und über den [AWS Support](https://aws.amazon.com/support) zur Verfügung. Weitere Informationen finden Sie unter [Wartung eines DB-Clusters](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) im *Amazon Aurora Aurora-Benutzerhandbuch*. ## Höhepunkte der Veröffentlichung + 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-secondary-availability.html) 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. ## Verbesserungen **Fehlerbehebungen bei der Sicherheit** CVEsKritisch: + [CVE-2024-11053](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-11053) + [CVE-2024-37371](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-37371) Mittel: CVEs + [CVE-2024-7264](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7264) + [CVE-2024-21193](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21193) + [CVE-2024-21194](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21194) + [CVE-2024-21196](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21196) + [CVE-2024-21197](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21197) + [CVE-2024-21198](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21198) + [CVE-2024-21199](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21199) + [CVE-2024-21201](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21201) + [CVE-2024-21203](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21203) + [CVE-2024-21207](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21207) + [CVE-2024-21212](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21212) + [CVE-2024-21213](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21213) + [CVE-2024-21218](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21218) + [CVE-2024-21219](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21219) + [CVE-2024-21230](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21230) + [CVE-2024-21236](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21236) + [CVE-2024-21238](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21238) + [CVE-2024-21239](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21239) + [CVE-2024-21241](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-21241) + [CVE-2025-21494](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21494) + [CVE-2025-21504](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21504) + [CVE-2025-21525](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21525) + [CVE-2025-21534](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21534) + [CVE-2025-21536](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21536) **Verbesserungen der Verfügbarkeit:** + 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](https://dev.mysql.com/doc/refman/8.0/en/blackhole-storage-engine.html) ü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. **Allgemeine Verbesserungen:** + 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\$1connect geändert. Weitere Informationen finden Sie unter [Amazon Aurora MySQL out-of-memory Issues](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-troubleshooting-workload.html#AuroraMySQLOOM) im *Amazon Aurora Aurora-Benutzerhandbuch*. + Die folgenden Rechte wurden dem hinzugefügt`rds_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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.MasterAccounts.html). `rds_superuser_role` Weitere Informationen zu diesen dynamischen Rechten finden Sie in der [MySQL-Dokumentation](https://dev.mysql.com/doc/refman/8.0/en/flush.html). + Ab dieser Aurora MySQL-Version ist die schnelle Insert-Optimierung nicht mehr aktiviert. Weitere Informationen finden Sie unter [Amazon-Aurora-MySQL-Leistungsverbesserungen](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMySQL.Overview.html#Aurora.AuroraMySQL.Performance) 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. **Upgrades und Migrationen:** + 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](https://dev.mysql.com/doc/refman/8.0/en/flush.html). ## Integration von MySQL-Fehlerbehebungen (Community Edition) Diese Version enthält alle Community-Bugfixes bis einschließlich 8.0.40. Weitere Informationen finden Sie unter [MySQL-Fehlerbehebungen durch Aurora-MySQL-3.x-Datenbank-Engine-Updates](AuroraMySQL.Updates.MySQLBugs.md#AuroraMySQL.Updates.MySQLBugs.v3). + Während große Transaktionen empfangen und angewendet wurden und eine Anfrage zum Stoppen des Replikationskanals gestellt wurde`STOP 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 \$1115966, Fehler \$137008345)