Updates der Aurora MySQL-Datenbank-Engine 2024-11-18 (Version 3.08.0, kompatibel mit MySQL 8.0.39)

Drei neue CloudWatch Amazon-Metriken wurden hinzugefügt, um Benutzern die Überwachung des InnoDB-Löschvorgangs zu ermöglichen:

Weitere Informationen finden Sie unter CloudWatchAmazon-Metriken für Amazon Aurora im Amazon Aurora Aurora-Benutzerhandbuch.

Es wurde eine neue CloudWatch Metrik TransactionAgeMaximum hinzugefügt, die es Benutzern ermöglicht, lang andauernde Transaktionen zu identifizieren, die möglicherweise die Löschgrenze einschränken. Weitere Informationen finden Sie unter CloudWatch Amazon-Metriken für Amazon Aurora im Amazon Aurora Aurora-Benutzerhandbuch.

Drei neue CloudWatch Metriken zur out-of-memory (OOM-) Vermeidung wurden hinzugefügt:

Weitere Informationen finden Sie unter CloudWatchAmazon-Metriken für Amazon Aurora im Amazon Aurora Aurora-Benutzerhandbuch.

Drei CloudWatch Metriken zur Vermeidung von out-of-memory (OOM) wurden von laufenden Gesamtwerten zu inkrementellen Zählern geändert:

Weitere Informationen finden Sie unter CloudWatchAmazon-Metriken für Amazon Aurora im Amazon Aurora Aurora-Benutzerhandbuch.

Zwei globale Statusvariablen wurden hinzugefügt, um die Menge an Speicher anzuzeigen, die von internen temporären Tabellen belegt wird: aurora_temptable_ram_allocation undaurora_temptable_max_ram_allocation. Diese globalen Statusvariablen erhöhen die Beobachtbarkeit und helfen bei der Diagnose von Problemen im Zusammenhang mit der Speichernutzung interner temporärer Tabellen.

Weitere Informationen finden Sie unter Globale Statusvariablen von Aurora MySQL im Amazon Aurora Aurora-Benutzerhandbuch.

Es wurde die neue Systemvariable eingeführtaurora_optimizer_trace_print_before_purge, mit der Optimizer-Traces in das Fehlerprotokoll gedruckt werden können, bevor der Server die Traces aus dem Speicher löscht. Eine Bereinigung kann auf der Grundlage der in den Systemvariablen optimizer_trace_offset und optimizer_trace_limit festgelegten Schwellenwerte ausgelöst werden.

Unterstützung für die folgenden DB-Instance-Klassen wurde hinzugefügt:

Weitere Informationen finden Sie unter Unterstützte DB-Engines für DB-Instance-Klassen im Benutzerhandbuch für Amazon Aurora.

Es wurde ein neuer Benutzer für die Replikation von Binärprotokollen (Binlog) eingeführt. rdsrepladmin_priv_checks_user Weitere Informationen finden Sie unter Privilege checks user for binary log replication im Amazon Aurora Aurora-Benutzerhandbuch.

Es wurde ein Problem behoben, bei dem Eingabeparameter für gespeicherte Aurora-MySQL-Prozeduren möglicherweise falsch behandelt wurden.

CVE-2023-44487

CVE-2024-0853

CVE-2024-20996

CVE-2024-21000

CVE-2024-21013

CVE-2024-21125

CVE-2024-21127

CVE-2024-21129

CVE-2024-21130

CVE-2024-21134

CVE-2024-21135

CVE-2024-21137

CVE-2024-21142

CVE-2024-21157

CVE-2024-21159

CVE-2024-21160

CVE-2024-21162

CVE-2024-21163

CVE-2024-21165

CVE-2024-21166

CVE-2024-21173

CVE-2024-21177

CVE-2024-21179

CVE-2024-21185

CVE-2024-25062

CVE-2024-37371

CVE-2025-21492

Es wurde ein Fehler behoben, der dazu führen kann, dass der Server unerwartet neu gestartet wird, nachdem DML-Befehle (Data Manipulation Language) für eine Tabelle ausgeführt wurden, in der bereits Spalten sofort gelöscht wurden, sodass die Anzahl der gelöschten und nicht gelöschten Spalten mehr als 1017 beträgt.

