Updates der Aurora MySQL-Datenbank-Engine 2024-03-15 (Version 3.04.2, kompatibel mit MySQL 8.0.28) - Amazon Aurora
VerbesserungenIntegration von MySQL-Fehlerbehebungen (Community Edition)

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 2024-03-15 (Version 3.04.2, kompatibel mit MySQL 8.0.28)

Version: 3.04.2

Aurora MySQL 3.04.2 ist allgemein verfügbar. Aurora MySQL 3.04-Versionen sind mit MySQL 8.0.28 kompatibel. Weitere Informationen zu Community-Änderungen, die eingetreten sind, finden Sie in den Versionshinweisen zu MySQL 8.0.

Details zu den neuen Features in Aurora MySQL Version 3 finden Sie unter Aurora MySQL Version 3, kompatibel mit MySQL 8.0. Die Unterschiede zwischen Aurora MySQL Version 3 und Aurora MySQL Version 2 finden Sie unter Vergleich von Aurora MySQL Version 2 und Aurora MySQL Version 3. 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.

Anmerkung

Diese Version ist als Long-Term Support- (LTS, Langzeit-Support)-Version ausgewiesen. Weitere Informationen finden Sie unter Aurora-MySQL-Long-Term-Support (LTS, Langzeit-Support)-Versionen im Amazon-Aurora-Benutzerhandbuch.

Wir empfehlen, den AutoMinorVersionUpgrade Parameter für LTS-Versionen nicht auf zu setzen true (oder die Option Automatisches Upgrade der Nebenversion in der zu aktivieren AWS Management Console). Dies könnte dazu führen, dass Ihr DB-Cluster auf eine Nicht-LTS-Version wie 3.05.2 aktualisiert wird.

Derzeit werden die Aurora MySQL-Versionen 2.07.9, 2.7.10, 2.11.*, 2.12.*, 3.03.*, 3.04.*, 3.05.* und 3.06.* unterstützt.

Sie können ein direktes Upgrade durchführen, einen Snapshot wiederherstellen oder ein verwaltetes Blue/Green-Upgrade mit Amazon RDS Blue/Green Deployments von jedem derzeit verfügbaren Aurora MySQL Version 2-Cluster in einen Aurora MySQL-Cluster der Version 3.04.2 initiieren.

Informationen zum Planen eines Upgrades auf Aurora MySQL Version 3 finden Sie unter Upgrade-Planung für Aurora MySQL Version 3 im Amazon-Aurora-Benutzerhandbuch. Allgemeine Informationen zu Aurora-MySQL-Upgrades finden Sie unter Upgrade von Amazon-Aurora-MySQL-DB-Clustern im Amazon-Aurora-Benutzerhandbuch.

Informationen zur Fehlerbehebung finden Sie unter Beheben von Upgrade-Problemen mit Aurora MySQL Version 3.

Wenn Sie Fragen oder Bedenken haben, steht Ihnen der AWS Support in den Community-Foren und über den AWS Support zur Verfügung. Weitere Informationen finden Sie unter Verwalten eines Amazon-Aurora-DB-Clusters im Amazon-Aurora-Benutzerhandbuch.

Verbesserungen

Sicherheitsprobleme wurden behoben und CVEs:

Die folgenden CVE-Fixes sind in dieser Version enthalten:

Verbesserungen der Verfügbarkeit:

  • Es wurde ein Problem behoben, bei dem eine Read Replica-DB-Instance nicht erfolgreich gestartet werden konnte, wenn in der Writer-DB-Instance eine hohe Arbeitslast herrscht.

  • Es wurde ein Problem behoben, bei dem eine Aurora MySQL Writer-DB-Instance aufgrund eines Defekts in der Komponente, die mit dem Aurora-Speicher kommuniziert, ein Failover durchführen kann. Der Fehler ist auf einen Ausfall der Kommunikation zwischen der DB-Instance und dem zugrunde liegenden Speicher nach einem Softwareupdate zurückzuführen.

  • Es wurde ein Problem behoben, das dazu führen kann, dass eine Datenbankinstanz neu gestartet wird, wenn die Anweisungen SHOW STATUS und PURGE BINARY LOGS gleichzeitig ausgeführt werden. PURGE BINARY LOGSist eine verwaltete Anweisung, die ausgeführt wird, um die vom Benutzer konfigurierte Aufbewahrungsfrist für Binlogs einzuhalten.

  • Es wurde ein Problem behoben, das beim Neustart einer Datenbankinstanz zu einem zusätzlichen Neustart führen kann.

  • Es wurde ein Problem mit Sperrkonflikten behoben, die durch einen Prüfprotokoll-Thread verursacht wurden und zu einer hohen CPU-Auslastung und Timeouts für Client-Anwendungen führen können.

  • Es wurde ein Problem behoben, bei dem es bei einer Aurora MySQL-Datenbank-Instance während des Instance-Starts zu mehreren Neustarts kommen kann, während große Rollback-Segmente initialisiert wurden.

  • Es wurde ein Problem behoben, das dazu führen kann, dass eine DB-Instance neu gestartet wird, während eine Abfrage ausgeführt wird, die auf eine Aggregatfunktion verweist.

