Bewährte Methoden mit Amazon Aurora MySQL - Amazon Aurora
Feststellen, mit welcher DB-Instance Sie verbunden sindBewährte Verfahren für die Leistung und Skalierung von Aurora MySQLBewährte Verfahren für die Hochverfügbarkeit von Aurora MySQLEmpfehlungen für Aurora MySQL

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.

Bewährte Methoden mit Amazon Aurora MySQL

Dieses Thema beinhaltet Informationen zu bewährten Methoden und Optionen für die Verwendung oder Migration von Daten in einem Amazon-Aurora-MySQL-DB-Cluster. Die Informationen in diesem Thema fassen einige der Richtlinien und Verfahren zusammen, die Sie unter Verwalten eines Amazon Aurora-DB-Clusters.

Feststellen, mit welcher DB-Instance Sie verbunden sind

Um herauszufinden, zu welcher DB-Instance in einem Aurora-MySQL-DB-Cluster eine Verbindung besteht, prüfen Sie die globale Variable innodb_read_only wie im folgenden Beispiel gezeigt.

SHOW GLOBAL VARIABLES LIKE 'innodb_read_only';

Die Variable innodb_read_only wird auf ON gesetzt, wenn Sie mit einer Reader-DB-Instance verbunden sind. Diese Einstellung ist OFF, wenn Sie mit einer Writer-DB-Instance verbunden sind, z. B. als primäre Instance in einem bereitgestellten Cluster.

Dieser Ansatz kann hilfreich sein, wenn Sie zu Ihrem Anwendungscode eine Logik hinzufügen möchten, um den Workload auszugleichen, oder sicherzustellen, dass eine Schreiboperation die richtige Verbindung verwendet.

Bewährte Verfahren für die Leistung und Skalierung von Aurora MySQL

Sie können die folgenden bewährten Verfahren anwenden, um die Leistung und Skalierbarkeit Ihrer Aurora-MySQL-Cluster zu verbessern.

Verwendung von T-Instance-Klassen für Entwicklung und Tests

Amazon Aurora MySQL-Instances, die die DB-Instanzklassen db.t2, db.t3 oder db.t4g verwenden, eignen sich am besten für Anwendungen, die nicht über einen längeren Zeitraum eine hohe Arbeitslast unterstützen. Die T-Instanzen sind so konzipiert, dass sie eine mäßige Basisleistung bieten und je nach Workload eine deutlich höhere Leistung erreichen können. Sie eignen sich für Workloads, die die volle CPU-Leistung selten oder uneinheitlich verwenden, jedoch gelegentlich Spitzenlasten verarbeiten müssen. Wir empfehlen, die T-DB-Instance-Klassen nur für Entwicklungs- und Testserver oder andere Nicht-Produktionsserver zu verwenden. Weitere Einzelheiten zu den T-Instance-Klassen finden Sie unter Burstable Performance Instances.

Wenn Ihr Aurora-Cluster größer als 40 TB ist, sollten Sie die T-Instance-Klassen nicht verwenden. Wenn Ihre Datenbank ein großes Datenvolumen hat, kann der Speicher-Overhead für die Verwaltung von Schemaobjekten die Kapazität einer T-Instance übersteigen.

Aktivieren Sie das MySQL-Leistungsschema nicht auf Amazon Aurora MySQL T-Instances. Wenn das Leistungsschema aktiviert ist, geht der Instance möglicherweise der Speicher aus.

Tipp

Wenn Ihre Datenbank manchmal inaktiv ist, aber zu anderen Zeiten eine erhebliche Workload aufweist, können Sie Aurora Serverless v2 als Alternative zu T-Instances verwenden. Mit Aurora Serverless v2 definieren Sie einen Kapazitätsbereich und Aurora skaliert Ihre Datenbank je nach aktueller Workload automatisch nach oben oder unten. Details zur Verwendung finden Sie unter Verwenden von Aurora Serverless v2. Die Versionen der Datenbank-Engine, die Sie mit Aurora Serverless v2 verwenden können, finden Sie unter Anforderungen und Einschränkungen für Aurora Serverless v2.

Wenn Sie eine T-Instance als DB-Instance in einem Aurora-MySQL DB-Cluster verwenden, empfehlen wir Folgendes:

  • Verwenden Sie für alle Instances in Ihrem DB–Cluster dieselbe DB-Instance-Klasse. Wenn Sie zum Beispiel db.t2.medium für Ihre Writer-Instance verwenden, empfehlen wir Ihnen, db.t2.medium auch für Ihre Reader-Instances zu verwenden.

  • Nehmen Sie keine speicherbezogenen Konfigurationseinstellungen vor, wie z. B. innodb_buffer_pool_size. Aurora verwendet einen hochgradig abgestimmten Satz von Standardwerten für Speicherpuffer auf T-Instanzen. Diese speziellen Voreinstellungen sind erforderlich, damit Aurora auf Instanzen mit begrenztem Speicherplatz läuft. Wenn Sie speicherbezogene Einstellungen auf einer T-Instance ändern, ist es viel wahrscheinlicher, dass Sie auf out-of-memory Bedingungen stoßen, auch wenn Ihre Änderung darauf abzielt, die Puffergröße zu erhöhen.

  • Überwachen Sie Ihr CPU-Guthaben (CPUCreditBalance), um sicherzustellen, dass es auf einem akzeptablen Stand ist. CPU-Guthaben werden nämlich zu denselben Tarifen angesammelt, wie sie verbraucht werden.

    Wenn Sie Ihr CPU-Guthaben aufgebraucht haben, werden Sie sofort eine Leistungsminderung der verfügbaren CPU und erhöhte Latenzen der Lese- und Schreibvorgänge in der Instance feststellen. Diese Situation führt zu einem starken Rückgang der Gesamtperformance der Instance.

    Wenn Ihr CPU-Guthaben nicht ausreicht, empfehlen wir Ihnen, Ihre DB-Instanz so zu ändern, dass sie eine der unterstützten R DB-Instance-Klassen (Scale Compute) verwendet.

    Weitere Informationen über das Überwachen von Metriken finden Sie unter Anzeigen von Metriken in der Amazon-RDS-Konsole.

  • Überwachen Sie die Replikverzögerung (AuroraReplicaLag) zwischen der Writer-Instance und den Reader-Instances.

    Wenn einer Reader-Instance das CPU-Guthaben vor der Writer-Instance ausgeht, kann die daraus resultierende Verzögerung dazu führen, dass die Reader-Instance häufig neu gestartet werden muss. Dieses Ergebnis tritt häufig auf, wenn eine Anwendung eine hohe Anzahl von Lesevorgängen hat, die auf die Reader-Instance verteilt sind, während die Schreib-Instance eine minimale Anzahl von Schreibvorgängen hat.

    Wenn Sie einen anhaltenden Anstieg der Verzögerung bei der Replikation feststellen, stellen Sie sicher, dass Ihr CPU-Guthaben für die Reader-Instances in Ihrem DB-Cluster nicht erschöpft ist.

    Wenn Ihr CPU-Guthaben nicht ausreicht, empfehlen wir Ihnen, Ihre DB-Instance so zu modifizieren, dass sie eine der unterstützten R DB-Instance-Klassen (scale compute) verwendet.

  • Halten Sie die Anzahl an Inserts pro Transaktion unter 1 Million für DB-Cluster, bei denen die Binärprotokollierung aktiviert ist.

    Wenn der Parameter in der DB-Cluster-Parametergruppe für Ihren DB-Cluster auf einen anderen Wert als gesetzt istOFF, kann es in Ihrem DB-Cluster zu Problemen kommen, wenn der DB-Cluster Transaktionen empfängt, die mehr als 1 Million einzufügende Zeilen enthalten. binlog_format out-of-memory Sie können den freien Speicher (FreeableMemory) metrisch überwachen, um festzustellen, ob Ihrem DB-Cluster der verfügbare Speicher ausgeht. Sie überprüfen dann die Metrik der Schreibvorgänge (VolumeWriteIOPS), um zu sehen, ob eine Writer-Instance eine große Last von Schreibvorgängen empfängt. Wenn dies der Fall ist, empfehlen wir, Ihre Anwendung zu aktualisieren, um die Anzahl von Einfügungen in einer Transaktion auf weniger als 1 Million zu begrenzen. Alternativ können Sie Ihre Instance so modifizieren, dass sie eine der unterstützten R DB-Instance-Klassen verwendet (scale compute).

