

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.

# Aurora MySQL-Datenbank-Engine-Updates 2026-08-27 (Version 3.13.0, kompatibel mit MySQL 8.0.45)
<a name="AuroraMySQL.Updates.3130"></a><a name="3130"></a><a name="3.13.0"></a>

**Version: 3.13.0 **

Aurora MySQL 3.13.0 ist jetzt allgemein verfügbar und mit MySQL 8.0.45 kompatibel. Weitere Informationen zu den Änderungen in der Community finden Sie in den Versionshinweisen zu [ MySQL 8.0 ](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/) auf der MySQL-Website.

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-Benutzerhandbuch*.

Sie können ein Upgrade von jedem derzeit unterstützten Aurora MySQL Version 2-Cluster auf einen Aurora MySQL-Cluster der Version 3.13.0 auf eine von drei Arten durchführen: Führen Sie ein direktes Upgrade mit [ Zero Downtime Patching (ZDP) durch](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.ZDP.html), stellen Sie einen Snapshot wieder her oder initiieren Sie ein verwaltetes blue/green Upgrade mithilfe von Amazon RDS Deployments. [ Blue/Green ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-overview.html)

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 Upgrade-Informationen finden Sie unter [ Upgrade von 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 Aurora MySQL-Upgrade ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.MajorVersionUpgrade.html#AuroraMySQL.Upgrading.Troubleshooting) im * Amazon Aurora-Benutzerhandbuch*.

Wenn Sie Fragen oder Bedenken haben, Support steht es in den Community-Foren und über [Support](https://aws.amazon.com/support) zur Verfügung. Weitere Informationen finden Sie unter [ Wartung eines Aurora-DB-Clusters ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) im * Amazon Aurora-Benutzerhandbuch*.

## Verbesserungen
<a name="AuroraMySQL.Updates.3130.Improvements"></a>

### Fehlerbehebungen bei der Sicherheit
<a name="AuroraMySQL.Updates.3130.SecurityFixes"></a>

Diese Version enthält Korrekturen für die folgenden CVEs mit hohem Schweregrad:
+ [CVE-2026-46863](https://www.cve.org/CVERecord?id=CVE-2026-46863)

Diese Version enthält Korrekturen für die folgenden CVEs mit mittlerem Schweregrad:
+ [CVE-2026-21936](https://www.cve.org/CVERecord?id=CVE-2026-21936)
+ [CVE-2026-21937](https://www.cve.org/CVERecord?id=CVE-2026-21937)
+ [CVE-2026-21941](https://www.cve.org/CVERecord?id=CVE-2026-21941)
+ [CVE-2026-21948](https://www.cve.org/CVERecord?id=CVE-2026-21948)
+ [CVE-2026-21968](https://www.cve.org/CVERecord?id=CVE-2026-21968)

### Verbesserungen der Verfügbarkeit
<a name="AuroraMySQL.Updates.3130.AvailabilityImprovements"></a>
+ Es wurde ein Problem behoben, das dazu führen kann, dass die Datenbankinstanz neu gestartet wird `ALTER TABLE ... REORGANIZE PARTITION``DROP PARTITION`, wenn `ADD PARTITION` sie ausgeführt wird oder wenn gleichzeitige Operationen (wie Performance-Schemaabfragen, Optimierung der Volltextsuche oder Statistikerfassung) 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 Erstellung eines neuen Datenbank-Clusters fehlschlug und der Cluster gelöscht und neu erstellt werden musste.
+ Es wurde ein Problem mit dem Mechanismus zur Vermeidung von Speichermangel (OOM) behoben, das zu einem Neustart der Datenbankinstanz führen konnte, während versucht wurde, Speicher unter kritischem Speicherauslastung wiederherzustellen.
+ Es wurde ein Problem behoben, das dazu führen konnte, dass die Writer-Instanz wiederholt neu gestartet wurde, wenn die Writer-Instanz beim Löschen eines Undo-Datensatzes für eine Tabelle mit Indizes in virtuellen Spalten neu gestartet wurde.
+ Es wurde ein Problem behoben, das dazu führen konnte, dass Read Replicas neu gestartet wurden, wenn die Writer-Instanz eine große Transaktion mit aktiviertem Binlog festschreibt. Dieses Problem konnte auch beim Lesen der Binlog-Datei, die die große Transaktion enthält, zu Fehlern führen.
+ Es wurde ein Problem behoben, bei dem eine Verzögerung bei der Größenänderung des InnoDB-Pufferpools während Aurora serverless Skalierungsvorgängen dazu führen konnte, dass die Datenbankinstanz nicht mehr reagierte und neu gestartet wurde.
+ 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 bereinigte.
+ Es wurde ein Problem behoben, das dazu führen konnte, dass eine Writer-DB-Instance neu gestartet wurde, wenn eine Reader-DB-Instance neu gestartet wurde, während die lokale oder globale Schreibweiterleitung aktiviert war.
+ Es wurde ein Problem behoben, das zu einem unerwarteten Datenbankneustart auf Reader-Instances führen konnte, wenn Unterabfragen, die parallele Query-Anfragen verwenden, nach Abschluss nicht korrekt geschlossen wurden.
+ Es wurde ein Problem behoben, bei dem eine Replikatinstanz neu gestartet werden konnte, wenn vorbereitete Anweisungen für das Binärprotokoll ausgeführt wurden, die per Schreibweiterleitung an den Writer weitergeleitet wurden.
+ Es wurde ein Problem behoben, das dazu führen konnte, dass die Writer-Instanz 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.
+ Die Leistung der physischen Aurora-Replikation wurde verbessert, indem Änderungen von der Writer-Instance mithilfe mehrerer Threads auf Reader-Instances angewendet wurden.

### Allgemeine Verbesserungen
<a name="AuroraMySQL.Updates.3130.GeneralImprovements"></a>
+ 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 selten auftretendes Problem behoben, das dazu führen konnte, dass die Datenbankinstanz neu gestartet wurde, wenn laufende SQL-Anweisungen während der Größenänderung des Pufferpools oder beim Löschen von Seiten aus temporären Tabellen gelesen wurden.
+ Die Reihenfolge der Commits bei Binlog-Replikaten mit aktiviertem Enhanced Binlog wurde korrigiert, sodass die Einstellung korrekt berücksichtigt wurde. `replica_preserve_commit_order` Dieses Sortierverhalten 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 konnte, 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 mit der Cluster-Verfügbarkeit behoben, das bei Datenbankserver-Upgrades auftreten konnte, wenn DML-Operationen an Systemtabellen auf veraltete Autoinkrement-Werte verwiesen.
+ Es wurde ein Problem behoben, das zu Replikationsfehlern führen konnte, wenn Binlog-Ereignisse verarbeitet wurden, die die `aurora_in_memory_relaylog` feste Cachegröße (128 MB) überstiegen.
+ Es wurde ein Problem behoben, bei dem der Reader während bestimmter Online-DDL-Operationen auf dem Writer bei Verwendung des Algorithmus Berichte `ERROR 1146` (Tabelle nicht gefunden) `INPLACE` ausgab.
+ Es wurde ein Problem behoben, das bei Vorgängen ohne Ausfallzeiten (ZDP) oder Neustarts (ZDR) zu verzögerter Instance-Verfügbarkeit führen konnte.
+ 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.

### Upgrades und Migrationen
<a name="AuroraMySQL.Updates.3130.UpgradesMigration"></a>
+ Es wurde ein Problem behoben, das dazu führen konnte, dass das Klonen von Datenbankclustern längere Zeit in Anspruch nahm.

## Integration von MySQL-Fehlerbehebungen (Community Edition)
<a name="AuroraMySQL.Updates.3130.Patches"></a>

Diese Version enthält alle Community-Bugfixes bis einschließlich 8.0.45. Weitere Informationen finden Sie unter [MySQL-Fehlerbehebungen durch Aurora-MySQL-3.x-Datenbank-Engine-Updates](AuroraMySQL.Updates.MySQLBugs.md#AuroraMySQL.Updates.MySQLBugs.v3).
+ 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. Referenz: MySQL-Upstream-Bug \#119784[. ](https://bugs.mysql.com/bug.php?id=119784)