Allgemeine Verbesserungen:

  • Es wurde ein Problem behoben, das dazu führen kann, dass eine parallel Abfrage aufgrund vorübergehender Netzwerkprobleme beim Lesen von Daten aus dem Aurora-DB-Cluster-Volume fehlschlägt

  • Es wurde ein Problem behoben, bei dem der Benutzer keine Abfrage unterbrechen oder Sitzungs-Timeouts für Abfragen festlegen konnte. performance_schema

  • Es wurde ein Problem behoben, bei dem die Replikation von Binärprotokollen (Binlog), die für die Verwendung benutzerdefinierter SSL-Zertifikate (mysql.rds_import_binlog_ssl_material) konfiguriert war, fehlschlagen konnte, wenn die Replikationsinstanz einem Host-Austausch unterzogen wurde.

  • Es wurde ein Problem im Zusammenhang mit der Verwaltung von Audit-Protokolldateien behoben, das dazu führen kann, dass auf Protokolldateien für den Download oder die Rotation nicht zugegriffen werden kann und das in einigen Fällen die CPU-Auslastung erhöht.

  • Die AUTO_INCREMENT Schlüsselwiederherstellung wurde optimiert, um die Abschlusszeit für die Wiederherstellung von Snapshots, die Durchführung der point-in-time Wiederherstellung und das Klonen von DB-Clustern mit einer großen Anzahl von Tabellen in der Datenbank zu verkürzen.

  • Es wurde ein Problem behoben, bei dem SQL-Anweisungen, die sich auf einige performance_schema Tabellen beziehen, einen Fehler zurückgeben können, weil diese Tabellen nach der Migration von Community MySQL auf die Aurora MySQL-Versionen 3.04.0 und 3.04.1 fehlen.

  • Es wurde ein Problem behoben, bei dem es bei kleinen Read Replica-Instances nach einem Upgrade von Aurora MySQL-Versionen unter 2.11.* zu einer erhöhten Replikationsverzögerung kommen kann.

  • Es wurde ein Problem behoben, das nach einer Snapshot-Wiederherstellung, einem Backtrack oder dem Klonen von Datenbanken zu Fehlern beim Duplizieren von Schlüsseln für AUTO_INCREMENT Spalten mit absteigenden Indizes führen kann.

  • Es wurde ein Problem behoben, das dazu führen kann, dass Änderungen des table_open_cache Datenbankparameters erst wirksam werden, wenn die DB-Instance neu gestartet wird.

  • Es wurde ein Problem behoben, bei dem die Reader-DB-Instance eine Tabelle nicht öffnen konnte (FEHLER 1146). Dieses Problem tritt auf, wenn bestimmte Arten von Online-DDL-Anweisungen (Data Definition Language) ausgeführt werden, während der INPLACE Algorithmus auf der Writer-DB-Instance verwendet wird.

  • Es wurde ein Problem behoben, um zu verhindern, dass die Instanz während Aurora Serverless v2 Skalierung, wenn der interne Überwachungsprozess fälschlicherweise doppelte Skalierungsanfragen sendet.

  • Es wurde ein Problem behoben, das zu einem Datenbankneustart führen kann, wenn verbundene Benutzer von Binärprotokollen (Binlog) einen doppelten Binlog-Replikationsserver verwenden. IDs

Upgrades und Migrationen:

  • Es wurde ein Problem behoben, das dazu führen kann, dass größere Versionsupgrades auf Aurora MySQL Version 3 fehlschlagen, weil verwaiste Einträge für bereits gelöschte Tablespaces in InnoDB-Systemtabellen in Aurora MySQL Version 2 vorhanden sind.

Integration von MySQL-Fehlerbehebungen (Community Edition)

Diese Version enthält alle Community-Bugfixes bis einschließlich 8.0.28, zusätzlich zu den folgenden. Weitere Informationen finden Sie unter MySQL-Fehlerbehebungen durch Aurora-MySQL-3.x-Datenbank-Engine-Updates.

  • Es wurde ein Problem behoben, bei dem der Wert der Cache-Zeile falsch berechnet werden konnte, was zu einem Fehler beim Neustart der Datenbank auf Graviton-basierten Instances führte. (Community-Bugfix #35479763)

  • Wiederholtes Ausführen einer gespeicherten Routine, bei der als Unterabfrage eine SELECT-Anweisung verwendet wurde, die mehrereAND, OR oder XOR -Bedingungen enthielt, führte zu übermäßigem Verbrauch und möglicherweise schließlich zur Erschöpfung des virtuellen Speichers. (Community-Bugfix #33852530)