Optimierung von mit Aurora MySQL indizierten Join-Abfragen mit asynchronem Key Prefetch

Aurora MySQL kann die asynchrone Key Prefetch (AKP)-Funktion verwenden, um die Performance von Abfragen zu verbessern, die Tabellen über Indizes hinweg verknüpfen. Diese Funktion verbessert die Leistung, indem sie die Zeilen vorwegnimmt, die zum Ausführen von Abfragen benötigt werden, bei denen eine JOIN-Abfrage die Verwendung des Batched Key Access (BKA) Join-Algorithmus und der Multi-Range Read (MRR)-Optimierungsfunktionen erfordert. Weitere Informationen zu BKA und MRR finden Sie unter Block Nested-Loop und Batched Key Access Joins und Multi-Range Read Optimization in der MySQL-Dokumentation.

Um einen Vorteil aus der AKP-Funktion zu ziehen, muss eine Abfrage sowohl BKA als auch MRR verwenden. Typischerweise tritt eine solche Abfrage auf, wenn die JOIN-Klausel einer Abfrage einen Sekundärindex verwendet, aber auch einige Spalten aus dem Primärindex benötigt. Sie können beispielsweise AKP verwenden, wenn eine JOIN-Klausel einen Equijoin auf Indexwerten zwischen einer kleinen äußeren und einer großen inneren Tabelle darstellt und der Index auf der größeren Tabelle hoch selektiv ist. AKP arbeitet mit BKA und MRR zusammen, um während der Evaluierung der JOIN-Klausel einen sekundären Index-Lookup durchzuführen. AKP identifiziert die Zeilen, die während der Auswertung der JOIN-Klausel benötigt werden, um die Abfrage auszuführen. Anschließend werden die Seiten, die diese Zeilen enthalten, mit einem Hintergrund-Thread asynchron in den Speicher geladen, bevor die Abfrage ausgeführt wird.

AKP ist für Aurora MySQL Version 2.10 und höher sowie Version 3 verfügbar. Weitere Informationen zu den Aurora MySQL-Versionen erhalten Sie unter Datenbank-Engine-Updates für Amazon Aurora MySQL.

Asynchrones Key Prefetch aktivieren

Sie können die AKP-Funktion aktivieren, indem Sie aurora_use_key_prefetch, eine MySQL-Servervariable, auf on setzen. Standardmäßig ist dieser Wert auf on festgelegt. AKP kann jedoch erst aktiviert werden, wenn Sie auch den BKA-Join-Algorithmus aktivieren und die preisbasierte MRR-Funktionalität deaktivieren. Dazu müssen Sie die folgenden Werte für optimizer_switch setzen, eine Variable von MySQL-Server:

  • Setzen Sie batched_key_access auf on. Dieser Wert steuert die Verwendung des BKA-Join-Algorithmus. Standardmäßig ist dieser Wert auf off festgelegt.

  • Setzen Sie mrr_cost_based auf off. Dieser Wert steuert die Nutzung der kostenbasierten MRR-Funktionalität. Standardmäßig ist dieser Wert auf on festgelegt.

Derzeit können Sie diese Werte nur auf Sitzungsebene festlegen. Das folgende Beispiel veranschaulicht, wie diese Werte gesetzt werden können, um AKP für die aktuelle Sitzung durch Ausführen von SET-Anweisungen zu aktivieren.


mysql> set @@session.aurora_use_key_prefetch=on;
mysql> set @@session.optimizer_switch='batched_key_access=on,mrr_cost_based=off';

Ähnlich können Sie mit SET-Anweisungen AKP und den BKA Join-Algorithmus deaktivieren und kostenbasierte MRR-Funktionalität für die aktuelle Sitzung wieder aktivieren, wie im folgenden Beispiel gezeigt.


mysql> set @@session.aurora_use_key_prefetch=off;
mysql> set @@session.optimizer_switch='batched_key_access=off,mrr_cost_based=on';

Weitere Informationen über die Optimierungsschalter batched_key_access und mrr_cost_based finden Sie unter Switchable Optimizations in der MySQL-Dokumentation.

Optimieren von Abfragen für asynchrones Key Prefetch

Sie können bestätigen, ob eine Abfrage die AKP-Funktion nutzen können soll. Verwenden Sie dazu die EXPLAIN-Anweisung, um die Abfrage vor der Ausführung zu profilieren. Die EXPLAIN-Anweisung stellt Informationen über den Ausführungsplan bereit, der für eine angegebene Abfrage verwendet werden soll.

