Aurora-MySQL-Datenbank-Engine-Updates 16.10.2015 (Versionen 1.2, 1.3) (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 16.10.2015 (Versionen 1.2, 1.3) (veraltet)

Versionen: 1.2, 1.3

Dieses Update enthält die folgenden Verbesserungen:

Behobene Probleme

  • Das out-of-memory Problem im neuen Lock-Manager mit lang andauernden Transaktionen wurde behoben

  • Gelöste Sicherheitsschwachstelle beim Replizieren mit Nicht-RDS for MySQL-Datenbanken

  • Aktualisiert, um sicherzustellen, dass Quorum-Schreibvorgänge korrekte Wiederholungsversuche bei Speicherfehlern ausführen

  • Aktualisiert, um Read Replica-Verzögerung präziser zu melden

  • Verbesserte Leistung durch Reduzierung von Konflikten, wenn viele nebenläufige Transaktionen versuchen, dieselbe Zeile zu ändern

  • Behobene Annullierung des Abfrage-Cache für Ansichten, die durch die Verknüpfung zweier Tabellen erstellt werden

  • Deaktivierter Abfrage-Cache für Transaktionen mit UNCOMMITTED_READ-Isolation

Verbesserungen

  • Bessere Leistung für Slow-Catalog-Abfragen in "warmen" Caches

  • Verbesserte Nebenläufigkeit in Wörterbuchstatistiken

  • Bessere Stabilität für den neuen Abfrage-Cache-Ressourcenmanager, erweiterte Verwaltung, Dateien gespeichert im Amazon Aurora Smart-Speicher und Batch-Schreibvorgänge von Protokolldatensätzen

Integration von MySQL-Fehlerbehebungen

  • Beenden einer Abfrage innerhalb innodb verursacht einen Ausfall mit einer Assertion. (Fehler #1608883)

  • Bei Fehlschlägen beim Erstellen eines neuen Threads für den Ereignis-Scheduler, die Ereignis-Ausführung oder neue Verbindung, wurde keine Mitteilung in das Fehlerprotokoll geschrieben. (Fehler #16865959)

  • Wenn eine Verbindung ihre standardmäßige Datenbank ändert und eine andere Verbindung simultan SHOW PROCESSLIST ausführt, könnte die zweite Verbindung auf ungültigen Arbeitsspeicher zugreifen, wenn sie versucht, den standardmäßigen Datenbankarbeitsspeicher der ersten Verbindung anzuzeigen. (Fehler #11765252)

  • PURGE BINARY LOGS entfernt standardmäßig keine Binärprotokolldateien, die verwendet werden oder aktiv sind, gab aber keinen Hinweis, wenn dies stattfand. (Fehler #13727933)

  • Bei einigen Statements könnte es zu Lecks im Arbeitsspeicher kommen, wenn der Optimierer unbenötigte Unterabfrage-Klassen entfernt hat. (Fehler #15875919)

  • Während des Herunterfahrens könnte der Server versuchen, einen nicht initialisierten Mutex zu sperren. (Fehler #16016493)

  • Ein vorbereitetes Statement, das GROUP CONCAT() und eine ORDER BY-Klausel verwendet hat, das mehrere Spalten benannt hat, könnte dazu führen, das der Server beendet wird. (Fehler #16075310)

  • Leistungsschema-Instrumentierung fehlte bei Replikat-Worker-Threads. (Fehler #16083949)

  • STOP SLAVE kann einen Deadlock verursachen, wenn sie gleichzeitig mit einer Anweisung wie SHOW STATUS ausgegeben wird, die die Werte für eine oder mehrere der Statusvariablen Slave_retried_transactions, Slave_heartbeat_period, Slave_received_heartbeats, Slave_last_heartbeat oder Slave_running abgerufen hat. (Fehler #16088188)

  • Eine vollständige Abfrage mithilfe des booleschen Modus konnte in einigen Fällen keine Ergebnisse liefern, wenn der Suchbegriff in Anführungszeichen stand. (Fehler #16206253)

  • Der Versuch des Optimierers, redundante Unterabfrage-Klauseln zu entfernen, erhöhte eine Assertion, wenn ein vorbereitetes Statement mit einer Unterabfrage in der On-Klausel einer Verbindung in einer Unterabfrage ausgeführt wurde. (Fehler #16318585)

  • GROUP_CONCAT instabil, Ausfall in ITEM_SUM::CLEAN_UP_AFTER_REMOVAL. (Fehler #16347450)

  • Der Versuch, die standardmäßige InnoDB-Volltextsuchen-Stoppwortliste (FTS) zu ersetzen, indem eine InnoDB-Tabelle mit derselben Struktur wie INFORMATION_SCHEMA.INNODB_FT_DEFAULT_STOPWORD erstellt wird, endete in einem Fehler. (Fehler #16373868)

  • Nachdem der Client-Thread auf einem Worker ein FLUSH TABLES WITH READ LOCK ausgeführt hat und darauf einige Updates auf dem Master folgten, stürzte der Worker ab, wenn ausgeführt wurd SHOW SLAVE STATUS. (Fehler #16387720)

  • Beim Parsen einer beschränkten Suchzeichenfolge wie "abc-def" in einer Volltextsuche verwendet InnoDB jetzt dieselben Trennzeichen wie MyISAM. (Fehler #16419661)

  • Ausfall in FTS_AST_TERM_SET_WILDCARD. (Fehler #16429306)

  • SEGFAULT in FTS_AST_VISIT() for FTS RQG Test. (Fehler #16435855)

  • Wenn bei Debug-Builds der Optimierer ein Item_ref entfernte, das auf eine Unterabfrage verwies, führte das zum Beenden des Servers. (Fehler #16509874)

  • Volltextsuche in InnoDB-Tabellen schlug fehl bei der Suche nach wörtlichen Sätzen in Kombination mit den Operatoren + oder -. (Fehler #16516193)

  • START SLAVEschlug fehl, als der Server mit den Optionen -- master-info-repository =TABLE relay-log-info-repository =TABLE gestartet wurde und Autocommit auf 0 gesetzt war, zusammen mit. --skip-slave-start (Fehler #16533802)

  • Sehr große InnoDB-Volltextsuchergebnisse (FTS) konnten in einigen Fällen eine übermäßige Menge an Arbeitsspeicher verbrauchen. (Fehler #16625973)

  • Bei Debug-Builds konnte in OPT_CHECK_ORDER_BY eine Assertion auftreten, wenn ein Binärprogramm direkt in der Suchzeichenfolge verwendet wurde, da Binärprogramme NULL-Bytes und andere bedeutungslose Zeichen enthalten können. (Fehler #16766016)

  • Bei einigen Statements könnte es zu Lecks im Arbeitsspeicher kommen, wenn der Optimierer unbenötigte Unterabfrage-Klassen entfernt hat. (Fehler #16807641)

  • Es war möglich, einen Deadlock zu verursachen, nachdem FLUSH TABLES WITH READ LOCK durch Verwendung von STOP SLAVE in einer neuen Verbindung an den Worker erteilt wurde und anschließend SHOW SLAVE STATUS über die ursprüngliche Verbindung erteilt wurde. (Fehler #16856735)

  • GROUP_CONCAT() mit einem ungültigen Trennzeichen konnte zum Beenden des Servers führen. (Fehler #16870783)

  • Der Server führte übermäßiges Sperren für die Mutexe LOCK_active_mi und active_mi->rli->data_lock jeder SHOW STATUS LIKE 'pattern'-Anweisung aus, selbst wenn das Muster nicht mit den Statusvariablen übereinstimmte, die diese Mutexe verwenden (Slave_heartbeat_period, Slave_last_heartbeat, Slave_received_heartbeats, Slave_retried_transactions, Slave_running). (Fehler #16904035)

  • Eine Volltextsuche, die den IN BOOLEAN MODE-Modifikator verwendet, konnte in einem Assertionfehler enden. (Fehler #16927092)

  • Volltextsuche in InnoDB-Tabellen schlug fehl bei Suchen, die den booleschen Operator + verwendet haben. (Fehler #17280122)

  • 4-Wege-Deadlock: Zombies, Binärprotokolle bereinigen, Prozesslisten anzeigen, Binärprotokolle anzeigen. (Fehler #17283409)

  • Wenn ein auf ein Commit-Lock wartender SQL-Thread beendet und neu gestartet wurde, führte das zum Überspringen einer Transaktion auf dem Worker. (Fehler #17450876)

  • Ein InnoDB-Volltextsuchen-Fehler konnte aufgrund eines "unbeendeten" Tokens auftreten. Die Zeichenfolge und die Zeichenfolgenlänge sollten für einen Zeichenfolgenvergleich weitergeleitet werden. (Fehler #17659310)

  • Eine große Anzahl an partitionierten InnoDB-Tabellen konnte, wenn diese in MySQL 5.6 oder 5.7 verwendet wurden, viel mehr Arbeitsspeicher verbrauchen als dieselben Tabellen in vorherigen Versionen von MySQL Server. (Fehler #17780517)

  • Bei Volltextabfragen konnte ein Fehler beim Überprüfen, ob num_token kleiner ist als max_proximity_item, in einer Assertion enden. (Fehler #18233051)

  • Bestimmte Abfragen für die INFORMATION SCHEMA TABLES- und COLUMNS-Tabellen konnten zu übermäßigem Arbeitsspeicherverbrauch führen, wenn es eine große Anzahl an leeren InnoDB-Tabellen gab. (Fehler #18592390)

  • Beim Übergeben einer Transaktion wird jetzt eine Kennzeichnung verwendet, um zu überprüfen, ob ein Thread erstellt wurde, anstatt den Thread selbst zu überprüfen, was mehr Ressourcen benötigte, besonderen wenn der Server mit master_info_repository=TABLE ausgeführt wird. (Fehler #18684222)

  • Wenn ein Client-Thread in einem Worker FLUSH TABLES WITH READ LOCK ausgeführt hat, während der Master eine DML ausführte, wurde das Ausführen von SHOW SLAVE STATUS auf demselben Client blockiert, was zu einem Deadlock führte. (Fehler #19843808)

  • Das Ordnen nach einem GROUP_CONCAT() -Ergebnis konnte zum Beenden des Servers führen. (Fehler #19880368)