Aurora-MySQL-Datenbank-Engine-Updates 07.08.2017 (Version 1.14) (veraltet) - Amazon Aurora

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 07.08.2017 (Version 1.14) (veraltet)

Version: 1.14

Aurora MySQL 1.14 ist allgemein verfügbar. Alle neuen Datenbank-Cluster, einschließlich der aus Snapshots wiederhergestellten, werden in Aurora MySQL 1.14 erstellt. Aurora MySQL 1.14 ist zudem ein obligatorisches Upgrade für bestehende Aurora MySQL-DB-Cluster. Wir werden eine separate Ankündigung dazu versenden, zu welchem Zeitpunkt frühere Versionen von Aurora MySQL eingestellt werden.

Mit Aurora MySQL-Version 1.14 verwenden wir ein Cluster-Patching-Modell, bei dem alle Knoten in einem Aurora-DB-Cluster gleichzeitig gepatcht werden. Da Updates den Neustart einer Datenbank erfordern, kommt es zu einem 20- bis 30-minütigen Nutzungsausfall, nach dem Sie wieder mit der Verwendung Ihres DB-Clusters oder -Cluster fortfahren können. Wenn Ihre DB-Cluster derzeit Version 1.13 ausführen, lässt die Zero-Downtime-Patch-Funktion (ZDP) von Aurora möglicherweise zu, dass Client-Verbindungen mit Ihrer primären Aurora-Instance während des Upgrades aufrechterhalten bleiben. Dies ist abhängig von Ihrem Workload.

Wenn Sie Fragen oder Bedenken haben, steht Ihnen der AWS Support in den Community-Foren und über den AWS Support zur Verfügung.

Zero-Downtime-Patching (Patchen ohne Ausfallzeiten)

Beim Feature des Patchens ohne Ausfallzeiten (ZDP – Zero-Downtime Patching) wird versucht, Client-Verbindungen auf Best-Effort-Basis vor dem Patch-Vorgang zu bewahren. Weitere Informationen finden Sie unter Verwendung des Zero-Downtime-Patchings im Amazon-Aurora-Benutzerhandbuch.

Verbesserungen

  • Falscher Fehler „Datensatz nicht gefunden“ behoben, wenn ein Datensatz im sekundären Index, jedoch nicht im primären Index gefunden wird.

  • Stabilitätsproblem behoben, das aufgrund einer zu hoch eingestellten Abwehrzusicherung (hinzugefügt in 1.12) auftreten kann, wenn ein einzelner Schreibvorgang mehr als 32 Seiten umfasst. Dies kann beispielsweise bei großen BLOB-Werten auftreten.

  • Stabilitätsproblem aufgrund von Inkonsistenzen zwischen dem Tabellenraum-Cache und dem Wörterbuch-Cache behoben.

  • Problem behoben, bei dem ein Aurora-Replica nicht mehr reagiert, nachdem die maximale Anzahl an Verbindungsversuchen mit der primären Instance überschritten wurde. Ein Aurora-Replica startet nun neu, wenn die Inaktivität länger ist als der Heartbeat-Zeitraum, der für die Zustandsprüfung von der primären Instance verwendet wird.

  • Livelock-Problem behoben, das bei sehr hohen Gleichzeitigkeitsstufen auftreten kann, wenn eine Verbindung versucht, eine exklusive Metadaten-Sperre (Meta Data Lock, MDL) zu erzielen, während ein Befehl ausgegeben wird, beispielsweise ALTER TABLE.

  • Stabilitätsproblem in einer Aurora-Read Replica bei vorliegendem logischen/parallelen Read-Ahead behoben.

  • LOAD FROM S3 in zweierlei Hinsicht verbessert:

    1. Besserer Umgang mit Amazon S3-Timeout-Fehlern durch Verwendung des SDK-Wiederholversuchs zusätzlich zum vorhandenen Wiederholversuch.

    2. Performance-Optimierung beim Laden sehr großer Dateien oder einer großen Dateianzahl durch Cachen und Wiederverwenden des Client-Status.

  • Folgende Stabilitätsprobleme mit schneller DDL für ALTER TABLE-Vorgänge behoben:

    1. Wenn die Anweisung ALTER TABLE mehrere ADD COLUMN-Befehle umfasst und die Spaltennamen nicht in aufsteigender Reihenfolge sortiert sind.

    2. Wenn der Name der zu aktualisierenden Spalte und der entsprechende Name, abgerufen aus der internen Systemtabelle, sich durch ein null-terminiertes Zeichen (/0) unterscheiden.

    3. Bei bestimmten B-Baum-Split-Operationen.

    4. Wenn die Tabelle über einen Primärschlüssel mit variabler Länge verfügt.

  • Stabilitätsproblem mit Aurora-Replicas behoben, bei dem es zu lange dauert, das Index-Cache für die Volltextsuche (Full Text Search, FTS) mit dem der primären Instance konsistent zu machen. Dies kann auftreten, wenn ein großer Teil der neu erstellten FTS-Indexeinträge in der primären Instance noch nicht auf das Laufwerk übertragen wurde.

  • Stabilitätsproblem behoben, das während der Indexerstellung auftreten kann.

  • Neue Infrastruktur, die den Speicherverbrauch pro Verbindung und die zugehörige Telemetrie aufzeichnet, die zur Entwicklung der OOM-Vermeidung (Out-Of-Memory) verwendet wird.

  • Ein Problem wurde behoben, bei dem ANALYZE TABLE fälschlicherweise für Aurora-Replicas zugelassen wurde. Dies wurde nun blockiert.

  • Stabilitätsproblem behoben, das durch ein seltenes Deadlock-Problem in Folge einer Race Condition zwischen dem logischen Read-Ahead und der Bereinigung verursacht wurde.

Integration von MySQL-Fehlerbehebungen

  • Eine Volltextsuche in Verbindung mit abgeleiteten Tabellen (Unterabfragen in der FROM-Klausel) führte zu einem Austritt des Servers. Wenn nun eine Volltextsuche von einer abgeleiteten Tabelle abhängt, gibt der Server eine Fehlermeldung aus, dass bei einer materialisierten Tabelle keine Volltextsuche durchgeführt werden kann. (Fehler #68751, Fehler #16539903)