In der Ausgabe der EXPLAIN-Anweisung beschreibt die Spalte Extra zusätzliche Informationen, die im Ausführungsplan eingeschlossen sind. Wenn das AKP-Feature auf eine in der Abfrage verwendete Tabelle zutrifft, enthält diese Spalte einen der folgenden Werte:

  • Using Key Prefetching

  • Using join buffer (Batched Key Access with Key Prefetching)

Das folgende Beispiel zeigt die Verwendung von EXPLAIN, um den Ausführungsplan für eine Abfrage anzuzeigen, die von AKP profitieren kann.


mysql> explain select sql_no_cache
    ->     ps_partkey,
    ->     sum(ps_supplycost * ps_availqty) as value
    -> from
    ->     partsupp,
    ->     supplier,
    ->     nation
    -> where
    ->     ps_suppkey = s_suppkey
    ->     and s_nationkey = n_nationkey
    ->     and n_name = 'ETHIOPIA'
    -> group by
    ->     ps_partkey having
    ->         sum(ps_supplycost * ps_availqty) > (
    ->             select
    ->                 sum(ps_supplycost * ps_availqty) * 0.0000003333
    ->             from
    ->                 partsupp,
    ->                 supplier,
    ->                 nation
    ->             where
    ->                 ps_suppkey = s_suppkey
    ->                 and s_nationkey = n_nationkey
    ->                 and n_name = 'ETHIOPIA'
    ->         )
    -> order by
    ->     value desc;
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
| id | select_type | table    | type | possible_keys         | key           | key_len | ref                              | rows | filtered | Extra                                                       |
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
|  1 | PRIMARY     | nation   | ALL  | PRIMARY               | NULL          | NULL    | NULL                             |   25 |   100.00 | Using where; Using temporary; Using filesort                |
|  1 | PRIMARY     | supplier | ref  | PRIMARY,i_s_nationkey | i_s_nationkey | 5       | dbt3_scale_10.nation.n_nationkey | 2057 |   100.00 | Using index                                                 |
|  1 | PRIMARY     | partsupp | ref  | i_ps_suppkey          | i_ps_suppkey  | 4       | dbt3_scale_10.supplier.s_suppkey |   42 |   100.00 | Using join buffer (Batched Key Access with Key Prefetching) |
|  2 | SUBQUERY    | nation   | ALL  | PRIMARY               | NULL          | NULL    | NULL                             |   25 |   100.00 | Using where                                                 |
|  2 | SUBQUERY    | supplier | ref  | PRIMARY,i_s_nationkey | i_s_nationkey | 5       | dbt3_scale_10.nation.n_nationkey | 2057 |   100.00 | Using index                                                 |
|  2 | SUBQUERY    | partsupp | ref  | i_ps_suppkey          | i_ps_suppkey  | 4       | dbt3_scale_10.supplier.s_suppkey |   42 |   100.00 | Using join buffer (Batched Key Access with Key Prefetching) |
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
6 rows in set, 1 warning (0.00 sec)

Weitere Informationen über das EXPLAIN-Ausgabeformat finden Sie unter Extended EXPLAIN Output Format in der MySQL-Dokumentation.

Optimierung von großen Aurora-MySQL-Join-Abfragen mit Hash-Joins

Wenn Sie eine große Datenmenge mit Hilfe eines Equijoins verknüpfen müssen, kann ein Hash-Join die Abfrageleistung verbessern. Sie können Hash-Joins für Aurora MySQL aktivieren.

Eine Hash-Join-Spalte kann ein beliebiger komplexer Ausdruck sein. In einer Hash-Join-Spalte haben Sie folgende Möglichkeiten, Datentypen übergreifend zu vergleichen:

  • Sie können alles über die Kategorie der präzisen numerischen Datentypen hinweg vergleichen, wie z. B. int, bigint, numeric und bit.

  • Sie können alles über die Kategorie der ungefähren numerischen Datentypen hinweg vergleichen, wie z. B. float und double.

  • Sie können Elemente über String-Typen hinweg vergleichen, wenn die String-Typen den gleichen Zeichensatz und die gleiche Sortierreihenfolge haben.

  • Sie können Elemente mit Datums- und Zeitstempel-Datentypen vergleichen, wenn die Typen identisch sind.

Anmerkung

Sie können Datentypen verschiedener Kategorien nicht miteinander vergleichen.

Die folgenden Einschränkungen gelten für Hash-Joins für Aurora MySQL:

  • Links-Rechts-Außen-Joins werden für Aurora MySQL-Version 2 nicht unterstützt, für Version 3 hingegen schon.

  • Semijoins wie Subqueries werden nicht unterstützt, es sei denn, die Subqueries erfolgen zuerst.

  • Mehrfach-Tabellen-Updates oder -Löschungen werden nicht unterstützt.

    Anmerkung

    Einzel-Tabellen-Updates oder -Löschungen werden unterstützt.

  • BLOB- und Geodatentyp-Spalten können keine Join-Spalten in einem Hash-Join sein.

Aktivieren von Hash-Joins

So aktivieren Sie Hash-Joins:

  • Aurora-MySQL-Version 2 – Stellen Sie den DB-Parameter oder den DB-Cluster-Parameter aurora_disable_hash_join auf 0 ein. Durch Deaktivierung von aurora_disable_hash_join wird der Wert von optimizer_switch auf hash_join=on gesetzt.

  • Aurora-MySQL-Version 3 – Stellen Sie den MySQL-Serverparameter optimizer_switch auf block_nested_loop=on ein.

Hash-Joins sind standardmäßig in Aurora-MySQL-Version 3 aktiviert und in Aurora-MySQL-Version 2 deaktiviert. Das folgende Beispiel zeigt, wie man Hash-Joins für Aurora-MySQL-Version 3 aktivieren kann. Sie können zuerst die Anweisung select @@optimizer_switch ausgeben, um zu sehen, welche anderen Einstellungen in der SET-Parameterzeichenfolge vorhanden sind. Das Aktualisieren einer Einstellung im Parameter optimizer_switch löscht oder ändert die anderen Einstellungen nicht.

mysql> SET optimizer_switch='block_nested_loop=on';
Anmerkung

Für Aurora-MySQL-Version 3 ist Hash-Join-Support in allen Nebenversionen verfügbar und standardmäßig aktiviert.

