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. # Optimierung von Aurora MySQL mit proaktiven Einblicken von Amazon DevOps Guru Die proaktiven Einblicke von DevOps Guru erkennen bekannte problematische Bedingungen auf Ihren Aurora-MySQL-DB-Clustern, bevor sie auftreten. DevOps Guru kann Folgendes tun: + Vermeiden vieler häufig auftretender Datenbankprobleme durch Abgleich der Datenbankkonfiguration mit den allgemein empfohlenen Einstellungen. + Warnen vor kritischen Problemen in der Flotte, die, wenn sie nicht überprüft werden, später zu größeren Problemen führen können. + Benachrichtigung bei neu erkannten Problemen. Jeder proaktive Einblick beinhaltet eine Analyse der Problemursache und Empfehlungen für Korrekturmaßnahmen. **Topics** + [Die Länge der InnoDB-Verlaufsliste wurde deutlich erhöht](proactive-insights.history-list.md) + [Die Datenbank erstellt temporäre Tabellen auf der Festplatte](proactive-insights.temp-tables.md) # Die Länge der InnoDB-Verlaufsliste wurde deutlich erhöht Ab sofort *date* wurde Ihre Verlaufsliste für Zeilenänderungen erheblich erweitert, bis hin *length* *db-instance* zu Dieser Anstieg wirkt sich auf die Leistung beim Herunterfahren von Abfragen und Datenbanken aus. **Topics** + [Unterstützte Engine-Versionen](#proactive-insights.history-list.context.supported) + [Kontext](#proactive-insights.history-list.context) + [Mögliche Ursachen für dieses Problem](#proactive-insights.history-list.causes) + [Aktionen](#proactive-insights.history-list.actions) + [Relevante Metriken](#proactive-insights.history-list.metrics) ## Unterstützte Engine-Versionen Diese Insight-Informationen werden für alle Versionen von unterstützt. ## Kontext Das InnoDB-Transaktionssystem behält die Multiversion Concurrency Control (MVCC) bei. Wenn eine Zeile geändert wird, wird die Version der geänderten Daten vor der Änderung als Undo-Datensatz in einem Undo-Protokoll gespeichert. Jeder Undo-Datensatz hat einen Verweis auf seinen vorherigen Redo-Datensatz, wodurch eine verknüpfte Liste entsteht. Die InnoDB-Verlaufsliste ist eine globale Liste der Undo-Protokolle für übernommene Transaktionen. MySQL verwendet die Verlaufsliste, um Datensätze und Protokollseiten zu löschen, wenn Transaktionen den Verlauf nicht mehr benötigen. Die Länge der Verlaufsliste ist die Gesamtzahl der Undo-Protokolle, die Änderungen in der Verlaufsliste enthalten. Jedes Protokoll umfasst eine oder mehrere Änderungen. Wenn die Länge der InnoDB-Verlaufsliste zu groß wird, was auf eine große Anzahl alter Zeilenversionen hinweist, werden Abfragen und Datenbankabschaltungen langsamer. ## Mögliche Ursachen für dieses Problem Zu den typischen Ursachen einer langen Verlaufsliste gehören die folgenden: + Transaktionen mit langer Laufzeit, entweder beim Lesen oder Schreiben + Eine hohe Schreiblast ## Aktionen Abhängig von den Ursachen Ihres Einblicks empfehlen wir verschiedene Aktionen. **Topics** + [Beginnen Sie keine Operation, die ein Herunterfahren der Datenbank beinhaltet, bis die InnoDB-Verlaufsliste kürzer wird](#proactive-insights.history-list.actions.no-shutdown) + [Identifizieren und beenden Sie lang andauernde Transaktionen](#proactive-insights.history-list.actions.long-txn) + [Verwenden Sie Performance Insights, um die Top-Hosts und Top-Benutzer zu identifizieren.](#proactive-insights.history-list.actions.top-PI) ### Beginnen Sie keine Operation, die ein Herunterfahren der Datenbank beinhaltet, bis die InnoDB-Verlaufsliste kürzer wird Da eine lange InnoDB-Verlaufsliste das Herunterfahren von Datenbanken verlangsamt, sollten Sie die Listengröße reduzieren, bevor Sie Operationen einleiten, die ein Herunterfahren der Datenbank beinhalten. Zu diesen Vorgängen gehören Datenbank-Upgrades der Hauptversionen. ### Identifizieren und beenden Sie lang andauernde Transaktionen Sie können Transaktionen mit langer Laufzeit finden, indem Sie `information_schema.innodb_trx` abfragen. **Anmerkung** Achten Sie auch darauf, auf Lesereplikaten nach Transaktionen mit langer Laufzeit zu suchen. **So identifizieren und beenden Sie lang andauernde Transaktionen** 1. Führen Sie das folgende Skript in Ihrem SQL-Client aus: ``` SELECT a.trx_id, a.trx_state, a.trx_started, TIMESTAMPDIFF(SECOND,a.trx_started, now()) as "Seconds Transaction Has Been Open", a.trx_rows_modified, b.USER, b.host, b.db, b.command, b.time, b.state FROM information_schema.innodb_trx a, information_schema.processlist b WHERE a.trx_mysql_thread_id=b.id AND TIMESTAMPDIFF(SECOND,a.trx_started, now()) > 10 ORDER BY trx_started ``` 1. Beenden Sie jede lang laufende Transaktion mit dem gespeicherten Verfahren [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill). ### Verwenden Sie Performance Insights, um die Top-Hosts und Top-Benutzer zu identifizieren. Optimieren Sie Transaktionen, so dass eine große Anzahl geänderter Zeilen sofort bestätigt wird. ## Relevante Metriken Die folgenden Metriken beziehen sich auf diesen Einblick: + `trx_rseg_history_len` – Diese Zählermetrik kann sowohl in Performance Insights als auch in der Tabelle `INFORMATION_SCHEMA.INNODB_METRICS` angezeigt werden. Weitere Informationen finden Sie in der [Metriktabelle „InnoDB INFORMATION\$1SCHEMA](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-metrics-table.html) in der MySQL-Dokumentation. + `RollbackSegmentHistoryListLength`— Diese CloudWatch Amazon-Metrik misst die Undo-Logs, in denen festgeschriebene Transaktionen mit als gelöscht markierten Datensätzen aufgezeichnet werden. Diese Datensätze sind für die Verarbeitung durch den InnoDB-Löschvorgang geplant. Die Metrik `trx_rseg_history_len` hat denselben Wert wie `RollbackSegmentHistoryListLength`. + `PurgeBoundary` – Die Transaktionsnummer, bis zu der eine InnoDB-Bereinigung zulässig ist. Wenn sich diese CloudWatch Metrik über einen längeren Zeitraum nicht weiterentwickelt, ist dies ein gutes Anzeichen dafür, dass das Löschen von InnoDB durch Transaktionen mit langer Laufzeit blockiert wird. Zur Untersuchung überprüfen Sie die aktiven Transaktionen auf Ihrem Aurora-MySQL-DB-Cluster. Dieser Parameter wird für Aurora-MySQL-Version 2.11 und höher sowie für Version 2.04.5 und höher unterstützt. + `PurgeFinishedPoint` – Die Transaktionsnummer, bis zu der eine InnoDB-Bereinigung ausgeführt wird. Mithilfe dieser CloudWatch Metrik können Sie untersuchen, wie schnell die InnoDB-Bereinigung voranschreitet. Dieser Parameter wird für Aurora-MySQL-Version 2.11 und höher sowie für Version 2.04.5 und höher unterstützt. + `TransactionAgeMaximum` – Das Alter der ältesten aktiven ausgeführten Transaktion. Diese CloudWatch Metrik ist nur für Aurora MySQL Version 3.08 und höher verfügbar. + `TruncateFinishedPoint` – Die Transaktions-ID, bis zu der die Kürzung rückgängig gemacht wird. Diese CloudWatch Metrik ist nur für Aurora MySQL Version 2.11 und höher und Version 3.08 und höher verfügbar. Weitere Informationen zu den CloudWatch Metriken finden Sie unter. [Metriken auf Instance-Ebene für Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances) # Die Datenbank erstellt temporäre Tabellen auf der Festplatte Ihre aktuelle Nutzung temporärer Tabellen auf der Festplatte hat erheblich zugenommen, bis zu*percentage*. Die Datenbank erstellt ungefähr *number* temporäre Tabellen pro Sekunde. Dies kann sich auf die Leistung auswirken und die Anzahl der Festplattenoperationen erhöhen*db-instance*. **Topics** + [Unterstützte Engine-Versionen](#proactive-insights.temp-tables.context.supported) + [Kontext](#proactive-insights.temp-tables.context) + [Mögliche Ursachen für dieses Problem](#proactive-insights.temp-tables.causes) + [Aktionen](#proactive-insights.temp-tables.actions) + [Relevante Metriken](#proactive-insights.temp-tables.metrics) ## Unterstützte Engine-Versionen Diese Insight-Informationen werden für alle Versionen von unterstützt. ## Kontext Manchmal ist es notwendig, dass der MySQL-Server während der Verarbeitung einer Abfrage eine interne temporäre Tabelle erstellt. Aurora MySQL kann eine interne temporäre Tabelle im Speicher speichern, wo sie von der Speicher-Engine TempTable oder MEMORY verarbeitet oder von InnoDB auf der Festplatte gespeichert werden kann. Weitere Informationen finden Sie unter [Interne Verwendung temporärer Tabellen in MySQL](https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html) im *MySQL-Referenzhandbuch*. ## Mögliche Ursachen für dieses Problem Eine Zunahme temporärer Tabellen auf der Festplatte weist auf die Verwendung komplexer Abfragen hin. Wenn der konfigurierte Speicher nicht ausreicht, um temporäre Tabellen im Speicher zu speichern, erstellt Aurora MySQL die Tabellen auf der Festplatte. Dies kann die Leistung beeinträchtigen und den Festplattenbetrieb erhöhen. ## Aktionen Abhängig von den Ursachen Ihres Einblicks empfehlen wir verschiedene Aktionen. + Für Aurora MySQL Version 3 empfehlen wir die Verwendung der TempTable Speicher-Engine. + Optimieren Sie Ihre Abfragen, um weniger Daten zurückzugeben, indem Sie nur die erforderlichen Spalten auswählen. Wenn Sie das Performance-Schema aktivieren und alle `statement`-Instrumente aktiviert und zeitgesteuert sind, können Sie `SYS.statements_with_temp_tables` abfragen, um die Liste der Abfragen abzurufen, die temporäre Tabellen verwenden. Weitere Informationen finden Sie unter [Voraussetzungen für die Verwendung des sys–Schemas](https://dev.mysql.com/doc/refman/8.0/en/sys-schema-prerequisites.html) in der MySQL-Dokumentation. + Erwägen Sie die Indizierung von Spalten, die an Sortier- und Gruppierungsoperationen beteiligt sind. + Schreiben Sie Ihre Abfragen neu, um `BLOB`- und `TEXT`-Spalten zu vermeiden. Diese Spalten verwenden immer die Festplatte. + Optimieren Sie die folgenden Datenbankparameter: `tmp_table_size` und `max_heap_table_size`. Der Standardwert für diese Parameter ist 16 MiB. Wenn Sie die MEMORY-Speicher-Engine für temporäre In-Memory-Tabellen verwenden, wird deren maximale Größe durch den `tmp_table_size`- oder `max_heap_table_size`-Wert definiert, je nachdem, welcher Wert kleiner ist. Wenn diese maximale Größe erreicht ist, konvertiert MySQL die interne temporäre In-Memory-Tabelle automatisch in eine interne temporäre InnoDB-Tabelle auf der Festplatte. Weitere Informationen finden Sie unter [Verwenden der TempTable Speicher-Engine auf Amazon RDS for MySQL und Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/). **Anmerkung** Beim expliziten Erstellen von MEMORY-Tabellen mit CREATE TABLE bestimmt nur die `max_heap_table_size`-Variable, wie groß eine Tabelle werden kann. Es erfolgt auch keine Konvertierung in ein Festplattenformat. ## Relevante Metriken Die folgenden Performance Insights-Metriken beziehen sich auf diesen Einblick: + Created\$1tmp\$1disk\$1tables + Created\$1tmp\$1tables Weitere Informationen finden Sie unter [Created\$1tmp\$1disk\$1tables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html#statvar_Created_tmp_disk_tables) in der MySQL-Dokumentation.