Es wurde ein Problem behoben, das dazu führen kann, dass Datenbank-Protokolldateien nicht korrekt rotiert wurden, was zu einer erhöhten Nutzung des lokalen Speicherplatzes auf einer DB-Instance führen kann.

Es wurde ein Problem behoben, das dazu führen konnte, dass die DB-Instance unter Speichermangel keine Verbindungen mehr schloss, wenn aurora_oom_response aktiviert war, was zu einem out-of-memory Neustart führte, der andernfalls vermieden werden könnte.

Es wurde ein Problem behoben, das dazu führen kann, dass eine Reader-DB-Instance neu gestartet wird, wenn Speicher freigegeben wird, der für die Protokollanwendung verwendet wurde.

Es wurde ein Problem bei der Berechnung interner Metriken für Volltextsuchindizes (FTS) behoben, das zu Datenbankneustarts führen kann.

Es wurde ein Community-Problem behoben, das manchmal zu falschen Abfrageergebnissen führen konnte, wenn eine LIMIT Klausel in Unterabfragen zusammen mit dem Pushdown von Indexbedingungen verwendet wurde.

Es wurde ein Problem behoben, das zu einer Speicherzugriffsverletzung führte, die dazu führte, dass ein Mutex-Objekt veröffentlicht wurde, das dem Thread nicht mehr gehörte.

Es wurde ein Problem behoben, das bei der Verarbeitung einer großen Anzahl von Relay-Protokolldateien während der Relay-Log-Wiederherstellung zu einem Neustart eines Binärprotokolls (Binlog) führen kann.

Es wurde ein Problem behoben, das dazu führen kann, dass eine Aurora-Reader-DB-Instance neu gestartet wird, wenn die Schreibweiterleitung aktiviert ist.

Es wurde ein Problem behoben, bei dem eine Abfrage, die mehrere UNION Klauseln enthielt, eine große Menge an Speicher zuweisen konnte, was zu einem Neustart der DB-Instance führte.

Es wurde ein Problem behoben, das dazu führte, dass die Writer-DB-Instance neu gestartet wurde, wenn eine parallel Abfrage auf einer Reader-DB-Instance ausgeführt wurde.

Es wurde ein Problem behoben, bei dem die Binlog-Replikation auf dem Replikat zum Stillstand kam, weil bei der Ausführung des Befehls ein Deadlock im I/O Thread des Replikats aufgetreten war. FLUSH RELAY LOGS

Es wurde ein Problem behoben, das bei der Verarbeitung großer GTID-Sätze auf einem DB-Cluster mit aktiviertem erweitertem Binlog zu einem Neustart der DB-Instance führte.

Es wurde ein Problem behoben, das zu einem Neustart eines Binlog-Replikats führen kann, wenn der In-Memory-Relay-Log-Cache aktiviert ist. Der In-Memory-Relay-Log-Cache ist auf von Aurora MySQL verwalteten Binärprotokollreplikaten aktiviert, wenn entweder die Single-Thread-Binärprotokollreplikation oder die Multithread-Replikation mit aktivierter GTID-Autopositionierung verwendet wird.

Es wurde ein Problem behoben, das dazu führen kann, dass eine Binlog-Replikatinstanz neu gestartet wird, wenn beim Starten der Datenbank-Engine DCL-Anweisungen (Data Control Language) angewendet werden.

Es wurde ein Problem behoben, das in seltenen Fällen dazu führen kann, dass eine Reader-DB-Instance aufgrund eines Deadlatches neu gestartet wird, wenn SELECT Abfragen für Tabellen ausgeführt werden, die von ihrer Writer-DB-Instance aktualisiert wurden.

Es wurde ein Problem behoben, das dazu führen kann, dass eine Aurora Global Database-Leseinstanz mit einer aktiven Schreibweiterleitungssitzung neu gestartet wird.

Es wurde ein Problem behoben, das dazu führen kann, dass Aurora-Read Replicas neu gestartet werden, wenn bestimmte seltene Transaktions-Commit-Bestellungen auf der Writer-DB-Instance ausgeführt wurden.