Für Aurora MySQL-Version-3 ist Hash-Join-Support in allen Nebenversionen verfügbar und standardmäßig aktiviert. In Aurora-MySQL-Version 2 wird die Hash-Join-Funktion immer durch den aurora_disable_hash_join-Wert gesteuert.

Mit dieser Einstellung wählt der Optimierer einen Hash-Join auf der Grundlage von Kosten, Abfragemerkmalen und Ressourcenverfügbarkeit. Wenn die Kalkulation fehlerhaft ist, können Sie den Optimierer zwingen, einen bestimmten Hash-Join zu wählen. Sie erreichen dies, indem Sie hash_join_cost_based, eine MySQL-Servervariable, auf off setzen. Das folgende Beispiel zeigt, wie Sie den Optimierer zwingen können, einen Hash-Join zu wählen.


mysql> SET optimizer_switch='hash_join_cost_based=off';
Anmerkung

Diese Einstellung setzt die Entscheidungen des kostenbasierten Optimierers außer Kraft. Während die Einstellung für Tests und Entwicklung nützlich sein kann, empfehlen wir, sie nicht in der Produktion zu verwenden.

Optimieren von Abfragen für Hash-Joins

Um herauszufinden, ob eine Abfrage einen Hash-Join nutzen kann, verwenden Sie die EXPLAIN-Anweisung, um die Abfrage zuerst zu profilieren. Die EXPLAIN-Anweisung stellt Informationen über den Ausführungsplan bereit, der für eine angegebene Abfrage verwendet werden soll.

In der Ausgabe der EXPLAIN-Anweisung beschreibt die Spalte Extra zusätzliche Informationen, die im Ausführungsplan eingeschlossen sind. Wenn ein Hash-Join für die in der Abfrage verwendeten Tabellen gilt, enthält diese Spalte Werte, die den folgenden ähnlich sind:

  • Using where; Using join buffer (Hash Join Outer table table1_name)

  • Using where; Using join buffer (Hash Join Inner table table2_name)

Das folgende Beispiel zeigt die Verwendung von EXPLAIN, um den Ausführungsplan für eine Hash-Join-Abfrage anzuzeigen.


mysql> explain SELECT sql_no_cache * FROM hj_small, hj_big, hj_big2
    ->     WHERE hj_small.col1 = hj_big.col1 and hj_big.col1=hj_big2.col1 ORDER BY 1;
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
| id | select_type | table    | type | possible_keys | key  | key_len | ref  | rows | Extra                                                          |
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
|  1 | SIMPLE      | hj_small | ALL  | NULL          | NULL | NULL    | NULL |    6 | Using temporary; Using filesort                                |
|  1 | SIMPLE      | hj_big   | ALL  | NULL          | NULL | NULL    | NULL |   10 | Using where; Using join buffer (Hash Join Outer table hj_big)  |
|  1 | SIMPLE      | hj_big2  | ALL  | NULL          | NULL | NULL    | NULL |   15 | Using where; Using join buffer (Hash Join Inner table hj_big2) |
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
3 rows in set (0.04 sec)

In der Ausgabe ist der Hash Join Inner table die Tabelle, die zum Aufbau der Hash-Tabelle verwendet wird, und der Hash Join Outer table ist die Tabelle, die zum Prüfen der Hash-Tabelle verwendet wird.

Weitere Informationen über das erweiterte EXPLAIN-Ausgabeformat finden Sie unter Extended EXPLAIN Output Format in der MySQL-Produktdokumentation.

In Aurora MySQL 2.08 und höher können Sie mithilfe von SQL-Hinweisen beeinflussen, ob eine Abfrage einen Hash-Join verwendet oder nicht und welche Tabellen für die Build- und Testseite des Joins verwendet werden sollen. Details hierzu finden Sie unter Aurora-MySQL-Hinweise.

Verwenden von Amazon Aurora für das Skalieren von Lesevorgängen in Ihrer MySQL-Datenbank

Sie können Amazon Aurora mit Ihrer MySQL-DB-Instance verwenden, um die Möglichkeiten der Skalierung von Lesevorgängen von Amazon Aurora zu nutzen und den Lese-Workload für Ihre MySQL-DB-Instance zu erweitern. Erstellen Sie einen Aurora-MySQL-DB-Cluster und machen Sie ihn zum Read Replica Ihrer MySQL-DB-Instance, um Aurora für die Skalierung von Lesevorgängen Ihrer MySQL-DB-Instance zu verwenden. Verbinden Sie sich dann mit dem Aurora-MySQL-Cluster, um die Leseabfragen zu verarbeiten. Die Quelldatenbank kann eine RDS for MySQL-DB-Instance oder eine MySQL-Datenbank sein, die außerhalb von Amazon RDS ausgeführt wird. Weitere Informationen finden Sie unter Verwenden von Amazon Aurora für das Skalieren von Lesevorgängen in Ihrer MySQL-Datenbank.

Optimierung von Zeitstempeloperationen

Wenn der Wert der Systemvariablen time_zone auf SYSTEM gesetzt ist, führt jeder MySQL-Funktionsaufruf, der eine Zeitzonenberechnung erfordert, einen Systembibliotheksaufruf aus. Wenn Sie SQL-Anweisungen ausführen, die solche TIMESTAMP-Werte mit hoher Nebenläufigkeit zurückgeben oder ändern, kann es zu einer höheren Latenz und CPU-Auslastung sowie zu Sperrkonflikten kommen. Weitere Informationen finden Sie unter time_zone in der MySQL-Dokumentation.

Wir empfehlen, den Wert des DB-Cluster-Parameters time_zone in UTC zu ändern, um dieses Verhalten zu vermeiden. Weitere Informationen finden Sie unter Ändern von Parametern in einer DB-Cluster-Parametergruppe.

Der Parameter time_zone ist zwar dynamisch (er erfordert keinen Neustart des Datenbankservers), der neue Wert wird jedoch nur für neue Verbindungen verwendet. Um sicherzustellen, dass alle Verbindungen so aktualisiert werden, dass sie den neuen time_zone-Wert verwenden, empfehlen wir, Ihre Anwendungsverbindungen nach der Aktualisierung des DB-Cluster-Parameters wiederzuverwenden.

Bewährte Verfahren für die Hochverfügbarkeit von Aurora MySQL

Sie können die folgenden bewährten Verfahren anwenden, um die Verfügbarkeit Ihrer Aurora MySQL-Cluster zu verbessern.

