Aurora-MySQL-Datenbank-Engine-Updates 25.05.2021 (Version 2.10.0) (veraltet) - Amazon Aurora
VerbesserungenIntegration von MySQL-Fehlerbehebungen (Community Edition):Vergleich mit Aurora MySQL Version 1Kompatibilität mit MySQL 5.7

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 25.05.2021 (Version 2.10.0) (veraltet)

Version: 2.10.0

Aurora MySQL 2.10.0 ist allgemein verfügbar. Aurora - 2.x-Versionen sind mit MySQL 5.7 kompatibel. Aurora-MySQL 1.x-Versionen sind mit MySQL 5.6 kompatibel.

Derzeit werden die Aurora-MySQL-Versionen 1.19.5, 1.19.6, 1.22.*, 1.23.*, 2.04.*, 2.07.*, 2.08.*, 2.09.*, 2.10.*, 3.01.* und 3.02.* unterstützt.

Sie können einen vorhandenen Aurora-MySQL-2.*-Datenbank-Cluster zu Aurora MySQL 2.10.0 aktualisieren. Für Cluster, auf denen Aurora MySQL Version 1 ausgeführt wird, können Sie einen vorhandenen Cluster Aurora MySQL 1.23 oder höher direkt auf 2.10.0 aktualisieren. Sie können einen Snapshot aus einer derzeit unterstützten Aurora MySQL-Version zu Aurora MySQL 2.10.0 wiederherstellen.

Bei Fragen oder Bedenken 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.

Anmerkung

Informationen zum Upgrade Ihres Aurora-MySQL-Datenbank-Clusters finden Sie unter Upgrade der Nebenversion oder des Patch-Levels eines Aurora-MySQL-DB-Clusters im Amazon-Aurora-Benutzerhandbuch.

Verbesserungen

Behobene Sicherheitsprobleme und CVEs sind unten aufgeführt:

Korrekturen und andere Verbesserungen bei der Feinabstimmung der Handhabung in einer verwalteten Umgebung. Weitere CVE-Korrekturen unten:

Neue Funktionen:

  • Die db.t3.large Instance-Klasse wird jetzt unterstützt für Aurora MySQL.

  • Binäre Protokoll-Replikation:

    • Einführung des Binlog-I/O-Cache zur Verbesserung der Binlog-Leistung durch Reduzierung der Konflikte zwischen Writer-Threads und Dump-Threads. Weitere Informationen finden Sie unter Optimieren der binären Protokollreplikation im Amazon-Aurora-Benutzerhandbuch.

    • In Aurora MySQL-Version 2.08 haben wir eine verbesserte Binärprotokoll-Verarbeitung (binlog) eingeführt, um die Wiederherstellungszeit nach einem Absturz und die Latenzzeit für die Commit-Zeit bei sehr großen Transaktionen zu reduzieren. Diese Verbesserungen werden jetzt für Cluster unterstützt, bei denen GTID aktiviert ist.

  • Verbesserte Verfügbarkeit von Reader-Instances:

    • Zuvor wurden, als eine Writer-Instance neu gestartet wurde, auch alle Reader-Instances in einem Aurora MySQL-Cluster neu gestartet. Mit dem heutigen Start stellen In-Region-Reader-Instances während eines Neustarts der Writer-Instance weiterhin Leseanfragen bereit, was die Leseverfügbarkeit im Cluster verbessert. Weitere Informationen finden Sie unter Neustart eines Aurora-MySQL-Clusters (Version 2.10 und höher) im Amazon-Aurora-Benutzerhandbuch.

      Wichtig

      Nach dem Upgrade auf Aurora MySQL 2.10 führt ein Neustart der Writer-Instance nicht zu einem Neustart des gesamten Clusters. Wenn Sie den gesamten Cluster neu starten möchten, starten Sie jetzt alle Reader-Instances im Cluster neu, nachdem Sie die Writer-Instance neu gestartet haben.

  • Die Leistung der Read-Ahead-Seiten wurde verbessert, die durch die logische Read-Ahead-(LRA) -Technik angefordert wurden. Dies geschah durch Stapeln der mehrseitigen Lesevorgänge in einer einzigen Anfrage, die an den Aurora Speicher gesendet wurde. Infolgedessen werden die Abfragen, die die LRA-Optimierung verwenden, bis zu dreifach schneller ausgeführt.

  • Neustart und Patches ohne Ausfallzeiten:

    • Verbesserter Neustart ohne Ausfallzeiten (ZDR) und Patchen ohne Ausfallzeiten (ZDP), um ZDR und ZDP in einem breiteren Spektrum von Szenarien zu ermöglichen, einschließlich der zusätzlichen Unterstützung für Fälle, in denen die binäre Protokollierung aktiviert ist. Außerdem wurde die Sichtbarkeit von ZDR- und ZDP-Ereignissen verbessert. Einzelheiten finden Sie in der Dokumentation: Zero-Downtime Restart (ZDR) für Amazon Aurora MySQL und Verwenden von Zero-Downtime-Patching im Amazon-Aurora-Benutzerhandbuch.