Es wurde ein Problem behoben, das dazu führen kann, dass eine Datenbank neu gestartet wird, wenn geplante Ereignisse abgebrochen werden, während sie auf DB-Instances laufen, für die Enhanced Binlog aktiviert ist.

Es wurde ein Problem behoben, bei dem eine Client-Verbindung beim Zero-Downtime-Patching (ZDP) oder beim Zero-Downtime-Patching (ZDR) hängen bleiben kann.

Es wurde ein Problem behoben, das in seltenen Fällen aufgrund eines Speicherverwaltungsproblems, das bei der Behandlung eines Fehlers beim Öffnen einer Tabelle auftreten kann, zu einem Neustart einer Datenbankinstanz führte.

Es wurde ein Problem behoben, das dazu führen kann, dass in SQL-Anweisungen in einigen Zeilen unerwartete Fehler oder Warnungen wegen einer Verletzung des Primärschlüssels auftreten, wenn gleichzeitige INSERT Anweisungen für eine Tabelle ausgeführt werden, die eine AUTO_INCREMENT Primärschlüsselspalte und eine eindeutige Schlüsselspalte hat, und wenn eine INSERT Anweisung eindeutige Schlüsselverletzungen in verschiedenen Zeilen aufweist.

Das Performance-Schema-Instrument memory/sql/sp_head::main_mem_root ist jetzt ein kontrolliertes Instrument. Folglich trägt der für die Analyse und Darstellung von gespeicherten Programmen zugewiesene Speicher nun zu den Speicherlimits pro Verbindung bei.

Es wurde ein Problem behoben, bei dem eine Zeile während einer Aktualisierung über den räumlichen Index nicht mehr lesbar wurde.

Es wurde ein Problem behoben, das Benutzer daran hinderte, die lokale Schreibweiterleitung zu deaktivieren.

Es wurde ein Problem behoben, bei dem eine SELECT COUNT Abfrage bei Verwendung der Schreibweiterleitung das falsche Ergebnis zurückgeben konnte.

Es wurde ein Problem behoben, das zu falschen Abfrageergebnissen führen kann, wenn ZDP Sitzungsvariablen, die als Hinweise in Abfragen festgelegt wurden, fälschlicherweise wiederherstellt.

Es wurde ein Problem mit der automatischen Kürzung von Undo-Tablespaces behoben, wenn sie in Upgrade-Szenarien den Schwellenwert innodb_max_undo_log_size überschreiten.

Es wurde ein Problem behoben, bei dem die Commit-Latenz und der Commit-Durchsatz nicht gemessen wurden, wenn auf gesetzt ist. innodb_flush_log_at_trx_commit 0

Es wurde ein Problem behoben, das dazu führen konnte, dass Verzögerungen bei Aurora-Replikaten falsch gemeldet wurden.

Es wurde ein Problem behoben, bei dem ein falscher Wert für die threads_running Variable angegeben wurde, wenn Aurora Global Database verwendet wurde.

Es wurde ein Problem behoben, bei dem ein Aurora MySQL-Binlog-Replikat mit aktivierter parallel sekundärer Indexoptimierung neu gestartet wurde, wenn Replikationsänderungen auf Tabellen mit Fremdschlüsseln angewendet wurden.

Es wurde ein Neustartproblem behoben, das durch eine längere Größenänderung der Sperr-Hash-Tabelle während des Hoch- oder Herunterskalierens verursacht wurde.

Es wurde ein Problem behoben, das dazu führen kann, dass eine DB-Instance nach dem Deaktivieren der Binärprotokollierung neu gestartet wird, obwohl die erweiterte Binärprotokollierung zuvor aktiviert war.

Es wurden Optimierungen eingeführt, um den Speicherverbrauch bei der Wiederherstellung logischer Datenwörterbücher bei einer großen Anzahl von Tabellen zu reduzieren.

Es wurde ein Problem behoben, bei dem ein Benutzer beim Ausführen der gespeicherten Prozedur mysql.rds_set_external_source auf einem Binlog-Replikat einen ERROR 1377 (HY000): Fatal error during log purge Fehler feststellen konnte, wenn die binäre Protokollreplikation bereits konfiguriert ist.

Es wurde ein Fehler behoben, der das Fortbestehen von Benutzerrollenrechten nach ZDR verhinderte.