Verwenden von Amazon Aurora zur Notfallwiederherstellung Ihrer MySQL-Datenbanken

Sie können Amazon Aurora mit Ihrer MySQL-DB-Instance verwenden, um ein außerhalb liegendes Backup für eine Notfallwiederherstellung zu erstellen. Erstellen Sie einen Amazon-Aurora-DB-Cluster und legen Sie ihn als Read Replica Ihrer MySQL-DB-Instance fest, um Aurora für die Notfallwiederherstellung Ihrer MySQL-DB-Instance zu verwenden. Dies gilt für eine RDS for MySQL-DB-Instance oder eine MySQL-Datenbank, die außerhalb von Amazon RDS ausgeführt wird.

Wichtig

Wenn Sie eine Replikation zwischen Ihrer MySQL-DB-Instance und einem Amazon-Aurora-MySQL-DB-Cluster einrichten, sollten Sie die Replikation prüfen, um sicherzustellen, dass sie sich in einem guten Zustand befindet, und sie bei Bedarf reparieren.

Anweisungen zum Erstellen eines Amazon-Aurora-MySQL-DB-Clusters und Festlegen als Read Replica Ihrer MySQL-DB-Instance finden Sie im Abschnitt Verwenden von Amazon Aurora für das Skalieren von Lesevorgängen in Ihrer MySQL-Datenbank.

Weitere Hinweise zu Notfallwiederherstellungsmodellen finden Sie unter So wählen Sie die beste Notfallwiederherstellungsoption für Ihren Amazon-Aurora-MySQL-Cluster aus.

Migrieren von MySQL zu Amazon Aurora MySQL mit reduzierter Ausfallzeit

Beim Importieren von Daten aus einer MySQL-Datenbank, die eine Live-Anwendung unterstützt, in einen Amazon-Aurora-MySQL-DB-Cluster möchten Sie möglicherweise die Zeit reduzieren, in der der Service während der Migration unterbrochen wird. Hierfür können Sie das Verfahren verwenden, das im Abschnitt zum Importieren von Daten in eine MySQL- oder MariaDB-DB-Instance mit reduzierter Ausfallzeit im Amazon Relational Database Service-Benutzerhandbuch dokumentiert ist. Diese Prozedur kann insbesondere dann hilfreich sein, wenn Sie mit einer sehr großen Datenbank arbeiten. Mit dieser Prozedur können Sie die Kosten des Imports reduzieren, indem Sie die Menge der Daten, die über das Netzwerk an AWS weitergeleitet werden, minimieren.

In der Prozedur sind Schritte zur Übertragung einer Kopie Ihrer Datenbank in eine Amazon EC2-Instance und zum Import der Daten in eine neue RDS for MySQL-DB-Instance aufgeführt. Da Amazon Aurora mit MySQL kompatibel ist, können Sie stattdessen einen Amazon-Aurora-DB-Cluster für die Amazon RDS-MySQL-DB-Ziel-Instance verwenden.

Vermeiden von Leistungseinbußen, automatischem Neustart und Failover für DB-Instances von Aurora MySQL

Wenn Sie hohe Workloads ausführen, die über die zugewiesenen Ressourcen Ihrer DB-Instance hinausgehen, können Sie die Ressourcen, auf denen Sie Ihre Anwendung und die Aurora-Datenbank ausführen, aufbrauchen. Um Metriken zu Ihrer Datenbank-Instance wie CPU-Auslastung, Speicherauslastung und Anzahl der verwendeten Datenbankverbindungen zu erhalten, können Sie auf die von Amazon CloudWatch, Performance Insights und Enhanced Monitoring bereitgestellten Metriken zurückgreifen. Informationen zur Überwachung Ihrer DB-Instance finden Sie unter Überwachung von Metriken in einem Amazon-Aurora-Cluster.

Wenn Ihre Workload die von Ihnen verwendeten Ressourcen aufbraucht, wird Ihre DB-Instance möglicherweise langsamer, neu gestartet oder es wird sogar ein Failover auf eine andere DB-Instance durchgeführt. Dies können Sie vermeiden, indem Sie Ihre Ressourcenauslastung überwachen, die Workload, die auf Ihrer DB-Instance ausgeführt wird, untersuchen und gegebenenfalls Optimierungen vornehmen. Wenn Optimierungen keine Verbesserungen der Instance-Metriken und keine Verringerung der Ressourcenauslastung ergeben, sollten Sie erwägen, Ihre DB-Instance hochzuskalieren, bevor diese an ihre Grenzen stößt. Weitere Hinweise zu verfügbaren DB-Instance-Klassen und ihren Spezifikationen finden Sie unter Aurora DB-Instance-Klassen.

Empfehlungen für Aurora MySQL

Die folgenden Funktionen sind in Aurora MySQL für die MySQL-Kompatibilität verfügbar. Sie haben jedoch Probleme mit der Leistung, Skalierbarkeit, Stabilität oder Kompatibilität in der Aurora-Umgebung. Wir empfehlen daher, dass Sie bei der Verwendung dieser Funktionen bestimmte Richtlinien einhalten. Wir empfehlen zum Beispiel, bestimmte Funktionen nicht für Aurora-Produktionseinsätze zu verwenden.

Verwenden von Multithread-Replikation in Aurora MySQL Version 3

Standardmäßig verwendet Aurora die Single-Thread-Replikation, wenn ein Aurora-MySQL-DB-Cluster als Read Replica für die Binärprotokollreplikation verwendet wird.

Obwohl Aurora MySQL die Multithread-Replikation nicht verbietet, wird diese Funktion nur in Aurora-MySQL-Version 3 unterstützt.

Aurora-MySQL Version 2 hat mehrere Probleme in Bezug auf die Multi-Thread-Replikation aus MySQL geerbt. Für diese Version empfehlen wir, die Multithread-Replikation in der Produktion nicht zu verwenden.

Wenn Sie Multi-Thread-Replikation verwenden, empfehlen wir Ihnen, diesen Vorgang vorher gründlich zu testen.

Weitere Informationen zur Verwendung der Replikation in Amazon Aurora finden Sie unter Replikation mit Amazon Aurora. Informationen zur Multithread-Replikation in Aurora-MySQL-Version 3 finden Sie unter Multithread-Binärprotokollreplikation (Aurora MySQL Version 3).