Verbesserungen der Verfügbarkeit:

  • Verbesserungen für einen schnelleren Start, wenn die Datenbank über eine große Anzahl temporärer Indizes und Tabellen verfügt, die während einer zuvor unterbrochenen DDL-Aktivität erstellt wurden.

  • Es wurden mehrere Probleme im Zusammenhang mit wiederholten Neustarts während der Wiederherstellung nach einem Ausfall von unterbrochenen DDL-Vorgängen behoben, z. B. DROP TRIGGER, ALTER TABLE und speziell ALTER TABLE, das die Art der Partitionierung oder die Anzahl der Partitionen in einer Tabelle ändert.

  • Es wurde ein Problem behoben, das zu einem Serverneustart während der Protokollverarbeitung von Database Activity Streams (DAS) führen konnte.

  • Es wurde ein Problem beim Drucken einer Fehlermeldung beim Verarbeiten einer ALTER Abfrage für Systemtabellen behoben.

Allgemeine Verbesserungen:

  • Es wurde ein Problem behoben, durch das der Abfrage-Cache veraltete Ergebnisse für eine Reader-Instance zurückgeben konnte.

  • Es wurde ein Problem behoben, durch das einige Aurora Commit-Metriken nicht aktualisiert wurden, als die Systemvariable innodb_flush_log_at_trx_commit auf 0 oder 2 festgelegt wurde.

  • Es wurde ein Problem behoben, durch das ein im Abfrage-Cache gespeichertes Abfrageergebnis nicht durch Transaktionen mit mehreren Anweisungen aktualisiert wurde.

  • Es wurde ein Problem behoben, das dazu führen konnte, dass der zuletzt geänderte Zeitstempel der binären Protokolldateien nicht korrekt aktualisiert wurde. Dies könnte dazu führen, dass binäre Protokolldateien vorzeitig gelöscht werden, bevor die vom Kunden konfigurierte Aufbewahrungsfrist erreicht wird.

  • Falscher gemeldeter Binlog-Dateiname und Position von InnoDB nach der Wiederherstellung nach einem Ausfall behoben.

  • Es wurde ein Problem behoben, das dazu führen konnte, dass große Transaktionen zu falschen Binärprotokollereignissen führen konnten, wenn binlog_checksum-Parameter auf NONE eingestellt wurde.

  • Es wurde ein Problem behoben, durch das ein Binlog-Replikat mit einem Fehler gestoppt wird, wenn die replizierte Transaktion eine DDL-Anweisung und eine große Anzahl von Zeilenänderungen enthält.

  • Es wurde ein Problem behoben, das zu einem Neustart in einer Reader-Instance beim Löschen einer Tabelle führte.

  • Es wurde ein Problem behoben, das dazu führte, dass Open-Source-Konnektoren fehlschlugen, wenn versucht wurde, eine Binlog-Datei mit einer großen Transaktion zu verbrauchen.

  • Es wurde ein Problem behoben, das zu falschen Abfrageergebnissen für die große Geometriespalte führen konnte, nachdem ein räumlicher Index für die Tabelle mit den großen Geometriewerten erstellt wurde.

  • Die Datenbank erstellt jetzt den temporären Tablespace während des Neustarts neu, wodurch der zugehörige Speicherplatz freigegeben und zurückgewonnen werden kann.

  • Es wurde ein Problem behoben, das verhinderte, dass performance_schema Tabellen auf Aurora Reader-Instances abgeschnitten wurden.

  • Es wurde ein Problem behoben, das dazu führte, dass ein Binlog-Replikat mit einem HA_ERR_KEY_NOT_FOUND-Fehler stoppt.

  • Es wurde ein Problem behoben, durch das die Datenbank beim Ausführen der FLUSH TABLES WITH READ LOCK Anweisung neu gestartet wurde.

  • Es wurde ein Problem behoben, das die Verwendung von Sperrfunktionen auf Benutzerebene bei Aurora Reader-Instances verhinderte.

