Aurora-MySQL-Datenbank-Engine-Updates 20.09.2018 (Version 1.18.0) (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 20.09.2018 (Version 1.18.0) (veraltet)

Version: 1.18.0

Aurora MySQL 1.18.0 ist allgemein verfügbar. Alle neuen mit MySQL 5.6 kompatiblen parallelen Aurora MySQL-Abfrage-Cluster, einschließlich der aus Snapshots wiederhergestellten, werden in Aurora MySQL 1.18.0 erstellt. Für bestehende parallele Abfrage-Cluster können Sie ein Upgrade auf Aurora MySQL 1.18.0 ausführen (nicht verpflichtend). Sie können neue DB-Cluster in Aurora MySQL 1.14.4, Aurora MySQL 1.15.1, Aurora MySQL 1.16 oder Aurora MySQL 1.17.6 erstellen. Sie können dazu die AWS CLI oder die Amazon RDS-API verwenden und die Engine-Version angeben.

Mit Aurora MySQL-Version 1.18.0 verwenden wir ein Cluster-Patching-Modell, bei dem alle Knoten in einem Aurora-DB-Cluster gleichzeitig gepatcht werden.

Wichtig

Aurora MySQL 1.18.0 gilt nur für parallele Aurora-Abfrage-Cluster. Wenn Sie einen bereitgestelltes 5.6.10a-Cluster aktualisieren, ergibt dies Version 1.17.8. Wenn Sie einen parallelen 5.6.10a-Abfrage-Cluster aktualisieren, ergibt dies Version 1.18.0.

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.

Features

  • Parallel Query ist mit dieser Version für neue Cluster und wiederhergestellte Schnappschüsse verfügbar. Aurora MySQL Parallel Query ist eine Optimierung, die bei der Verarbeitung datenintensiver Abfragen einen Teil der I/O-Operationen und Berechnungen parallelisiert. Die parallelisierten Vorgänge beinhalten das Abrufen von Zeilen aus dem Speicher, das Extrahieren von Spaltenwerten und das Bestimmen der Zeilen, die den Bedingungen der WHERE-Klausel und der JOIN-Klauseln entsprechen. Diese datenintensive Arbeit wird (datenbankoptimiert, herabgestuft) an mehrere Knoten in der verteilten Speicherebene von Aurora delegiert. Ohne eine Parallelabfrage leitet jede Abfrage die gescannten Daten zu einem einzigen Knoten innerhalb des Aurora MySQL-Clusters (Hauptknoten) und die Verarbeitung jeglicher Abfragen erfolgt dort.

    • Ist Parallel Query aktiviert, entscheidet die Aurora MySQL-Engine automatisch, wann Abfragen profitieren können. An SQL müssen dafür keine Änderungen (z. B. Hinweise oder Tabellenattribute) vorgenommen werden.

    Weitere Informationen finden Sie im Abschnitt zum Arbeiten mit parallelen Abfragen für Amazon Aurora MySQL im Amazon-Aurora-Benutzerhandbuch.

  • OOM-Vermeidung: Diese Funktion überwacht den Systemspeicher und verfolgt den von verschiedenen Datenbankkomponenten genutzten Speicher. Sobald das System nicht über ausreichend Arbeitsspeicher verfügt, wird zum Vermeiden von Out of Memory (OOM) und eines Datenbankneustarts eine Reihe an Aktionen ausgeführt, um Arbeitsspeicher von verschiedenen verfolgten Komponenten freizugeben. Diese Best-Effort-Funktion ist für t2-Instances standardmäßig aktiviert und kann mithilfe des neuen Instance-Parameters auch für andere Instance-Klassen aktiviert werde aurora_oom_response. Der Instance-Parameter führt eine Zeichenfolge mit durch Kommata getrennten Aktionen aus, die eine Instance durchführen muss, wenn nur wenig Arbeitsspeicher zur Verfügung steht. Gültige Aktionen sind „print“, „tune“, „decline“, „kill_query“ und jegliche Kombinationen dieser. Jede leere Zeichenfolge bedeutet, dass keine Aktionen durchgeführt werden dürfen und die Funktion wird deaktiviert. Die Standardaktion für die Funktion lautet „print, tune“. Verwendungsbeispiele:

    • „print“ – druckt nur die Abfragen mit hohem Speicherbedarf.

    • „tune“ – stellt die Caches der internen Tabellen so ein, dass etwas Arbeitsspeicher für das System freigegeben wird.

    • „decline“ – lehnt neue Abfragen ab, sobald der Instance wenig Speicherplatz zur Verfügung steht.

    • „kill_query“ – beendet die Abfragen in absteigender Reihenfolge des Speicherverbrauchs, bis der Instance-Speicher oberhalb des unteren Schwellenwerts liegt. Data Definition Language (DDL)-Anweisungen werden nicht beendet.

    • „print, tune“ – führt die beschriebenen Aktionen sowohl für „print“ als auch für „tune“ aus.

    • „tune, decline, kill_query“ – führt die beschriebenen Aktionen für „tune“, „decline“ und „kill_query“ aus.

    Informationen zu den out-of-memory Bearbeitungsbedingungen und weitere Hinweise zur Fehlerbehebung finden Sie unter Probleme mit Amazon Aurora MySQL out of memory im Amazon Aurora Aurora-Benutzerhandbuch.