AWS Lambda Funktionen mit nativen MySQL-Funktionen aufrufen

Wir empfehlen, die nativen MySQL-Funktionen lambda_sync und lambda_async zu verwenden, um Lambda-Funktionen aufzurufen.

Wenn Sie die veraltete Prozedur mysql.lambda_async verwenden, empfehlen wir, dass Sie die Aufrufe an die Prozedur mysql.lambda_async in einer gespeicherten Prozedur übergeben. Sie können diese gespeicherte Prozedur aus verschiedenen Quellen aufrufen, wie z. B. Trigger oder Client-Code. Dieser Ansatz kann helfen, Probleme hinsichtlich Impedanz-Unstimmigkeiten zu vermeiden und macht es Ihren Datenbank-Programmieren einfacher Lambda-Funktionen aufzurufen.

Weitere Informationen über das Aufrufen von Lambda-Funktionen in Amazon Aurora finden Sie unter Aufrufen einer Lambda-Funktion aus einem Amazon Aurora MySQL-DB-Cluster.

Vermeiden von XA-Transaktionen mit Amazon Aurora MySQL

Wir empfehlen Ihnen, keine eXtended Architecture (XA)-Transaktionen mit Aurora MySQL zu verwenden, da diese lange Wiederherstellungszeiten verursachen können, wenn sich die XA im Status PREPARED befunden hat. Wenn Sie XA-Transaktionen mit Aurora MySQL verwenden müssen, befolgen Sie diese bewährten Verfahren:

  • Lassen Sie eine XA-Transaktion nicht im Status PREPARED offen.

  • Halten Sie XA-Transaktionen so klein wie möglich.

Weitere Informationen zur Verwendung von XA-Transaktionen mit MySQL finden Sie unter XA Transactions in der MySQL-Dokumentation.

Aktivieren von Fremdschlüsseln während DML-Anweisungen

Wir empfehlen Ihnen dringend, keine DDL-Anweisungen (Data Definition Language) auszuführen, wenn die Variable foreign_key_checks auf 0 (aus) gesetzt ist.

Wenn Sie Zeilen einfügen oder aktualisieren müssen, die eine vorübergehende Verletzung von Fremdschlüsseln bedingen, gehen Sie wie folgt vor:

  1. Setzen Sie foreign_key_checks auf 0.

  2. Nehmen Sie Ihre DML-Änderungen (Data Manipulation Language) vor.

  3. Stellen Sie sicher, dass Ihre durchgeführten Änderungen keine Fremdschlüsselbedingungen verletzen.

  4. Setzen Sie foreign_key_checks auf 1 (ein).

Darüber hinaus halten Sie die folgenden anderen bewährten Methoden für Fremdschlüsselbedingungen ein:

  • Stellen Sie sicher, dass Ihre Client-Anwendungen die Variable foreign_key_checks nicht auf 0 als Teil der Variablen init_connect setzen.

  • Wenn eine Wiederherstellung aus einer logischen Sicherung, wie beispielsweise mysqldump, fehlschlägt oder unvollständig ist, stellen Sie sicher, dass foreign_key_checks auf 1 gesetzt ist, bevor Sie innerhalb derselben Sitzung andere Operationen starten. Eine logische Sicherung setzt foreign_key_checks beim Start auf 0.

Konfigurieren, wie oft der Protokollpuffer geleert wird

In der MySQL Community Edition muss der InnoDB-Protokollpuffer in einen dauerhaften Speicher geleert werden, um Transaktionen dauerhaft zu machen. Verwenden Sie den Parameter innodb_flush_log_at_trx_commit, um zu konfigurieren, wie oft der Protokollpuffer geleert und auf die Festplatte übertragen wird.

Wenn Sie den Parameter innodb_flush_log_at_trx_commit auf den Standardwert 1 festlegen, wird der Protokollpuffer bei jedem Transaktions-Commit geleert. Diese Einstellung hilft, die Datenbank ACID-konform zu halten. Wir empfehlen, die Standardeinstellung 1 beizubehalten.

Das Ändern innodb_flush_log_at_trx_commit zu einem anderen Wert als dem Standardwert kann dazu beitragen, die Latenz in der Datenmanipulationssprache (Data Manipulation Language, DML) zu reduzieren, beeinträchtigt jedoch die Haltbarkeit der Protokolldatensätze. Durch diese mangelnde Haltbarkeit ist die Datenbank nicht ACID-konform. Ihre Datenbanken sollten ACID-konform sein, um das Risiko von Datenverlusten bei einem Serverneustart zu vermeiden. Weitere Informationen zu diesem Parameter finden Sie unter innodb_flush_log_at_trx_commit in der MySQL-Dokumentation.

In Aurora MySQL wird die Redo-Protokollverarbeitung auf die Speicherschicht verlagert, sodass auf der DB-Instance kein Leeren in Protokolldateien erfolgt. Wenn ein Schreibvorgang ausgeführt wird, werden Redo-Protokolle von der Writer-DB-Instance direkt an das Aurora-Cluster-Volume gesendet. Die einzigen Schreibvorgänge, die das Netzwerk passieren, sind Redo-Protokolldatensätze. Auf der Datenbankebene werden grundsätzlich keine Seiten geschrieben.

Standardmäßig wartet jeder Thread, der eine Transaktion festschreibt, auf die Bestätigung durch das Aurora-Cluster-Volume. Diese Bestätigung gibt an, dass dieser Datensatz und alle vorherigen Redo-Protokolldatensätze geschrieben wurden und das Quorum erreicht haben. Dadurch, dass die Protokolldatensätze beibehalten und das Quorum erreicht wird, ist die Transaktion dauerhaft gemacht worden, sei es durch Autocommit oder explizites Commit. Weitere Informationen zur Aurora-Speicherarchitektur finden Sie unter Amazon Aurora storage demystified (Amazon-Aurora-Speicher entmystifiziert).

Aurora MySQL leert keine Protokolle in Datendateien, wie dies bei der MySQL Community Edition der Fall ist. Sie können den Parameter innodb_flush_log_at_trx_commit jedoch verwenden, um Haltbarkeitsbeschränkungen beim Schreiben von Redo-Protokolldatensätzen auf das Aurora-Clustervolume zu lockern.

