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](CHAP_Aurora.md). **Contents** + [Feststellen, mit welcher DB-Instance Sie verbunden sind](#AuroraMySQL.BestPractices.DeterminePrimaryInstanceConnection) + [Bewährte Verfahren für die Leistung und Skalierung von Aurora MySQL](AuroraMySQL.BestPractices.Performance.md) + [Verwendung von T-Instance-Klassen für Entwicklung und Tests](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium) + [Optimierung von mit Aurora MySQL indizierten Join-Abfragen mit asynchronem Key Prefetch](AuroraMySQL.BestPractices.Performance.md#Aurora.BestPractices.AKP) + [Asynchrones Key Prefetch aktivieren](AuroraMySQL.BestPractices.Performance.md#Aurora.BestPractices.AKP.Enabling) + [Optimieren von Abfragen für asynchrones Key Prefetch](AuroraMySQL.BestPractices.Performance.md#Aurora.BestPractices.AKP.Optimizing) + [Optimierung von großen Aurora-MySQL-Join-Abfragen mit Hash-Joins](AuroraMySQL.BestPractices.Performance.md#Aurora.BestPractices.HashJoin) + [Aktivieren von Hash-Joins](AuroraMySQL.BestPractices.Performance.md#Aurora.BestPractices.HashJoin.Enabling) + [Optimieren von Abfragen für Hash-Joins](AuroraMySQL.BestPractices.Performance.md#Aurora.BestPractices.HashJoin.Optimizing) + [Verwenden von Amazon Aurora für das Skalieren von Lesevorgängen in Ihrer MySQL-Datenbank](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.ReadScaling) + [Optimierung von Zeitstempeloperationen](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.Performance.TimeZone) + [Überlauffehler bei virtuellen Index-IDs](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.Performance.VirtualIndexIDOverflow) + [Bewährte Methoden für die Hochverfügbarkeit von Aurora MySQL](AuroraMySQL.BestPractices.HA.md) + [Verwenden von Amazon Aurora zur Notfallwiederherstellung Ihrer MySQL-Datenbanken](AuroraMySQL.BestPractices.HA.md#AuroraMySQL.BestPractices.DisasterRecovery) + [Migrieren von MySQL zu Amazon Aurora MySQL mit reduzierter Ausfallzeit](AuroraMySQL.BestPractices.HA.md#AuroraMySQL.BestPractices.Migrating) + [Vermeiden von Leistungseinbußen, automatischem Neustart und Failover für DB-Instances von Aurora MySQL](AuroraMySQL.BestPractices.HA.md#AuroraMySQL.BestPractices.Avoiding) + [Empfehlungen für MySQL-Funktionen in Aurora MySQL](AuroraMySQL.BestPractices.FeatureRecommendations.md) + [Verwenden von Multithread-Replikation in Aurora MySQL](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.MTReplica) + [AWS Lambda Funktionen mit nativen MySQL-Funktionen aufrufen](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Lambda) + [Vermeiden von XA-Transaktionen mit Amazon Aurora MySQL](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.XA) + [Aktivieren von Fremdschlüsseln während DML-Anweisungen](AuroraMySQL.BestPractices.FeatureRecommendations.md#Aurora.BestPractices.ForeignKeys) + [Konfigurieren, wie oft der Protokollpuffer geleert wird](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush) + [Minimieren und Beheben von Aurora-MySQL-Deadlocks](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks) + [Minimieren von InnoDB-Deadlocks](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks-minimize) + [Überwachen von InnoDB-Deadlocks](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks-monitor) + [Bewertung der DB-Instance-Nutzung für Aurora MySQL mit CloudWatch Amazon-Metriken](AuroraMySQL.BestPractices.CW.md) ## 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. **Topics** + [Verwendung von T-Instance-Klassen für Entwicklung und Tests](#AuroraMySQL.BestPractices.T2Medium) + [Optimierung von mit Aurora MySQL indizierten Join-Abfragen mit asynchronem Key Prefetch](#Aurora.BestPractices.AKP) + [Optimierung von großen Aurora-MySQL-Join-Abfragen mit Hash-Joins](#Aurora.BestPractices.HashJoin) + [Verwenden von Amazon Aurora für das Skalieren von Lesevorgängen in Ihrer MySQL-Datenbank](#AuroraMySQL.BestPractices.ReadScaling) + [Optimierung von Zeitstempeloperationen](#AuroraMySQL.BestPractices.Performance.TimeZone) + [Überlauffehler bei virtuellen Index-IDs](#AuroraMySQL.BestPractices.Performance.VirtualIndexIDOverflow) ## Verwendung von T-Instance-Klassen für Entwicklung und Tests Amazon Aurora MySQL-Instances, die die DB-Instance-Klassen `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-Instances 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html). 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](aurora-serverless-v2.md). 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](aurora-serverless-v2.requirements.md). 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-Instances. Diese speziellen Voreinstellungen sind erforderlich, damit Aurora auf Instances 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-Instance 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](USER_Monitoring.md). + Ü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 ist`OFF`, 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](https://dev.mysql.com/doc/refman/5.6/en/bnl-bka-optimization.html) und [Multi-Range Read Optimization](https://dev.mysql.com/doc/refman/5.6/en/mrr-optimization.html) 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 MySQLLTS-Versionen (Long-Term-Support, Langzeit-Support) und Betaversionen für Amazon Aurora MySQL](AuroraMySQL.Updates.md). ### 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\$1key\$1access** und **mrr\$1cost\$1based** finden Sie unter [Switchable Optimizations](https://dev.mysql.com/doc/refman/5.6/en/switchable-optimizations.html) 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](https://dev.mysql.com/doc/refman/8.0/en/explain-extended.html) 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](https://dev.mysql.com/doc/refman/8.0/en/explain-extended.html) 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](AuroraMySQL.Reference.Hints.md). ## 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 für MySQL-DB-Instance oder eine MySQL-Datenbank sein, die außerhalb von Amazon RDS ausgeführt wird. Weitere Informationen finden Sie unter [Skalieren von Lesevorgängen für Ihre MySQL-Datenbank mit Amazon Aurora](AuroraMySQL.Replication.ReadScaling.md). ## 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\$1zone](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_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 in Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md). 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. ## Überlauffehler bei virtuellen Index-IDs Aurora MySQL begrenzt die Werte für den virtuellen Index IDs auf 8 Bit und verhindert ein Problem, das durch das Undo-Format in MySQL verursacht wird. Wenn ein Index das Limit für virtuelle Index-IDs überschreitet, ist Ihr Cluster möglicherweise nicht verfügbar. Wenn sich ein Index dem Limit für virtuelle Index-IDs nähert oder wenn Sie versuchen, einen Index zu erstellen, der über dem Limit für virtuelle Index-IDs liegt, gibt RDS möglicherweise einen `63955`-Fehler oder `63955`-Warnungscode aus. Zum Beheben eines Fehlers beim Limit für virtuelle Index-IDs empfehlen wir Ihnen, Ihre Datenbank mit einem logischen Dump und einer Wiederherstellung neu zu erstellen. Weitere Informationen zu logischem Dump und Restore für Amazon Aurora MySQL finden Sie unter [Migrieren sehr großer Datenbanken zu Amazon Aurora MySQL mithilfe von MyDumper und MyLoader](https://aws.amazon.com/blogs/database/migrate-very-large-databases-to-amazon-aurora-mysql-using-mydumper-and-myloader/). Weitere Informationen zum Zugriff auf Fehlerprotokolle in Amazon Aurora finden Sie unter [Überwachen von Amazon Aurora-Protokolldateien](USER_LogAccess.md). # Bewährte Methoden 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. **Topics** + [Verwenden von Amazon Aurora zur Notfallwiederherstellung Ihrer MySQL-Datenbanken](#AuroraMySQL.BestPractices.DisasterRecovery) + [Migrieren von MySQL zu Amazon Aurora MySQL mit reduzierter Ausfallzeit](#AuroraMySQL.BestPractices.Migrating) + [Vermeiden von Leistungseinbußen, automatischem Neustart und Failover für DB-Instances von Aurora MySQL](#AuroraMySQL.BestPractices.Avoiding) ## 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 für 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](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.ReadScaling). Weitere Hinweise zu Notfallwiederherstellungsmodellen finden Sie unter [So wählen Sie die beste Notfallwiederherstellungsoption für Ihren Amazon-Aurora-MySQL-Cluster aus](https://aws.amazon.com/blogs/database/how-to-choose-the-best-disaster-recovery-option-for-your-amazon-aurora-mysql-cluster/). ## 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 DB-Instance von Amazon RDS für MySQL mit reduzierter Ausfallzeit](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-reduced-downtime.html) im *Benutzerhandbuch zu Amazon Relational Database Service* 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 für 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](MonitoringAurora.md). 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 [Amazon Aurora Aurora-DB-Instance-Klassen](Concepts.DBInstanceClass.md). # Empfehlungen für MySQL-Funktionen in 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. **Topics** + [Verwenden von Multithread-Replikation in Aurora MySQL](#AuroraMySQL.BestPractices.MTReplica) + [AWS Lambda Funktionen mit nativen MySQL-Funktionen aufrufen](#AuroraMySQL.BestPractices.Lambda) + [Vermeiden von XA-Transaktionen mit Amazon Aurora MySQL](#AuroraMySQL.BestPractices.XA) + [Aktivieren von Fremdschlüsseln während DML-Anweisungen](#Aurora.BestPractices.ForeignKeys) + [Konfigurieren, wie oft der Protokollpuffer geleert wird](#AuroraMySQL.BestPractices.Flush) + [Minimieren und Beheben von Aurora-MySQL-Deadlocks](#AuroraMySQL.BestPractices.deadlocks) ## Verwenden von Multithread-Replikation in Aurora MySQL Bei der Multithread-Replikation für binäre Protokolle liest ein SQL-Thread Ereignisse aus dem Relay-Log und stellt sie in die Warteschlange, damit SQL-Worker-Threads angewendet werden können. Die SQL-Worker-Threads werden von einem Koordinator-Thread verwaltet. Die binären Protokollereignisse werden nach Möglichkeit parallel angewendet. Die Multithread-Replikation wird in Aurora-MySQL-Version 3 und Aurora-MySQL-Version 2.12.1 und höher unterstützt. Für Aurora-MySQL-Versionen unter 3.04 verwendet Aurora standardmäßig die Single-Thread-Replikation, wenn ein Aurora-MySQL-DB-Cluster als Read Replica für die Binärprotokollreplikation verwendet wird. Frühere Versionen von Aurora-MySQL-Version 2 haben mehrere Probleme in Bezug auf die Multi-Thread-Replikation aus der MySQL Community Edition geerbt. Für diese Versionen empfehlen wir, die Multithread-Replikation in der Produktion nicht zu verwenden. Wenn Sie die Multi-Thread-Replikation verwenden, empfehlen wir Ihnen, diese vorher gründlich zu testen. Weitere Informationen zur Verwendung der Replikation in Amazon Aurora finden Sie unter [Replikation mit Amazon Aurora](Aurora.Replication.md). Weitere Informationen zur Multithread-Replikation in Aurora MySQL finden Sie unter [Multithread-Replikation für binäre Protokolle](binlog-optimization.md#binlog-optimization-multithreading). ## 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](AuroraMySQL.Integrating.Lambda.md). ## 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](https://dev.mysql.com/doc/refman/8.0/en/xa.html) 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`. 1. Nehmen Sie Ihre DML-Änderungen (Data Manipulation Language) vor. 1. Stellen Sie sicher, dass Ihre durchgeführten Änderungen keine Fremdschlüsselbedingungen verletzen. 1. 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](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_acid)-konform zu halten. Wir empfehlen, die Standardeinstellung 1 beizubehalten. Wenn Sie `innodb_flush_log_at_trx_commit` in einen nicht standardmäßigen Wert ändern, kann dies dazu beitragen, die Latenz der Data Manipulation Language (DML) zu verringern, 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\$1flush\$1log\$1at\$1trx\$1commit](https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_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 einen Commit für eine Transaktion ausführt, auf die Bestätigung vom Aurora-Cluster-Volume. Diese Bestätigung gibt an, dass dieser Datensatz und alle vorherigen Redo-Protokolldatensätze geschrieben wurden und das [Quorum](https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-quorum-and-correlated-failure/) 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](https://d1.awsstatic.com/events/reinvent/2020/Amazon_Aurora_storage_demystified_DAT401.pdf) (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-Protokolldatensä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-Protokolldatensä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-Protokolldatensä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-Protokolldatensä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 `innodb_flush_log_at_trx_commit` in Aurora-MySQL-Version 3 in einen anderen Wert als 1 ändern können, müssen Sie zuerst den Wert von `innodb_trx_commit_allow_data_loss` auf 1 ändern. Auf diese Weise 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](https://bugs.mysql.com/bug.php?id=98324) 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](https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-26.html) 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](https://dev.mysql.com/doc/refman/5.7/en/innodb-index-types.html) 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](https://bugs.mysql.com/bug.php?id=98324). 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. 1. 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; ``` 1. 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; ``` 1. 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. 1. 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. 1. 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. 1. Wenn Sie auf eine [Lückensperre](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-gap-locks) 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](https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html) 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](https://dev.mysql.com/doc/refman/8.0/en/glossary.html#glos_deadlock) 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](https://dev.mysql.com/doc/refman/8.0/en/glossary.html#glos_deadlock_detection) 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](https://dev.mysql.com/doc/refman/5.7/en/show-engine.html) 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\$1print\$1all\$1deadlocks](https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_print_all_deadlocks) aktivieren. Wenn dieser Parameter aktiviert ist, werden Informationen über alle Deadlocks in InnoDB-Benutzertransaktionen im [Fehlerprotokoll](https://dev.mysql.com/doc/refman/8.0/en/error-log.html) 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](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances). + 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](https://aws.amazon.com/blogs/database/monitor-errors-in-amazon-aurora-mysql-and-amazon-rds-for-mysql-using-amazon-cloudwatch-and-send-notifications-using-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](USER_PerfInsights_Counters.md#USER_PerfInsights_Counters.Aurora_MySQL.NonNative). # Bewertung der DB-Instance-Nutzung für Aurora MySQL mit CloudWatch Amazon-Metriken Sie können CloudWatch Metriken verwenden, um Ihren DB-Instance-Durchsatz zu überwachen und festzustellen, ob Ihre DB-Instance-Klasse ausreichend Ressourcen für Ihre Anwendungen bereitstellt. Weitere Informationen zu Ihren DB-Instance-Klassenlimits finden Sie unter [Hardwarespezifikationen für DB-Instance-Klassen für Aurora](Concepts.DBInstanceClass.Summary.md). Suchen Sie die Spezifikationen für Ihre DB-Instance-Klasse, um die Netzwerkleistung zu ermitteln. Wenn sich Ihre DB-Instance-Nutzung dem Instance-Klassenlimit nähert, kann sich die Leistung verschlechtern. Die CloudWatch Metriken können diese Situation bestätigen, sodass Sie planen können, manuell auf eine größere Instance-Klasse hochzuskalieren. Kombinieren Sie die folgenden CloudWatch Metrikwerte, um herauszufinden, ob Sie sich dem Instance-Klassenlimit nähern: + **NetworkThroughput**— Die Menge des Netzwerkdurchsatzes, der von den Clients für jede Instance im Aurora-DB-Cluster empfangen und übertragen wird. Dieser Durchsatzwert berücksichtigt nicht den Netzwerkdatenverkehr zwischen den Instances im DB-Cluster und dem Cluster-Volume. + **StorageNetworkThroughput**— Die Menge des Netzwerkdurchsatzes, der von jeder Instance im Aurora-DB-Cluster empfangen und an das Aurora-Speichersubsystem gesendet wurde. Fügen Sie den hinzu **NetworkThroughput**, **StorageNetworkThroughput**um den Netzwerkdurchsatz zu ermitteln, der von jeder Instance in Ihrem Aurora-DB-Cluster vom Aurora-Speichersubsystem empfangen und an dieses gesendet wurde. Das Instance-Klassenlimit für Ihre Instance sollte größer sein als die Summe dieser beiden kombinierten Metriken. Sie können die folgenden Metriken verwenden, um zusätzliche Details des Netzwerkverkehrs Ihrer Client-Anwendungen beim Senden und Empfangen zu überprüfen: + **NetworkReceiveThroughput**— Die Menge des Netzwerkdurchsatzes, den jede DB-Instance im Aurora MySQL-DB-Cluster von Clients erhält. Dieser Durchsatz beinhaltet nicht den Netzwerkdatenverkehr zwischen den Instances im -DB-Cluster und dem Cluster-Volume. + **NetworkTransmitThroughput** – Der Umfang des von Clients gesendeten Netzwerkdurchsatzes für jede Instance im Aurora-DB-Cluster Dieser Durchsatz beinhaltet nicht den Netzwerkdatenverkehr zwischen den Instances im -DB-Cluster und dem Cluster-Volume. + **StorageNetworkReceiveThroughput** – Der Umfang des vom Aurora-Speicheruntersystem empfangenen Netzwerkdurchsatzes für jede Instance im DB-Cluster + **StorageNetworkTransmitThroughput**— Die Menge des Netzwerkdurchsatzes, der von jeder Instance im DB-Cluster an das Aurora-Speichersubsystem gesendet wird. Addieren Sie all diese Metriken, um zu bewerten, wie Ihre Netzwerknutzung im Vergleich zum DB-Instance-Klassenlimit abschneidet. Das Instance-Klassenlimit sollte größer sein als die Summe dieser kombinierten Metriken. Die Netzwerklimits und die CPU-Auslastung für Speicher stehen in direktem Zusammenhang. Wenn der Netzwerkdurchsatz steigt, steigt auch die CPU-Auslastung. Die Überwachung der CPU- und Netzwerknutzung gibt Aufschluss darüber, wie und warum die Ressourcen erschöpft werden. Sie können Folgendes in Betracht ziehen, um die Netzwerknutzung zu minimieren: + Verwenden einer größeren DB-Instance-Klasse + Aufteilen der Schreibanforderungen in Batches, um die Gesamttransaktionen zu reduzieren + Weiterleiten der schreibgeschützten Workload an eine schreibgeschützte Instance + Löschen aller ungenutzten Indizes