Integration von MySQL-Fehlerbehebungen (Community Edition):

  • Verschachtelte Transaktionen konnten manchmal den Replikat-Applier blockieren, wenn die Transaktionsisolationsstufe auf REPEATABLE READ eingestellt wurde. (Bug #25040331)

  • Wenn eine gespeicherte Prozedur eine Anweisung enthielt, die auf eine Ansicht verweist, die wiederum auf eine andere Ansicht verweist, konnte die Prozedur nicht mehr als einmal erfolgreich aufgerufen werden. (Fehler #87858, Fehler #26864199)

  • Bei Abfragen mit vielen OR Bedingungen ist der Optimierer jetzt speichereffizienter und überschreitet weniger wahrscheinlich die Speichergrenze, die durch die Systemvariable range_optimizer_max_mem_size auferlegt wird. Darüber hinaus wurde der Standardwert für diese Variable von 1.536.000 auf 8.388.608 angehoben. (Fehler #79450, Fehler #22283790)

  • Replikation: In der next_event()-Funktion, die vom SQL-Thread eines Replikats aufgerufen wird, um das nächste Ereignis aus dem Relay-Protokoll zu lesen, hat der SQL-Thread das erfasste relaylog.log_lock nicht freigegeben, als ein Fehler aufgetreten ist (z. B. aufgrund eines geschlossenen Relay-Protokolls), dazu führen, dass alle anderen Threads, die darauf warten, eine Sperre für das Relay-Protokoll zu erhalten, hängen bleiben. Mit dieser Fehlerbehebung wird die Sperre aufgehoben, bevor der SQL-Thread die Funktion unter der Situation verlässt. (Fehler #21697821)

  • Beheben einer Speicherbeschädigung für ALTER TABLE mit virtueller Spalte. (Fehler #24961167, Fehler #24960450)

  • Replikation: Multithreaded-Replikate konnten nicht mit kleinen Warteschlangengrößen unter Verwendung von slave_pending_jobs_size_max konfiguriert werden, wenn sie jemals Transaktionen verarbeiten mussten, die größer als diese Größe sind. Jedes Paket, das größer als slave_pending_jobs_size_max ist, wurde mit dem Fehler ER_MTS_EVENT_BIGGER_PENDING_JOBS_SIZE_MAX abgelehnt, auch wenn das Paket kleiner war als das von slave_max_allowed_packet festgelegte Limit. Mit dieser Fehlerbehebung wird slave_pending_jobs_size_max eher zu einem sanften Limit als zu einem harten Limit. Wenn die Größe eines Pakets slave_pending_jobs_size_max überschreitet, aber kleiner als slave_max_allowed_packet ist, wird die Transaktion solange gehalten, bis alle Replikat-Worker leere Warteschlangen haben und dann verarbeitet. Alle nachfolgenden Transaktionen werden solange gehalten, bis die große Transaktion abgeschlossen ist. Die Warteschlangengröße für Replikat-Worker kann daher begrenzt sein, während gelegentlich größere Transaktionen zugelassen werden. (Fehler #21280753, Fehler #77406)

  • Replikation: Bei Verwendung eines Multithread-Replikats zeigten Applier-Fehler Worker ID-Daten an, die mit Daten, die in den Replikationstabellen des Leistungsschemas externalisierten Daten nicht übereinstimmten. (Fehler #25231367)

  • Replikation: Auf einem GTID-basierten Replikationsreplikat, das mit -gtid-mode=ON, -log-bin=OFF und mit ausgeführt wird,slave-skip-errors wenn ein Fehler aufgetreten ist, der ignoriert werden sollte, Exec_Master_Log_Pos wurde die Synchronisierung mit nicht korrekt aktualisiert, wodurch Exec_Master_Log_Pos die Synchronisierung mit verliertRead_master_log_pos. Wenn ein GTID_NEXT nicht angegeben wurde, würde das Replikat seinen GTID-Status niemals aktualisieren, wenn es von einer Transaktion mit einer einzelnen Anweisung zurückgesetzt wird. Der Exec_Master_Log_Pos würde nicht aktualisiert werden, denn obwohl die Transaktion abgeschlossen war, zeigte ihr GTID-Status etwas anderes an. Die Fehlerbehebung hebt die Zurückhaltung der Aktualisierung des GTID-Status auf, wenn eine Transaktion nur zurückgesetzt wird, wenn in einer Transaktion GTID_NEXT angegeben wird. (Fehler #22268777)

  • Replikation: Eine teilweise fehlgeschlagene Anweisung verbrauchte eine automatisch generierte oder angegebene GTID nicht korrekt, wenn die binäre Protokollierung deaktiviert wurde. Die Fehlerbehebung stellt sicher, dass eine teilweise fehlgeschlagene DROP TABLE, ein teilweise fehlgeschlagener DROP USER oder ein teilweise fehlgeschlagener DROP VIEW die relevante GTID verbrauchen und sie in der @@GLOBAL.GTID_EXECUTED- und mysql.gtid_executed-Tabelle speichern, wenn die binäre Protokollierung deaktiviert wird. (Fehler #21686749)

  • Replikation: Replikate, auf denen MySQL 5.7 ausgeführt wird, konnten aufgrund eines Fehlers beim Abrufen von server_uuid, die nicht Teil von MySQL 5.5 ist, keine Verbindung zu einer MySQL 5.5-Quelle herstellen. Dies wurde durch Änderungen in der Methode zum Abrufen von verursach server_uuid. (Fehler #22748612)

  • Replikation: Der Mechanismus zum Überspringen von GTID-Transaktionen, der eine zuvor ausgeführte GTID-Transaktion stillschweigend überspringt, funktionierte für XA-Transaktionen nicht richtig. (Fehler #25041920)

  • ">XA ROLLBACK-Anweisungen, die fehlgeschlagen sind, weil eine falsche Transaktions-ID angegeben wurde, konnten im Binärprotokoll mit der richtigen Transaktions-ID aufgezeichnet werden und konnten daher durch Replikationsreplikate verwendet werden. Vor der binären Protokollierung wird nun die Fehlersituation geprüft und fehlgeschlagene XA ROLLBACK-Anweisungen nicht protokolliert. (Fehler #26618925)

  • Replikation: Wenn ein Replikat mit einer Anweisung CHANGE MASTER TO eingerichtet wurde, die den Namen der Quellprotokolldatei und die Position des Quellprotokolls nicht angegeben hat, fahren Sie herunter, bevor START SLAVE ausgegeben wurde, und starten Sie die Replikation dann nicht mit der Option –relay-log-recovery gesetzt. Dies geschah, weil der Empfänger-Thread vor dem Versuch der Wiederherstellung des Relay-Protokolls nicht gestartet wurde, sodass im Relay-Protokoll kein Protokollrotationsereignis verfügbar war, um den Namen der Quellprotokolldatei und die Quellprotokollposition bereitzustellen. In diesem Fall überspringt das Replikat nun die Wiederherstellung des Relay-Protokolls und protokolliert eine Warnung und beginnt dann mit der Replikation. (Fehler #28996606, Fehler #93397)

  • Replikation: Bei der zeilenbasierten Replikation wurde eine Meldung zurückgegeben, die Feldlängen falsch anzeigte, wenn von einer Tabelle mit einer utf8mb3-Spalte in eine Tabelle derselben Definition repliziert wurde, in der die Spalte mit einem utf8mb4-Zeichensatz definiert wurde. (Fehler #25135304, Fehler #83918)

  • Replikation: Als eine RESET SLAVE-Anweisung für ein Replikations-Replikat mit verwendeten GTIDs ausgegeben wurde, wurden die vorhandenen Relay-Protokolldateien bereinigt, aber die neue Relay-Protokolldatei für den Kanal wurde generiert, bevor der Satz der empfangenen GTIDs für den Kanal gelöscht wurde. Der frühere GTID-Satz wurde daher als PREVIOUS_GTIDS Ereignis in die neue Relay-Protokolldatei geschrieben, was zu einem schwerwiegenden Fehler bei der Replikation führte, der besagt, dass das Replikat mehr GTIDs als die Quelle hatte, obwohl der für beide Server festgelegte Wert „gtid_executed“ leer war. Wenn nun RESET SLAVE ausgegeben wird, wird der Satz der empfangenen GTIDs gelöscht, bevor die neue Relay-Protokolldatei generiert wird, damit diese Situation nicht auftritt. (Fehler #27411175)

  • Replikation: Bei Verwendung von GTIDs, die für die Replikation verwendet wurden, konnten Transaktionen einschließlich Anweisungen, die einen Analysefehler verursachten (ER_PARSE_ERROR), nicht manuell durch die empfohlene Methode zum Einspritzen einer leeren oder Ersatztransaktion mit derselben GTID übersprungen werden. Diese Aktion sollte dazu führen, dass das Replikat die GTID als bereits verwendet identifiziert und daher die unerwünschte Transaktion überspringt, die seine GTID geteilt hat. Im Falle eines Parsing-Fehlers wurde der Replikationsanwendungs-Thread jedoch aufgrund des Parsing-Fehlers gestoppt, da die Anweisung geparst wurde, bevor die GTID überprüft wurde, um zu sehen, ob sie übersprungen werden musste, obwohl die Transaktion trotzdem übersprungen werden sollte. Mit dieser Fehlerbehebung ignoriert der Replikations-Applier-Thread jetzt Parsingfehler, wenn die betreffende Transaktion übersprungen werden muss, da die GTID bereits verwendet wurde. Beachten Sie, dass diese Verhaltensänderung nicht bei Workloads gilt, die aus einer von erzeugten Binärprotokollausgabe bestehe mysqlbinlog. In dieser Situation bestünde die Gefahr, dass eine Transaktion mit einem Parsing-Fehler, der unmittelbar auf eine übersprungene Transaktion folgt, auch stillschweigend übersprungen wird, wenn sie einen Fehler auslösen sollte. (Fehler #27638268)

  • Replikation: Aktivieren Sie den SQL-Thread, um eine Teiltransaktion mit GTID zu überspringen. (Fehler #25800025)

  • Replikation: Wenn ein negativer oder fraktionierter Zeitüberschreitungs-Parameter an WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS() angegeben wurde, verhielt sich der Server auf unerwartete Weise. Mit dieser Fehlerbehebung.

    • Wird ein fraktionierter Zeitüberschreitungs-Wert unverändert gelesen, ohne Abrunden.

    • Wird ein negativer Zeitüberschreitungs-Wert mit einem Fehler zurückgewiesen, wenn sich der Server in einem strikten SQL-Modus befindet. Wenn sich der Server nicht in einem strikten SQL-Modus befindet, bewirkt der Wert, dass die Funktion NULL sofort ohne Wartezeit zurückgibt und dann eine Warnung ausgibt. (Fehler #24976304, Fehler #83537)

  • Replikation: Wenn die WAIT_FOR_EXECUTED_GTID_SET()-Funktion mit einem Zeitüberschreitungs-Wert verwendet wurde, der einen Bruchteil enthält (z. B. 1,5), führte ein Fehler in der Umwandlungslogik dazu, dass die Zeitüberschreitung auf die nächste ganze Sekunde abgerundet wurde und bei Werten unter 1 Sekunde auf null (zum Beispiel 0,1). Die Casting-Logik wurde nun korrigiert, sodass der Zeitüberschreitungs-Wert wie ursprünglich angegeben ohne Rundung angewendet wird. Danke an Dirkjan Bussink für den Beitrag. (Fehler #29324564, Fehler #94247)

  • Wenn GTIDs aktiviert sind, löste XA COMMIT bei einer nicht verbundenen XA-Transaktion innerhalb einer Transaktion mit mehreren Anweisungen eine Zusicherung aus. (Fehler #22173903)

  • Replikation: In Debug-Builds wurde eine Zusicherung ausgelöst, wenn eine XA ROLLBACK-Anweisung für eine unbekannte Transaktions-ID ausgegeben wurde, als der gtid_next -Wert manuell festgelegt wurde. Der Server versucht jetzt nicht, den GTID-Status zu aktualisieren, wenn eine ROLLBACK XA-Anweisung mit einem Fehler fehlschlägt. (Fehler #27928837, Fehler #90640)

  • Behebt das Problem mit der falschen Sortierreihenfolge, wenn mehrere CASE Funktionen in der ORDER BY Klausel verwendet werden (Fehler #22810883).

  • Einige Abfragen, bei denen die Sortierung verwendet wurde, konnten während der Optimierung auf eine nicht initialisierte Spalte zugreifen und verursachten ein Server-Exit. (Fehler #27389294)

Vergleich mit Aurora MySQL Version 1

Die folgenden Amazon-Aurora-MySQL-Funktionen werden in Aurora-MySQL-Version 1 (mit MySQL 5.6 kompatibel), jedoch derzeit nicht in Aurora-MySQL-Version 2 (MySQL 5.7 kompatibel) unterstützt.

Kompatibilität mit MySQL 5.7

Diese Aurora-MySQL-Version ist drahtkompatibel mit MySQL 5.7 und enthält Funktionen wie JSON-Unterstützung, räumliche Indizes und generierte Spalten. Aurora MySQL verwendet eine native Implementierung der räumlichen Indexierung unter Verwendung von Kurven der Z-Ordnung, um eine > 20 x bessere Schreibleistung und eine > 10 x bessere Leseleistung als MySQL 5.7 für räumliche Datensätze zu liefern.

Diese Aurora-MySQL-Version bietet aktuell keine Unterstützung für die folgenden MySQL-5.7-Funktionen:

  • Plug-In für die Gruppenreplikation

  • Größere Seitengröße

  • Laden des InnoDB-Pufferpools beim Starten

  • Plugin für den InnoDB-Volltext-Parser

  • Replikation aus mehreren Quellen

  • Größenanpassung des Online-Pufferpools

  • Plugin für die Passwortvalidierung

  • Plugins für die Umformulierung von Abfragen

  • Replikationsfilter

  • Die SQL-Anweisung CREATE TABLESPACE