Wie löse ich das Problem einer hohen CPU-Auslastung und einer langsamen Abfrageleistung, nachdem ich meine Amazon RDS für MySQL- oder Aurora MySQL-kompatible DB-Instance aktualisiert habe?

Lösung

Voraussetzungen:

Um Fehldiagnosen zu vermeiden, strukturiere deinen Problembehandlungsablauf richtig und verwende AWS-Tools und -Services. Weitere Informationen findest du in den folgenden Artikeln:

• Wie behebe und löse ich das Problem einer hohen CPU-Auslastung auf meiner Amazon RDS für MySQL- oder Aurora MySQL-Compatible DB-Instance?
• Wie behebe ich das Problem einer langsamen Abfrage und verbessere ihre Leistung in Amazon RDS für MySQL?

Nach upgrade-spezifischen Problemen suchen

Wenn du eine Instance aktualisierst, z. B. von Aurora MySQL-kompatibel 5.7 auf Aurora MySQL-kompatibel 8.0, entfernt das Upgrade möglicherweise bestimmte Funktionen aus der Instance.

Wenn deine Instance veraltete Funktionen verwendet, können Probleme mit der Leistung deiner Instance auftreten. Um zu überprüfen, ob deine Instance-Version veraltete Funktionen verwendet, die sich auf deine Arbeitslast auswirken, lies dir die Versionshinweise für die Amazon Aurora MySQL-kompatible Ausgabe durch. Oder lies die Versionshinweise zu MySQL 8.0 auf der MySQL-Website durch.

Im folgenden Beispielszenario aktualisierst du einen Aurora MySQL-kompatiblen 5.7-Cluster auf Aurora MySQL-kompatibel 8.0. Nach dem Upgrade verdoppelt sich die CPU der Writer-Instance, obwohl die Abfragen, Ausführungspläne und Workload-Muster identisch sind.

Um dieses Problem zu beheben, kannst du die Metriken für deinen Amazon RDS für MySQL- oder Aurora MySQL-kompatiblen Cluster überprüfen. Vergleiche anhand des Problems die zugehörigen Metriken für den Cluster aus der Vorgängerversion mit der aktualisierten Version.

Beispiel für Aurora MySQL-kompatible 5.7-Metriken:

SHOW GLOBAL STATUS LIKE 'Qcache%';

Beispiel für Aurora MySQL-kompatible 8.0-Metriken:

`mysql> SHOW STATUS LIKE 'Qcache%';`  
`+-------------------------+--------+`  
`| Variable_name | Value |`  
`+-------------------------+--------+`  
`| Qcache_free_blocks | 36 |`  
`| Qcache_free_memory | 138488 |`  
`| Qcache_hits | 79570 |`  
`| Qcache_inserts | 27087 |`  
`| Qcache_lowmem_prunes | 3114 |`  
`| Qcache_not_cached | 22989 |`  
`| Qcache_queries_in_cache | 415 |`  
`| Qcache_total_blocks | 912 |`  
`+-------------------------+--------+`

In diesem Beispiel entfernte Aurora MySQL-kompatibel 8.0 eine Funktion, die Abfragen aus dem Cache bediente, um vollständige Ausführungen zu vermeiden. Ohne diese Funktion führt Aurora MySQL alle Abfragen vollständig aus und verdoppelt die Workload.

Wenn du Spitzen in der Instance-CPU feststellst, überprüfe die folgenden Metriken:

• Abfragen
• Com_select
• Innodb_rows_read

Führe die folgenden Aufgaben aus, um Probleme mit diesen Metriken zu beheben:

• Skaliere vertikal, um die unmittelbare CPU-Last zu bewältigen.
• Verwende vorbereitete Anweisungen. Weitere Informationen findest du unter Vorbereitete Anweisungen auf der MySQL-Website.
• Verwende Amazon ElastiCache, um deine Cluster-Einstellungen zwischenzuspeichern.

Weitere Schritte zur Fehlerbehebung

Du kannst die vorherige Version der Ausführungspläne mit den Ausführungsplänen der aktualisierten Version vergleichen, um Probleme besser beheben zu können. Verwende die Abfrage EXPLAIN FORMAT=JSON, um die Parametergruppeneinstellungen zu vergleichen. Kritische Konfigurationen wie innodb_buffer_pool_size müssen in beiden Versionen identisch sein. Weitere Informationen findest du unter InnoDB-Puffer-Pool-Größe konfigurieren und EXPLAIN-Anweisung auf der MySQL-Website.

Es hat sich bewährt, die Aurora-Cloning-Funktion zu verwenden, um Upgrades in einer Staging-Umgebung zu testen. Du kannst Tools wie Sysbench verwenden, um Workloads in der Staging-Umgebung zu simulieren. Verwende dann AWS-Tools wie AWS Database Insights und Enhanced Monitoring, um wichtige Metriken zu überwachen.