Für Aurora MySQL Version 2:

  • innodb_flush_log_at_trx_commit= 0 oder 2 — Die Datenbank wartet nicht auf die Bestätigung, dass die Redo-Log-Datensätze auf das Aurora-Cluster-Volume geschrieben wurden.

  • innodb_flush_log_at_trx_commit= 1 — Die Datenbank wartet auf die Bestätigung, dass die Redo-Log-Datensätze auf das Aurora-Cluster-Volume geschrieben wurden.

Für Aurora MySQL Version 3:

  • innodb_flush_log_at_trx_commit= 0 — Die Datenbank wartet nicht auf die Bestätigung, dass die Redo-Log-Datensätze auf das Aurora-Cluster-Volume geschrieben wurden.

  • innodb_flush_log_at_trx_commit= 1 oder 2 — Die Datenbank wartet auf die Bestätigung, dass die Redo-Log-Datensätze auf das Aurora-Cluster-Volume geschrieben wurden.

Um in Aurora MySQL Version 3 dasselbe nicht standardmäßige Verhalten zu erzielen, das Sie mit dem Wert 0 oder 2 in Aurora MySQL Version 2 erzielen würden, setzen Sie den Parameter daher auf 0.

Diese Einstellungen können zwar die DML-Latenz für den Client verringern, sie können im Falle eines Failovers oder Neustarts aber auch zu Datenverlust führen. Daher empfehlen wir, für den Parameter innodb_flush_log_at_trx_commit den Standardwert 1 beizubehalten.

Während Datenverlust sowohl bei der MySQL Community Edition als auch bei Aurora MySQL auftreten kann, unterscheidet sich das Verhalten in jeder Datenbank aufgrund ihrer unterschiedlichen Architekturen. Diese Unterschiede in der Architektur können zu unterschiedlich starkem Datenverlust führen. damit sichergestellt wird, dass Ihre Datenbank ACID-konform ist, legen Sie innodb_flush_log_at_trx_commit immer auf den Wert 1 fest.

Anmerkung

Bevor Sie in Aurora MySQL Version 3 innodb_flush_log_at_trx_commit zu einem anderen Wert als 1 wechseln können, müssen Sie zuerst den Wert von innodb_trx_commit_allow_data_loss auf 1 ändern. Damit erkennen Sie das Risiko eines Datenverlusts an.

Minimieren und Beheben von Aurora-MySQL-Deadlocks

Bei Benutzern, die Workloads ausführen, bei denen regelmäßig Einschränkungen für eindeutige sekundäre Indizes oder Fremdschlüssel verletzt werden, kann es bei der gleichzeitigen Änderung von Datensätzen auf derselben Datenseite zu erhöhten Deadlocks und Wartezeitüberschreitungen bei Sperren kommen. Diese Deadlocks und Zeitüberschreitungen sind auf einen Bugfix der MySQL Community Edition zurückzuführen.

Dieser Bugfix ist in den MySQL-Community-Edition-Versionen 5.7.26 und höher enthalten und wurde in die Aurora-MySQL-Versionen 2.10.3 und höher zurückportiert. Der Bugfix ist notwendig, um die Serialisierbarkeit zu erzwingen, indem zusätzliche Sperren für diese Arten von Data Manipulation Language (DML)-Operationen für Änderungen an Datensätzen in einer InnoDB-Tabelle implementiert werden. Dieses Problem wurde im Rahmen einer Untersuchung von Deadlock-Problemen aufgedeckt, die durch einen früheren Bugfix der MySQL Community Edition verursacht wurden.

Mit dem Bugfix wurde die interne Behandlung für das teilweise Rollback eines Tupel- (Zeilen-)Updates in der InnoDB-Speicher-Engine geändert. Operationen, die zu Einschränkungsverstößen bei Fremdschlüsseln oder eindeutigen Sekundärindizes führen, verursachen ein partielles Rollback. Dies beinhaltet, ist aber nicht beschränkt auf gleichzeitige INSERT...ON DUPLICATE KEY UPDATE-, REPLACE INTO,- und INSERT IGNORE-Anweisungen (upserts).

In diesem Zusammenhang bezieht sich partielles Rollback nicht auf das Rollback von Transaktionen auf Anwendungsebene, sondern auf ein internes InnoDB-Rollback von Änderungen an einem gruppierten Index, wenn ein Einschränkungsverstoß auftritt. Beispielsweise wird während einer Upsert-Operation ein doppelter Schlüsselwert gefunden.

In einem normalen Einfügevorgang erstellt InnoDB automatisch gruppierte und sekundäre Indexeinträge für jeden Index. Wenn InnoDB während einer Upsert-Operation einen doppelten Wert in einem eindeutigen sekundären Index erkennt, muss der eingefügte Eintrag im gruppierten Index rückgängig gemacht werden (partielles Rollback), und die Aktualisierung muss dann auf die vorhandene doppelte Zeile angewendet werden. Während dieses internen partiellen Rollback-Schritts muss InnoDB jeden Datensatz sperren, der als Teil des Vorgangs angezeigt wird. Der Bugfix gewährleistet die Serialisierbarkeit von Transaktionen, indem nach dem partiellen Rollback eine zusätzliche Sperrung eingeführt wird.

Minimieren von InnoDB-Deadlocks

Sie können die folgenden Ansätze verwenden, um die Häufigkeit von Deadlocks in Ihrer Datenbank-Instance zu reduzieren. Weitere Beispiele finden Sie in der MySQL-Dokumentation.

  1. Um die Wahrscheinlichkeit von Deadlocks zu verringern, sollten Sie für Transaktionen sofort einen Commit ausführen, nachdem Sie die entsprechenden Änderungen vorgenommen haben. Teilen Sie dazu große Transaktionen (mehrere Zeilenaktualisierungen zwischen Commits) in kleinere Transaktionen auf. Wenn Sie Zeilen stapelweise einfügen, versuchen Sie, die Größe der Stapeleinfügungen zu reduzieren, insbesondere wenn Sie die zuvor genannten Upsert-Operationen verwenden.

    Um die Anzahl möglicher partieller Rollbacks zu reduzieren, können Sie einige der folgenden Ansätze ausprobieren:

    1. Ersetzen Sie Batch-Einfügeoperationen durch das Einfügen einer Zeile nach der anderen. Dadurch kann die Zeit reduziert werden, in der Sperren aufgrund von Transaktionen, die möglicherweise zu Konflikten führen, aufrechterhalten bleiben.

    2. Anstatt REPLACE INTO zu verwenden, schreiben Sie die SQL-Anweisung in eine Transaktion mit mehreren Anweisungen um, z. B. die folgende:

      BEGIN;
