Aurora MySQL 3.14 allgemein verfügbar: Hybrider Post-Quanten-TLS-Schlüsselaustausch braucht auch Client-Unterstützung, DELETE erhält RETURNING und macht es zum reservierten Wort, Zeilengrößenverhalten bleibt anders als bei Community 8.0.46
Am 2. November 2026 gab AWS Aurora MySQL 3.14 (kompatibel mit MySQL 8.0.46) als allgemein verfügbar bekannt, mit dem Post-Quanten-TLS-Schlüsselaustausch (PQ-TLS) als Hauptpunkt. Die Versionshinweise ergänzen die hybriden Gruppen X25519MLKEM768 und SecP256r1MLKEM768 für TLS 1.3, die nur ausgehandelt werden, wenn der Client sie unterstützt, sonst bleibt es bei klassischen Gruppen; prüfbar über die Statusvariable Aurora_ssl_named_group. Außerdem genannt: schnellere Minor-Upgrades ab 3.08, RETURNING für Einzeltabellen-DELETE (RETURNING wird reserviert, Bezeichner brauchen Backticks), die Metrik FTSCacheMemoryUsed und beibehaltenes Zeilengrößenverhalten vor 8.0.46, das von Community-MySQL abweicht. Audit-Logs erfassen den aufrufenden Client statt des Definierers. Die Hinweise tragen das Datum 26. Oktober und nennen keine Upgrade-Geschwindigkeit oder TLS-Mehraufwand.
Am 2. November 2026 gab AWS bekannt, dass Amazon Aurora MySQL-kompatible Edition 3, die MySQL-8.0-Linie, jetzt als Aurora MySQL 3.14 MySQL 8.0.46 unterstützt. Laut Ankündigung enthält die Version Korrekturen aus dem Community-MySQL und Aurora-spezifische Verbesserungen, und ihre wichtigste Ergänzung ist die Unterstützung des Post-Quanten-TLS-Schlüsselaustauschs (PQ-TLS). Sie ist in allen AWS-Regionen verfügbar, in denen es Aurora MySQL gibt. Ein Datum verlangt Vorsicht: Die Aurora-Versionshinweise führen 3.14.0 unter dem Datum 2026-10-26, die Engine war also etwa eine Woche vor der Ankündigung „ab heute“ dokumentiert.
Die Ankündigung ist kurz, und die Versionshinweise erklären, was die Post-Quanten-Funktion tut. Aurora MySQL fügt für TLS-1.3-Verbindungen neben den klassischen Gruppen auf elliptischen Kurven zwei hybride Schlüsselaustauschgruppen hinzu, X25519MLKEM768 und SecP256r1MLKEM768. Clients, die Post-Quanten-Schlüsselaustausch unterstützen, handeln automatisch ein quantenresistentes gemeinsames Geheimnis aus, und Clients ohne diese Unterstützung nutzen weiter klassische Gruppen. Das Einschalten ist also kein Schalter auf dem Server: Es geschieht nur, wenn auch die Client-Bibliothek diese Gruppen unterstützt und TLS 1.3 nutzt. Was eine Sitzung ausgehandelt hat, zeigt SHOW STATUS LIKE 'Aurora_ssl_named_group'.
Die Versionshinweise nennen weitere Änderungen, die für Betreiber wichtiger sein können. Minor-Version-Upgrades auf 3.14 ab Version 3.08 oder höher laufen jetzt schneller ab, sodass die Writer-Instanz früher wieder im Dienst ist, ohne Konfigurationsänderung oder Opt-in. Einzeltabellen-DELETE-Anweisungen erhalten eine RETURNING-Klausel, die Werte der gelöschten Zeilen ohne separates SELECT liefert. Weil RETURNING nun ein reserviertes Schlüsselwort ist, muss jeder Bezeichner namens returning in Backticks stehen, und ein nicht maskierter wird nach dem Upgrade nicht mehr geparst. Eine neue CloudWatch-Metrik, FTSCacheMemoryUsed, zeigt den Speicher, den der InnoDB-Volltextsuch-Cache über alle Tabellen einer Instanz nutzt.
Eine Kompatibilitätsentscheidung verdient genaues Lesen. Community-MySQL 8.0.46 hat die Behandlung von Tabellen mit vielen Spalten bestimmter Art geändert, sodass das Anlegen einer solchen Tabelle mit ERROR 1118 „Row size too large“ scheitern kann, obwohl dieselbe Anweisung in früheren 8.0-Versionen funktionierte. Die Versionshinweise sagen, Aurora MySQL 3.14.0 behalte das ältere Verhalten bei, sodass diese Anweisungen wie in 3.13.0 und früher weiter funktionieren. Aurora 3.14 weicht hier also von Community 8.0.46 ab, was beim Testen oder Migrieren zwischen beiden zählt.
Die Hinweise listen auch Sicherheitskorrekturen. Das Advanced-Audit-Log erfasste für Anweisungen in einer SQL-SECURITY-DEFINER-Routine bisher Benutzer und Host des Definierers statt des aufrufenden Clients und erfasst jetzt den aufrufenden Client. Vorbereitete Anweisungen erzeugen keine doppelten Audit-Einträge mehr. Eine Korrektur betrifft SET ROLE NONE, das in Sitzungen mit Write-Forwarding die Rechte einer früheren Rolle nicht löschte und so Vorgänge erlauben konnte, die verweigert werden sollten. Die Version nennt zudem Korrekturen für zwei CVEs hoher Schwere und eine längere Liste mittlerer Schwere. Teams, die Audit-Logs für Compliance auswerten, sollten damit rechnen, dass sich die Werte für Benutzer und Host nach dem Upgrade ändern.
Zum Rollout sagt AWS, man könne in Wartungsfenstern mit automatischen Minor-Version-Upgrades aktualisieren, und die Upgrade-Rollout-Richtlinie von AWS Organizations könne Upgrades phasenweise über Cluster verteilen. Upgrades sind direkt oder per Snapshot-Wiederherstellung möglich. Für ein Team ist die Checkliste kurz: prüfen, ob Client-Bibliotheken die hybriden Gruppen aushandeln, wenn PQ-TLS das Ziel ist, im Code nach nicht maskierten returning-Bezeichnern suchen, Verbraucher der Audit-Logs prüfen und zuerst in einer niedrigeren Umgebung testen. Ankündigung und Hinweise nennen keine Zahlen zur Geschwindigkeit des schnelleren Upgrades oder zu einem TLS-Mehraufwand.
Sources
FAQ
Macht das Upgrade auf Aurora MySQL 3.14 meine Verbindungen automatisch quantenresistent?
Nicht unbedingt. Die Versionshinweise ergänzen die hybriden Gruppen X25519MLKEM768 und SecP256r1MLKEM768 für TLS 1.3, doch sie werden nur ausgehandelt, wenn auch der Client Post-Quanten-Schlüsselaustausch unterstützt; sonst nutzt die Sitzung klassische Gruppen. Die Statusvariable Aurora_ssl_named_group zeigt, was eine Sitzung ausgehandelt hat.
Welches Kompatibilitätsproblem trifft man vor dem Upgrade am leichtesten?
RETURNING ist jetzt ein reserviertes Schlüsselwort, weil Einzeltabellen-DELETE eine RETURNING-Klausel erhielt. Jeder Bezeichner namens returning muss in Backticks stehen, sonst scheitert das Parsen nach dem Upgrade. Außerdem erfasst das Audit-Log in Definer-Routinen jetzt den aufrufenden Client; Auswertungen, die alte Benutzer- oder Hostwerte erwarten, sind zu prüfen.
Behandelt Aurora 3.14 die Zeilengröße wie Community-MySQL 8.0.46?
Nein. Community 8.0.46 kann bei manchen Tabellen mit vielen Spalten mit ERROR 1118, Row size too large, scheitern, doch laut Versionshinweisen behält Aurora MySQL 3.14.0 das Verhalten vor 8.0.46 bei, sodass diese Anweisungen wie in 3.13.0 und früher gelingen. Beim Testen oder Migrieren zwischen beiden ist dieser Unterschied zu beachten.