Ein Speicherproblem im Zusammenhang mit den Standardrollen des View Definers wurde behoben.

Es wurde ein Problem behoben, das dazu führen kann, dass eine DB-Instance neu gestartet wird, wenn sie ausgeführt SHOW VOLUME STATUS wird.

Es wurde ein Neustartproblem behoben, das durch eine längere Größenänderung des Pufferpools beim Hoch- oder Herunterskalieren verursacht wurde.

Es wurde ein Neustartproblem behoben, das durch den logischen Read-Ahead-Zugriff (LRA) auf freigegebene Seiten aufgrund der Größenänderung des Puffers während eines Herunterskaliervorgangs verursacht wurde.

Es wurde ein Problem behoben, bei dem SELECT Abfragen, die falsche Ergebnisse lieferten, wenn die Abfrage eine LEFT OUTER JOIN Semi-Join-Transformation verwendet, die Materialisierung als Strategie verwendet, verwendet.

Es wurde ein Problem behoben, das dazu führen kann, dass die Deaktivierung der Schreibweiterleitung nicht abgeschlossen werden kann.

Es wurde ein Problem behoben, bei dem die BlockedTransactions CloudWatch Metriken ActiveTransactions und niedrigere Werte als erwartet meldeten.

Es wurde ein Problem behoben, bei dem die Binlog-Replikation unterbrochen wurde, wenn das Replikat eine DELETE Anweisung mit mehreren Tabellen verarbeitet, die explizit sowohl aus einer übergeordneten als auch aus einer untergeordneten Tabelle löscht.

Es wurde ein Problem behoben, das zu einem Neustart der DB-Instance führen kann, wenn ein Trigger mit benutzerdefinierten Funktionen verarbeitet wird, die einen Typ zurückgeben. enum

Es wurde ein Problem behoben, bei dem die DMLLatency CloudWatch Metrik bei der Replikation mit binlog_format set to falsche Werte für eine binäre Protokollreplikat-Instance anzeigte. row

Es wurde ein Problem behoben, bei dem langsame INSERTDELETE, und UPDATE Abfragen, die vom MySQL Event Scheduler ausgeführt wurden, nicht im Protokoll für langsame Abfragen aufgezeichnet wurden, es sei denn, ihnen ging eine langsame SELECT Abfrage voraus.

Es wurde ein Problem behoben, das in seltenen Fällen entweder zu einer zeitweiligen Nichtverfügbarkeit einer Aurora-Lesereplik oder zu Inkonsistenzen der Tabellendefinitionen, manchmal mit dem FehlerTable does not exist, auf dem Replikat führte. Dies ist auf gleichzeitige Leseabfragen auf das Replikat und auf DDL-Operationen (Data Definition Language) auf der Writer-DB-Instance zurückzuführen.

Es wurde ein Problem behoben, das dazu führte, dass die Ausführung des SHOW BINARY LOGS Befehls auf einem DB-Cluster, in dem das erweiterte 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.

Die Leistung des Hauptversions-Upgrades von Aurora MySQL Version 2 auf Version 3 für DB-Cluster mit einer großen Anzahl von Datenbankobjekten (wie Tabellen, Triggern und Routinen) wurde verbessert.

Für größere DB-Instance-Klassen aktualisiert der Datenbank-Upgrade-Prozess traditionelle MySQL-Objektmetadaten parallel unter Verwendung mehrerer Threads auf das neue, atomare MySQL 8.0-Datenwörterbuch.

Es wurde ein Problem behoben, das dazu führte, dass Upgrades oder Migrationen fehlschlugen, wenn die Zielversion der Aurora MySQL-DB-Engine 3.04.0 oder höher ist. Dies tritt auf, wenn der lower_case_table_names DB-Cluster-Parameter auf 1 gesetzt ist und die MySQL-Datenbankkollation nicht mit Tabellennamen in Kleinbuchstaben kompatibel ist.

Es wurde ein Problem behoben, das dazu führte, dass bei bestimmten Abfragen, die sowohl als auch JOIN Operationen enthielten, fälschlicherweise NULL Werte aus der Ergebnismenge weggelassen wurden. UNION (Community-Bugfix #114301)