DELETE conflicting rows;
INSERT new rows;
COMMIT;

    3. Anstatt INSERT...ON DUPLICATE KEY UPDATE zu verwenden, schreiben Sie die SQL-Anweisung in eine Transaktion mit mehreren Anweisungen um, z. B. die folgende:

      BEGIN;
SELECT rows that conflict on secondary indexes;
UPDATE conflicting rows;
INSERT new rows;
COMMIT;

  2. Vermeiden Sie lang dauernde Transaktionen, ob aktiv oder inaktiv, die Sperren möglicherweise aufrechterhalten. Dazu gehören interaktive MySQL-Client-Sitzungen, die möglicherweise über einen längeren Zeitraum geöffnet sind, wenn für eine Transaktion kein Commit ausgeführt wird. Bei der Optimierung von Transaktionsgrößen oder Batch-Größen können die Auswirkungen in Abhängigkeit von einer Reihe von Faktoren wie Parallelität, Anzahl der Duplikate und Tabellenstruktur variieren. Alle Änderungen sollten auf der Grundlage Ihrer Workload implementiert und getestet werden.

  3. In einigen Situationen können Deadlocks auftreten, wenn zwei Transaktionen versuchen, auf dieselben Datensätze, entweder in einer oder mehreren Tabellen, in unterschiedlicher Reihenfolge zuzugreifen. Um dies zu verhindern, können Sie die Transaktionen so ändern, dass sie in derselben Reihenfolge auf die Daten zugreifen, wodurch der Zugriff serialisiert wird. Erstellen Sie beispielsweise eine Warteschlange mit Transaktionen, die abgeschlossen werden sollen. Dieser Ansatz kann dazu beitragen, Deadlocks zu vermeiden, wenn mehrere Transaktionen gleichzeitig stattfinden.

  4. Durch Hinzufügen sorgfältig ausgewählter Indizes zu Ihren Tabellen lässt sich die Selektivität verbessern und die Notwendigkeit, auf Zeilen zuzugreifen, reduzieren, was zu weniger Sperren führt.

  5. Wenn Sie auf eine Lückensperre stoßen, können Sie die Transaktionsisolationsstufe für die Sitzung oder Transaktion in READ COMMITTED ändern, um dies zu verhindern. Weitere Informationen zu InnoDB-Isolationsstufen und ihrem Verhalten finden Sie unter Transaktionsisolationsstufen in der MySQL-Dokumentation.

Anmerkung

Sie können zwar Vorkehrungen treffen, um die Wahrscheinlichkeit von Deadlocks zu verringern, Deadlocks sind jedoch ein erwartetes Datenbankverhalten und können dennoch auftreten. Anwendungen sollten über die erforderliche Logik zum Umgang mit Deadlocks verfügen, wenn diese auftreten. Implementieren Sie beispielsweise die Wiederholungs- und Back-Off-Logik in der Anwendung. Es ist am besten, die Ursache des Problems zu beheben. Wenn jedoch ein Deadlock auftritt, hat die Anwendung die Möglichkeit, zu warten und es erneut zu versuchen.

Überwachen von InnoDB-Deadlocks

Deadlocks können in MySQL auftreten, wenn Anwendungstransaktionen versuchen, Sperren auf Tabellen- und Zeilenebene so zu umgehen, dass zirkuläres Warten entsteht. Ein gelegentlicher InnoDB-Deadlock ist nicht unbedingt ein Problem, da die InnoDB-Speicher-Engine den Zustand sofort erkennt und für eine der Transaktionen automatisch ein Rollback durchführt. Wenn Sie häufig auf Deadlocks stoßen, empfehlen wir, Ihre Anwendung zu überprüfen und zu ändern, um Leistungsprobleme zu verringern und Deadlocks zu vermeiden. Wenn die Deadlock-Erkennung aktiviert ist (Standard), erkennt InnoDB automatisch Transaktions-Deadlocks und führt ein Rollback für eine oder mehrere Transaktionen durch, um den Deadlock zu durchbrechen. InnoDB versucht, kleine Transaktionen für das Rollback auszuwählen, wobei die Größe einer Transaktion durch die Anzahl der eingefügten, aktualisierten oder gelöschten Zeilen bestimmt wird.

  • SHOW ENGINE-Anweisung – Die SHOW ENGINE INNODB STATUS \G-Anweisung enthält Details zum letzten Deadlock, der seit dem letzten Neustart in der Datenbank aufgetreten ist.

  • MySQL-Fehlerprotokoll – Wenn Sie häufig auf Deadlocks stoßen, bei denen die Ausgabe der SHOW ENGINE-Anweisung unangemessen ist, können Sie den DB-Cluster-Parameter innodb_print_all_deadlocks aktivieren.

    Wenn dieser Parameter aktiviert ist, werden Informationen über alle Deadlocks in InnoDB-Benutzertransaktionen im Fehlerprotokoll von Aurora MySQL aufgezeichnet.

  • CloudWatch Amazon-Metriken — Wir empfehlen Ihnen außerdem, Deadlocks anhand der CloudWatch Metrik proaktiv zu überwachen. Deadlocks Weitere Informationen finden Sie unter Metriken auf Instance-Ebene für Amazon Aurora.

  • Amazon CloudWatch Logs — Mit CloudWatch Logs können Sie Metriken anzeigen, Protokolldaten analysieren und Alarme in Echtzeit erstellen. Weitere Informationen finden Sie unter Überwachen von Fehlern in Amazon Aurora MySQL und Amazon RDS for MySQL mithilfe von Amazon CloudWatch und Senden von Benachrichtigungen mithilfe von Amazon SNS.

    Wenn Sie CloudWatch Logs verwenden, wenn diese Option innodb_print_all_deadlocks aktiviert ist, können Sie Alarme so konfigurieren, dass Sie benachrichtigt werden, wenn die Anzahl der Deadlocks einen bestimmten Schwellenwert überschreitet. Wenn Sie einen Schwellenwert definieren möchten, empfehlen wir Ihnen, Ihre Trends zu beobachten und einen Wert zu verwenden, der auf Ihrer normalen Workload basiert.

  • Performance Insights – Wenn Sie Performance Insights verwenden, können Sie die Metriken innodb_deadlocks und innodb_lock_wait_timeout überwachen. Weitere Informationen zu diesen Metriken, finden Sie unter Nicht-native Zähler für Aurora MySQL.