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. # Amazon Aurora MySQL-Referenz Diese Referenz enthält Informationen über Aurora MySQL-Parameter, Statusvariablen und allgemeine SQL-Erweiterungen oder Unterschiede zur MySQL-Datenbank-Engine der Community. **Topics** + [Aurora MySQL Konfigurationsparameter](AuroraMySQL.Reference.ParameterGroups.md) + [Globale Statusvariablen von Aurora MySQL](AuroraMySQL.Reference.GlobalStatusVars.md) + [Aurora-MySQL-Warteereignisse](AuroraMySQL.Reference.Waitevents.md) + [Aurora-MySQL-Thread-Zustände](AuroraMySQL.Reference.thread-states.md) + [Aurora MySQL-Isolierungsstufen](AuroraMySQL.Reference.IsolationLevels.md) + [Aurora-MySQL-Hinweise](AuroraMySQL.Reference.Hints.md) + [Referenz für gespeicherte Aurora-MySQL-Prozeduren](AuroraMySQL.Reference.StoredProcs.md) + [Aurora-MySQL-spezifische information\$1schema-Tabellen](AuroraMySQL.Reference.ISTables.md) # Aurora MySQL Konfigurationsparameter Sie können Ihr Amazon-Aurora-MySQL-DB-Cluster auf dieselbe Art und Weise verwalten, wie Sie Ihre anderen Amazon-RDS-DB-Instances verwalten, und zwar indem Sie die Parameter in einer DB-Parametergruppe verwenden. Amazon Aurora unterscheidet sich von anderen DB-Engines dadurch, dass Sie über einen DB-Cluster verfügen, der mehrere DB-Instances enthält. Folglich gelten einige der Parameter, mit denen Sie Ihren Aurora MySQL-DB-Cluster verwalten, für den gesamten Cluster. Andere Parameter gelten nur für eine bestimmte DB-Instance im DB-Cluster. Um Parameter auf Cluster-Ebene zu verwalten, verwenden Sie DB-Cluster-Parametergruppen. Um Parameter auf Instance-Ebene zu verwalten, verwenden Sie DB-Parametergruppen. Jede DB-Instance in einem Aurora MySQL-DB-Cluster ist mit der MySQL-Datenbank-Engine kompatibel. Sie wenden jedoch einige der Parameter der MySQL-Datenbank-Engine auf Cluster-Ebene an und verwalten diese Parameter mit DB-Cluster-Parametergruppen. Sie können keine Parameter auf Cluster-Ebene in der DB-Parametergruppe für eine Instance in einem Aurora-DB-Cluster finden. Eine Liste der Parameter auf Cluster-Ebene erscheint weiter unten in diesem Thema. Sie können die Parameter sowohl auf der Cluster- als auch auf der Instance-Ebene mithilfe der AWS-Managementkonsole, AWS CLI oder Amazon-RDS-API verwalten. Sie verwenden separate Befehle für die Verwaltung von Parametern auf Cluster- und Instance-Ebene. Beispielsweise können Sie mit dem CLI-Befehl [modify-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html) Parameter auf Cluster-Ebene in einer DB-Cluster-Parametergruppe verwalten. Sie können den CLI-Befehl [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) verwenden, um Parameter auf Instance-Ebene in einer DB-Parametergruppe für eine DB-Instance in einem DB-Cluster zu verwalten. Sie können Parameter auf Cluster- und Instance-Ebene in der Konsole oder mithilfe der CLI oder der RDS-API anzeigen. Beispielsweise können Sie mit den AWS CLI-Befehl [describe-db-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-parameters.html) verwenden, um Parameter auf Cluster-Ebene in einer DB-Cluster-Parametergruppe anzuzeigen. Sie können den CLI-Befehl [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) verwenden, um Parameter auf Instance-Ebene in einer DB-Parametergruppe für eine DB-Instance in einem DB-Cluster anzuzeigen. **Anmerkung** Jede [Standard-Parametergruppe](USER_WorkingWithParamGroups.md) enthält die Standardwerte für alle Parameter in der Parametergruppe. Wenn der Parameter „Engine-Standard“ für diesen Wert hat, finden Sie in der versionsspezifischen MySQL- oder PostgreSQL-Dokumentation den tatsächlichen Standardwert. Sofern nicht anders angegeben, gelten die in den folgenden Tabellen aufgeführten Parameter für die Aurora-MySQL-Versionen 2 und 3. Weitere Informationen zu DB-Parametergruppen finden Sie unter [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.md). Regeln und Einschränkungen für Aurora Serverless v1-Cluster finden Sie unter [Parametergruppen für Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.parameter-groups). **Topics** + [Parameter auf Cluster-Ebene](#AuroraMySQL.Reference.Parameters.Cluster) + [Parameter auf Instance-Ebene](#AuroraMySQL.Reference.Parameters.Instance) + [MySQL-Parameter, die nicht auf Aurora MySQL zutreffen](#AuroraMySQL.Reference.Parameters.Inapplicable) ## Parameter auf Cluster-Ebene In der folgenden Tabelle werden alle Parameter aufgeführt, die für das gesamte Aurora MySQL-DB-Cluster gelten. | Parametername | Anpassbar | Hinweise | | --- | --- | --- | | `aurora_binlog_read_buffer_size` | Ja | Beeinflusst nur Cluster, die Binärprotokoll-Replikation (Binlog) verwenden. Hinweise zur Binärprotokoll-Replikation finden Sie unter [Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)](AuroraMySQL.Replication.MySQL.md). Aus Aurora-MySQL-Version 3 entfernt. | | `aurora_binlog_replication_max_yield_seconds` | Ja | Beeinflusst nur Cluster, die Binärprotokoll-Replikation (Binlog) verwenden. Hinweise zur Binärprotokoll-Replikation finden Sie unter [Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)](AuroraMySQL.Replication.MySQL.md). | | `aurora_binlog_replication_sec_index_parallel_workers` | Ja | Legt die Gesamtzahl der verfügbaren parallelen Threads fest, um sekundäre Indexänderungen anzuwenden, wenn Transaktionen für große Tabellen mit mehr als einem sekundären Index repliziert werden. Der Parameter ist standardmäßig auf `0` (deaktiviert) eingestellt. Dieser Parameter ist in Aurora-MySQL-Version 3.06 und höher verfügbar. Weitere Informationen finden Sie unter [Optimieren einer binären Protokollreplikation für Aurora MySQL](binlog-optimization.md). | | `aurora_binlog_use_large_read_buffer` | Ja | Beeinflusst nur Cluster, die Binärprotokoll-Replikation (Binlog) verwenden. Hinweise zur Binärprotokoll-Replikation finden Sie unter [Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)](AuroraMySQL.Replication.MySQL.md). Aus Aurora-MySQL-Version 3 entfernt. | | `aurora_disable_hash_join` | Ja | Setzen Sie diesen Parameter auf `ON`, um die Hash-Join-Optimierung in Aurora MySQL Version 2.09 oder höher zu deaktivieren. Für Version 3 wird dies nicht unterstützt. Weitere Informationen finden Sie unter [Parallel Query für Amazon Aurora MySQL](aurora-mysql-parallel-query.md). | | `aurora_enable_replica_log_compression` | Ja | Weitere Informationen finden Sie unter [Performance-Überlegungen zur Amazon Aurora MySQL-Replikation](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Performance). Gilt nicht für Cluster, die Teil einer globalen Aurora-Datenbank sind. Aus Aurora-MySQL-Version 3 entfernt. | | `aurora_enable_repl_bin_log_filtering` | Ja | Weitere Informationen finden Sie unter [Performance-Überlegungen zur Amazon Aurora MySQL-Replikation](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Performance). Gilt nicht für Cluster, die Teil einer globalen Aurora-Datenbank sind. Aus Aurora-MySQL-Version 3 entfernt. | | `aurora_enable_staggered_replica_restart` | Ja | Diese Einstellung ist in Aurora MySQL Versione 3 verfügbar, wird aber nicht verwendet. | | `aurora_enable_zdr` | Ja | Diese Einstellung ist standardmäßig in Aurora MySQL 2.10 und höher aktiviert. | | `aurora_in_memory_relaylog` | Ja | Legt den In-Memory-Relay-Protokollmodus fest. Sie können diese Funktion für Binärprotokollreplikate verwenden, um die Leistung der Binärprotokollreplikation zu verbessern. Zum Ausschalten dieser Funktion setzen Sie den Parameter auf OFF. Zum Einschalten dieser Funktion setzen Sie den Parameter auf ON. | | `aurora_enhanced_binlog` | Ja | Legen Sie den Wert dieses Parameters auf 1 fest, um das erweiterte Binärprotokoll in Aurora MySQL Version 3.03.1 und höher zu aktivieren. Weitere Informationen finden Sie unter [Einrichten eines erweiterten Binärprotokolls für Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). | | `aurora_full_double_precision_in_json` | Ja | Stellen Sie den Wert dieses Parameters ein, um das Parsing von Fließkommazahlen in JSON-Dokumenten mit voller Genauigkeit zu ermöglichen. | | `aurora_jemalloc_background_thread` | Ja | Verwenden Sie diesen Parameter, um einen Hintergrund-Thread zur Durchführung von Speicherwartungsoperationen zu aktivieren. Die zulässigen Werte sind `0` (deaktiviert) und `1` (aktiviert). Der Standardwert ist `0`. Dieser Parameter gilt für Aurora MySQL Version 3.05 und höher. | | `aurora_jemalloc_dirty_decay_ms` | Ja | Verwenden Sie diesen Parameter zur Beibehaltung von freigegebenem Speicher für eine bestimmte Zeit (in Millisekunden). Die Beibehaltung von Speicher ermöglicht eine schnellere Wiederverwendung. Die zulässigen Werte sind `0` bis `18446744073709551615`. Der Standardwert ist `10000` (10 Sekunden). Eine kürzere Verzögerung kann helfen, Speicherprobleme zu vermeiden, führt jedoch zu einer geringeren Leistung. Dieser Parameter gilt für Aurora MySQL Version 3.05 und höher. | | `aurora_jemalloc_tcache_enabled` | Ja | Verwenden Sie diesen Parameter, um kleine Speicheranforderungen (bis zu 32 KiB) in einem lokalen Thread-Cache zu bearbeiten und dabei die Speicherarenen zu umgehen. Die zulässigen Werte sind `0` (deaktiviert) und `1` (aktiviert). Der Standardwert ist `1`. Dieser Parameter gilt für Aurora MySQL Version 3.05 und höher. | | `aurora_load_from_s3_role` | Ja | Weitere Informationen finden Sie unter [Laden von Daten in einen Amazon Aurora MySQL-DB-Cluster aus Textdateien in einem Amazon S3-Bucket](AuroraMySQL.Integrating.LoadFromS3.md). Derzeit nicht in Aurora-MySQL-Version 3 verfügbar. Verwenden Sie `aws_default_s3_role`. | | `aurora_mask_password_hashes_type` | Ja | Diese Einstellung ist in Aurora MySQL 2.11 und höher standardmäßig aktiviert. Verwenden Sie diese Einstellung, um Passwort-Hashes von Aurora MySQL in den allgemeinen Protokollen, den langsamen Abfrageprotokollen und den Audit-Protokollen zu maskieren. Die zulässigen Werte sind `0` und `1` (Standardeinstellung). Wenn diese Einstellung auf `1` festgelegt ist, werden Passwörter als `` protokolliert. Wenn diese Einstellung auf `0` festgelegt ist, werden Passwörter als Hash-Werte (`#`) protokolliert. | | `aurora_select_into_s3_role` | Ja | Weitere Informationen finden Sie unter [Speichern von Daten aus einem Amazon Aurora MySQL-DB-Cluster in Textdateien in einem Amazon S3-Bucket](AuroraMySQL.Integrating.SaveIntoS3.md). Derzeit nicht in Aurora-MySQL-Version 3 verfügbar. Verwenden Sie `aws_default_s3_role`. | | `authentication_kerberos_caseins_cmp` | Ja | Steuert den Benutzernamenvergleich ohne Berücksichtigung der Groß-/Kleinschreibung für das Plug-in `authentication_kerberos`. Setzen Sie den Parameter auf `true`, um den Vergleich ohne Berücksichtigung der Groß-/Kleinschreibung zu aktivieren. Standardmäßig wird der Vergleich unter Berücksichtigung der Groß-/Kleinschreibung verwendet (`false`). Weitere Informationen finden Sie unter [Verwenden der Kerberos-Authentifizierung für Aurora MySQL](aurora-mysql-kerberos.md). Dieser Parameter ist in Aurora MySQL Version 3.03 und höher verfügbar. | | `auto_increment_increment` | Ja | Keine | | `auto_increment_offset` | Ja | Keine | | `aws_default_lambda_role` | Ja | Weitere Informationen finden Sie unter [Aufrufen einer Lambda-Funktion aus einem Amazon Aurora MySQL-DB-Cluster](AuroraMySQL.Integrating.Lambda.md). | | `aws_default_s3_role` | Ja | Wird beim Aufrufen der Anweisung `LOAD DATA FROM S3`, `LOAD XML FROM S3` oder `SELECT INTO OUTFILE S3` aus Ihrem DB-Cluster verwendet. Bei Aurora MySQL Version 2 wird die in diesem Parameter festgelegte IAM-Rolle verwendet, wenn keine IAM-Rolle für `aurora_load_from_s3_role` oder `aurora_select_into_s3_role` für die entsprechende Anweisung festgelegt ist. Bei Aurora-MySQL-Version 3 wird die für diesen Parameter festgelegte IAM-Rolle immer verwendet. Weitere Informationen finden Sie unter [Zuweisen einer IAM-Rolle zu einem Amazon-Aurora-MySQL-DB-Cluster](AuroraMySQL.Integrating.Authorizing.IAM.AddRoleToDBCluster.md). | | `binlog_backup` | Ja | Legen Sie den Wert dieses Parameters auf 0 fest, um das erweiterte Binärprotokoll in Aurora MySQL Version 3.03.1 und höher zu aktivieren. Sie können diesen Parameter nur deaktivieren, wenn Sie das erweiterte Binärprotokoll verwenden. Weitere Informationen finden Sie unter [Einrichten eines erweiterten Binärprotokolls für Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). | | `binlog_checksum` | Ja | Die AWS CLI und RDS-API melden einen Wert von `None`, wenn dieser Parameter nicht festgelegt ist. In diesem Fall verwendet Aurora MySQL den Standardwert für die Engine, d.h. `CRC32`. Dies ist anders als die explizite Einstellung von `NONE`, die die Prüfsumme ausschaltet. | | `binlog-do-db` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `binlog_format` | Ja | Weitere Informationen finden Sie unter [Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)](AuroraMySQL.Replication.MySQL.md). | | `binlog_group_commit_sync_delay` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `binlog_group_commit_sync_no_delay_count` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `binlog-ignore-db` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `binlog_replication_globaldb` | Ja | Legen Sie den Wert dieses Parameters auf 0 fest, um das erweiterte Binärprotokoll in Aurora MySQL Version 3.03.1 und höher zu aktivieren. Sie können diesen Parameter nur deaktivieren, wenn Sie das erweiterte Binärprotokoll verwenden. Weitere Informationen finden Sie unter [Einrichten eines erweiterten Binärprotokolls für Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). | | `binlog_row_image` | Nein | Keine | | `binlog_row_metadata` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `binlog_row_value_options` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `binlog_rows_query_log_events` | Ja | Keine | | `binlog_transaction_compression` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `binlog_transaction_compression_level_zstd` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `binlog_transaction_dependency_history_size` | Ja | Dieser Parameter legt eine Obergrenze für die Anzahl der Zeilen-Hashes fest, die im Speicher abgelegt und für die Suche nach der Transaktion, die eine bestimmte Zeile zuletzt geändert hat, verwendet werden. Sobald diese Anzahl von Hashes erreicht wurde, wird der Verlauf gelöscht. Dieser Parameter gilt für Aurora-MySQL-Version 2.12 und höher sowie Version 3. | | `binlog_transaction_dependency_tracking` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `character-set-client-handshake` | Ja | Keine | | `character_set_client` | Ja | Keine | | `character_set_connection` | Ja | Keine | | `character_set_database` | Ja | Der von der Standarddatenbank verwendete Zeichensatz. Der Standardwert ist `utf8mb4`. | | `character_set_filesystem` | Ja | Keine | | `character_set_results` | Ja | Keine | | `character_set_server` | Ja | Keine | | `collation_connection` | Ja | Keine | | `collation_server` | Ja | Keine | | `completion_type` | Ja | Keine | | `default_storage_engine` | Nein | Aurora MySQL-Cluster verwenden für all Ihre Daten die InnoDB-Speicher-Engine. | | `enforce_gtid_consistency` | Manchmal | Veränderbar in Aurora MySQL-Version 2 und höher. | | `event_scheduler` | Ja | Zeigt den Status des Ereignisplaners an. Modifizierbar nur auf Cluster-Ebene in Aurora-MySQL-Version 3. | | `gtid-mode` | Manchmal | Veränderbar in Aurora MySQL-Version 2 und höher. | | `information_schema_stats_expiry` | Ja | Die Anzahl der Sekunden, nach denen der MySQL-Datenbankserver Daten von der Speicher-Engine abruft und die Daten im Cache ersetzt. Die zulässigen Werte sind `0` bis `31536000`. Dieser Parameter gilt für Aurora MySQL Version 3. | | `init_connect` | Ja | Der Befehl, der vom Server für jeden Client ausgeführt wird, der eine Verbindung herstellt. Verwenden Sie doppelte Anführungszeichen („) für Einstellungen, um Verbindungsfehler zu vermeiden, zum Beispiel: 
SET optimizer_switch="hash_join=off"
Bei Aurora MySQL Version 3 gilt dieser Parameter nicht für Benutzer, die über die `CONNECTION_ADMIN`-Berechtigung verfügen. Dies schließt den Aurora-Hauptbenutzer ein. Weitere Informationen finden Sie unter [Rollenbasiertes Berechtigungsmodell](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). | | `innodb_adaptive_hash_index` | Ja | Sie können diesen Parameter auf DB-Cluster-Ebene in den Aurora-MySLQ-Versionen 2 und 3 ändern. Der Adaptive-Hash-Index wird auf Reader-DB-Instances nicht unterstützt. | | `innodb_aurora_instant_alter_column_allowed` | Ja | Steuert, ob der `INSTANT`-Algorithmus für `ALTER COLUMN`-Operationen auf globaler Ebene verwendet werden kann. Die zulässigen Werte sind folgende: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Weitere Informationen finden Sie unter [Column Operations](https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html#online-ddl-column-operations) in der MySQL-Dokumentation. Dieser Parameter gilt für Aurora MySQL Version 3.05 und höher. | | `innodb_autoinc_lock_mode` | Ja | Keine | | `innodb_checksums` | Nein | Aus Aurora-MySQL-Version 3 entfernt. | | `innodb_cmp_per_index_enabled` | Ja | Keine | | `innodb_commit_concurrency` | Ja | Keine | | `innodb_data_home_dir` | Nein | Aurora MySQL verwendet verwaltete Instances, bei denen Sie nicht direkt auf das Archivsystem zugreifen. | | `innodb_deadlock_detect` | Ja | Diese Option wird verwendet, um die Deadlock-Erkennung in Aurora-MySQL-Version 2.11 und höher sowie Version 3 zu deaktivieren. Auf Systemen mit hoher Parallelität kann die Deadlock-Erkennung zu einer Verlangsamung führen, wenn zahlreiche Threads auf dieselbe Sperre warten. Weitere Informationen zu diesem Parameter finden Sie in der MySQL-Dokumentation. | | `innodb_default_row_format` | Ja | Dieser Parameter definiert das Standardzeilenformat für InnoDB-Tabellen (einschließlich benutzerdefinierter temporärer InnoDB-Tabellen). Er gilt für Aurora MySQL Version 2 und 3. Mögliche Werte sind `DYNAMIC`, `COMPACT` oder `REDUNDANT.`. | | `innodb_file_per_table` | Ja | Dieser Parameter wirkt sich auf die Organisation des Tabellenspeichers aus. Weitere Informationen finden Sie unter [Speicherskalierung](Aurora.Managing.Performance.md#Aurora.Managing.Performance.StorageScaling). | | `innodb_flush_log_at_trx_commit` | Ja | Es wird dringend empfohlen, den Standardwert `1` zu verwenden. Bevor Sie diesen Parameter in Aurora-MySQL-Version 3 in einen anderen Wert als `1` ändern können, müssen Sie den Wert von `innodb_trx_commit_allow_data_loss` in `1` ändern. Weitere Informationen finden Sie unter [Konfigurieren, wie oft der Protokollpuffer geleert wird](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush). | | `innodb_ft_max_token_size` | Ja | Keine | | `innodb_ft_min_token_size` | Ja | Keine | | `innodb_ft_num_word_optimize` | Ja | Keine | | `innodb_ft_sort_pll_degree` | Ja | Keine | | `innodb_online_alter_log_max_size` | Ja | Keine | | `innodb_optimize_fulltext_only` | Ja | Keine | | `innodb_page_size` | Nein | Keine | | `innodb_print_all_deadlocks` | Ja | Wenn dieser Parameter aktiviert ist, werden Informationen über alle InnoDB-Deadlocks im Fehlerprotokoll von Aurora MySQL aufgezeichnet. Weitere Informationen finden Sie unter [Minimieren und Beheben von Aurora-MySQL-Deadlocks](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks). | | `innodb_purge_batch_size` | Ja | Keine | | `innodb_purge_threads` | Ja | Keine | | `innodb_rollback_on_timeout` | Ja | Keine | | `innodb_rollback_segments` | Ja | Keine | | `innodb_spin_wait_delay` | Ja | Keine | | `innodb_strict_mode` | Ja | Keine | | `innodb_support_xa` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `innodb_sync_array_size` | Ja | Keine | | `innodb_sync_spin_loops` | Ja | Keine | | `innodb_stats_include_delete_marked` | Ja | Wenn dieser Parameter aktiviert ist, bezieht InnoDB zum Löschen markierte Datensätze in die Berechnung der persistenten Optimierungsstatistiken ein. Dieser Parameter gilt für Aurora-MySQL-Version 2.12 und höher sowie Version 3. | | `innodb_table_locks` | Ja | Keine | | `innodb_trx_commit_allow_data_loss` | Ja | In Aurora-MySQL-Version 3 legen Sie den Wert dieses Parameters auf `1` fest, sodass Sie den Wert von `innodb_flush_log_at_trx_commit` ändern können. Der Standardwert von `innodb_trx_commit_allow_data_loss` ist `0`. Weitere Informationen finden Sie unter [Konfigurieren, wie oft der Protokollpuffer geleert wird](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush). | | `innodb_undo_directory` | Nein | Aurora MySQL verwendet verwaltete Instances, bei denen Sie nicht direkt auf das Archivsystem zugreifen. | | `internal_tmp_disk_storage_engine` | Ja | Steuert, welche In-Memory-Speicher-Engine für interne temporäre Tabellen verwendet wird. Zulässige Werte sind `INNODB` und `MYISAM`. Dieser Parameter gilt für Aurora MySQL Version 2. | | `internal_tmp_mem_storage_engine` | Ja | Steuert, welche In-Memory-Speicher-Engine für interne temporäre Tabellen verwendet wird. Zulässige Werte sind `MEMORY` und `TempTable`. Dieser Parameter gilt für Aurora MySQL Version 3. | | `key_buffer_size` | Ja | Schlüssel-Cache für MyISAM-Tabellen. Weitere Informationen finden Sie unter [keycache->cache\$1lock mutex](AuroraMySQL.Reference.Waitevents.md#key-cache.cache-lock). | | `lc_time_names` | Ja | Keine | | `log_error_suppression_list` | Ja | Gibt eine Liste von Fehlercodes an, die nicht im MySQL-Fehlerprotokoll protokolliert werden. Auf diese Weise können Sie bestimmte unkritische Fehlerbedingungen ignorieren, um Ihre Fehlerprotokolle sauber zu halten. Weitere Informationen finden Sie unter [log\$1error\$1suppression\$1list](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list) in der MySQL-Dokumentation. Dieser Parameter gilt für Aurora-MySQL-Version 3.03 und höher. | | `low_priority_updates` | Ja | `INSERT`-, `UPDATE`-, `DELETE`- und `LOCK TABLE WRITE`-Operationen warten, bis kein ausstehender `SELECT`-Vorgang mehr vorhanden ist. Dieser Parameter wirkt sich nur auf Speicher-Engines aus, die ausschließlich Sperren auf Tabellenebene verwenden (MyISAM, MEMORY, MERGE). Dieser Parameter gilt für Aurora MySQL Version 3. | | `lower_case_table_names` | Ja (Aurora-MySQL-Version 2) Nur zur Clustererstellung (Aurora-MySQL-Version 3) | Stellen Sie in Aurora-MySQL-Version 2.10 und höheren 2.x-Versionen sicher, dass Sie alle Reader-Instances neu starten, nachdem Sie diese Einstellung geändert und die Writer-Instance neu gestartet haben. Details hierzu finden Sie unter [Neustarten eines Aurora-Clusters mit Leseverfügbarkeit](aurora-mysql-survivable-replicas.md). In Aurora-MySQL-Version 3 wird der Wert dieses Parameters zum Zeitpunkt der Erstellung des Clusters dauerhaft festgelegt. Wenn Sie für diese Option einen nicht standardmäßigen Wert verwenden, richten Sie Ihre benutzerdefinierte Parametergruppe Aurora-MySQL-Version 3 vor dem Upgrade ein, und geben Sie die Parametergruppe während des Snapshot-Wiederherstellungsvorgangs an, der den Cluster der Version 3 erstellt. Mit einer globalen Aurora-Datenbank, die auf Aurora MySQL basiert, können Sie kein direktes Upgrade von Aurora MySQL Version 2 auf Version 3 durchführen, wenn der `lower_case_table_names`-Parameter aktiviert ist. Weitere Informationen zu den möglichen Verfahren finden Sie unter [Hauptversions-Upgrades](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major). | | `master-info-repository` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `master_verify_checksum` | Ja | Aurora-MySQL-Version 2. Verwenden Sie `source_verify_checksum` in Aurora-MySQL-Version 3. | | `max_delayed_threads` | Ja | Legt die maximale Anzahl von Threads für die Verarbeitung von `INSERT DELAYED`-Anweisungen fest. Dieser Parameter gilt für Aurora MySQL Version 3. | | `max_error_count` | Ja | Die maximale Anzahl von Fehler-, Warn- und Hinweismeldungen, die für die Anzeige gespeichert werden sollen. Dieser Parameter gilt für Aurora MySQL Version 3. | | `max_execution_time` | Ja | Das Timeout für die Ausführung von `SELECT`-Anweisungen in Millisekunden. Der Wert kann zwischen `0` und `18446744073709551615` liegen. Wenn auf `0` eingestellt, gibt es kein Timeout. Weitere Informationen finden Sie unter [max\$1execution\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_execution_time) in der MySQL-Dokumentation. | | `min_examined_row_limit` | Ja | Verwenden Sie diesen Parameter, um zu verhindern, dass Abfragen, die weniger als die angegebene Anzahl von Zeilen untersuchen, protokolliert werden. | | `partial_revokes` | Nein | Dieser Parameter gilt für Aurora MySQL Version 3. | | `preload_buffer_size` | Ja | Die Größe des Puffers, der beim Vorabladen von Indizes zugewiesen wird. Dieser Parameter gilt für Aurora MySQL Version 3. | | `query_cache_type` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `read_only` | Ja | Wenn dieser Parameter aktiviert ist, erlaubt der Server nur Aktualisierungen, die von Replikat-Threads durchgeführt werden. Für Aurora-MySQL-Version 2 sind die folgenden Werte gültig: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Für Aurora-MySQL-Version 3 sind die folgenden Werte gültig: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Bei Aurora MySQL Version 3 gilt dieser Parameter nicht für Benutzer, die über die `CONNECTION_ADMIN`-Berechtigung verfügen. Dies schließt den Aurora-Hauptbenutzer ein. Weitere Informationen finden Sie unter [Rollenbasiertes Berechtigungsmodell](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). | | `relay-log-space-limit` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `replica_parallel_type` | Ja | Dieser Parameter ermöglicht die parallele Ausführung aller Threads mit ausstehendem Commit, die sich bereits in der Vorbereitungsphase befinden, auf dem Replikat, ohne die Konsistenz zu verletzen. Er gilt für Aurora MySQL Version 3. In Aurora MySQL Version 3.03.\$1 und niedriger ist der Standardwert DATABASE. In Aurora MySQL Version 3.04.\$1 und höher ist der Standardwert LOGICAL\$1CLOCK. | | `replica_preserve_commit_order` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `replica_transaction_retries` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `replica_type_conversions` | Ja | Dieser Parameter bestimmt die Typkonvertierungen, die für Replikate verwendet werden. Die zulässigen Werte sind `ALL_LOSSY`, `ALL_NON_LOSSY`, `ALL_SIGNED` und `ALL_UNSIGNED`. Weitere Informationen finden Sie in der MySQL-Dokumentation unter [Replication with Differing Table Definitions on Source and Replica](https://dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html). Dieser Parameter gilt für Aurora MySQL Version 3. | | `replicate-do-db` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `replicate-do-table` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `replicate-ignore-db` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `replicate-ignore-table` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `replicate-wild-do-table` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `replicate-wild-ignore-table` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `require_secure_transport` | Ja | Dieser Parameter gilt für Aurora MySQL Version 2 und 3. Weitere Informationen finden Sie unter [TLS-Verbindungen mit DB-Clustern von Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL). | | `rpl_read_size` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `server_audit_cw_upload` | Nein | Dieser Parameter wurde in Aurora MySQL als veraltet gekennzeichnet. Verwenden Sie `server_audit_logs_upload`. Weitere Informationen finden Sie unter [Veröffentlichen von Amazon Aurora MySQL-Protokollen in Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). | | `server_audit_events` | Ja | Weitere Informationen finden Sie unter [Verwenden von Advanced Auditing in einem Amazon Aurora MySQL DB-Cluster](AuroraMySQL.Auditing.md). | | `server_audit_excl_users` | Ja | Weitere Informationen finden Sie unter [Verwenden von Advanced Auditing in einem Amazon Aurora MySQL DB-Cluster](AuroraMySQL.Auditing.md). | | `server_audit_incl_users` | Ja | Weitere Informationen finden Sie unter [Verwenden von Advanced Auditing in einem Amazon Aurora MySQL DB-Cluster](AuroraMySQL.Auditing.md). | | `server_audit_logging` | Ja | Anweisungen zum Hochladen von Protokollen in Amazon CloudWatch Logs finden Sie unter [Veröffentlichen von Amazon Aurora MySQL-Protokollen in Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). | | `server_audit_logs_upload` | Ja | Sie können Prüfprotokolle in CloudWatch Logs veröffentlichen, indem Sie das erweiterte Auditing aktivieren und diesen Parameter auf `1` setzen. Der Standardwert für den Parameter `server_audit_logs_upload` ist `0`. Weitere Informationen finden Sie unter [Veröffentlichen von Amazon Aurora MySQL-Protokollen in Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). | | `server_id` | Nein | Keine | | `skip-character-set-client-handshake` | Ja | Keine | | `skip_name_resolve` | Nein | Keine | | `slave-skip-errors` | Ja | Gilt nur für Cluster der Aurora MySQL Version 2 mit MySQL-5.7-Kompatibilität. | | `source_verify_checksum` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `sync_frm` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `thread_cache_size` | Ja | Die Anzahl der Threads, die zwischengespeichert werden sollen. Dieser Parameter gilt für Aurora MySQL Version 2 und 3. | | `time_zone` | Ja | Standardmäßig ist die Zeitzone für einen Aurora-DB-Cluster auf die Universal Time Coordinated (UTC) eingestellt. Sie können die Zeitzone für Instances in Ihrem DB-Cluster stattdessen auf die lokale Zeitzone Ihrer Anwendung festlegen. Weitere Informationen finden Sie unter [Lokale Zeitzone für Amazon Aurora-DB-Cluster](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.LocalTimeZone). | | `tls_version` | Ja | Weitere Informationen finden Sie unter [TLS-Versionen für Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL.TLS_Version). | ## Parameter auf Instance-Ebene In der folgenden Tabelle werden alle Parameter aufgeführt, die für eine bestimmte DB-Instance in einem Aurora MySQL-DB-Cluster gelten. | Parametername | Anpassbar | Hinweise | | --- | --- | --- | | `activate_all_roles_on_login` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `allow-suspicious-udfs` | Nein | Keine | | `aurora_disable_hash_join` | Ja | Setzen Sie diesen Parameter auf `ON`, um die Hash-Join-Optimierung in Aurora MySQL Version 2.09 oder höher zu deaktivieren. Für Version 3 wird dies nicht unterstützt. Weitere Informationen finden Sie unter [Parallel Query für Amazon Aurora MySQL](aurora-mysql-parallel-query.md). | | `aurora_lab_mode` | Ja | Weitere Informationen finden Sie unter [Amazon Aurora MySQL-Labor-Modus](AuroraMySQL.Updates.LabMode.md). Aus Aurora-MySQL-Version 3 entfernt. | | `aurora_oom_response` | Ja | Dieser Parameter wird für die Aurora-MySQL-Versionen 2 und 3 unterstützt. Weitere Informationen finden Sie unter [Beheben von Speicherproblemen bei Aurora-MySQL-Datenbanken](AuroraMySQLOOM.md). | | `aurora_parallel_query` | Ja | Legen Sie dies auf `ON` fest, um parallele Abfragen in den Aurora-MySQL-Versionen 2.09 oder höher zu unterstützen. Der alte Parameter `aurora_pq` wird in diesen Versionen nicht verwendet. Weitere Informationen finden Sie unter [Parallel Query für Amazon Aurora MySQL](aurora-mysql-parallel-query.md). | | `aurora_pq` | Ja | Setzen Sie dies auf `OFF`, um parallele Abfragen für bestimmte DB-Instances in Aurora-MySQL-Versionen vor 2.09 zu deaktivieren. In den Versionen 2.09 oder höher aktivieren und deaktivieren Sie parallele Abfragen stattdessen mit `aurora_parallel_query`. Weitere Informationen finden Sie unter [Parallel Query für Amazon Aurora MySQL](aurora-mysql-parallel-query.md). | | `aurora_read_replica_read_committed` | Ja | Aktiviert die Isolationsstufe `READ COMMITTED` für Aurora Replicas und ändert das Isolationsverhalten zur Reduzierung der Bereinigungsverzögerung bei lang andauernden Abfragen. Aktivieren Sie diese Einstellung nur, wenn Sie die Verhaltensänderungen und deren Auswirkungen auf Ihre Abfrageergebnisse verstehen. Beispielsweise gehört dazu, dass diese Einstellung eine weniger strikte Isolation als der MySQL-Standard verwendet. Bei Aktivierung kann es sein, dass lang andauernde Abfragen mehr als eine Kopie derselben Zeile sehen, da Aurora die Tabellendaten umorganisiert, während die Abfrage läuft. Weitere Informationen finden Sie unter [Aurora MySQL-Isolierungsstufen](AuroraMySQL.Reference.IsolationLevels.md). | | `aurora_tmptable_enable_per_table_limit` | Ja | Bestimmt, ob der der Parameter `tmp_table_size` auch die maximale Größe temporärer Tabellen im Arbeitsspeicher steuert, die von der `TempTable`-Speicher-Engine in Aurora-MySQL-Version 3.04 und höher erstellt werden. Weitere Informationen finden Sie unter [Begrenzung der Größe interner temporärer Tabellen im Arbeitsspeicher](ams3-temptable-behavior.md#ams3-temptable-behavior-limit). | | `aurora_use_vector_instructions` | Ja | Wenn dieser Parameter aktiviert ist, verwendet Aurora MySQL optimierte Anweisungen zur Vektorverarbeitung, die von modernen CPUs bereitgestellt werden, um die Leistung bei I/O-intensiven Workloads zu verbessern. Diese Einstellung ist in Aurora MySQL Version 3.05 und höher standardmäßig aktiviert. | | `autocommit` | Ja | Keine | | `automatic_sp_privileges` | Ja | Keine | | `back_log` | Ja | Keine | | `basedir` | Nein | Aurora MySQL verwendet verwaltete Instances, bei denen Sie nicht direkt auf das Archivsystem zugreifen. | | `binlog_cache_size` | Ja | Keine | | `binlog_max_flush_queue_time` | Ja | Keine | | `binlog_order_commits` | Ja | Keine | | `binlog_stmt_cache_size` | Ja | Keine | | `binlog_transaction_compression` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `binlog_transaction_compression_level_zstd` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `bulk_insert_buffer_size` | Ja | Keine | | `concurrent_insert` | Ja | Keine | | `connect_timeout` | Ja | Keine | | `core-file` | Nein | Aurora MySQL verwendet verwaltete Instances, bei denen Sie nicht direkt auf das Archivsystem zugreifen. | | `datadir` | Nein | Aurora MySQL verwendet verwaltete Instances, bei denen Sie nicht direkt auf das Archivsystem zugreifen. | | `default_authentication_plugin` | Nein | Dieser Parameter gilt für Aurora MySQL Version 3. | | `default_time_zone` | Nein | Keine | | `default_tmp_storage_engine` | Ja | Die Standard-Speicher-Engine für temporäre Tabellen. | | `default_week_format` | Ja | Keine | | `delay_key_write` | Ja | Keine | | `delayed_insert_limit` | Ja | Keine | | `delayed_insert_timeout` | Ja | Keine | | `delayed_queue_size` | Ja | Keine | | `div_precision_increment` | Ja | Keine | | `end_markers_in_json` | Ja | Keine | | `eq_range_index_dive_limit` | Ja | Keine | | `event_scheduler` | Manchmal | Zeigt den Status des Ereignisplaners an. Modifizierbar nur auf Cluster-Ebene in Aurora-MySQL-Version 3. | | `explicit_defaults_for_timestamp` | Ja | Keine | | `flush` | Nein | Keine | | `flush_time` | Ja | Keine | | `ft_boolean_syntax` | Nein | Keine | | `ft_max_word_len` | Ja | Keine | | `ft_min_word_len` | Ja | Keine | | `ft_query_expansion_limit` | Ja | Keine | | `ft_stopword_file` | Ja | Keine | | `general_log` | Ja | Anweisungen zum Hochladen von Protokollen in CloudWatch Logs finden Sie unter [Veröffentlichen von Amazon Aurora MySQL-Protokollen in Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). | | `general_log_file` | Nein | Aurora MySQL verwendet verwaltete Instances, bei denen Sie nicht direkt auf das Archivsystem zugreifen. | | `group_concat_max_len` | Ja | Keine | | `host_cache_size` | Ja | Keine | | `init_connect` | Ja | Der Befehl, der vom Server für jeden Client ausgeführt wird, der eine Verbindung herstellt. Verwenden Sie doppelte Anführungszeichen („) für Einstellungen, um Verbindungsfehler zu vermeiden, zum Beispiel: 
SET optimizer_switch="hash_join=off"
Bei Aurora MySQL Version 3 gilt dieser Parameter nicht für Benutzer, die über die `CONNECTION_ADMIN`-Berechtigung verfügen. Weitere Informationen finden Sie unter [Rollenbasiertes Berechtigungsmodell](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). | | `innodb_adaptive_hash_index` | Ja | Sie können diesen Parameter auf DB-Instance-Ebene in Aurora MySLQ Version 2 ändern. In Aurora MySQL Version 3 kann er nur auf DB-Cluster-Ebene geändert werden. Der Adaptive-Hash-Index wird auf Reader-DB-Instances nicht unterstützt. | | `innodb_adaptive_max_sleep_delay` | Ja | Das Ändern dieses Parameters hat keine Auswirkung, da `innodb_thread_concurrency` für Aurora immer 0 ist. | | `innodb_aurora_max_partitions_for_range` | Ja | In einigen Fällen, in denen persistente Statistiken nicht verfügbar sind, können Sie diesen Parameter verwenden, um die Leistung von Schätzungen der Zeilenanzahl in partitionierten Tabellen zu verbessern. Sie können ihn auf einen Wert zwischen 0 und 8192 festlegen, wobei der Wert die Anzahl der Partitionen bestimmt, die bei der Schätzung der Zeilenanzahl überprüft werden sollen. Der Standardwert ist 0. Dieser entspricht der Schätzung, dass alle Partitionen verwendet werden, was mit dem Standardverhalten von MySQL übereinstimmt. Dieser Parameter ist für Aurora MySQL Version 3.03.1 verfügbar. | | `innodb_autoextend_increment` | Ja | Keine | | `innodb_buffer_pool_dump_at_shutdown` | Nein | Keine | | `innodb_buffer_pool_dump_now` | Nein | Keine | | `innodb_buffer_pool_filename` | Nein | Keine | | `innodb_buffer_pool_load_abort` | Nein | Keine | | `innodb_buffer_pool_load_at_startup` | Nein | Keine | | `innodb_buffer_pool_load_now` | Nein | Keine | | `innodb_buffer_pool_size` | Ja | Der Standardwert wird durch eine Formel dargestellt. Mehr über die Berechnung des `DBInstanceClassMemory`-Werts in der Formel erfahren Sie unter [DB-Parameter-Formel-Variablen](USER_ParamValuesRef.md#USER_FormulaVariables). | | `innodb_change_buffer_max_size` | Nein | Aurora MySQL verwendet den InnoDB-Änderungspuffer überhaupt nicht. | | `innodb_compression_failure_threshold_pct` | Ja | Keine | | `innodb_compression_level` | Ja | Keine | | `innodb_compression_pad_pct_max` | Ja | Keine | | `innodb_concurrency_tickets` | Ja | Das Ändern dieses Parameters hat keine Auswirkung, da `innodb_thread_concurrency` für Aurora immer 0 ist. | | `innodb_deadlock_detect` | Ja | Diese Option wird verwendet, um die Deadlock-Erkennung in Aurora-MySQL-Version 2.11 und höher sowie Version 3 zu deaktivieren. Auf Systemen mit hoher Parallelität kann die Deadlock-Erkennung zu einer Verlangsamung führen, wenn zahlreiche Threads auf dieselbe Sperre warten. Weitere Informationen zu diesem Parameter finden Sie in der MySQL-Dokumentation. | | `innodb_file_format` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `innodb_flushing_avg_loops` | Nein | Keine | | `innodb_force_load_corrupted` | Nein | Keine | | `innodb_ft_aux_table` | Ja | Keine | | `innodb_ft_cache_size` | Ja | Keine | | `innodb_ft_enable_stopword` | Ja | Keine | | `innodb_ft_server_stopword_table` | Ja | Keine | | `innodb_ft_user_stopword_table` | Ja | Keine | | `innodb_large_prefix` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `innodb_lock_wait_timeout` | Ja | Keine | | `innodb_log_compressed_pages` | Nein | Keine | | `innodb_lru_scan_depth` | Ja | Keine | | `innodb_max_purge_lag` | Ja | Keine | | `innodb_max_purge_lag_delay` | Ja | Keine | | `innodb_monitor_disable` | Ja | Keine | | `innodb_monitor_enable` | Ja | Keine | | `innodb_monitor_reset` | Ja | Keine | | `innodb_monitor_reset_all` | Ja | Keine | | `innodb_old_blocks_pct` | Ja | Keine | | `innodb_old_blocks_time` | Ja | Keine | | `innodb_open_files` | Ja | Keine | | `innodb_print_all_deadlocks` | Ja | Wenn dieser Parameter aktiviert ist, werden Informationen über alle InnoDB-Deadlocks im Fehlerprotokoll von Aurora MySQL aufgezeichnet. Weitere Informationen finden Sie unter [Minimieren und Beheben von Aurora-MySQL-Deadlocks](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks). | | `innodb_random_read_ahead` | Ja | Keine | | `innodb_read_ahead_threshold` | Ja | Keine | | `innodb_read_io_threads` | Nein | Keine | | `innodb_read_only` | Nein | Aurora MySQL verwaltet den Schreibschutz- und Lesen/Schreiben-Status von DB-Instances basierend auf dem Typ des Clusters. Ein bereitgestellter Cluster hat beispielsweise eine Lesen/Schreiben-DB-Instance (die *primäre Instance*). Alle anderen Instances im Cluster sind schreibgeschützt (die Aurora-Replicas). | | `innodb_replication_delay` | Ja | Keine | | `innodb_sort_buffer_size` | Ja | Keine | | `innodb_stats_auto_recalc` | Ja | Keine | | `innodb_stats_method` | Ja | Keine | | `innodb_stats_on_metadata` | Ja | Keine | | `innodb_stats_persistent` | Ja | Keine | | `innodb_stats_persistent_sample_pages` | Ja | Keine | | `innodb_stats_transient_sample_pages` | Ja | Keine | | `innodb_thread_concurrency` | Nein | Keine | | `innodb_thread_sleep_delay` | Ja | Das Ändern dieses Parameters hat keine Auswirkung, da `innodb_thread_concurrency` für Aurora immer 0 ist. | | `interactive_timeout` | Ja | Aurora wertet den Mindestwert von `interactive_timeout` und `wait_timeout` aus. Dieses Minimum wird dann als Timeout verwendet, um alle inaktiven Sitzungen, sowohl interaktive als auch nicht interaktive, zu beenden. | | `internal_tmp_disk_storage_engine` | Ja | Steuert, welche In-Memory-Speicher-Engine für interne temporäre Tabellen verwendet wird. Zulässige Werte sind `INNODB` und `MYISAM`. Dieser Parameter gilt für Aurora MySQL Version 2. | | `internal_tmp_mem_storage_engine` | Manchmal | Steuert, welche In-Memory-Speicher-Engine für interne temporäre Tabellen verwendet wird. Zulässige Werte für Schreiber-DB-Instances sind `MEMORY` und`TempTable`. Für Leser-DB-Instances ist dieser Parameter auf `TempTable` gesetzt und kann nicht geändert werden. Dieser Parameter gilt für Aurora MySQL Version 3. | | `join_buffer_size` | Ja | Keine | | `keep_files_on_create` | Ja | Keine | | `key_buffer_size` | Ja | Schlüssel-Cache für MyISAM-Tabellen. Weitere Informationen finden Sie unter [keycache->cache\$1lock mutex](AuroraMySQL.Reference.Waitevents.md#key-cache.cache-lock). | | `key_cache_age_threshold` | Ja | Keine | | `key_cache_block_size` | Ja | Keine | | `key_cache_division_limit` | Ja | Keine | | `local_infile` | Ja | Keine | | `lock_wait_timeout` | Ja | Keine | | `log-bin` | Nein | Wenn die Einstellung `binlog_format` auf `STATEMENT`, `MIXED` oder `ROW` gesetzt wird, wird `log-bin` automatisch auf `ON` festgelegt. Wenn die Einstellung `binlog_format` auf `OFF` gesetzt wird, wird `log-bin` automatisch auf `OFF` gesetzt. Weitere Informationen finden Sie unter [Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)](AuroraMySQL.Replication.MySQL.md). | | `log_bin_trust_function_creators` | Ja | Keine | | `log_bin_use_v1_row_events` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `log_error` | Nein | Keine | | `log_error_suppression_list` | Ja | Gibt eine Liste von Fehlercodes an, die nicht im MySQL-Fehlerprotokoll protokolliert werden. Auf diese Weise können Sie bestimmte unkritische Fehlerbedingungen ignorieren, um Ihre Fehlerprotokolle sauber zu halten. Weitere Informationen finden Sie unter [log\$1error\$1suppression\$1list](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list) in der MySQL-Dokumentation. Dieser Parameter gilt für Aurora-MySQL-Version 3.03 und höher. | | `log_output` | Ja | Keine | | `log_queries_not_using_indexes` | Ja | Keine | | `log_slave_updates` | Nein | Aurora-MySQL-Version 2. Verwenden Sie `log_replica_updates` in Aurora-MySQL-Version 3. | | `log_replica_updates` | Nein | Aurora-MySQL-Version 3 | | `log_throttle_queries_not_using_indexes` | Ja | Keine | | `log_warnings` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `long_query_time` | Ja | Keine | | `low_priority_updates` | Ja | `INSERT`-, `UPDATE`-, `DELETE`- und `LOCK TABLE WRITE`-Operationen warten, bis kein ausstehender `SELECT`-Vorgang mehr vorhanden ist. Dieser Parameter wirkt sich nur auf Speicher-Engines aus, die ausschließlich Sperren auf Tabellenebene verwenden (MyISAM, MEMORY, MERGE). Dieser Parameter gilt für Aurora MySQL Version 3. | | `max_allowed_packet` | Ja | Keine | | `max_binlog_cache_size` | Ja | Keine | | `max_binlog_size` | Nein | Keine | | `max_binlog_stmt_cache_size` | Ja | Keine | | `max_connect_errors` | Ja | Keine | | `max_connections` | Ja | Der Standardwert wird durch eine Formel dargestellt. Mehr über die Berechnung des `DBInstanceClassMemory`-Werts in der Formel erfahren Sie unter [DB-Parameter-Formel-Variablen](USER_ParamValuesRef.md#USER_FormulaVariables). Informationen zu den Standardwerten in Abhängigkeit von der Instance-Klasse finden Sie unter [Maximale Verbindungen zu einer Aurora MySQL-DB-Instance](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.MaxConnections). | | `max_delayed_threads` | Ja | Legt die maximale Anzahl von Threads für die Verarbeitung von `INSERT DELAYED`-Anweisungen fest. Dieser Parameter gilt für Aurora MySQL Version 3. | | `max_error_count` | Ja | Die maximale Anzahl von Fehler-, Warn- und Hinweismeldungen, die für die Anzeige gespeichert werden sollen. Dieser Parameter gilt für Aurora MySQL Version 3. | | `max_execution_time` | Ja | Das Timeout für die Ausführung von `SELECT`-Anweisungen in Millisekunden. Der Wert kann zwischen `0` und `18446744073709551615` liegen. Wenn auf `0` eingestellt, gibt es kein Timeout. Weitere Informationen finden Sie unter [max\$1execution\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_execution_time) in der MySQL-Dokumentation. | | `max_heap_table_size` | Ja | Keine | | `max_insert_delayed_threads` | Ja | Keine | | `max_join_size` | Ja | Keine | | `max_length_for_sort_data` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `max_prepared_stmt_count` | Ja | Keine | | `max_seeks_for_key` | Ja | Keine | | `max_sort_length` | Ja | Keine | | `max_sp_recursion_depth` | Ja | Keine | | `max_tmp_tables` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `max_user_connections` | Ja | Keine | | `max_write_lock_count` | Ja | Keine | | `metadata_locks_cache_size` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `min_examined_row_limit` | Ja | Verwenden Sie diesen Parameter, um zu verhindern, dass Abfragen, die weniger als die angegebene Anzahl von Zeilen untersuchen, protokolliert werden. Dieser Parameter gilt für Aurora MySQL Version 3. | | `myisam_data_pointer_size` | Ja | Keine | | `myisam_max_sort_file_size` | Ja | Keine | | `myisam_mmap_size` | Ja | Keine | | `myisam_sort_buffer_size` | Ja | Keine | | `myisam_stats_method` | Ja | Keine | | `myisam_use_mmap` | Ja | Keine | | `net_buffer_length` | Ja | Keine | | `net_read_timeout` | Ja | Keine | | `net_retry_count` | Ja | Keine | | `net_write_timeout` | Ja | Keine | | `old-style-user-limits` | Ja | Keine | | `old_passwords` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `optimizer_prune_level` | Ja | Keine | | `optimizer_search_depth` | Ja | Keine | | `optimizer_switch` | Ja | Weitere Informationen zu Aurora MySQL-Features, die diesen Schalter verwenden, finden Sie unter [Bewährte Methoden mit Amazon Aurora MySQL](AuroraMySQL.BestPractices.md). | | `optimizer_trace` | Ja | Keine | | `optimizer_trace_features` | Ja | Keine | | `optimizer_trace_limit` | Ja | Keine | | `optimizer_trace_max_mem_size` | Ja | Keine | | `optimizer_trace_offset` | Ja | Keine | | `performance-schema-consumer-events-waits-current` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance-schema-consumer-events-waits-current`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance-schema-instrument` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance-schema-instrument`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema` | Ja | Wenn die Spalte **Quelle** auf `Modified` gesetzt ist, verwaltet Performance Insights das Leistungsschema. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_accounts_size` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_accounts_size`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_global_instrumentation` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_consumer_global_instrumentation`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_thread_instrumentation` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_consumer_thread_instrumentation`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_stages_current` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_consumer_events_stages_current`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_stages_history` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_consumer_events_stages_history`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_stages_history_long` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_consumer_events_stages_history_long`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_statements_current` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_consumer_events_statements_current`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_statements_history` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_consumer_events_statements_history`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_statements_history_long` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_consumer_events_statements_history_long`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_waits_history` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_consumer_events_waits_history`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_waits_history_long` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_consumer_events_waits_history_long`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_statements_digest` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_consumer_statements_digest`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_digests_size` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_digests_size`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_stages_history_long_size` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_events_stages_history_long_size`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_stages_history_size` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_events_stages_history_size`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_statements_history_long_size` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_events_statements_history_long_size`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_statements_history_size` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_events_statements_history_size`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_transactions_history_long_size` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_events_transactions_history_long_size`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_transactions_history_size` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_events_transactions_history_size`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_waits_history_long_size` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_events_waits_history_long_size`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_waits_history_size` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_events_waits_history_size`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_hosts_size` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_hosts_size`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_cond_classes` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_cond_classes`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_cond_instances` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_cond_instances`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_digest_length` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_digest_length`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_file_classes` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_file_classes`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_file_handles` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_file_handles`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_file_instances` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_file_instances`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_index_stat` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_index_stat`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_memory_classes` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_memory_classes`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_metadata_locks` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_metadata_locks`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_mutex_classes` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_mutex_classes`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_mutex_instances` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_mutex_instances`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_prepared_statements_instances` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_prepared_statements_instances`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_program_instances` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_program_instances`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_rwlock_classes` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_rwlock_classes`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_rwlock_instances` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_rwlock_instances`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_socket_classes` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_socket_classes`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_socket_instances` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_socket_instances`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_sql_text_length` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_sql_text_length`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_stage_classes` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_stage_classes`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_statement_classes` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_statement_classes`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_statement_stack` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_statement_stack`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_table_handles` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_table_handles`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_table_instances` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_table_instances`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_table_lock_stat` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_table_lock_stat`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_thread_classes` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_thread_classes`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_thread_instances` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_max_thread_instances`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_session_connect_attrs_size` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_session_connect_attrs_size`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_setup_actors_size` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_setup_actors_size`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_setup_objects_size` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_setup_objects_size`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_show_processlist` | Ja | Dieser Parameter bestimmt, welche SHOW PROCESSLIST-Implementierung verwendet werden soll: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html)Dieser Parameter gilt für Aurora-MySQL-Version 2.12 und höher sowie Version 3. Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_show_processlist`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_users_size` | Ja | Wenn die Spalte **Quelle** für den Parameter `performance_schema` auf `Modified` gesetzt ist, verwendet das Leistungsschema den Parameter `performance_schema_users_size`. Weitere Informationen zum Aktivieren des Leistungsschemas finden Sie unter [Feststellen, ob Performance Insights das Leistungsschema verwaltet](USER_PerfInsights.EnableMySQL.determining-status.md). | | `pid_file` | Nein | Keine | | `plugin_dir` | Nein | Aurora MySQL verwendet verwaltete Instances, bei denen Sie nicht direkt auf das Archivsystem zugreifen. | | `port` | Nein | Aurora MySQL verwaltet die Verbindungseigenschaften und erzwingt konsistente Einstellungen für alle DB-Instances in einem Cluster. | | `preload_buffer_size` | Ja | Die Größe des Puffers, der beim Vorabladen von Indizes zugewiesen wird. Dieser Parameter gilt für Aurora MySQL Version 3. | | `profiling_history_size` | Ja | Keine | | `query_alloc_block_size` | Ja | Keine | | `query_cache_limit` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `query_cache_min_res_unit` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `query_cache_size` | Ja | Der Standardwert wird durch eine Formel dargestellt. Mehr über die Berechnung des `DBInstanceClassMemory`-Werts in der Formel erfahren Sie unter [DB-Parameter-Formel-Variablen](USER_ParamValuesRef.md#USER_FormulaVariables). Aus Aurora-MySQL-Version 3 entfernt. | | `query_cache_type` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `query_cache_wlock_invalidate` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `query_prealloc_size` | Ja | Keine | | `range_alloc_block_size` | Ja | Keine | | `read_buffer_size` | Ja | Keine | | `read_only` | Ja | Wenn dieser Parameter aktiviert ist, erlaubt der Server nur Aktualisierungen, die von Replikat-Threads durchgeführt werden. Für Aurora-MySQL-Version 2 sind die folgenden Werte gültig: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Wir empfehlen, die DB-Cluster-Parametergruppe in Aurora MySQL Version 2 zu verwenden, um sicherzustellen, dass der `read_only`-Parameter beim Failover auf neue Writer-Instances angewendet wird. Reader-Instances sind immer schreibgeschützt, da Aurora MySQL `innodb_read_only` für alle Reader auf `1` festlegt. Daher ist `read_only` auf Reader-Instances redundant. Auf Instance-Ebene aus Aurora MySQL Version 3 entfernt. | | `read_rnd_buffer_size` | Ja | Keine | | `relay-log` | Nein | Keine | | `relay_log_info_repository` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `relay_log_recovery` | Nein | Keine | | `replica_checkpoint_group` | Ja | Aurora-MySQL-Version 3 | | `replica_checkpoint_period` | Ja | Aurora-MySQL-Version 3 | | `replica_parallel_workers` | Ja | Aurora-MySQL-Version 3 | | `replica_pending_jobs_size_max` | Ja | Aurora-MySQL-Version 3 | | `replica_skip_errors` | Ja | Aurora-MySQL-Version 3 | | `replica_sql_verify_checksum` | Ja | Aurora-MySQL-Version 3 | | `safe-user-create` | Ja | Keine | | `secure_auth` | Ja | Dieser Parameter ist in Aurora-MySQL-Version 2 immer aktiviert. Der Versuch, ihn zu deaktivieren, generiert einen Fehler. Aus Aurora-MySQL-Version 3 entfernt. | | `secure_file_priv` | Nein | Aurora MySQL verwendet verwaltete Instances, bei denen Sie nicht direkt auf das Archivsystem zugreifen. | | `show_create_table_verbosity` | Ja | Wenn diese Variable aktiviert wird, zeigt [SHOW\$1CREATE\$1TABLE](https://dev.mysql.com/doc/refman/5.7/en/show-create-table.html) das `ROW_FORMAT` unabhängig davon an, ob es das Standardformat ist. Dieser Parameter gilt für Aurora-MySQL-Version 2.12 und höher sowie Version 3. | | `skip-slave-start` | Nein | Keine | | `skip_external_locking` | Nein | Keine | | `skip_show_database` | Ja | Keine | | `slave_checkpoint_group` | Ja | Aurora-MySQL-Version 2. Verwenden Sie `replica_checkpoint_group` in Aurora-MySQL-Version 3. | | `slave_checkpoint_period` | Ja | Aurora-MySQL-Version 2. Verwenden Sie `replica_checkpoint_period` in Aurora-MySQL-Version 3. | | `slave_parallel_workers` | Ja | Aurora-MySQL-Version 2. Verwenden Sie `replica_parallel_workers` in Aurora-MySQL-Version 3. | | `slave_pending_jobs_size_max` | Ja | Aurora-MySQL-Version 2. Verwenden Sie `replica_pending_jobs_size_max` in Aurora-MySQL-Version 3. | | `slave_sql_verify_checksum` | Ja | Aurora-MySQL-Version 2. Verwenden Sie `replica_sql_verify_checksum` in Aurora-MySQL-Version 3. | | `slow_launch_time` | Ja | Keine | | `slow_query_log` | Ja | Anweisungen zum Hochladen von Protokollen in CloudWatch Logs finden Sie unter [Veröffentlichen von Amazon Aurora MySQL-Protokollen in Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). | | `slow_query_log_file` | Nein | Aurora MySQL verwendet verwaltete Instances, bei denen Sie nicht direkt auf das Archivsystem zugreifen. | | `socket` | Nein | Keine | | `sort_buffer_size` | Ja | Keine | | `sql_mode` | Ja | Keine | | `sql_select_limit` | Ja | Keine | | `stored_program_cache` | Ja | Keine | | `sync_binlog` | Nein | Keine | | `sync_master_info` | Ja | Keine | | `sync_source_info` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. | | `sync_relay_log` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `sync_relay_log_info` | Ja | Keine | | `sysdate-is-now` | Ja | Keine | | `table_cache_element_entry_ttl` | Nein | Keine | | `table_definition_cache` | Ja | Der Standardwert wird durch eine Formel dargestellt. Mehr über die Berechnung des `DBInstanceClassMemory`-Werts in der Formel erfahren Sie unter [DB-Parameter-Formel-Variablen](USER_ParamValuesRef.md#USER_FormulaVariables). | | `table_open_cache` | Ja | Der Standardwert wird durch eine Formel dargestellt. Mehr über die Berechnung des `DBInstanceClassMemory`-Werts in der Formel erfahren Sie unter [DB-Parameter-Formel-Variablen](USER_ParamValuesRef.md#USER_FormulaVariables). | | `table_open_cache_instances` | Ja | Keine | | `temp-pool` | Ja | Aus Aurora-MySQL-Version 3 entfernt. | | `temptable_max_mmap` | Ja | Dieser Parameter gilt für Aurora-MySQL-Version 3. Details hierzu finden Sie unter [Neues temporäres Tabellenverhalten in Aurora-MySQL-Version 3](ams3-temptable-behavior.md). | | `temptable_max_ram` | Ja | Dieser Parameter gilt für Aurora-MySQL-Version 3. Details hierzu finden Sie unter [Neues temporäres Tabellenverhalten in Aurora-MySQL-Version 3](ams3-temptable-behavior.md). | | `temptable_use_mmap` | Ja | Dieser Parameter gilt für Aurora-MySQL-Version 3. Details hierzu finden Sie unter [Neues temporäres Tabellenverhalten in Aurora-MySQL-Version 3](ams3-temptable-behavior.md). | | `thread_cache_size` | Ja | Die Anzahl der Threads, die zwischengespeichert werden sollen. Dieser Parameter gilt für Aurora MySQL Version 2 und 3. | | `thread_handling` | Nein | Keine | | `thread_stack` | Ja | Keine | | `timed_mutexes` | Ja | Keine | | `tmp_table_size` | Ja | Definiert die maximale Größe temporärer Tabellen, die von der `MEMORY`-Speicher-Engine in Aurora-MySQL-Version 3 erstellt werden. Definiert in Aurora-MySQL-Version 3.04 und höher die maximale Größe temporärer Tabellen im Arbeitsspeicher, die von der `TempTable`-Speicher-Engine erstellt werden, wenn `aurora_tmptable_enable_per_table_limit` auf `ON` festgelegt ist. Weitere Informationen finden Sie unter [Begrenzung der Größe interner temporärer Tabellen im Arbeitsspeicher](ams3-temptable-behavior.md#ams3-temptable-behavior-limit). | | `tmpdir` | Nein | Aurora MySQL verwendet verwaltete Instances, bei denen Sie nicht direkt auf das Archivsystem zugreifen. | | `transaction_alloc_block_size` | Ja | Keine | | `transaction_isolation` | Ja | Dieser Parameter gilt für Aurora MySQL Version 3. Er ersetzt `tx_isolation`. | | `transaction_prealloc_size` | Ja | Keine | | `tx_isolation` | Ja | Aus Aurora-MySQL-Version 3 entfernt. Es wird durch `transaction_isolation` ersetzt. | | `updatable_views_with_limit` | Ja | Keine | | `validate-password` | Nein | Keine | | `validate_password_dictionary_file` | Nein | Keine | | `validate_password_length` | Nein | Keine | | `validate_password_mixed_case_count` | Nein | Keine | | `validate_password_number_count` | Nein | Keine | | `validate_password_policy` | Nein | Keine | | `validate_password_special_char_count` | Nein | Keine | | `wait_timeout` | Ja | Aurora wertet den Mindestwert von `interactive_timeout` und `wait_timeout` aus. Dieses Minimum wird dann als Timeout verwendet, um alle inaktiven Sitzungen, sowohl interaktive als auch nicht interaktive, zu beenden. | ## MySQL-Parameter, die nicht auf Aurora MySQL zutreffen Aufgrund von Architekturunterschieden zwischen Aurora MySQL und MySQL gelten einige MySQL-Parameter nicht für Aurora MySQL. Die folgenden MySQL-Parameter gelten nicht für Aurora MySQL. Diese Liste ist nicht umfassend. + `activate_all_roles_on_login` – Dieser Parameter gilt nicht für Aurora-MySQL-Version 2. Er ist in Aurora-MySQL-Version 3 verfügbar. + `big_tables` + `bind_address` + `character_sets_dir` + `innodb_adaptive_flushing` + `innodb_adaptive_flushing_lwm` + `innodb_buffer_pool_chunk_size` + `innodb_buffer_pool_instances` + `innodb_change_buffering` + `innodb_checksum_algorithm` + `innodb_data_file_path` + `innodb_dedicated_server` + `innodb_doublewrite` + `innodb_flush_log_at_timeout`: Dieser Parameter gilt nicht für Aurora MySQL. Weitere Informationen finden Sie unter [Konfigurieren, wie oft der Protokollpuffer geleert wird](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush). + `innodb_flush_method` + `innodb_flush_neighbors` + `innodb_io_capacity` + `innodb_io_capacity_max` + `innodb_log_buffer_size` + `innodb_log_file_size` + `innodb_log_files_in_group` + `innodb_log_spin_cpu_abs_lwm` + `innodb_log_spin_cpu_pct_hwm` + `innodb_log_writer_threads` + `innodb_max_dirty_pages_pct` + `innodb_numa_interleave` + `innodb_page_size` + `innodb_redo_log_capacity` + `innodb_redo_log_encrypt` + `innodb_undo_log_encrypt` + `innodb_undo_log_truncate` + `innodb_undo_logs` + `innodb_undo_tablespaces` + `innodb_use_native_aio` + `innodb_write_io_threads` # Globale Statusvariablen von Aurora MySQL Aurora MySQL enthält Statusvariablen aus Community-MySQL und Variablen, die es nur bei Aurora gibt. Sie können diese Variablen untersuchen, um zu erfahren, was in der Datenbank-Engine passiert. Weitere Informationen zu den Statusvariablen in Community-MySQL finden Sie unter [Serverstatusvariablen](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html) in der Community-MySQL-8.0-Dokumentation. Sie können die aktuellen Werte für die globalen Statusvariablen von Aurora MySQL mithilfe einer Anweisung wie den folgenden ermitteln: ``` show global status like '%aurora%'; ``` **Anmerkung** Globale Statusvariablen werden gelöscht, wenn die DB-Engine neu gestartet wird. In der folgenden Tabelle werden die globalen Statusvariablen beschrieben, die Aurora MySQL verwendet. | Name | Description | | --- | --- | | `AuroraDb_commits` | Die Gesamtzahl der Commits seit dem letzten Neustart. | | `AuroraDb_commit_latency` | Die aggregierte Commit-Latenz seit dem letzten Neustart. | | `AuroraDb_ddl_stmt_duration` | Die aggregierte DDL-Latenz seit dem letzten Neustart. | | `AuroraDb_select_stmt_duration` | Die aggregierte `SELECT`-Anweisungslatenz seit dem letzten Neustart. | | `AuroraDb_insert_stmt_duration` | Die aggregierte `INSERT`-Anweisungslatenz seit dem letzten Neustart. | | `AuroraDb_update_stmt_duration` | Die aggregierte `UPDATE`-Anweisungslatenz seit dem letzten Neustart. | | `AuroraDb_delete_stmt_duration` | Die aggregierte `DELETE`-Anweisungslatenz seit dem letzten Neustart. | | `Aurora_binlog_io_cache_allocated` | Die Anzahl der Byte, die dem I/O Binlog-Cache zugewiesen sind. | | `Aurora_binlog_io_cache_read_requests` | Die Anzahl der Leseanforderungen an den I/O Binlog-Cache. | | `Aurora_binlog_io_cache_reads` | Die Anzahl der Leseanforderungen, die vom I/O Binlog-Cache aus bedient wurden. | | `Aurora_enhanced_binlog` | Gibt an, ob das erweiterte Binärprotokoll für diese DB-Instance aktiviert oder deaktiviert ist. Weitere Informationen finden Sie unter [Einrichten eines erweiterten Binärprotokolls für Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). | | `Aurora_external_connection_count` | Die Anzahl der Datenbankverbindungen mit der DB-Instance, ausgenommen RDS-Serviceverbindungen, die für Datenbankzustandsprüfungen verwendet werden. | | `Aurora_fast_insert_cache_hits` | Ein Zähler, der erhöht wird, wenn der zwischengespeicherte Cursor erfolgreich abgerufen und bestätigt wurde. Weitere Informationen zum Cache für schnelles Einfügen finden Sie unter [Amazon Aurora MySQL-Leistungserweiterungen](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance). | | `Aurora_fast_insert_cache_misses` | Ein Zähler, der erhöht wird, wenn der zwischengespeicherte Cursor nicht mehr gültig ist und Aurora einen normalen Index-Durchlauf durchführt. Weitere Informationen zum Cache für schnelles Einfügen finden Sie unter [Amazon Aurora MySQL-Leistungserweiterungen](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance). | | `Aurora_fts_cache_memory_used` | Die Speichermenge in Byte, die das InnoDB-Volltextsuchsystem verwendet. Diese Variable gilt für Aurora-MySQL-Version 3.07 und höher. | | `Aurora_fwd_master_dml_stmt_count` | Die Gesamtzahl der DML-Anweisungen, die an diese Schreiber-DB-Instance weitergeleitet werden. Diese Variable gilt für Aurora-MySQL-Version 2. | | `Aurora_fwd_master_dml_stmt_duration` | Die Gesamtdauer der DML-Anweisungen, die an diese Writer-DB-Instance weitergeleitet werden. Diese Variable gilt für Aurora-MySQL-Version 2. | | `Aurora_fwd_master_errors_rpc_timeout` | Gibt an, wie oft eine weitergeleitete Verbindung nicht auf dem Writer hergestellt werden konnte. | | `Aurora_fwd_master_errors_session_limit` | Die Anzahl der weitergeleiteten Abfragen, die aufgrund von `session full` auf dem Writer abgelehnt werden. | | `Aurora_fwd_master_errors_session_timeout` | Die Angabe, wie oft eine Weiterleitungssitzung aufgrund eines Timeouts auf dem Writer beendet wird. | | `Aurora_fwd_master_open_sessions` | Die Anzahl der weitergeleiteten Sitzungen auf der Writer-DB-Instance. Diese Variable gilt für Aurora-MySQL-Version 2. | | `Aurora_fwd_master_select_stmt_count` | Die Gesamtzahl der `SELECT`-Anweisungen, die an diese Schreiber-DB-Instance weitergeleitet werden. Diese Variable gilt für Aurora-MySQL-Version 2. | | `Aurora_fwd_master_select_stmt_duration` | Die Gesamtdauer der `SELECT`-Anweisungen, die an diese Schreiber-DB-Instance weitergeleitet werden. Diese Variable gilt für Aurora-MySQL-Version 2. | | `Aurora_fwd_writer_dml_stmt_count` | Die Gesamtzahl der DML-Anweisungen, die an diese Writer-DB-Instance weitergeleitet werden. Diese Variable gilt für Aurora-MySQL-Version 3. | | `Aurora_fwd_writer_dml_stmt_duration` | Die Gesamtdauer der DML-Anweisungen, die an diese Writer-DB-Instance weitergeleitet werden. Diese Variable gilt für Aurora-MySQL-Version 3. | | `Aurora_fwd_writer_errors_rpc_timeout` | Gibt an, wie oft eine weitergeleitete Verbindung nicht auf dem Writer hergestellt werden konnte. | | `Aurora_fwd_writer_errors_session_limit` | Die Anzahl der weitergeleiteten Abfragen, die aufgrund von `session full` auf dem Writer abgelehnt werden. | | `Aurora_fwd_writer_errors_session_timeout` | Die Angabe, wie oft eine Weiterleitungssitzung aufgrund eines Timeouts auf dem Writer beendet wird. | | `Aurora_fwd_writer_open_sessions` | Die Anzahl der weitergeleiteten Sitzungen auf der Writer-DB-Instance. Diese Variable gilt für Aurora-MySQL-Version 3. | | `Aurora_fwd_writer_select_stmt_count` | Die Gesamtzahl der `SELECT`-Anweisungen, die an diese Writer-DB-Instance weitergeleitet werden. Diese Variable gilt für Aurora-MySQL-Version 3. | | `Aurora_fwd_writer_select_stmt_duration` | Die Gesamtdauer der `SELECT`-Anweisungen, die an diese Writer-DB-Instance weitergeleitet werden. Diese Variable gilt für Aurora-MySQL-Version 3. | | `Aurora_lockmgr_buffer_pool_memory_used` | Die Menge an Pufferpoolspeicher in Byte, die der Aurora MySQL Lock Manager verwendet. | | `Aurora_lockmgr_memory_used` | Die Speichermenge in Byte, die der Aurora MySQL Lock Manager verwendet. | | `Aurora_ml_actual_request_cnt` | Die aggregierte Anzahl der Anfragen, die Aurora My SQLmakes an die Aurora-Machine-Learning-Dienste sendet, über alle Abfragen hinweg, die von Benutzern der DB-Instance ausgeführt werden. Weitere Informationen finden Sie unter [Verwendung von Amazon Aurora Machine Learning mit Aurora MySQL](mysql-ml.md). | | `Aurora_ml_actual_response_cnt` | Die aggregierte Zahl der Antworten, die Aurora MySQL von den Machine-Learning-Services von Aurora über alle von Benutzern der DB-Instance durchgeführten Abfragen hinweg erhält. Weitere Informationen finden Sie unter [Verwendung von Amazon Aurora Machine Learning mit Aurora MySQL](mysql-ml.md). | | `Aurora_ml_cache_hit_cnt` | Die aggregierte Zahl der internen Cache-Treffer, die Aurora MySQL von den Machine-Learning-Services von Aurora über alle von Benutzern der DB-Instance durchgeführten Abfragen hinweg erhält. Weitere Informationen finden Sie unter [Verwendung von Amazon Aurora Machine Learning mit Aurora MySQL](mysql-ml.md). | | `Aurora_ml_logical_request_cnt` | Die Anzahl der logischen Anfragen, die die DB-Instance seit dem letzten Status-Reset zum Senden an die Aurora-Machine-Learning-Services ausgewertet hat. Je nachdem, ob Stapelverarbeitung verwendet wurde, kann dieser Wert höher sein als `Aurora_ml_actual_request_cnt`. Weitere Informationen finden Sie unter [Verwendung von Amazon Aurora Machine Learning mit Aurora MySQL](mysql-ml.md). | | `Aurora_ml_logical_response_cnt` | Die aggregierte Zahl der Antworten, die Aurora MySQL von den Machine-Learning-Services von Aurora über alle von Benutzern der DB-Instance durchgeführten Abfragen hinweg erhält. Weitere Informationen finden Sie unter [Verwendung von Amazon Aurora Machine Learning mit Aurora MySQL](mysql-ml.md). | | `Aurora_ml_retry_request_cnt` | Die Anzahl der wiederholten Anfragen, die die DB-Instance seit dem letzten Status-Reset an die Aurora-Machine-Learning-Services gesendet hat. Weitere Informationen finden Sie unter [Verwendung von Amazon Aurora Machine Learning mit Aurora MySQL](mysql-ml.md). | | `Aurora_ml_single_request_cnt` | Die aggregierte Zahl der Machine-Learning-Funktionen von Aurora, die im Nicht-Batch-Modus über alle von Benutzern der DB-Instance durchgeführten Abfragen hinweg evaluiert werden. Weitere Informationen finden Sie unter [Verwendung von Amazon Aurora Machine Learning mit Aurora MySQL](mysql-ml.md). | | `aurora_oom_avoidance_recovery_state` | Gibt an, ob sich Aurora out-of-memory (OOM) Avoidance Recovery für diese DB-Instance im `INACTIVE` Status `ACTIVE` oder befindet. Diese Variable gilt für Aurora-MySQL-Version 3.06.0 und höher. | | `aurora_oom_reserved_mem_enter_kb` | Stellt den Schwellenwert für den Eintritt in den `RESERVED`-Status im Mechanismus zur Behandlung eines Speichermangels von Aurora dar. Wenn der verfügbare Speicher auf dem Server unter diesen Schwellenwert fällt, ändert sich der `aurora_oom_status` in `RESERVED`, was darauf hinweist, dass sich der Server einem kritischen Speicherverbrauchsniveau nähert. Diese Variable gilt für Aurora-MySQL-Version 3.06.0 und höher. | | `aurora_oom_reserved_mem_exit_kb` | Stellt den Schwellenwert für den Austritt aus dem `RESERVED`-Status im Mechanismus zur Behandlung eines Speichermangels von Aurora dar. Wenn der verfügbare Speicher auf dem Server über diesen Schwellenwert steigt, kehrt der `aurora_oom_status` zu `NORMAL` zurück, was bedeutet, dass der Server in einen stabileren Zustand mit ausreichenden Speicherressourcen zurückgekehrt ist. Diese Variable gilt für Aurora-MySQL-Version 3.06.0 und höher. | | `aurora_oom_status` | Stellt den aktuellen Status eines Speichermangels dieser DB-Instance dar. Wenn der Wert `NORMAL` lautet, bedeutet dies, dass ausreichend Speicherressourcen vorhanden sind. Ändert sich der Wert in `RESERVED`, bedeutet dies, dass der Server nur wenig verfügbaren Arbeitsspeicher hat. Die Aktionen werden auf der Grundlage der `aurora_oom_response`-Parameterkonfiguration ausgeführt. Weitere Informationen finden Sie unter [Beheben von Speicherproblemen bei Aurora-MySQL-Datenbanken](AuroraMySQLOOM.md). Diese Variable gilt für Aurora-MySQL-Version 3.06.0 und höher. | | `Aurora_pq_bytes_returned` | Die Anzahl der Bytes, die in Zusammenhang mit Tupel-Datenstrukturen während der Parallelabfragen an den Hauptknoten übertragen wurden. Für den Abgleich mit durch 16 348 teile `Aurora_pq_pages_pushed_down`. | | `Aurora_pq_max_concurrent_requests` | Die Höchstanzahl der Parallel Query-Sitzungen, die auf dieser Aurora-DB-Instance gleichzeitig ausgeführt werden können. Dies ist eine feste Zahl, die von der AWS DB-Instance-Klasse abhängt. | | `Aurora_pq_pages_pushed_down` | Die Anzahl der Datenseiten (jeweils fix 16 KiB groß), auf denen Parallel Query eine netzwerkgebundene Übertragung an den Hauptknoten verhindert hat. | | `Aurora_pq_request_attempted` | Die Anzahl der angeforderten Parallel Query-Sitzungen. Hinter diesem Wert können pro Abfrage mehrere Sitzungen stehen. Ausschlaggebend sind SQL-Konstrukte wie Unterabfragen und Join-Abfragen. | | `Aurora_pq_request_executed` | Die Anzahl der erfolgreich ausgeführten Parallel Query-Sitzungen. | | `Aurora_pq_request_failed` | Die Anzahl der Parallel Query-Sitzungen, die dem Client einen Fehler zurückgaben. Es kann vorkommen, dass eine angeforderte Parallelabfrage fehlschlägt – z. B. wegen eines Problems auf der Speicherschicht. In diesen Fällen wird der fehlgeschlagene Abfrageteil wiederholt. Dafür kommt der nicht-parallele Abfragemechanismus zum Einsatz. Wenn auch die wiederholte Abfrage fehlschlägt, wird dem Client ein Fehler zurückgegeben. Die Zähleranzeige erhöht sich. | | `Aurora_pq_request_in_progress` | Die Anzahl der derzeit in Ausführung befindlichen Parallel Query-Sitzungen. Die Zahl bezieht sich auf die angeschlossene Aurora-DB-Instance, mit der Sie verbunden sind, nicht auf das gesamte Aurora-DB-Cluster. Sie können prüfen, ob eine DB-Instance die Obergrenze für gleichzeitige Abfragen annähernd erreicht hat. Gleichen Sie dazu diesen Wert mit a `Aurora_pq_max_concurrent_requests`. | | `Aurora_pq_request_not_chosen` | Die Anzahl der Situationen, in denen Parallel Query nicht für die Abarbeitung einer Abfrage genutzt wurde. Dieser Wert setzt sich aus den Beiträgen mehrerer Zähler mit höherer Granularität zusammen. Die Zähleranzeige kann mit einer `EXPLAIN`-Anweisung erhöht werden, selbst wenn die Abfrage nicht tatsächlich ausgeführt wird. | | `Aurora_pq_request_not_chosen_below_min_rows` | Die Anzahl der Situationen, in denen die Anzahl der Tabellenzeilen der Grund für den Nichteinsatz von Parallel Query war. Die Zähleranzeige kann mit einer `EXPLAIN`-Anweisung erhöht werden, selbst wenn die Abfrage nicht tatsächlich ausgeführt wird. | | `Aurora_pq_request_not_chosen_column_bit` | Die Anzahl der Parallelabfrageanforderungen, die aufgrund eines nicht unterstützten Datentyps in der Liste der projizierten Spalten den nicht-parallelen Abfrageverarbeitungspfad nutzen. | | `Aurora_pq_request_not_chosen_column_geometry` | Die Anzahl der Parallelabfrageanforderungen, die den nicht-parallelen Abfrageverarbeitungspfad nutzen, da die Tabelle Spalten mit dem Datentyp `GEOMETRY` enthält. Informationen zu Aurora-MySQL-Versionen, die diese Einschränkung aufheben, finden Sie unter [Upgrade paralleler Abfrage-Cluster auf Aurora-MySQL-Version 3](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2). | | `Aurora_pq_request_not_chosen_column_lob` | Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Tabelle Spalten mit einem `LOB`-Datentyp enthält oder `VARCHAR`- Spalten, die aufgrund der deklarierten Länge extern gespeichert werden. Informationen zu Aurora-MySQL-Versionen, die diese Einschränkung aufheben, finden Sie unter [Upgrade paralleler Abfrage-Cluster auf Aurora-MySQL-Version 3](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2). | | `Aurora_pq_request_not_chosen_column_virtual` | Die Anzahl der Parallelabfrageanforderungen, die den nicht-parallelen Abfrageverarbeitungspfad nutzen, da die Tabelle eine virtuelle Spalte enthält. | | `Aurora_pq_request_not_chosen_custom_charset` | Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Tabelle Spalten mit einem benutzerdefinierten Zeichensatz enthält. | | `Aurora_pq_request_not_chosen_fast_ddl` | Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Tabelle zurzeit durch eine schnelle `ALTER`-DDL-Anweisung geändert wird. | | `Aurora_pq_request_not_chosen_few_pages_outside_buffer_pool` | Die Anzahl der Situationen, in denen Parallel Query nicht genutzt wurde, obwohl weniger als 95 Prozent der Tabellendaten im Bufferpool waren. Grund: Es gab zu wenig nicht gepufferte Tabellendaten. Eine Parallelabfrage lohnte sich deshalb nicht. | | `Aurora_pq_request_not_chosen_full_text_index` | Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Tabelle Volltextindizes enthält. | | `Aurora_pq_request_not_chosen_high_buffer_pool_pct` | Die Anzahl der Situationen, in denen Parallel Query nicht genutzt wurde, weil ein hoher Anteil der Tabellendaten (derzeit >95 Prozent) bereits im Bufferpool war. In diesen Fällen entscheidet der Optimierer, dass das Lesen der Daten aus dem Bufferpool effizienter ist. Die Zähleranzeige kann mit einer `EXPLAIN`-Anweisung erhöht werden, selbst wenn die Abfrage nicht tatsächlich ausgeführt wird. | | `Aurora_pq_request_not_chosen_index_hint` | Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Abfrage einen Indexhinweis enthält. | | `Aurora_pq_request_not_chosen_innodb_table_format` | Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Tabelle ein nicht unterstütztes InnoDB-Zeilenformat verwendet. Die parallele Aurora-Abfrage gilt nur für die `COMPACT`-, `REDUNDANT`- und `DYNAMIC`-Zeilenformate. | | `Aurora_pq_request_not_chosen_long_trx` | Die Anzahl der Parallelabfrageanforderungen, die den nicht-parallelen Abfrageverarbeitungspfad nutzten, weil die Abfrage in einer lang laufenden Transaktion gestartet wurde. Die Zähleranzeige kann mit einer `EXPLAIN`-Anweisung erhöht werden, selbst wenn die Abfrage nicht tatsächlich ausgeführt wird. | | `Aurora_pq_request_not_chosen_no_where_clause` | Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Abfrage keine `WHERE`-Klausel enthält. | | `Aurora_pq_request_not_chosen_range_scan` | Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Abfrage einen Bereichsscan für einen Index verwendet. | | `Aurora_pq_request_not_chosen_row_length_too_long` | Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Gesamtlänge aller Spalten zu groß ist. | | `Aurora_pq_request_not_chosen_small_table` | Die Anzahl der Situationen, in denen die Gesamtgröße der Tabelle (Zeilenanzahl und durchschnittliche Zeilenlänge) der Grund für den Nichteinsatz von Parallel Query war. Die Zähleranzeige kann mit einer `EXPLAIN`-Anweisung erhöht werden, selbst wenn die Abfrage nicht tatsächlich ausgeführt wird. | | `Aurora_pq_request_not_chosen_temporary_table` | Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Abfrage auf temporäre Tabellen verweist, die die nicht unterstützten Tabellentypen `MyISAM` oder `memory` verwenden. | | `Aurora_pq_request_not_chosen_tx_isolation` | Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Abfrage eine nicht unterstützte Transaktionsisolationsstufe verwendet. Bei DB-Leser-Instances wird die parallele Abfrage nur auf die Isolationsstufen `REPEATABLE READ` und `READ COMMITTED` angewendet. | | `Aurora_pq_request_not_chosen_update_delete_stmts` | Die Anzahl der parallelen Abfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da die Abfrage Teil einer `UPDATE`- oder `DELETE`-Anweisung ist. | | `Aurora_pq_request_not_chosen_unsupported_access` | Die Anzahl der Parallelabfrageanforderungen, die den nicht-parallelen Abfrageverarbeitungspfad nutzen, weil die `WHERE`-Klausel nicht den Kriterien einer Parallelabfrage gerecht wird. Dieses Ergebnis kann eintreten, wenn für die Abfrage kein datenintensiver Scan erforderlich ist oder wenn es sich bei der Abfrage um eine `DELETE`- oder `UPDATE`-Anweisung handelt. | | `Aurora_pq_request_not_chosen_unsupported_storage_type` | Die Anzahl der Parallelabfrageanforderungen, die den nicht parallelen Abfrageverarbeitungspfad verwenden, da der DB-Cluster von Aurora MySQL keine unterstützte Aurora-Cluster-Speicherkonfiguration verwendet. Weitere Informationen finden Sie unter [Einschränkungen](aurora-mysql-parallel-query.md#aurora-mysql-parallel-query-limitations). Dieser Parameter gilt für Aurora-MySQL-Version 3.04 und höher. | | `Aurora_pq_request_throttled` | Die Anzahl der Situationen, in denen Parallel Query nicht genutzt wurde, weil die Höchstmenge gleichzeitiger Parallelabfragen bereits auf einer bestimmten Aurora-DB-Instance ausgeführt wird. | | `Aurora_repl_bytes_received` | Anzahl der Byte, die seit dem letzten Neustart auf eine Reader-Datenbank-Instance von Aurora MySQL repliziert wurden. Weitere Informationen finden Sie unter [Replikation mit Amazon Aurora My SQL](AuroraMySQL.Replication.md). | | `Aurora_reserved_mem_exceeded_incidents` | Gibt an, wie oft die Engine seit dem letzten Neustart die Grenzen des reservierten Speichers überschritten hat. Falls `aurora_oom_response` konfiguriert, definiert dieser Schwellenwert, wann out-of-memory (OOM-) Vermeidungsaktivitäten ausgelöst werden. Weitere Informationen zur Antwort wegen Speichermangel von Aurora MySQL finden Sie unter [Beheben von Speicherproblemen bei Aurora-MySQL-Datenbanken](AuroraMySQLOOM.md). | | `aurora_temptable_max_ram_allocation` | Die maximale Speichermenge in Byte, die zu einem beliebigen Zeitpunkt von internen temporären Tabellen seit dem letzten Neustart verwendet wird. | | `aurora_temptable_ram_allocation` | Die aktuelle Speichermenge in Byte, die von internen temporären Tabellen verwendet wird. | | `Aurora_in_memory_relaylog_status` | Der aktuelle Status der In-Memory-Relay-Protokollfunktion. Der Wert kann ENABLED oder DISABLED sein. | | `Aurora_in_memory_relaylog_disabled_reason` | Zeigt den Grund für den aktuellen Status der In-Memory-Relay-Protokollfunktion an. Wenn die Funktion deaktiviert ist, wird eine Meldung mit einer Erklärung angezeigt, warum die Funktion deaktiviert ist. | | `Aurora_in_memory_relaylog_fallback_count` | Zeigt die Gesamtzahl der Fallbacks der In-Memory-Relay-Protokollfunktion in den persistenten Relay-Protokollmodus (veraltet) an. Ein Fallback kann entweder durch ein einzelnes Ereignis verursacht werden, das größer als die Cachegröße (derzeit 128 MB) ist, oder wenn eine Transaktionswiederholung das Wiederholungslimit für Replikattransaktionen replica\$1transaction\$1retries überschreitet. | | `Aurora_in_memory_relaylog_recovery_count` | Zeigt die Gesamtzahl der In-Memory-Relay-Protokollwiederherstellungen an, die automatisch durchgeführt wurden. Diese Anzahl umfasst die Gesamtzahl der Fallbacks sowie die Anzahl der automatischen Modus-Rückschaltungen in den In-Memory-Relay-Protokollmodus nach den temporären Fallbacks. | | `Aurora_thread_pool_thread_count` | Die aktuelle Anzahl von Threads im Aurora-Threadpool. Weitere Informationen zum Threadpool in Aurora MySQL finden Sie unter [Thread-Pool](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.pool). | | `Aurora_tmz_version` | Bezeichnet die aktuelle Version der Zeitzoneninformationen, die vom DB-Cluster verwendet werden. Die Werte folgen dem Format der Internet Assigned Numbers Authority (IANA): `YYYYsuffix`, zum Beispiel `2022a` und `2023c`. Dieser Parameter gilt für Aurora-MySQL-Version 2.12 und höher sowie Version 3.04 und höher. | | `Aurora_zdr_oom_threshold` | Stellt den Speicherschwellenwert in Kilobyte (KB) für eine Aurora-DB-Instance dar, um einen Neustart ohne Ausfallzeit (Zero Downtime Restart, ZDR) zur Bewältigung potenzieller Speicherprobleme einzuleiten. | | `server_aurora_das_running` | Gibt an, ob Database Activity Streams (DAS) auf dieser DB-Instance aktiviert oder deaktiviert sind. Weitere Informationen finden Sie unter [Überwachung von Amazon Aurora mithilfe von Datenbankaktivitätsstreams](DBActivityStreams.md). | ## MySQL-Statusvariablen, die nicht für Aurora MySQL gelten Aufgrund der architektonischen Unterschiede zwischen Aurora MySQL und MySQL gelten einige MySQL-Statusvariablen nicht für Aurora MySQL. Die folgenden MySQL-Statusvariablen gelten nicht für Aurora MySQL. Diese Liste ist nicht umfassend. + `innodb_buffer_pool_bytes_dirty` + `innodb_buffer_pool_pages_dirty` + `innodb_buffer_pool_pages_flushed` Aurora-MySQL-Version 3 entfernt die folgenden Statusvariablen in Aurora-MySQL-Version 2: + `AuroraDb_lockmgr_bitmaps0_in_use` + `AuroraDb_lockmgr_bitmaps1_in_use` + `AuroraDb_lockmgr_bitmaps_mem_used` + `AuroraDb_thread_deadlocks` + `available_alter_table_log_entries` + `Aurora_lockmgr_memory_used` + `Aurora_missing_history_on_replica_incidents` + `Aurora_new_lock_manager_lock_release_cnt` + `Aurora_new_lock_manager_lock_release_total_duration_micro` + `Aurora_new_lock_manager_lock_timeout_cnt` + `Aurora_total_op_memory` + `Aurora_total_op_temp_space` + `Aurora_used_alter_table_log_entries` + `Aurora_using_new_lock_manager` + `Aurora_volume_bytes_allocated` + `Aurora_volume_bytes_left_extent` + `Aurora_volume_bytes_left_total` + `Com_alter_db_upgrade` + `Compression` + `External_threads_connected` + `Innodb_available_undo_logs` + `Last_query_cost` + `Last_query_partial_plans` + `Slave_heartbeat_period` + `Slave_last_heartbeat` + `Slave_received_heartbeats` + `Slave_retried_transactions` + `Slave_running` + `Time_since_zero_connections` Diese MySQL-Statusvariablen sind in Aurora-MySQL-Version 1 2 verfügbar, in Aurora-MySQL-Version 3 jedoch nicht: + `Innodb_redo_log_enabled` + `Innodb_undo_tablespaces_total` + `Innodb_undo_tablespaces_implicit` + `Innodb_undo_tablespaces_explicit` + `Innodb_undo_tablespaces_active` # Aurora-MySQL-Warteereignisse Es folgen verschiedene typische Warteereignisse für Aurora MySQL. **Anmerkung** Informationen zur Optimierung der Leistung von Aurora MySQL mithilfe von Warteereignissen finden Sie unter [Optimieren von Aurora MySQL mit Warteereignissen](AuroraMySQL.Managing.Tuning.wait-events.md). Informationen zu den in MySQL-Warteereignissen geltenden Namenskonventionen finden Sie unter [Performance Schema Instrument Naming Conventions](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-instrument-naming.html) in der MySQL-Dokumentation. **cpu** Die Anzahl der aktiven Verbindungen, die betriebsbereit sind, ist durchweg höher als die Anzahl von CPUs v. Weitere Informationen finden Sie unter[cpu](ams-waits.cpu.md). **io/aurora\$1redo\$1log\$1flush** Eine Sitzung enthält Daten für den Aurora-Speicher. Typischerweise bezieht sich dieses Warteereignis auf eine Schreib-I/O-Operation in Aurora MySQL. Weitere Informationen finden Sie unter [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md). **io/aurora\$1respond\$1to\$1client** Die Abfrageverarbeitung ist abgeschlossen und die Ergebnisse werden für die folgenden Aurora-MySQL-Version an den Anwendungs-Client zurückgegeben: 2.10.2 und höhere 2.10-Versionen, 2.09.3 und höhere 2.09-Versionen, 2.07.7 und höhere 2.07-Versionen. Vergleichen Sie die Netzwerkbandbreite der DB-Instance-Klasse mit der Größe der zurückgegebenen Ergebnismenge. Überprüfen Sie auch clientseitige Reaktionszeiten. Wenn der Client nicht reagiert und die TCP-Pakete nicht verarbeiten kann, können Paketabfälle und TCP-Neuübertragungen auftreten. Diese Situation wirkt sich negativ auf die Netzwerkbandbreite aus. In Versionen vor 2.10.2, 2.09.3 und 2.07.7 enthält das Warteereignis fälschlicherweise die Leerlaufzeit. Um zu erfahren, wie Sie Ihre Datenbank optimieren, wenn diese Wartezeit im Vordergrund steht, lesen Sie [io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md). **io/file/csv/data** Threads schreiben in Tabellen im CSV-Format (Comma-Separated Value). Prüfen Sie die Auslastung der CSV-Tabellen. Eine typische Ursache für dieses Ereignis ist die Einstellung `log_output` auf einer Tabelle. **io/file/sql/binlog** Ein Thread wartet auf eine binäre Protokoll-Datei (binlog), die auf den Datenträger geschrieben wird. **io/redo\$1log\$1flush** Eine Sitzung enthält Daten für den Aurora-Speicher. In der Regel bezieht sich dieses Warteereignis auf einen I/O Schreibvorgang in Aurora MySQL. Weitere Informationen finden Sie unter [io/redo\$1log\$1flush](ams-waits.io-redologflush.md). **io/socket/sql/client\$1Verbindung** Das Programm `mysqld` ist damit beschäftigt, Threads zu erstellen, um eingehende neue Client-Verbindungen zu verarbeiten. Weitere Informationen finden Sie unter [io/socket/sql/client\$1verbindung](ams-waits.client-connection.md). **io/table/sql/handler** Der Motor wartet auf Zugang zu einer Tabelle. Dieses Ereignis tritt unabhängig davon auf, ob die Daten im Pufferpool zwischengespeichert oder auf der Festplatte zugegriffen werden. Weitere Informationen finden Sie unter [io/table/sql/handler](ams-waits.waitio.md). **lock/table/sql/handler** Dieses Warteereignis ist ein Warteereignis-Handler für Tabellensperren. Weitere Informationen zu Atom- und Molekülereignissen im Leistungsschema finden Sie unter [Leistungsschema-Atom- und Molekülereignisse](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-atom-molecule-events.html) in der MySQL-Dokumentation. **synch/cond/innodb/row\$1lock\$1wait** Mehrere DML-Anweisungen (DML = Data Manipulation Language) greifen gleichzeitig auf dieselben Datenbankzeilen zu. Weitere Informationen finden Sie unter [synch/cond/innodb/row\$1sperren\$1warten](ams-waits.row-lock-wait.md). **synch/cond/innodb/row\$1lock\$1wait\$1cond** Mehrere DML-Anweisungen greifen gleichzeitig auf dieselben Datenbankzeilen zu. Weitere Informationen finden Sie unter [synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md). **synch/cond/sql/MDL\$1context: :cond\$1wait\$1status** Threads warten auf eine Tabellen-Metadatensperre. Die Engine verwendet diese Art von Sperre, um den gleichzeitigen Zugriff auf ein Datenbankschema zu verwalten und die Datenkonsistenz sicherzustellen. Weitere Informationen finden Sie unter [Optimizing Locking Operations](https://dev.mysql.com/doc/refman/8.0/en/locking-issues.html) in der MySQL-Dokumentation. Um zu erfahren, wie Sie Ihre Datenbank optimieren, wenn dieses Ereignis im Vordergrund steht, lesen Sie [synch/cond/sql/MDL\$1context: :cond\$1wait\$1status](ams-waits.cond-wait-status.md). **synch/cond/sql/MYSQL\$1BIN\$1LOG: :cond\$1DONE** Sie haben die binäre Protokollierung aktiviert. Es kann einen hohen Commit-Durchsatz, eine große Anzahl von Transaktionen oder Replikate geben, die Binlogs lesen. Erwägen Sie, mehrzeilige Anweisungen zu verwenden oder Anweisungen in einer Transaktion zu bündeln. Verwenden Sie in Aurora globale Datenbanken anstelle der Binärprotokollreplikation oder verwenden Sie die Parameter `aurora_binlog_*`. **synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex** Mehrere DML-Anweisungen greifen gleichzeitig auf dieselben Datenbankzeilen zu. Weitere Informationen finden Sie unter [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md). **synch/mutex/innodb/buf\$1pool\$1mutex** Der Puffer-Pool ist nicht groß genug, um den Arbeitsdatensatz zu speichern. Oder die Workload greift auf Seiten aus einer bestimmten Tabelle zu, was zu Konflikten im Pufferpool führt. Weitere Informationen finden Sie unter [synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md). **synch/mutex/innodb/fil\$1system\$1mutex** Der Prozess wartet auf den Zugriff auf den Tablespace-Speicher-Cache. Weitere Informationen finden Sie unter [synch/mutex/innodb/fil\$1system\$1mutex](ams-waits.innodb-fil-system-mutex.md). **synch/mutex/innodb/trx\$1sys\$1mutex** Operationen sind das Überprüfen, Aktualisieren, Löschen oder Hinzufügen von Transaktionen IDs in InnoDB auf konsistente oder kontrollierte Weise. Diese Vorgänge erfordern einen `trx_sys`-Mutex-Aufruf, der von der Leistungs-Schema-Instrumentierung verfolgt wird. Zu den Vorgängen gehören die Verwaltung des Transaktionssystems beim Starten oder Herunterfahren der Datenbank, Rollbacks, Rückgängig-Bereinigungen, Zeilen-Lesezugriff und Pufferpool-Lasten. Eine hohe Datenbanklast bei einer großen Anzahl von Transaktionen führt zum häufigen Auftreten dieses Wait-Ereignisses. Weitere Informationen finden Sie unter [synch/mutex/innodb/trx\$1sys\$1mutex](ams-waits.trxsysmutex.md). **synch/mutex/mysys/KEY\$1CACHE: :cache\$1lock** Der `keycache->cache_lock`-Mutex steuert den Zugriff auf den Schlüsselcache für MyISAM-Tabellen. Aurora MySQL erlaubt zwar keine MyISAM-Tabellen zum Speichern persistenter Daten, diese werden jedoch zum Speichern interner temporärer Tabellen verwendet. Prüfen Sie ggf. die Statuszähler `created_tmp_tables` oder `created_tmp_disk_tables`, da in bestimmten Situationen temporäre Tabellen auf die Festplatte geschrieben werden, wenn sie nicht mehr in den Speicher passen. **synch/mutex/sql/FILE\$1AS\$1TABLE: :Lock\$1Offsets** Die Engine erwirbt diesen Mutex beim Öffnen oder Erstellen eines Tabellen-Metadatenarchivs. Wenn dieses Warteereignis mit übermäßiger Häufigkeit auftritt, ist die Anzahl der erstellten oder geöffneten Tabellen gestiegen. **synch/mutex/sql/FILE\$1AS\$1TABLE: :Lock\$1SHIM\$1LISTS** Die Engine ruft diesen Mutex ab, während sie Vorgänge wie `reset_size`, `detach_contents` oder `add_contents` an der internen Struktur durchführt, die geöffnete Tabellen verfolgt. Der Mutex synchronisiert den Zugriff auf den Listeninhalt. Wenn dieses Warteereignis mit hoher Frequenz auftritt, deutet dies auf eine plötzliche Änderung des Tabellensatzes hin, auf die zuvor zugegriffen wurde. Die Engine muss auf neue Tabellen zugreifen oder den Kontext, der sich auf zuvor aufgerufene Tabellen bezieht, loslassen. **synch/mutex/sql/LOCK\$1öffnen** Die Anzahl der Tabellen, die Ihre Sitzungen öffnen, überschreitet die Größe des Tabellendefinitions-Caches oder des Caches zum Öffnen der Tabelle. Erhöhen Sie die Größe dieser Caches. Weitere Informationen finden Sie unter [How MySQL Opens and Closes Tables](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html). **synch/mutex/sql/LOCK\$1Tabellencache** Die Anzahl der Tabellen, die Ihre Sitzungen öffnen, überschreitet die Größe des Tabellendefinitions-Caches oder des Caches zum Öffnen der Tabelle. Erhöhen Sie die Größe dieser Caches. Weitere Informationen finden Sie unter [How MySQL Opens and Closes Tables](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html). **synch/mutex/sql/LOG** Bei diesem Warteereignis warten Threads auf eine Protokollsperre. Beispiel: Ein Thread wartet auf eine Sperre, um in die Slow-Query-Protokolldatei zu schreiben. **synch/mutex/sql/MYSQL\$1BIN\$1LOG: :Lock\$1Commit** Bei diesem Warteereignis wartet ein Thread auf eine Sperre, um Daten in das Binärprotokoll schreiben zu können. Konflikte in der Binärprotokollierung können bei Datenbanken mit sehr hoher Änderungsrate auftreten. In Abhängigkeit von der MySQL-Version werden verschiedene Sperren verwendet, um Konsistenz und Haltbarkeit des Binärprotokolls zu schützen. In RDS für MySQL werden Binärprotokolle für die Replikation und für automatische Sicherungen verwendet. In Aurora MySQL werden keine Binärprotokolle für die native Replikation und für Sicherungen benötigt. Sie sind standardmäßig deaktiviert, können aber aktiviert und für die externe Replikation oder die Erfassung von Änderungsdaten genutzt werden. Weitere Informationen finden Sie unter [The Binary Log](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) in der MySQL-Dokumentation. **sync/mutex/sql/MYSQL\$1BIN\$1LOG: :Lock\$1Dump\$1Thread\$1Metrics\$1Collection** Wenn die binäre Protokollierung aktiviert ist, erwirbt die Engine diesen Mutex, wenn sie aktive Dump-Thread-Metriken an das Engine-Fehlerprotokoll und in die interne Vorgangs-Mappe druckt. **sync/mutex/sql/MYSQL\$1BIN\$1LOG: :Lock\$1Inactive\$1BinLogs\$1Map** Wenn die binäre Protokollierung aktiviert ist, erwirbt die Engine diesen Mutex, wenn sie die Liste der Binlog-Datei hinter der neuesten hinzufügt, sie löscht oder durchsucht. **sync/mutex/sql/MYSQL\$1BIN\$1LOG: :IO\$1Cache sperren** Wenn die binäre Protokollierung aktiviert ist, erwirbt die Engine diesen Mutex während der Aurora-Binlog-IO-Cache-Vorgänge: Zuweisen, Größe ändern, freigeben, schreiben, lesen, löschen und auf Cache-Informationen zugreifen. Wenn dieses Ereignis häufig auftritt, greift die Engine auf den Cache zu, in dem Binlog-Ereignisse gespeichert werden. Um Wartezeiten zu reduzieren, reduzieren Sie Commits. Versuchen Sie, mehrere Anweisungen in einer einzigen Transaktion zu gruppieren. **synch/mutex/sql/MYSQL\$1BIN\$1LOG: :LOG SPERREN** Sie haben die binäre Protokollierung aktiviert. Möglicherweise gibt es einen hohen Commit-Durchsatz, viele Transaktionen oder Replikate, die Binlogs lesen. Erwägen Sie, mehrzeilige Anweisungen zu verwenden oder Anweisungen in einer Transaktion zu bündeln. Verwenden Sie in Aurora globale Datenbanken anstelle der Binärprotokollreplikation oder verwenden Sie die Parameter `aurora_binlog_*`. **synch/mutex/sql/SERVER\$1THREAD: :LOCK\$1SYNC** Der `SERVER_THREAD::LOCK_sync`-Mutex wird während des Planens, Verarbeitens oder Startens von Threads für Dateischreibvorgänge erfasst. Das übermäßige Auftreten dieses Wait-Ereignisses weist auf eine erhöhte Schreibaktivität in der Datenbank hin. **synch/mutex/sql/TABLESPACES\$1THREAD: :lock\$1sync ----sep----:sperren** Die Engine ruft den `TABLESPACES:lock`-Mutex während der folgenden Tablespace-Vorgänge ab: erstellen, löschen, abschneiden und erweitern. Das übermäßige Auftreten dieses Wait-Ereignisses weist auf eine hohe Häufigkeit von Tablespace-Vorgänge hin. Ein Beispiel ist das Laden einer großen Datenmenge in die Datenbank. **synch/rwlock/innodb/dict** Bei diesem Warteereignis warten Threads auf eine rwlock, die für das InnoDB-Datenwörterbuch gesetzt ist. **synch/rwlock/innodb/dict\$1operation\$1lock** Bei diesem Warteereignis warten Threads auf Sperren, die für InnoDB-Datenwörterbuch-Operationen gesetzt sind. **synch/rwlock/innodb/dictsys-RW-Sperre** Eine große Anzahl gleichzeitiger Datensteuerungs-Sprachanweisungen (DCLs) im Datendefinitionssprachencode (DDLs) wird gleichzeitig ausgelöst. Reduzieren Sie die Abhängigkeit der Anwendung DDLs während der regulären Anwendungsaktivität. **synch/rwlock/innodb/index\$1tree\$1rw\$1lock** Eine große Anzahl ähnlicher DML-Anweisungen (Data Manipulation Language) greift gleichzeitig auf dasselbe Datenbankobjekt zu. Versuchen Sie es mit mehrreihigen Anweisungen. Verteilen Sie die Workload auch auf verschiedene Datenbankobjekte. Implementieren Sie beispielsweise die Partitionierung. **synch/sxlock/innodb/dict\$1Betriebssperre** Eine große Anzahl gleichzeitiger Datensteuerungs-Sprachanweisungen (DCLs) im Datendefinitionssprachencode (DDLs) wird gleichzeitig ausgelöst. Reduzieren Sie die Abhängigkeit der Anwendung DDLs während der regulären Anwendungsaktivität. **synch/sxlock/innodb/dict\$1sys\$1lock** Eine große Anzahl gleichzeitiger Datensteuerungs-Sprachanweisungen (DCLs) im Datendefinitionssprachencode (DDLs) wird gleichzeitig ausgelöst. Reduzieren Sie die Abhängigkeit der Anwendung DDLs während der regulären Anwendungsaktivität. **synch/sxlock/innodb/hash\$1table\$1locks** Die Sitzung konnte keine Seiten im Puffer-Pool finden. Die Engine muss entweder eine Datei lesen oder die zuletzt verwendete Liste (LRU) für den Pufferpool ändern. Erwägen Sie, die Puffer-Cache-Größe zu erhöhen und die Zugriffspfade für die entsprechenden Abfragen **synch/sxlock/innodb/index\$1tree\$1rw\$1lock** Viele ähnliche DML-Anweisungen (DML = Data Manipulation Language) greifen gleichzeitig auf dasselbe Datenbankobjekt zu. Versuchen Sie es mit mehrreihigen Anweisungen. Verteilen Sie die Workload auch auf verschiedene Datenbankobjekte. Implementieren Sie beispielsweise die Partitionierung. **synch/mutex/innodb/temp\$1poolmanager\$1mutex** Dieses Wartungsereignis tritt auf, wenn eine Sitzung darauf wartet, einen Mutex für die Verwaltung des Pools temporärer Sitzungs-Tablespaces zu erhalten. Weitere Informationen zur Fehlerbehebung bei Synchronisierungs-Warteereignissen finden Sie unter [Warum zeigt meine MySQL-DB-Instance eine hohe Anzahl aktiver Sitzungen an, die auf SYNCH-Warteereignisse in Performance Insights warten?](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-mysql-synch-wait-events/). # Aurora-MySQL-Thread-Zustände Im Folgenden werden einige allgemeine Thread-Zustände für Aurora MySQL aufgeführt. **Berechtigungen werden überprüft** Der Thread prüft, ob der Server über die erforderlichen Berechtigungen zum Ausführen der Anweisung verfügt. **Abfrage-Cache auf Abfrage prüfen** Der Server prüft, ob die aktuelle Abfrage im Abfrage-Cache vorhanden ist. **Bereinigen** Dies ist der endgültige Status einer Verbindung, deren Arbeit abgeschlossen ist, aber vom Client nicht geschlossen wurde. Die beste Lösung besteht darin, die Verbindung explizit im Code zu schließen. Oder Sie stellen einen niedrigeren Wert für `wait_timeout` in Ihrer Parametergruppe ein. **Schließen von Tabellen** Der Thread löscht die geänderten Tabellendaten auf die Festplatte und schließt die verwendeten Tabellen. Wenn dies kein schneller Vorgang ist, überprüfen Sie die Metriken für den Verbrauch der Netzwerkbandbreite im Hinblick auf die Netzwerkbandbreite der Instance-Klasse. Überprüfen Sie außerdem, ob die Parameterwerte für die Parameter `table_open_cache` und `table_definition_cache` erlauben, dass genügend Tabellen gleichzeitig geöffnet sind, damit die Engine Tabellen nicht häufig öffnen und schließen muss. Diese Parameter beeinflussen den Speicherverbrauch der Instance. **Konvertieren von HEAP in myISAM** Die Abfrage konvertiert eine temporäre Tabelle von In-Memory in On-Disk. Diese Konvertierung ist notwendig, da die von MySQL in den Zwischenschritten der Abfrageverarbeitung erstellten temporären Tabellen für den Speicher zu groß wurden. Überprüfen Sie die Werte von `tmp_table_size` und `max_heap_table_size`. In späteren Versionen lautet dieser Threadstatusname `converting HEAP to ondisk`. **Konvertieren von HEAP in Ondisk** Der Thread konvertiert eine interne temporäre Tabelle von einer In-Memory-Tabelle in eine On-Disk-Tabelle. **in tmp-Tabelle kopieren** Der Thread verarbeitet eine `ALTER TABLE`-Anweisung. Dieser Status tritt auf, nachdem die Tabelle mit der neuen Struktur erstellt wurde, aber bevor Zeilen in sie kopiert werden. Für einen Thread in diesem Status können Sie das Leistungsschema verwenden, um Informationen über den Fortschritt des Kopiervorgangs zu erhalten. **Sortierindex erstellen** Aurora MySQL führt eine Sortierung durch, weil es keinen vorhandenen Index verwenden kann, um die `ORDER BY`- oder `GROUP BY`-Klausel einer Abfrage zu erfüllen. Weitere Informationen finden Sie unter [Erstellen des Sortierindex](ams-states.sort-index.md). **Tabelle wird erstellt** Der Thread erstellt eine permanente oder temporäre Tabelle. **verzögertes Commit ok fertig** Ein asynchrones Commit in Aurora MySQL hat eine Bestätigung erhalten und ist vollständig. **verzögertes Commit ok initiiert** Der Aurora MySQL-Thread hat den asynchronen Commit-Prozess gestartet, wartet aber auf die Bestätigung. Dies ist normalerweise die echte Commit-Zeit einer Transaktion. **verzögert senden ok fertig** Ein Aurora MySQL-Worker-Thread, der an eine Verbindung gebunden ist, kann freigegeben werden, während eine Antwort an den Client gesendet wird. Der Thread kann mit anderen Arbeiten beginnen. Der Zustand `delayed send ok` bedeutet, dass die asynchrone Quittung an den Client abgeschlossen ist. **verzögert senden ok initiiert** Ein Aurora MySQL-Worker-Thread hat asynchron eine Antwort an einen Client gesendet und kann nun für andere Verbindungen arbeiten. Die Transaktion hat einen asynchronen Commit-Prozess gestartet, der noch nicht bestätigt wurde. **executing** Der Thread hat begonnen, eine Anweisung auszuführen. **Freigeben von Gegenständen** Der Thread hat einen Befehl ausgeführt. Ein gewisses Freigeben von Elementen, die in diesem Status durchgeführt wurden, beinhaltet den Abfrage-Cache. Auf diesen Zustand folgt normalerweise ein Aufräumen. **init** Dieser Zustand tritt vor der Initialisierung von `ALTER TABLE`-, `DELETE`-, `INSERT`-, `SELECT`- oder `UPDATE`-Anweisungen auf. Zu den Aktionen in diesem Status gehören das Löschen des Binärprotokolls oder des InnoDB-Protokolls und eine Bereinigung des Abfrage-Caches. **Quelle hat alle Binlogs an das Replikat gesendet; wartet auf weitere Updates** Der Primärknoten hat seinen Teil der Replikation abgeschlossen. Der Thread wartet darauf, dass weitere Abfragen ausgeführt werden, damit er in das Binärprotokoll (Binlog) schreiben kann. **Öffnen von Tabellen** Der Thread versucht eine Tabelle zu öffnen. Dieser Vorgang ist schnell, es sei denn, eine `ALTER TABLE`- oder `LOCK TABLE`-Anweisung muss beendet werden oder sie überschreitet den Wert von `table_open_cache`. **optimieren** Der Server führt erste Optimierungen für eine Abfrage durch. **vorbereiten** Dieser Status tritt während der Abfrageoptimierung auf. **Abfrage Ende** Dieser Status tritt nach der Verarbeitung einer Abfrage jedoch vor dem Status „Freigegebene Elemente“ auf. **Entfernen von Duplikaten** Aurora MySQL konnte einen `DISTINCT`-Vorgang in der frühen Phase einer Abfrage nicht optimieren. Aurora MySQL muss alle duplizierten Zeilen entfernen, bevor das Ergebnis an den Client gesendet wird. **Zeilen nach Update suchen** Der Thread findet alle übereinstimmenden Zeilen, bevor er sie aktualisiert. Diese Phase ist erforderlich, wenn `UPDATE` den Index ändert, den die Engine zum Auffinden der Zeilen verwendet. **Binlog-Ereignis an Slave senden** Der Thread liest ein Ereignis aus dem Binärprotokoll und sendet es an das Replikat. **Zwischengespeichertes Ergebnis an den Client senden** Der Server nimmt das Ergebnis einer Abfrage aus dem Abfrage-Cache und sendet es an den Client. **senden von Daten** Der Thread liest und verarbeitet Zeilen für eine `SELECT`-Anweisung, hat aber noch nicht damit begonnen, Daten an den Client zu senden. Der Prozess identifiziert, welche Seiten die Ergebnisse enthalten, die erforderlich sind, um die Abfrage zu erfüllen. Weitere Informationen finden Sie unter [Senden von Daten](ams-states.sending-data.md). **an den Kunden senden** Der Server schreibt ein Paket an den Client. In früheren MySQL-Versionen wurde dieses Warteereignis mit `writing to net` bezeichnet. **starting** Dies ist die erste Stufe zu Beginn der Ausführung von Anweisungen. **statistics** Der Server berechnet Statistiken, um einen Abfrageausführungsplan zu entwickeln. Wenn sich ein Thread längere Zeit in diesem Zustand befindet, ist der Server wahrscheinlich festplattengebunden, während er andere Arbeiten ausführt. **Speichern von Ergebnis im Abfrage-Cache** Der Server speichert das Ergebnis einer Abfrage im Abfrage-Cache. **Systemsperre** Der Thread hat `mysql_lock_tables` aufgerufen, aber der Threadstatus wurde seit dem Aufruf nicht aktualisiert. Dieser allgemeine Zustand tritt aus vielen Gründen auf. **update** Der Thread bereitet sich darauf vor, die Tabelle zu aktualisieren. **executing** Der Thread sucht nach Zeilen und aktualisiert sie. **Benutzersperre** Der Thread hat einen `GET_LOCK`-Aufruf ausgegeben. Der Thread hat entweder eine Beratungssperre angefordert und wartet darauf oder plant, sie anzufordern. **auf weitere Updates warten** Der Primärknoten hat seinen Teil der Replikation abgeschlossen. Der Thread wartet darauf, dass weitere Abfragen ausgeführt werden, damit er in das Binärprotokoll (Binlog) schreiben kann. **Warten auf Schema-Metadatensperre** Dies ist ein Warten auf eine Metadatensperre. **auf die Sperre der gespeicherten Funktion Metadaten** Dies ist ein Warten auf eine Metadatensperre. **Warten auf Metadatensperre der gespeicherten** Dies ist ein Warten auf eine Metadatensperre. **Warten auf Tabellenintegration** Der Thread führt `FLUSH TABLES` aus und wartet darauf, dass alle Threads ihre Tabellen schließen. Oder der Thread erhielt eine Benachrichtigung, dass sich die zugrunde liegende Struktur für eine Tabelle geändert hat, daher muss er die Tabelle erneut öffnen, um die neue Struktur zu erhalten. Um die Tabelle erneut zu öffnen, muss der Thread warten, bis alle anderen Threads die Tabelle geschlossen haben. Diese Benachrichtigung erfolgt, wenn ein anderer Thread eine der folgenden Anweisungen in der Tabelle verwendet hat: `FLUSH TABLES`, `ALTER TABLE`, `RENAME TABLE`, `REPAIR TABLE`, `ANALYZE TABLE`, oder `OPTIMIZE TABLE`. **auf Tabellen-Levelsperre** Eine Sitzung hält eine Sperre für eine Tabelle, während eine andere Sitzung versucht, dieselbe Sperre für dieselbe Tabelle zu erwerben. **Warten auf Tabellen-Metadatensperre** Aurora MySQL verwendet die Sperre von Metadaten, um den gleichzeitigen Zugriff auf Datenbankobjekte zu verwalten und die Datenkonsistenz sicherzustellen. In diesem Warteereignis hält eine Sitzung eine Metadatensperre für eine Tabelle, während eine andere Sitzung versucht, dieselbe Sperre für dieselbe Tabelle zu erwerben. Wenn das Leistungsschema aktiviert ist, wird dieser Threadstatus als Warteereignis `synch/cond/sql/MDL_context::COND_wait_status` gemeldet. **Schreiben ins Netz** Der Server schreibt ein Paket in das Netzwerk. In späteren MySQL-Versionen wird dieses Warteereignis mit `Sending to client` markiert. # Aurora MySQL-Isolierungsstufen Im Folgenden erfahren Sie, wie DB-Instances in einem Aurora MySQL-Cluster die Datenbankeigenschaft „Isolation“ implementieren. Dieses Thema erläutert, wie das Standardverhalten von Aurora MySQL einen Ausgleich zwischen strenger Konsistenz und hoher Leistung sucht. Mithilfe dieser Informationen können Sie entscheiden, wann je nach den Eigenschaften Ihres Workloads die Standardeinstellungen geändert werden sollten. ## Verfügbare Isolierungsstufen für Writer-Instances Sie können die Isolierungsstufen `REPEATABLE READ`, `READ COMMITTED`, `READ UNCOMMITTED` und `SERIALIZABLE` für die primäre Instance eines Aurora MySQL DB-Clusters verwenden. Diese Isolierungsstufen funktionieren in Aurora MySQL genauso wie in RDS für MySQL. ## Isolierungsstufe REPEATABLE READ für Reader-Instances Standardmäßig verwenden als schreibgeschützte Aurora-Replicas konfigurierte Aurora MySQL-DB-Instances die Isolierungsstufe `REPEATABLE READ`. Diese DB-Instances ignorieren alle `SET TRANSACTION ISOLATION LEVEL`-Anweisungen und verwenden weiterhin die Isolierungsstufe `REPEATABLE READ`. ## Isolierungsstufe READ COMMITTED für Reader-Instances Wenn Ihre Anwendung schreibintensive Workloads auf der primären Instance und lang andauernde Abfragen auf den Aurora-Replicas beinhaltet, kann es zu erheblichen Bereinigungsverzögerungen kommen. Eine *Bereinigungsverzögerung* tritt auf, wenn die interne Garbage Collection von lang andauernden Abfragen blockiert wird. Das Symptom, das Sie sehen, ist ein hoher Wert für `history list length` in der Ausgabe des `SHOW ENGINE INNODB STATUS`-Befehls. Sie können diesen Wert anhand der `RollbackSegmentHistoryListLength`-Metrik in CloudWatch überwachen. Eine erhebliche Bereinigungsverzögerung kann die Effektivität sekundärer Indizes reduzieren und zu einer geringeren allgemeinen Abfrageleistung führen sowie Speicherplatz verschwenden. Wenn diese Probleme bei Ihnen auftreten, können Sie mit einer Aurora MySQL-Konfigurationseinstellung auf Sitzungsebene, `aurora_read_replica_read_committed`, die Isolierungsstufe `READ COMMITTED` für Aurora-Replicas verwenden. Die Verwendung dieser Einstellung kann Verlangsamungen sowie die Verschwendung von Speicherplatz durch lang andauernde Abfragen reduzieren, während Transaktionen Ihre Tabellen modifizieren. Wie empfehlen, dass Sie sich mit dem spezifischen Aurora MySQL-Verhalten der `READ COMMITTED`-Isolierung gut vertraut machen, bevor Sie diese Einstellung verwenden. Das Aurora-Replica `READ COMMITTED`-Verhalten entspricht dem ANSI SQL-Standard. Die Isolierung ist jedoch weniger strikt als bei dem typischen MySQL `READ COMMITTED`-Verhalten, mit dem Sie möglicherweise vertraut sind. So kann es etwa zu abweichenden Ergebnissen einer Abfrage unter `READ COMMITTED` auf einem Aurora MySQL-Lesereplikat und für dieselbe Abfrage unter `READ COMMITTED` auf der primären Aurora MySQL-Instance oder auf RDS für MySQL kommen. Sie können die `aurora_read_replica_read_committed`-Einstellung für Anwendungsfälle wie einen umfassenden Bericht über eine sehr große Datenbank verwenden. Für kurze Abfragen mit kleinen Ergebnissätzen, bei denen es auf Präzision und Wiederholbarkeit ankommt, sollten Sie sie eher nicht verwenden. Die `READ COMMITTED`-Isolierungsstufe ist nicht für Sitzungen innerhalb eines sekundären Clusters in einer globalen Aurora-Datenbank verfügbar, die die Schreibweiterleitungsfunktion verwenden. Informationen zur Schreibweiterleitung finden Sie unter [Verwenden der Schreibweiterleitung in einer Amazon Aurora globalen Datenbank](aurora-global-database-write-forwarding.md). ### Verwenden von READ COMMITTED für Reader Um die Isolierungsstufe `READ COMMITTED` für Aurora-Replicas zu aktivieren, setzen Sie die Konfigurationseinstellung `aurora_read_replica_read_committed` auf `ON`. Verwenden Sie diese Einstellung auf Sitzungsebene bei Verbindung zu einer spezifischen Aurora-Replica. Führen Sie dazu die folgenden SQL-Befehle aus: ``` set session aurora_read_replica_read_committed = ON; set session transaction isolation level read committed; ``` Sie können diese Konfigurationseinstellung temporär verwenden, um interaktive einmalige Abfragen durchzuführen. Sie können auch eine Berichts- oder Datenanalyseanwendung ausführen, die von der Isolierungsstufe `READ COMMITTED` profitiert, wobei die Standards für andere Anwendungen unverändert bleiben. Wenn die `aurora_read_replica_read_committed`-Einstellung aktiviert ist, geben Sie mit dem `SET TRANSACTION ISOLATION LEVEL`-Befehl die Isolierungsstufe für die jeweiligen Transaktionen an. ``` set transaction isolation level read committed; ``` ### Unterschiede beim Verhalten von READ COMMITTED auf Aurora-Replikaten Die `aurora_read_replica_read_committed`-Einstellung stellt die Isolierungsstufe `READ COMMITTED` für eine Aurora-Replica zur Verfügung, mit einem Konsistenzverhalten, das für lang andauernde Transaktionen optimiert ist. Die Isolierungsstufe `READ COMMITTED` auf Aurora-Replicas bietet eine weniger strikte Isolierung als auf primären Aurora-Instances. Aktivieren Sie daher diese Einstellung nur auf Aurora-Replicas, wenn Sie wissen, dass für Ihre Abfragen bestimmte Arten inkonsistenter Ergebnisse akzeptabel sind. Bei Ihren Abfragen können bestimmte Arten von Anomalien auftreten, wenn die `aurora_read_replica_read_committed`-Einstellung aktiviert ist. Dabei sollten Sie besonders zwei Arten von Anomalien verstehen und in Ihrem Anwendungscode berücksichtigen. Eine *nicht-wiederholbarer Lesevorgang* tritt auf, wenn eine andere Transaktion ein Commit durchführt, während Ihre Abfrage läuft. Eine lang andauernde Abfrage kann an ihrem Anfang andere Daten sehen als an ihrem Ende. Eine *Phantom-Lesevorgang* tritt auf, wenn andere Transaktionen dazu führen, dass bestehende Zeilen umorganisiert werden, während Ihre Abfrage läuft, und dass dadurch eine oder mehrere Zeilen von Ihrer Abfrage zweimal gelesen werden. Phantom-Lesevorgänge können in Ihren Abfragen zu inkonsistenten Zeilenanzahlen führen. Nicht-wiederholbare Lesevorgänge können auch zur Ausgabe unvollständiger oder inkonsistenter Ergebnisse führen. Nehmen Sie beispielsweise an, eine Join-Operation bezieht sich auf Tabellen, die gleichzeitig von SQL-Anweisungen wie `INSERT` oder `DELETE` modifiziert werden. In diesem Fall kann es sein, dass die Join-Abfrage eine Zeile aus einer Tabelle liest, aber nicht die entsprechende Zeile aus einer anderen Tabelle. Der ANSI SQL-Standard lässt beide Verhaltensweisen für die Isolationsstufe `READ COMMITTED` zu. Diese Verhaltensweisen unterscheiden sich jedoch von der typischen MySQL-Implementierung von `READ COMMITTED`. Prüfen Sie daher vor der Aktivierung der `aurora_read_replica_read_committed`-Einstellung bestehenden SQL-Code darauf, ob er im Rahmen des lockereren Konsistenzmodell so funktioniert wie erwartet. Zeilenanzahlen und andere Ergebnisse sind auf der Isolationsstufe `READ COMMITTED` bei Aktivierung dieser Einstellung möglicherweise nicht streng konsistent. Sie sollten diese Einstellung daher typischerweise nur aktivieren, wenn Sie analytische Abfragen ausführen, die große Datenmengen aggregieren und für die keine absolute Präzision erforderlich ist. Wenn Sie nicht solche lang andauernden Abfragen zusammen mit schreibintensiven Workloads verwenden, benötigen Sie die `aurora_read_replica_read_committed`-Einstellung wahrscheinlich nicht. Ohne die Kombination aus lang andauernden Abfragen und schreibintensiven Workloads sind Probleme mit der Länge der Verlaufsliste unwahrscheinlich. **Example Abfragen mit Isolationsverhalten für READ COMMITTED auf Aurora-Replicas** Das folgende Beispiel zeigt, wie `READ COMMITTED`-Abfragen auf einer Aurora-Replica möglicherweise nicht wiederholbare Ergebnisse ausgeben, wenn Transaktionen gleichzeitig die zugehörigen Tabellen modifizieren. Die Tabelle `BIG_TABLE` enthält eine Million Zeilen vor Beginn jeder Anfrage. Andere DML- (Data Manipulation Language) Anweisungen fügen Zeilen hinzu, entfernen oder ändern sie. Die Abfragen auf der primären Aurora-Instance bei Isolierungsstufe `READ COMMITTED` führen zu vorhersehbaren Ergebnissen. Die Overheadlast, die damit verbunden ist, den Consistent-Lesevorgang für die gesamte Dauer einer lang andauernden Abfrage aufrechtzuerhalten, kann später zum umfangreichen Garbage Collection führen. Die Abfragen auf der Aurora-Replica bei Isolierungsstufe `READ COMMITTED` sind so optimiert, dass dieses Garbage-Collection-Overhead minimiert wird. Dies führt aber andererseits dazu, dass die Ergebnisse abweichen können, wenn die Abfragen auf Zeilen stoßen, die von Transaktionen, die während der Ausführung der Abfrage Commits durchführen, hinzugefügt, entfernt oder umorganisiert werden. Die Abfragen können diese Zeilen berücksichtigen, müssen dies aber nicht tun. Zu Demonstrationszwecken prüfen die Abfragen nur die Anzahl der Zeilen in der Tabelle mithilfe der `COUNT(*)`-Funktion. | Zeit | DML-Anweisung auf der primären Aurora-Instance | Abfrage auf der primären Aurora-Instance mit READ COMMITTED | Abfrage auf einer Aurora-Replica mit READ COMMITTED | | --- | --- | --- | --- | | T1 | INSERT INTO big\$1table SELECT \$1 FROM other\$1table LIMIT 1000000; COMMIT; | | | | T2 | | Q1: SELECT COUNT(\$1) FROM big\$1table; | Q2: SELECT COUNT(\$1) FROM big\$1table; | | T3 | INSERT INTO big\$1table (c1, c2) VALUES (1, 'one more row'); COMMIT; | | | | T4 | | Wenn Q1 jetzt beendet wird, ist das Ergebnis 1 000 000. | Wenn Q2 jetzt beendet wird, ist das Ergebnis 1 000 000 oder 1 000.001. | | T5 | DELETE FROM big\$1table LIMIT 2; COMMIT; | | | | T6 | | Wenn Q1 jetzt beendet wird, ist das Ergebnis 1 000 000. | Wenn Q2 jetzt beendet wird, ist das Ergebnis 1 000 000, 1 000 001, 999 999 oder 999 998. | | T7 | UPDATE big\$1table SET c2 = CONCAT(c2,c2,c2); COMMIT; | | | | T8 | | Wenn Q1 jetzt beendet wird, ist das Ergebnis 1 000 000. | Wenn Q2 jetzt beendet wird, ist das Ergebnis 1 000 000, 1 000 001, 999 999 oder möglicherweise eine höhere Zahl. | | T9 | | Q3: SELECT COUNT(\$1) FROM big\$1table; | Q4: SELECT COUNT(\$1) FROM big\$1table; | | T10 | | Wenn Q3 jetzt beendet wird, ist das Ergebnis 999.999. | Wenn Q4 jetzt beendet wird, ist das Ergebnis 999.999. | | T11 | | Q5: SELECT COUNT(\$1) FROM parent\$1table p JOIN child\$1table c ON (p.id = c.id) WHERE p.id = 1000; | Q6: SELECT COUNT(\$1) FROM parent\$1table p JOIN child\$1table c ON (p.id = c.id) WHERE p.id = 1000; | | T12 | INSERT INTO parent\$1table (id, s) VALUES (1000, 'hello'); INSERT INTO child\$1table (id, s) VALUES (1000, 'world'); COMMIT; | | | | T13 | | Wenn Q5 jetzt beendet wird, ist das Ergebnis 0. | Wenn Q6 jetzt beendet wird, ist das Ergebnis 0 oder 1. | Wenn die Abfragen schnell abgeschlossen sind, bevor andere Transaktionen DML-Anweisungen und Commits durchführen, sind die Ergebnisse vorhersehbar und zwischen der primären Instance und der Aurora-Replica identisch. Sehen wir uns die Verhaltensunterschiede im Detail an, beginnend mit der ersten Abfrage. Die Ergebnisse für Q1 sind äußerst vorhersehbar, weil `READ COMMITTED` auf der primären Instance ein starkes Konsistenzmodell ähnlich der Isolierungsstufe `REPEATABLE READ` verwendet. Die Ergebnisse für Q2 können je nachdem, welche Transaktionen während der Ausführung der Abfrage Commits durchführen, abweichen. Nehmen wir beispielsweise an, dass andere Transaktionen DML-Anweisungen und Commits durchführen, während die Abfragen laufen. In diesem Fall kann es sein, dass die Abfrage auf der Aurora-Replica mit Isolierungsstufe `READ COMMITTED` die Änderungen berücksichtigt oder nicht. Die Zeilenanzahlen sind dabei nicht in der gleichen Weise vorhersagbar wie bei Isolierungsstufe `REPEATABLE READ`. Sie sind auch nicht so vorhersagbar wie Abfragen mit Isolierungsstufe `READ COMMITTED` auf der primären Instance oder auf einer RDS für MySQL-Instance. Die `UPDATE`-Anweisung bei T7 ändert die Anzahl der Zeilen in der Tabelle nicht. Durch die Änderung der Länge einer Spalte mit variabler Länge kann diese Anweisung jedoch dazu führen, dass Zeilen intern umorganisiert werden. Eine lang andauernde `READ COMMITTED`-Transaktion kann zunächst die alte Version einer Zeile und später im Rahmen derselben Transaktion eine neue Version derselben Zeile sehen. Die Abfrage kann auch die alte und die neue Version der Zeile überspringen, so dass die Anzahl der Zeilen von der erwarteten abweicht. Die Ergebnisse von Q5 und Q6 können identisch oder leicht abweichend sein. Abfrage Q6 auf der Aurora-Replica unter `READ COMMITTED` kann, muss aber nicht, die neuen Zeilen sehen, für die während der Dauer der Abfrage ein Commit durchgeführt wird. Möglicherweise sieht sie auch die Zeile aus einer, aber nicht aus der anderen Tabelle. Wenn die Join-Abfrage keine übereinstimmende Zeile in beiden Tabellen findet, gibt sie die Anzahl 0 zurück. Wenn die Abfrage beide neuen Zeilen in `PARENT_TABLE` und `CHILD_TABLE` findet, gibt sie die Anzahl 1 zurück. In einer lang andauernden Anfrage können die Lookups aus den verbundenen Tabellen zu weit auseinanderliegenden Zeitpunkten stattfinden. Diese Verhaltensunterschiede hängen davon ab, wann für Transaktionen Commits durchgeführt werden, und wann die Abfragen die zugrunde liegenden Tabellenzeilen abfragen. Daher sind solche Unterschiede am wahrscheinlichsten in Berichtsabfragen, die mehrere Minuten oder Stunden dauern, und die auf Aurora-Clustern durchgeführt werden, die gleichzeitig OLTP-Transaktionen ausführen. Dies sind die Arten gemischter Workloads, die am meisten von der Isolierungsstufe `READ COMMITTED` auf Aurora-Replicas profitieren. # Aurora-MySQL-Hinweise Sie können SQL-Hinweise mit Aurora-MySQL-Abfragen verwenden, um die Leistung zu optimieren. Sie können auch Hinweise verwenden, um zu verhindern, dass Ausführungspläne für wichtige Abfragen aufgrund unvorhersehbarer Bedingungen geändert werden. **Tipp** Um zu überprüfen, welche Auswirkungen ein Hinweis auf eine Abfrage hat, überprüfen Sie den von der `EXPLAIN`-Anweisung erzeugten Abfrageplan. Vergleichen Sie die Abfragepläne mit und ohne Hinweis. In Aurora MySQL Version 3 können Sie alle Hinweise verwenden, die in der MySQL Community Edition 8.0 verfügbar sind. Weitere Informationen zu diesen Hinweisen finden Sie unter [Optimierungshinweise](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) im *MySQL-Referenzhandbuch*. Die folgenden Hinweise sind in Aurora MySQL Version 2 verfügbar. Diese Hinweise gelten für Abfragen, bei denen die Hash-Join-Funktion in Aurora MySQL Version 2 verwendet wird, insbesondere Abfragen, bei denen die parallele Abfrageoptimierung verwendet wird. **PQ, NO\$1PQ** Gibt an, ob der Optimierer gezwungen werden soll, Parallelabfragen pro Tabelle oder pro Abfrage zu verwenden. `PQ` zwingt den Optimierer, Parallelabfragen für bestimmte Tabellen oder die gesamte Abfrage (Block) zu verwenden. `NO_PQ` verhindert, dass der Optimierer Parallelabfragen für bestimmte Tabellen oder die gesamte Abfrage (Block) verwendet. Dieser Hinweis ist in Aurora MySQL 2.11 und höher verfügbar. In den folgenden Beispielen wird gezeigt, wie Sie diesen Hinweis verwenden können. Die Angabe eines Tabellennamens zwingt den Optimierer, den `PQ/NO_PQ`-Hinweis nur auf diese ausgewählten Tabellen anzuwenden. Wenn kein Tabellenname angegeben ist, wird der `PQ/NO_PQ`-Hinweis für alle vom Abfrageblock betroffenen Tabellen erzwungen. ``` EXPLAIN SELECT /*+ PQ() */ f1, f2 FROM num1 t1 WHERE f1 > 10 and f2 < 100; EXPLAIN SELECT /*+ PQ(t1) */ f1, f2 FROM num1 t1 WHERE f1 > 10 and f2 < 100; EXPLAIN SELECT /*+ PQ(t1,t2) */ f1, f2 FROM num1 t1, num1 t2 WHERE t1.f1 = t2.f21; EXPLAIN SELECT /*+ NO_PQ() */ f1, f2 FROM num1 t1 WHERE f1 > 10 and f2 < 100; EXPLAIN SELECT /*+ NO_PQ(t1) */ f1, f2 FROM num1 t1 WHERE f1 > 10 and f2 < 100; EXPLAIN SELECT /*+ NO_PQ(t1,t2) */ f1, f2 FROM num1 t1, num1 t2 WHERE t1.f1 = t2.f21; ``` **HASH\$1JOIN, NO\$1HASH\$1JOIN** Aktiviert oder deaktiviert die Funktion des Parallelabfragenoptimierers, auszuwählen, ob die Hash-Join-Optimierungsmethode für eine Abfrage verwendet werden soll. `HASH_JOIN` ermöglicht es dem Optimierer, Hash-Join zu verwenden, wenn dieser Mechanismus effizienter ist. `NO_HASH_JOIN` verhindert, dass der Optimierer Hash-Join für die Abfrage verwendet. Dieser Hinweis ist in Aurora MySQL 2.08 und höher verfügbar. Er hat keine Auswirkungen in Aurora-MySQL-Version 3. In den folgenden Beispielen wird gezeigt, wie Sie diesen Hinweis verwenden können. ``` EXPLAIN SELECT/*+ HASH_JOIN(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; EXPLAIN SELECT /*+ NO_HASH_JOIN(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; ``` **HASH\$1JOIN\$1PROBING, NO\$1HASH\$1JOIN\$1PROBING** Gibt in einer Hash-Join-Abfrage an, ob die angegebene Tabelle für die Testseite des Joins verwendet werden soll. Statt den gesamten Inhalt der Testtabelle zu lesen, wird über die Abfrage geprüft, ob Spaltenwerte aus der Build-Tabelle in der Testtabelle vorhanden sind. Mit `HASH_JOIN_PROBING` und `HASH_JOIN_BUILDING` können Sie angeben, wie Hash-Join-Abfragen verarbeitet werden, ohne die Tabellen innerhalb des Abfragetextes neu zu ordnen. Dieser Hinweis ist in Aurora MySQL 2.08 und höher verfügbar. Er hat keine Auswirkungen in Aurora-MySQL-Version 3. In den folgenden Beispielen wird gezeigt, wie Sie diesen Hinweis verwenden können. Die Angabe des `HASH_JOIN_PROBING`-Hinweises für die Tabelle `T2` hat den gleichen Effekt wie die Angabe von `NO_HASH_JOIN_PROBING` für die Tabelle `T1`. ``` EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_PROBING(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_PROBING(t1) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; ``` **HASH\$1JOIN\$1BUILDING, NO\$1HASH\$1JOIN\$1BUILDING** Gibt in einer Hash-Join-Abfrage an, ob die angegebene Tabelle für die Build-Seite des Joins verwendet werden soll oder nicht. Mit der Abfrage werden alle Zeilen aus dieser Tabelle verarbeitet, um die Liste der Spaltenwerte und den Querverweis auf die andere Tabelle zu erstellen. Mit `HASH_JOIN_PROBING` und `HASH_JOIN_BUILDING` können Sie angeben, wie Hash-Join-Abfragen verarbeitet werden, ohne die Tabellen innerhalb des Abfragetextes neu zu ordnen. Dieser Hinweis ist in Aurora MySQL 2.08 und höher verfügbar. Er hat keine Auswirkungen in Aurora-MySQL-Version 3. Im folgenden Beispiel wird gezeigt, wie Sie diesen Hinweis verwenden können. Die Angabe des `HASH_JOIN_BUILDING`-Hinweises für die Tabelle `T2` hat den gleichen Effekt wie die Angabe von `NO_HASH_JOIN_BUILDING` für die Tabelle `T1`. ``` EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_BUILDING(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_BUILDING(t1) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; ``` **JOIN\$1FIXED\$1ORDER** Gibt an, dass Tabellen in der Abfrage basierend auf der Reihenfolge, in der sie in der Abfrage aufgelistet sind, verknüpft werden. Dieser Hinweis ist besonders nützlich bei Abfragen mit drei oder mehr Tabellen. Er ist als Ersatz für den MySQL–H9inweis gedacht und entspricht dem MySQL-Hinweis [JOIN\$1FIXED\$1ORDER](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html). Dieser Hinweis ist in Aurora MySQL 2.08 und höher verfügbar. Im folgenden Beispiel wird gezeigt, wie Sie diesen Hinweis verwenden können. ``` EXPLAIN SELECT /*+ JOIN_FIXED_ORDER() */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id); ``` **JOIN\$1ORDER** Gibt die Join-Reihenfolge für die Tabellen in der Abfrage an. Dieser Hinweis ist besonders nützlich bei Abfragen mit drei oder mehr Tabellen. Er entspricht dem MySQL-[JOIN\$1ORDER](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html)-Hinweis. Dieser Hinweis ist in Aurora MySQL 2.08 und höher verfügbar. Im folgenden Beispiel wird gezeigt, wie Sie diesen Hinweis verwenden können. ``` EXPLAIN SELECT /*+ JOIN_ORDER (t4, t2, t1, t3) */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id); ``` **JOIN\$1PREFIX** Gibt die Tabellen an, die in der Join-Reihenfolge an erster Stelle stehen sollen. Dieser Hinweis ist besonders nützlich bei Abfragen mit drei oder mehr Tabellen. Er entspricht dem MySQL-[JOIN\$1PREFIX](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html)-Hinweis. Dieser Hinweis ist in Aurora MySQL 2.08 und höher verfügbar. Im folgenden Beispiel wird gezeigt, wie Sie diesen Hinweis verwenden können. ``` EXPLAIN SELECT /*+ JOIN_PREFIX (t4, t2) */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id); ``` **JOIN\$1SUFFIX** Gibt die Tabellen an, die in der Join-Reihenfolge an letzter Stelle stehen sollen. Dieser Hinweis ist besonders nützlich bei Abfragen mit drei oder mehr Tabellen. Er entspricht dem MySQL-[JOIN\$1SUFFIX](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html)-Hinweis. Dieser Hinweis ist in Aurora MySQL 2.08 und höher verfügbar. Im folgenden Beispiel wird gezeigt, wie Sie diesen Hinweis verwenden können. ``` EXPLAIN SELECT /*+ JOIN_SUFFIX (t1) */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id); ``` Informationen zur Verwendung von Hash-Join-Abfragen finden Sie unter [Optimierung von großen Aurora-MySQL-Join-Abfragen mit Hash-Joins](AuroraMySQL.BestPractices.Performance.md#Aurora.BestPractices.HashJoin). # Referenz für gespeicherte Aurora-MySQL-Prozeduren Sie können Ihren Aurora MySQL-DB-Clusters durch Aufrufen integrierter gespeicherter Verfahren verwalten. **Topics** + [Erfassen und Verwalten des globalen Statusverlaufs](mysql-stored-proc-gsh.md) + [Konfigurieren, Starten und Beenden der Binärprotokollreplikation (binlog)](mysql-stored-proc-replicating.md) + [Beenden einer Sitzung oder Abfrage](mysql-stored-proc-ending.md) + [Transaktionen replizieren mit GTIDs](mysql-stored-proc-gtid.md) + [Rotieren der Abfrageprotokolle](mysql-stored-proc-logging.md) + [Festlegen und Anzeigen der Konfiguration des Binärprotokolls](mysql-stored-proc-configuring.md) # Erfassen und Verwalten des globalen Statusverlaufs Amazon RDS stellt einen Satz von Verfahren bereit, die Snapshots der Werte dieser Statusvariablen im Zeitverlauf erstellen und diese zusammen mit allen Änderungen seit dem letzten Snapshot in eine Tabelle schreiben. Diese Infrastruktur wird als Global Status History bezeichnet. Weitere Informationen finden Sie unter [Verwalten des globalen Statusverlaufs](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH). Die folgenden gespeicherten Prozeduren verwalten, wie die Global Status History erfasst und verwaltet wird. **Topics** + [mysql.rds\$1collect\$1global\$1status\$1history](#mysql_rds_collect_global_status_history) + [mysql.rds\$1disable\$1gsh\$1collector](#mysql_rds_disable_gsh_collector) + [mysql.rds\$1disable\$1gsh\$1rotation](#mysql_rds_disable_gsh_rotation) + [mysql.rds\$1enable\$1gsh\$1collector](#mysql_rds_enable_gsh_collector) + [mysql.rds\$1enable\$1gsh\$1rotation](#mysql_rds_enable_gsh_rotation) + [mysql.rds\$1rotate\$1global\$1status\$1history](#mysql_rds_rotate_global_status_history) + [mysql.rds\$1set\$1gsh\$1collector](#mysql_rds_set_gsh_collector) + [mysql.rds\$1set\$1gsh\$1rotation](#mysql_rds_set_gsh_rotation) ## mysql.rds\$1collect\$1global\$1status\$1history Generiert einen Snapshot auf Anforderung für den globalen Statusverlauf (Global Status History, GoSH). ### Syntax ``` CALL mysql.rds_collect_global_status_history; ``` ## mysql.rds\$1disable\$1gsh\$1collector Deaktiviert die periodische Generierung von Snapshots des globalen Statusverlaufs (Global Status History, GoSH). ### Syntax ``` CALL mysql.rds_disable_gsh_collector; ``` ## mysql.rds\$1disable\$1gsh\$1rotation Schaltet die Rotation der `mysql.global_status_history`-Tabelle aus. ### Syntax ``` CALL mysql.rds_disable_gsh_rotation; ``` ## mysql.rds\$1enable\$1gsh\$1collector Aktiviert den globalen Statusverlauf (Global Status History, GoSH), um Standard-Snapshots in zeitlichen Abständen, die mithilfe von `rds_set_gsh_collector` festgelegt wurden, zu generieren. ### Syntax ``` CALL mysql.rds_enable_gsh_collector; ``` ## mysql.rds\$1enable\$1gsh\$1rotation Aktiviert die Rotation der Inhalte der Tabelle `mysql.global_status_history` zu `mysql.global_status_history_old` in zeitlichen Abständen, die durch `rds_set_gsh_rotation` angegeben werden. ### Syntax ``` CALL mysql.rds_enable_gsh_rotation; ``` ## mysql.rds\$1rotate\$1global\$1status\$1history Rotiert die Inhalte der Tabelle `mysql.global_status_history` bei Anforderung zu `mysql.global_status_history_old`. ### Syntax ``` CALL mysql.rds_rotate_global_status_history; ``` ## mysql.rds\$1set\$1gsh\$1collector Gibt den zeitlichen Abstand für die Generierung von aufeinander folgenden Snapshots durch den globalen Statusverlauf (Global Status History, GoSH) an. ### Syntax ``` CALL mysql.rds_set_gsh_collector(intervalPeriod); ``` ### Parameter *intervalPeriod* Der zeitliche Abstand in Minuten für die periodische Generierung von Snapshots. Der Standardwert ist `5`. ## mysql.rds\$1set\$1gsh\$1rotation Gibt den zeitlichen Abstand in Tagen für die periodische Rotation der Tabelle `mysql.global_status_history` an. ### Syntax ``` CALL mysql.rds_set_gsh_rotation(intervalPeriod); ``` ### Parameter *intervalPeriod* Der zeitliche Abstand in Tagen für die periodische Tabellenrotation. Der Standardwert ist `7`. # Konfigurieren, Starten und Beenden der Binärprotokollreplikation (binlog) Sie können die folgenden gespeicherten Prozeduren aufrufen, während Sie mit der primären Instance in einem Aurora MySQL-Cluster verbunden sind. Diese Verfahren steuern, wie Transaktionen aus einer externen Datenbank in Aurora MySQL oder aus Aurora MySQL in einer externen Datenbank repliziert werden. **Topics** + [mysql.rds\$1disable\$1session\$1binlog (Aurora-MySQL-Version 2)](#mysql_rds_disable_session_binlog) + [mysql.rds\$1enable\$1session\$1binlog (Aurora-MySQL-Version 2)](#mysql_rds_enable_session_binlog) + [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) + [mysql.rds\$1next\$1master\$1log )](#mysql_rds_next_master_log) + [mysql.rds\$1next\$1source\$1log (Aurora-MySQL-Version 3)](#mysql_rds_next_source_log) + [mysql.rds\$1remove\$1binlog\$1ssl\$1material](#mysql_rds_remove_binlog_ssl_material) + [mysql.rds\$1next\$1master\$1log (Aurora-MySQL-Version 2)](#mysql_rds_reset_external_master) + [mysql.rds\$1next\$1source\$1log (Aurora-MySQL-Version 3)](#mysql_rds_reset_external_source) + [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora-MySQL-version 3)](#mysql_rds_set_binlog_source_ssl) + [mysql.rds\$1set\$1external\$1master (Aurora-MySQL-Version 2)](#mysql_rds_set_external_master) + [mysql.rds\$1set\$1external\$1source (Aurora-MySQL- Version 3)](#mysql_rds_set_external_source) + [mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (Aurora-MySQL-Version 2)](#mysql_rds_set_external_master_with_auto_position) + [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL Version 3)](#mysql_rds_set_external_source_with_auto_position) + [mysql.rds\$1set\$1master\$1auto\$1position )](#mysql_rds_set_master_auto_position) + [mysql.rds\$1set\$1read\$1only (Aurora-MySQL-Version 3)](#mysql_rds_set_read_only) + [mysql.rds\$1set\$1session\$1binlog\$1format (Aurora-MySQL-Version 2)](#mysql_rds_set_session_binlog_format) + [mysql.rds\$1set\$1source\$1auto\$1position (Aurora-MySQL-Version 3)](#mysql_rds_set_source_auto_position) + [mysql.rds\$1skip\$1repl\$1error](#mysql_rds_skip_repl_error) + [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) + [mysql.rds\$1start\$1replication\$1until (Aurora MySQL Version 3)](#mysql_rds_start_replication_until) + [mysql.rds\$1stop\$1replication](#mysql_rds_stop_replication) ## mysql.rds\$1disable\$1session\$1binlog (Aurora-MySQL-Version 2) Deaktiviert die binäre Protokollierung für die aktuelle Sitzung, indem die Variable `sql_log_bin` auf `OFF` festgelegt wird. ### Syntax ``` CALL mysql.rds_disable_session_binlog; ``` ### Parameters Keine ### Nutzungshinweise Sie rufen dieses gespeicherte Verfahren für einen Aurora MySQL-DB-Cluster auf, während Sie mit der primären Instance verbunden sind. Für Aurora wird dieses Verfahren für Aurora-MySQL-Version 2.12 und höher und MySQL-5.7-kompatible Versionen unterstützt. **Anmerkung** In Aurora-MySQL-Version 3 können Sie den folgenden Befehl verwenden, um die Binärprotokollierung für die aktuelle Sitzung zu deaktivieren, sofern Sie über die entsprechenden `SESSION_VARIABLES_ADMIN`-Berechtigungen verfügen: ``` SET SESSION sql_log_bin = OFF; ``` ## mysql.rds\$1enable\$1session\$1binlog (Aurora-MySQL-Version 2) Aktiviert die binäre Protokollierung für die aktuelle Sitzung, indem die Variable `sql_log_bin` auf `ON` festgelegt wird. ### Syntax ``` CALL mysql.rds_enable_session_binlog; ``` ### Parameters Keine ### Nutzungshinweise Sie rufen dieses gespeicherte Verfahren für einen Aurora MySQL-DB-Cluster auf, während Sie mit der primären Instance verbunden sind. Für Aurora wird dieses Verfahren für Aurora-MySQL-Version 2.12 und höher und MySQL-5.7-kompatible Versionen unterstützt. **Anmerkung** In Aurora-MySQL-Version 3 können Sie den folgenden Befehl verwenden, um die Binärprotokollierung für die aktuelle Sitzung zu aktivieren, sofern Sie über die entsprechenden `SESSION_VARIABLES_ADMIN`-Berechtigungen verfügen: ``` SET SESSION sql_log_bin = ON; ``` ## mysql.rds\$1import\$1binlog\$1ssl\$1material Importiert das Zertifizierungsstellenzertifikat, das Clientzertifikat und den Clientschlüssel in eine/einen Aurora-MySQL-DB-Cluster. Die Informationen werden für die SSL-Kommunikation und die verschlüsselte Replikation benötigt. **Anmerkung** Derzeit wird dieses Verfahren für folgende Aurora-MySQL 2-Versionen unterstützt: 2.09.2, 2.10.0, 2.10.1 und 2.11.0; sowie Version 3: 3.01.1 und höher. ### Syntax ``` CALL mysql.rds_import_binlog_ssl_material ( ssl_material ); ``` ### Parameters *ssl\$1material* JSON-Nutzlast mit dem Inhalt der folgenden PEM-Dateien für einen MySQL-Client: + „ssl\$1ca“:““ *Certificate authority certificate* + „ssl\$1cert“:““ *Client certificate* + „ssl\$1key“:““ *Client key* ### Nutzungshinweise Bereiten Sie die verschlüsselte Replikation vor, bevor Sie diese Schritte durchführen: + Wenn SSL auf dem externen Server mit der MySQL-Quelldatenbankinstance nicht aktiviert ist und Sie keinen Clientschlüssel und kein Clientzertifikat vorbereitet haben, aktivieren Sie SSL auf dem MySQL-Datenbankserver und generieren Sie den Clientschlüssel und das Clientzertifikat. + Wenn SSL auf der externen Quelldatenbankinstance aktiviert ist, geben Sie einen Clientschlüssel und ein Clientzertifikat für das Aurora MySQL-DB-Cluster an. Wenn Sie diese Werte nicht haben, erstellen Sie ein einen neuen Schlüssel und ein neues Zertifikat für das Aurora MySQL-DB-Cluster. Sie benötigen zur Signierung des Clientzertifikats den Zertifizierungsstellenschlüssel, den Sie zum Konfigurieren von SSL auf der externen MySQL-Quelldatenbankinstance verwendet haben. Weitere Informationen finden Sie unter [ Creating SSL Certificates and Keys Using openssl](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html) in der MySQL-Dokumentation. **Wichtig** Führen Sie nach dem Vorbereiten der verschlüsselten Replikation die folgenden Schritte über eine SSL-Verbindung durch. Der Clientschlüssel darf nicht über eine unsichere Verbindung übertragen werden. Bei diesem Vorgang werden SSL-Informationen aus einer externen MySQL-Datenbank in ein Aurora MySQL-DB-Cluster importiert. Die SSL-Informationen für das Aurora MySQL-DB-Cluster befinden sich in PEM-Dateien. Während der verschlüsselten Replikation dient das Aurora MySQL-DB-Cluster als Client für den MySQL-Datenbankserver. Die Zertifikate und Schlüssel für den Aurora MySQL-Client befinden sich in Dateien im PEM-Format. Sie können die Informationen aus diesen Dateien in den Parameter `ssl_material` in der richtigen JSON-Nutzlast kopieren. Um die verschlüsselte Replikation zu unterstützen, importieren Sie diese SSL-Informationen in das Aurora MySQL-DB-Cluster. Die JSON-Nutzlast muss das folgende Format aufweisen. ``` '{"ssl_ca":"-----BEGIN CERTIFICATE----- ssl_ca_pem_body_code -----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE----- ssl_cert_pem_body_code -----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY----- ssl_key_pem_body_code -----END RSA PRIVATE KEY-----\n"}' ``` ### Beispiele Im folgenden Beispiel werden SSL-Informationen in eine Aurora MySQL importiert. Der Code in den PEM-Dateien ist in der Regel länger als in diesem Beispiel. ``` call mysql.rds_import_binlog_ssl_material( '{"ssl_ca":"-----BEGIN CERTIFICATE----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END RSA PRIVATE KEY-----\n"}'); ``` ## mysql.rds\$1next\$1master\$1log ) Ändert die Protokollposition der Quelldatenbankinstance in den Anfang des nächsten Binärprotokolls auf der Quelldatenbankinstance. Verwenden Sie dieses Verfahren nur, wenn Sie bei einer Read Replica den Replikationsfehler 1236 erhalten. I/O ### Syntax ``` CALL mysql.rds_next_master_log( curr_master_log ); ``` ### Parameters *curr\$1master\$1log* Der Index der aktuellen Master-Protokolldatei. Der Index ist im Dateinamen codiert. Eine aktuelle Datei mit dem Namen `mysql-bin-changelog.012345` hat beispielsweise den Index 12345. Um den Namen der aktuellen Master-Protokolldatei zu ermitteln, führen Sie den Befehl `SHOW REPLICA STATUS` aus. Sie finden den Namen anschließend im Feld `Master_Log_File`. ### Nutzungshinweise Die Prozedur `mysql.rds_next_master_log` muss vom Hauptbenutzer ausgeführt werden. **Warnung** Rufen Sie `mysql.rds_next_master_log` nur auf, wenn die Replikation nach einem Failover einer Multi-AZ-DB-Instance, die die Replikationsquelle ist, fehlschlägt und das `Last_IO_Errno` Feld den Fehler 1236 meldet. `SHOW REPLICA STATUS` I/O Ein Aufruf von `mysql.rds_next_master_log` kann zu Datenverlust im Lesereplikat führen, falls Transaktionen in der Quell-Instance nicht in das binäre Protokoll auf der Festplatte geschrieben wurden, bevor das Failover-Ereignis auftrat. ### Beispiele Angenommen, die Replikation schlägt auf einer - Aurora-MySQL-Read Replica fehl. Die Ausführung von `SHOW REPLICA STATUS\G` für das Lesereplikat gibt das folgende Ergebnis zurück: ``` *************************** 1. row *************************** Replica_IO_State: Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com Source_User: MasterUser Source_Port: 3306 Connect_Retry: 10 Source_Log_File: mysql-bin-changelog.012345 Read_Source_Log_Pos: 1219393 Relay_Log_File: relaylog.012340 Relay_Log_Pos: 30223388 Relay_Source_Log_File: mysql-bin-changelog.012345 Replica_IO_Running: No Replica_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Source_Log_Pos: 30223232 Relay_Log_Space: 5248928866 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Source_SSL_Allowed: No Source_SSL_CA_File: Source_SSL_CA_Path: Source_SSL_Cert: Source_SSL_Cipher: Source_SSL_Key: Seconds_Behind_Master: NULL Source_SSL_Verify_Server_Cert: No Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.' Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Source_Server_Id: 67285976 ``` Den Angeben im Feld `Last_IO_Errno` ist zu entnehmen, dass die Instance eine I/O-Fehlermeldung mit der Nummer 1236 erhalten hat. Dem Feld `Master_Log_File` ist zudem zu entnehmen, dass die betroffene Protokolldatei den Namen `mysql-bin-changelog.012345` aufweist und ihr Index folglich `12345` lautet. Zur Behebung des Fehlers können Sie dann `mysql.rds_next_master_log` mit dem folgenden Parameter aufrufen: ``` CALL mysql.rds_next_master_log(12345); ``` ## mysql.rds\$1next\$1source\$1log (Aurora-MySQL-Version 3) Ändert die Protokollposition der Quelldatenbankinstance in den Anfang des nächsten Binärprotokolls auf der Quelldatenbankinstance. Verwenden Sie dieses Verfahren nur, wenn Sie bei einer Read Replica den I/O Replikationsfehler 1236 erhalten. ### Syntax ``` CALL mysql.rds_next_source_log( curr_source_log ); ``` ### Parameters *curr\$1source\$1log* Der Index der aktuellen Quell-Protokolldatei. Der Index ist im Dateinamen codiert. Eine aktuelle Datei mit dem Namen `mysql-bin-changelog.012345` hat beispielsweise den Index 12345. Um den Namen der aktuellen Quell-Protokolldatei zu ermitteln, führen Sie den Befehl `SHOW REPLICA STATUS` aus. Sie finden den Namen anschließend im Feld `Source_Log_File`. ### Nutzungshinweise Der Administrator muss das `mysql.rds_next_source_log`-Verfahren ausführen. **Warnung** Rufen Sie `mysql.rds_next_source_log` nur auf, wenn die Replikation nach einem Failover einer Multi-AZ-DB-Instance, die die Replikationsquelle ist, fehlschlägt und das `Last_IO_Errno` Feld den Fehler 1236 meldet. `SHOW REPLICA STATUS` I/O Ein Aufruf von `mysql.rds_next_source_log` kann zu Datenverlust im Lesereplikat führen, falls Transaktionen in der Quell-Instance nicht in das binäre Protokoll auf der Festplatte geschrieben wurden, bevor das Failover-Ereignis auftrat. Sie können durch Festlegung der Quell-Instance-Parameter `sync_binlog` und `innodb_support_xa` auf `1` das Risiko dafür verringern, obwohl dies zu einer Reduzierung der Leistung führen kann. ### Beispiele Angenommen, die Replikation schlägt auf einer - Aurora-MySQL-Read Replica fehl. Die Ausführung von `SHOW REPLICA STATUS\G` für das Lesereplikat gibt das folgende Ergebnis zurück: ``` *************************** 1. row *************************** Replica_IO_State: Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com Source_User: MasterUser Source_Port: 3306 Connect_Retry: 10 Source_Log_File: mysql-bin-changelog.012345 Read_Source_Log_Pos: 1219393 Relay_Log_File: relaylog.012340 Relay_Log_Pos: 30223388 Relay_Source_Log_File: mysql-bin-changelog.012345 Replica_IO_Running: No Replica_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Source_Log_Pos: 30223232 Relay_Log_Space: 5248928866 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Source_SSL_Allowed: No Source_SSL_CA_File: Source_SSL_CA_Path: Source_SSL_Cert: Source_SSL_Cipher: Source_SSL_Key: Seconds_Behind_Source: NULL Source_SSL_Verify_Server_Cert: No Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from source when reading data from binary log: 'Client requested source to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.' Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Source_Server_Id: 67285976 ``` Den Angeben im Feld `Last_IO_Errno` ist zu entnehmen, dass die Instance eine I/O-Fehlermeldung mit der Nummer 1236 erhalten hat. Dem Feld `Source_Log_File` ist zudem zu entnehmen, dass die betroffene Protokolldatei den Namen `mysql-bin-changelog.012345` aufweist und ihr Index folglich `12345` lautet. Zur Behebung des Fehlers können Sie dann `mysql.rds_next_source_log` mit dem folgenden Parameter aufrufen: ``` CALL mysql.rds_next_source_log(12345); ``` ## mysql.rds\$1remove\$1binlog\$1ssl\$1material Entfernt das Zertifizierungsstellenzertifikat, das Clientzertifikat und den Clientschlüssel für SSL-Kommunikation und verschlüsselte Replikation. Diese Informationen werden mit importier [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material). ### Syntax ``` CALL mysql.rds_remove_binlog_ssl_material; ``` ## mysql.rds\$1next\$1master\$1log (Aurora-MySQL-Version 2) Rekonfiguriert eine Aurora-MySQL-DB-Instance, sodass sie keine Read Replica einer Instance von MySQL außerhalb von Amazon RDS ist. **Wichtig** Um diese Prozedur auszuführen, muss `autocommit` aktiviert sein. Um dies zu aktivieren, setzen Sie den `autocommit`-Parameter auf `1`. Weitere Informationen zum Ändern von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md). ### Syntax ``` CALL mysql.rds_reset_external_master; ``` ### Nutzungshinweise Die Prozedur `mysql.rds_reset_external_master` muss vom Hauptbenutzer ausgeführt werden. Diese Prozedur muss auf der MySQL-DB-Instance ausgeführt werden, die nicht mehr Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance sein soll. **Anmerkung** Wir bieten diese gespeicherten Prozeduren hauptsächlich an, um die Replikation mit MySQL-Instances zu ermöglichen, die außerhalb von Amazon RDS ausgeführt werden. Wir empfehlen die Verwendung von Aurora Replicas, um die Replikation innerhalb eines DB-Clusters von Aurora MySQL zu verwalten, wenn dies möglich ist. Informationen zur Verwaltung der Replikation in DB-Clustern von Aurora MySQL finden Sie unter [Verwendung von Aurora-Replicas](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas). Weitere Informationen zur Verwendung der Replikation für den Import von Daten aus einer außerhalb von Aurora MySQL ausgeführten Instance finden Sie unter [Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)](AuroraMySQL.Replication.MySQL.md). ## mysql.rds\$1next\$1source\$1log (Aurora-MySQL-Version 3) Rekonfiguriert eine Aurora-MySQL-DB-Instance, sodass sie keine Read Replica einer Instance von MySQL außerhalb von Amazon RDS ist. **Wichtig** Um diese Prozedur auszuführen, muss `autocommit` aktiviert sein. Um dies zu aktivieren, setzen Sie den `autocommit`-Parameter auf `1`. Weitere Informationen zum Ändern von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md). ### Syntax ``` CALL mysql.rds_reset_external_source; ``` ### Nutzungshinweise Der Administrator muss das `mysql.rds_reset_external_source`-Verfahren ausführen. Diese Prozedur muss auf der MySQL-DB-Instance ausgeführt werden, die nicht mehr Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance sein soll. **Anmerkung** Wir bieten diese gespeicherten Prozeduren hauptsächlich an, um die Replikation mit MySQL-Instances zu ermöglichen, die außerhalb von Amazon RDS ausgeführt werden. Wir empfehlen die Verwendung von Aurora Replicas, um die Replikation innerhalb eines DB-Clusters von Aurora MySQL zu verwalten, wenn dies möglich ist. Informationen zur Verwaltung der Replikation in DB-Clustern von Aurora MySQL finden Sie unter [Verwendung von Aurora-Replicas](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas). ## mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora-MySQL-version 3) Aktiviert die `SOURCE_SSL`-Verschlüsselung für die Binlog-Replikation. Weitere Informationen finden Sie unter [CHANGE REPLICATION SOURCE TO-Anweisung](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html) in der MySQL-Dokumentation. ### Syntax ``` CALL mysql.rds_set_binlog_source_ssl(mode); ``` ### Parameters *mode* Ein Wert, der angibt, ob die `SOURCE_SSL`-Verschlüsselung aktiviert ist: + `0` – Die `SOURCE_SSL`-Verschlüsselung ist deaktiviert. Der Standardwert ist `0`. + `1` – Die `SOURCE_SSL`-Verschlüsselung ist aktiviert. Sie können die Verschlüsselung mit SSL oder TLS konfigurieren. ### Nutzungshinweise Diese Prozedur wird für Aurora-MySQL-Version 3.06 und höher unterstützt. ## mysql.rds\$1set\$1external\$1master (Aurora-MySQL-Version 2) Konfiguriert eine Aurora-MySQL-Instance für die Verwendung als Read Replica einer außerhalb von Amazon RDS ausgeführten MySQL-Instance. Das `mysql.rds_set_external_master`-Verfahren ist veraltet und wird in einer künftigen Version entfernt. Verwenden Sie stattdessen `mysql.rds\$1set\$1external\$1source`. **Wichtig** Um diese Prozedur auszuführen, muss `autocommit` aktiviert sein. Um dies zu aktivieren, setzen Sie den `autocommit`-Parameter auf `1`. Weitere Informationen zum Ändern von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md). ### Syntax ``` CALL mysql.rds_set_external_master ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption ); ``` ### Parameters *host\$1name* Der Hostname bzw. die IP-Adresse der außerhalb von Amazon RDS ausgeführten MySQL-Instance, die als Quelldatenbank-Instance festgelegt werden soll. *host\$1port* Der Port, der von der außerhalb von Amazon RDS ausgeführten MySQL-Instance verwendet wird, die als Quelldatenbank-Instance konfiguriert werden soll. Wenn Ihre Netzwerkkonfiguration die Replikation über Secure Shell (SSH)-Ports einschließt, welche die Portnummer konvertiert, geben Sie für diesen Parameter die von SSH offengelegte Portnummer an. *replication\$1user\$1name* Die ID eines Benutzers mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` auf der MySQL-Instance, die extern zu Amazon RDS ausgeführt wird. Es wird empfohlen, ein Benutzerkonto bereitzustellen, das ausschließlich für die Replikation mit der externen Instance genutzt wird. *replication\$1user\$1password* Das zu dem in `replication_user_name` angegebenen User-ID gehörige Passwort. *mysql\$1binary\$1log\$1file\$1name* Der Name des Binärprotokolls auf der Quelldatenbank-Instance, die die Replikationsinformationen enthält. *mysql\$1binary\$1log\$1file\$1location* Die Position in der binären Protokolldatei `mysql_binary_log_file_name`, ab der bei der Replikation die Replikationsinformationen gelesen werden. Sie können den Namen und den Speicherort der Binlog-Datei ermitteln, indem Sie `SHOW MASTER STATUS`auf der Quelldatenbank-Instance starten. *ssl\$1encryption* Ein Wert, der angibt, ob die SSL-Verschlüsselung (Secure Socket Layer) für die Replikationsverbindung verwendet wird. 1 = SSL-Verschlüsselung, 0 = keine Verschlüsselung. Der Standardwert ist 0. Die Option `MASTER_SSL_VERIFY_SERVER_CERT` wird nicht unterstützt. Diese Option ist auf 0 gesetzt, was bedeutet, dass die Verbindung verschlüsselt ist, aber die Zertifikate nicht überprüft werden. ### Nutzungshinweise Die Prozedur `mysql.rds_set_external_master` muss vom Hauptbenutzer ausgeführt werden. Diese Prozedur muss auf der MySQL-DB-Instance ausgeführt werden, die als Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance konfiguriert werden soll. Vor der Ausführung von `mysql.rds_set_external_master` müssen Sie zuerst die außerhalb von Amazon RDS ausgeführte MySQL-Instance für die Verwendung als Quelldatenbank-Instance konfigurieren. Um eine Verbindung zu der außerhalb von Amazon RDS ausgeführten MySQL-Instance herzustellen, müssen Sie Werte für `replication_user_name` und `replication_user_password` bereitstellen, die auf einen Replikationsbenutzer verweisen, der über die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für die externe MySQL-Instance verfügt. **So konfigurieren Sie eine externe Instance von MySQL als Quelldatenbank-Instance** 1. Verbinden Sie sich mithilfe eines MySQL-Clients Ihrer Wahl mit der externen MySQL-Instance und erstellen Sie ein Benutzerkonto, das für die Replikation verwendet werden soll. Im Folgenden wird ein -Beispiel gezeigt. **MySQL 5.7** ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **MySQL 8.0** ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED WITH mysql_native_password BY 'password'; ``` **Anmerkung** Geben Sie aus Sicherheitsgründen ein anderes Passwort als hier angegeben an. 1. Erteilen Sie innerhalb der externen MySQL-Instance Ihrem Replikationsbenutzer die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE`. Im folgenden Beispiel werden dem Benutzer 'repl\$1user' für Ihre Domäne die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für alle Datenbanken erteilt. **MySQL 5.7** ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **MySQL 8.0** ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'; ``` Um die verschlüsselte Replikation zu verwenden, konfigurieren Sie die Quelldatenbank-Instance für die Verwendung von SSL-Verbindungen. Importieren Sie außerdem mit der Prozedur [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) das Zertifizierungsstellenzertifikat, das Clientzertifikat und den Clientschlüssel in die DB-Instance bzw. das DB-Cluster. **Anmerkung** Wir bieten diese gespeicherten Prozeduren hauptsächlich an, um die Replikation mit MySQL-Instances zu ermöglichen, die außerhalb von Amazon RDS ausgeführt werden. Wir empfehlen die Verwendung von Aurora Replicas, um die Replikation innerhalb eines DB-Clusters von Aurora MySQL zu verwalten, wenn dies möglich ist. Informationen zur Verwaltung der Replikation in DB-Clustern von Aurora MySQL finden Sie unter [Verwendung von Aurora-Replicas](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas). Nachdem Sie `mysql.rds_set_external_master` aufgerufen haben, um eine Amazon-RDS-DB-Instance als Lesereplikat zu konfigurieren, können Sie [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) für das Lesereplikat aufrufen, um die Replikation zu starten Zudem haben Sie die Möglichkeit, mit einem Aufruf von [mysql.rds\$1next\$1master\$1log (Aurora-MySQL-Version 2)](#mysql_rds_reset_external_master) die Lesereplikat-Konfiguration zu entfernen. Beim Aufrufen von `mysql.rds_set_external_master` werden von Amazon RDS Uhrzeit, Benutzer und eine Aktion von `set master` in den Tabellen `mysql.rds_history` und `mysql.rds_replication_status` protokolliert. ### Beispiele Bei Ausführung innerhalb einer MySQL-DB-Instance konfiguriert das folgende Beispiel diese DB-Instance für die Verwendung als Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance. ``` call mysql.rds_set_external_master( 'Externaldb.some.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.0777', 120, 1); ``` ## mysql.rds\$1set\$1external\$1source (Aurora-MySQL- Version 3) Konfiguriert eine Aurora-MySQL-Instance für die Verwendung als Read Replica einer außerhalb von Amazon RDS ausgeführten MySQL-Instance. **Wichtig** Um diese Prozedur auszuführen, muss `autocommit` aktiviert sein. Um dies zu aktivieren, setzen Sie den `autocommit`-Parameter auf `1`. Weitere Informationen zum Ändern von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md). ### Syntax ``` CALL mysql.rds_set_external_source ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption ); ``` ### Parameters *host\$1name* Der Hostname bzw. die IP-Adresse der außerhalb von Amazon RDS ausgeführten MySQL-Instance, die als Quelldatenbank-Instance festgelegt werden soll. *host\$1port* Der Port, der von der außerhalb von Amazon RDS ausgeführten MySQL-Instance verwendet wird, die als Quelldatenbank-Instance konfiguriert werden soll. Wenn Ihre Netzwerkkonfiguration die Replikation über Secure Shell (SSH)-Ports einschließt, welche die Portnummer konvertiert, geben Sie für diesen Parameter die von SSH offengelegte Portnummer an. *replication\$1user\$1name* Die ID eines Benutzers mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` auf der MySQL-Instance, die extern zu Amazon RDS ausgeführt wird. Es wird empfohlen, ein Benutzerkonto bereitzustellen, das ausschließlich für die Replikation mit der externen Instance genutzt wird. *replication\$1user\$1password* Das zu dem in `replication_user_name` angegebenen User-ID gehörige Passwort. *mysql\$1binary\$1log\$1file\$1name* Der Name des Binärprotokolls auf der Quelldatenbank-Instance, die die Replikationsinformationen enthält. *mysql\$1binary\$1log\$1file\$1location* Die Position in der binären Protokolldatei `mysql_binary_log_file_name`, ab der bei der Replikation die Replikationsinformationen gelesen werden. Sie können den Namen und den Speicherort der Binlog-Datei ermitteln, indem Sie `SHOW MASTER STATUS`auf der Quelldatenbank-Instance starten. *ssl\$1encryption* Ein Wert, der angibt, ob die SSL-Verschlüsselung (Secure Socket Layer) für die Replikationsverbindung verwendet wird. 1 = SSL-Verschlüsselung, 0 = keine Verschlüsselung. Der Standardwert ist 0. Sie müssen ein benutzerdefiniertes SSL-Zertifikat mit [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) importiert haben, um diese Option zu aktivieren. Wenn Sie kein benutzerdefiniertes SSL-Zertifikat importiert haben, legen Sie diesen Parameter auf 0 fest und verwenden Sie [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora-MySQL-version 3)](#mysql_rds_set_binlog_source_ssl), um SSL für die binäre Protokollreplikation zu aktivieren. Die Option `SOURCE_SSL_VERIFY_SERVER_CERT` wird nicht unterstützt. Diese Option ist auf 0 gesetzt, was bedeutet, dass die Verbindung verschlüsselt ist, aber die Zertifikate nicht überprüft werden. ### Nutzungshinweise Der Administrator muss das `mysql.rds_set_external_source`-Verfahren ausführen. Dieses Verfahren muss auf der DB-Instance von Aurora MySQL ausgeführt werden, die als Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance konfiguriert werden soll. Vor der Ausführung von `mysql.rds_set_external_source` müssen Sie zuerst die außerhalb von Amazon RDS ausgeführte MySQL-Instance für die Verwendung als Quelldatenbank-Instance konfigurieren. Um eine Verbindung zu der außerhalb von Amazon RDS ausgeführten MySQL-Instance herzustellen, müssen Sie Werte für `replication_user_name` und `replication_user_password` bereitstellen, die auf einen Replikationsbenutzer verweisen, der über die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für die externe MySQL-Instance verfügt. **So konfigurieren Sie eine externe Instance von MySQL als Quelldatenbank-Instance** 1. Verbinden Sie sich mithilfe eines MySQL-Clients Ihrer Wahl mit der externen MySQL-Instance und erstellen Sie ein Benutzerkonto, das für die Replikation verwendet werden soll. Im Folgenden wird ein -Beispiel gezeigt. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **Anmerkung** Geben Sie aus Sicherheitsgründen ein anderes Passwort als hier angegeben an. 1. Erteilen Sie innerhalb der externen MySQL-Instance Ihrem Replikationsbenutzer die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE`. Im folgenden Beispiel werden dem Benutzer 'repl\$1user' für Ihre Domäne die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` für alle Datenbanken erteilt. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'; ``` Um die verschlüsselte Replikation zu verwenden, konfigurieren Sie die Quelldatenbank-Instance für die Verwendung von SSL-Verbindungen. Importieren Sie außerdem mit der Prozedur [mysql.rds\$1import\$1binlog\$1ssl\$1material](url-rds-user;mysql_rds_import_binlog_ssl_material.html) das Zertifizierungsstellenzertifikat, das Clientzertifikat und den Clientschlüssel in die DB-Instance bzw. den DB-Cluster. **Anmerkung** Wir bieten diese gespeicherten Prozeduren hauptsächlich an, um die Replikation mit MySQL-Instances zu ermöglichen, die außerhalb von Amazon RDS ausgeführt werden. Wir empfehlen die Verwendung von Aurora Replicas, um die Replikation innerhalb eines DB-Clusters von Aurora MySQL zu verwalten, wenn dies möglich ist. Informationen zur Verwaltung der Replikation in DB-Clustern von Aurora MySQL finden Sie unter [Verwendung von Aurora-Replicas](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas). Nachdem Sie `mysql.rds_set_external_source` aufgerufen haben, um eine DB-Instance von Aurora MySQL als Lesereplikat zu konfigurieren, können Sie [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) für das Lesereplikat aufrufen, um die Replikation zu starten Zudem haben Sie die Möglichkeit, mit einem Aufruf von [mysql.rds\$1next\$1source\$1log (Aurora-MySQL-Version 3)](#mysql_rds_reset_external_source) die Lesereplikat-Konfiguration zu entfernen. Beim Aufrufen von `mysql.rds_set_external_source` werden von Amazon RDS Uhrzeit, Benutzer und eine Aktion von `set master` in den Tabellen `mysql.rds_history` und `mysql.rds_replication_status` protokolliert. ### Beispiele Bei Ausführung auf einer DB-Instance von Aurora MySQL konfiguriert das folgende Beispiel diese DB-Instance für die Verwendung als Lesereplikat einer außerhalb von Amazon RDS ausgeführten MySQL-Instance. ``` call mysql.rds_set_external_source( 'Externaldb.some.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.0777', 120, 1); ``` ## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (Aurora-MySQL-Version 2) Konfiguriert eine primäre Instance von Aurora MySQL, um eine eingehende Replikation von einer externen MySQL-Instance zu akzeptieren. Bei diesem Verfahren wird auch die Replikation auf der Grundlage globaler Transaktions-Identifikatoren () konfiguriert. GTIDs Dieses Verfahren konfiguriert nicht die verzögerte Replikation, da Aurora MySQL die verzögerte Replikation nicht unterstützt. ### Syntax ``` CALL mysql.rds_set_external_master_with_auto_position ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption ); ``` ### Parameters *host\$1name* Der Hostname bzw. die IP-Adresse der außerhalb von Aurora ausgeführten MySQL-Instance, die als Replikationsquelle festgelegt werden soll. *host\$1port* Der Port, der von der außerhalb von Aurora ausgeführten MySQL-Instance verwendet wird, die als Replikations-Quelle konfiguriert werden soll. Wenn Ihre Netzwerkkonfiguration die Replikation über Secure Shell (SSH)-Ports einschließt, welche die Portnummer konvertiert, geben Sie für diesen Parameter die von SSH offengelegte Portnummer an. *replication\$1user\$1name* Die ID eines Benutzers mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` auf der MySQL-Instance, die extern zu Aurora ausgeführt wird. Es wird empfohlen, ein Benutzerkonto bereitzustellen, das ausschließlich für die Replikation mit der externen Instance genutzt wird. *replication\$1user\$1password* Das zu dem in `replication_user_name` angegebenen User-ID gehörige Passwort. *ssl\$1encryption* Diese Option ist derzeit nicht implementiert. Der Standardwert ist 0. ### Nutzungshinweise Sie rufen dieses gespeicherte Verfahren für einen Aurora MySQL-DB-Cluster auf, während Sie mit der primären Instance verbunden sind. Die Prozedur `mysql.rds_set_external_master_with_auto_position` muss vom Hauptbenutzer ausgeführt werden. Der Master-Benutzer führt diese Verfahren auf der primären Instance eines Aurora MySQL-DB-Clusters durch, der als Replikationsziel fungiert. Dies kann das Replikationsziel einer externen MySQL-DB-Instance oder eines Aurora MySQL-DB-Clusters sein. Diese Prozedur wird für Aurora-MySQL-Version 2 unterstützt. Verwenden Sie für Aurora-MySQL-Version 3 stattdessen das Verfahren [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL Version 3)](#mysql_rds_set_external_source_with_auto_position). Konfigurieren Sie die externe MySQL-DB-Instance vor der Ausführung von `mysql.rds_set_external_master_with_auto_position` als Replikationsquelle. Um sich mit der externen MySQL-Instance zu verbinden, geben Sie Werte für `replication_user_name` und `replication_user_password` an. Diese Werte müssen einen Replikationsbenutzer mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` auf der externen MySQL-Instance angeben. **So konfigurieren Sie eine externe MySQL-Instance als Replikationsquelle** 1. Verbinden Sie sich mithilfe eines MySQL-Clients Ihrer Wahl mit der externen MySQL-Instance und erstellen Sie ein Benutzerkonto, das für die Replikation verwendet werden soll. Im Folgenden wird ein Beispiel gezeigt. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` 1. Erteilen Sie Ihrem Replikationsbenutzer auf der externen MySQL-Instance die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE`. Im folgenden Beispiel werden dem Benutzer `REPLICATION CLIENT` für Ihre Domäne die Berechtigungen `REPLICATION SLAVE` und `'repl_user'` für alle Datenbanken erteilt. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` Wenn Sie `mysql.rds_set_external_master_with_auto_position` aufrufen, zeichnet Amazon RDS bestimmte Informationen auf. Diese Informationen umfassen die Zeit, den Benutzer und eine Aktion von `"set master"` in den Tabellen `mysql.rds_history` und `mysql.rds_replication_status`. Wenn Sie eine bestimmte GTID-basierte Transaktion überspringen möchten, von der Sie wissen, dass sie ein Problem verursacht, können Sie die gespeicherte Prozedur [mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL Version 2 und 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid) verwenden. Weitere Informationen über das Arbeiten mit der GTID-basierten Replikation finden Sie unter [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md). ### Beispiele Wenn die folgende Beispielkonfiguration auf einer primären Instance von Aurora ausgeführt wird, wird der Aurora-Cluster so konfiguriert, dass er als Lesereplikat einer Instance von MySQL dient, die extern von Aurora ausgeführt wird. ``` call mysql.rds_set_external_master_with_auto_position( 'Externaldb.some.com', 3306, 'repl_user'@'mydomain.com', 'SomePassW0rd'); ``` ## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL Version 3) Konfiguriert eine primäre Instance von Aurora MySQL, um eine eingehende Replikation von einer externen MySQL-Instance zu akzeptieren. Bei diesem Verfahren wird auch die Replikation auf der Grundlage globaler Transaktions-Identifikatoren () konfiguriert. GTIDs ### Syntax ``` CALL mysql.rds_set_external_source_with_auto_position ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption ); ``` ### Parameters *host\$1name* Der Hostname bzw. die IP-Adresse der außerhalb von Aurora ausgeführten MySQL-Instance, die als Replikationsquelle festgelegt werden soll. *host\$1port* Der Port, der von der außerhalb von Aurora ausgeführten MySQL-Instance verwendet wird, die als Replikations-Quelle konfiguriert werden soll. Wenn Ihre Netzwerkkonfiguration die Replikation über Secure Shell (SSH)-Ports einschließt, welche die Portnummer konvertiert, geben Sie für diesen Parameter die von SSH offengelegte Portnummer an. *replication\$1user\$1name* Die ID eines Benutzers mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` auf der MySQL-Instance, die extern zu Aurora ausgeführt wird. Es wird empfohlen, ein Benutzerkonto bereitzustellen, das ausschließlich für die Replikation mit der externen Instance genutzt wird. *replication\$1user\$1password* Das zu dem in `replication_user_name` angegebenen User-ID gehörige Passwort. *ssl\$1encryption* Diese Option ist derzeit nicht implementiert. Der Standardwert ist 0. Verwenden Sie [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora-MySQL-version 3)](#mysql_rds_set_binlog_source_ssl), um SSL für die Binärprotokollreplikation zu aktivieren. ### Nutzungshinweise Sie rufen dieses gespeicherte Verfahren für einen Aurora MySQL-DB-Cluster auf, während Sie mit der primären Instance verbunden sind. Der Administrator muss das `mysql.rds_set_external_source_with_auto_position`-Verfahren ausführen. Der Administrator-Benutzer führt diese Verfahren auf der primären Instance eines Aurora MySQL-DB-Clusters durch, der als Replikationsziel fungiert. Dies kann das Replikationsziel einer externen MySQL-DB-Instance oder eines Aurora MySQL-DB-Clusters sein. Zurzeit wird diese Prozedur für Aurora MySQL Version 3 unterstützt. Dieses Verfahren konfiguriert nicht die verzögerte Replikation, da Aurora MySQL die verzögerte Replikation nicht unterstützt. Konfigurieren Sie die externe MySQL-DB-Instance vor der Ausführung von `mysql.rds_set_external_source_with_auto_position` als Replikationsquelle. Um sich mit der externen MySQL-Instance zu verbinden, geben Sie Werte für `replication_user_name` und `replication_user_password` an. Diese Werte müssen einen Replikationsbenutzer mit den Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE` auf der externen MySQL-Instance angeben. **So konfigurieren Sie eine externe MySQL-Instance als Replikationsquelle** 1. Verbinden Sie sich mithilfe eines MySQL-Clients Ihrer Wahl mit der externen MySQL-Instance und erstellen Sie ein Benutzerkonto, das für die Replikation verwendet werden soll. Im Folgenden wird ein Beispiel gezeigt. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` 1. Erteilen Sie Ihrem Replikationsbenutzer auf der externen MySQL-Instance die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE`. Im folgenden Beispiel werden dem Benutzer `REPLICATION CLIENT` für Ihre Domäne die Berechtigungen `REPLICATION SLAVE` und `'repl_user'` für alle Datenbanken erteilt. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` Wenn Sie `mysql.rds_set_external_source_with_auto_position` aufrufen, zeichnet Amazon RDS bestimmte Informationen auf. Diese Informationen umfassen die Zeit, den Benutzer und eine Aktion von `"set master"` in den Tabellen `mysql.rds_history` und `mysql.rds_replication_status`. Wenn Sie eine bestimmte GTID-basierte Transaktion überspringen möchten, von der Sie wissen, dass sie ein Problem verursacht, können Sie die gespeicherte Prozedur [mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL Version 2 und 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid) verwenden. Weitere Informationen über das Arbeiten mit der GTID-basierten Replikation finden Sie unter [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md). ### Beispiele Wenn die folgende Beispielkonfiguration auf einer primären Instance von Aurora ausgeführt wird, wird der Aurora-Cluster so konfiguriert, dass er als Lesereplikat einer Instance von MySQL dient, die extern von Aurora ausgeführt wird. ``` call mysql.rds_set_external_source_with_auto_position( 'Externaldb.some.com', 3306, 'repl_user'@'mydomain.com', 'SomePassW0rd'); ``` ## mysql.rds\$1set\$1master\$1auto\$1position ) Legt fest, dass der Replikationsmodus entweder auf binären Protokolldateipositionen oder auf globalen Transaktions-Identifikatoren (GTIDs) basiert. ### Syntax ``` CALL mysql.rds_set_master_auto_position ( auto_position_mode ); ``` ### Parameters *auto\$1position\$1mode* Ein Wert, der angibt, ob die Replikation auf Basis der Protokolldateiposition oder der GTID verwendet werden soll: + `0` – Verwendung der auf der Binärprotokolldateiposition basierenden Replikationsmethode. Der Standardwert ist `0`. + `1` – Verwendung der auf GTID basierenden Replikationsmethode. ### Nutzungshinweise Die Prozedur `mysql.rds_set_master_auto_position` muss vom Hauptbenutzer ausgeführt werden. Diese Prozedur wird für Aurora-MySQL-Version 2 unterstützt. ## mysql.rds\$1set\$1read\$1only (Aurora-MySQL-Version 3) Aktiviert oder deaktiviert den Modus `read_only` global für die DB-Instance. ### Syntax ``` CALL mysql.rds_set_read_only(mode); ``` ### Parameters *mode* Ein Wert, der angibt, ob der `read_only`-Modus für die DB-Instance global aktiviert oder deaktiviert ist: + `0` – `OFF`. Standard ist `0`. + `1` – `ON` ### Nutzungshinweise Das gespeicherte `mysql.rds_set_read_only`-Verfahren ändert nur den Parameter `read_only`. Der Parameter `innodb_read_only` kann auf Reader-DB-Instances nicht geändert werden. Die Änderung des Parameters `read_only` wird beim Neustart nicht beibehalten. Um dauerhafte Änderungen an `read_only` vorzunehmen, müssen Sie den DB-Cluster-Parameter `read_only` verwenden. Diese Prozedur wird für Aurora-MySQL-Version 3.06 und höher unterstützt. ## mysql.rds\$1set\$1session\$1binlog\$1format (Aurora-MySQL-Version 2) Legt das binäre Protokollformat für die aktuelle Sitzung fest. ### Syntax ``` CALL mysql.rds_set_session_binlog_format(format); ``` ### Parameters *format* Ein Wert, der das binäre Protokollformat für die aktuelle Sitzung angibt: + `STATEMENT` – Die Replikationsquelle schreibt Ereignisse auf der Grundlage von SQL-Anweisungen in das Binärprotokoll. + `ROW` – Die Replikationsquelle schreibt Ereignisse in das Binärprotokoll, die auf Änderungen an einzelnen Tabellenzeilen hinweisen. + `MIXED` – Die Protokollierung basiert in der Regel auf SQL-Anweisungen, wechselt jedoch unter bestimmten Bedingungen zu Zeilen. Weitere Informationen finden Sie unter [Mixed Binary Logging Format](https://dev.mysql.com/doc/refman/8.0/en/binary-log-mixed.html) (Gemischtes Binärprotokollformat) in der MySQL-Dokumentation. ### Nutzungshinweise Sie rufen dieses gespeicherte Verfahren für einen Aurora MySQL-DB-Cluster auf, während Sie mit der primären Instance verbunden sind. Wenn Sie diese gespeicherte Prozedur verwenden möchten, müssen Sie die Binärprotokollierung für die aktuelle Sitzung konfiguriert haben. Für Aurora wird dieses Verfahren für Aurora-MySQL-Version 2.12 und höher und MySQL-5.7-kompatible Versionen unterstützt. ## mysql.rds\$1set\$1source\$1auto\$1position (Aurora-MySQL-Version 3) Legt fest, dass der Replikationsmodus entweder auf binären Protokolldateipositionen oder auf globalen Transaktions-Identifikatoren () GTIDs basiert. ### Syntax ``` CALL mysql.rds_set_source_auto_position (auto_position_mode); ``` ### Parameters *auto\$1position\$1mode* Ein Wert, der angibt, ob die Replikation auf Basis der Protokolldateiposition oder der GTID verwendet werden soll: + `0` – Verwendung der auf der Binärprotokolldateiposition basierenden Replikationsmethode. Der Standardwert ist `0`. + `1` – Verwendung der auf GTID basierenden Replikationsmethode. ### Nutzungshinweise Sie rufen dieses gespeicherte Verfahren für einen Aurora MySQL-DB-Cluster auf, während Sie mit der primären Instance verbunden sind. Der Administrator muss das `mysql.rds_set_source_auto_position`-Verfahren ausführen. ## mysql.rds\$1skip\$1repl\$1error Ignoriert und löscht einen Replikationsfehler in einem MySQL-DB-Lesereplikat. ### Syntax ``` CALL mysql.rds_skip_repl_error; ``` ### Nutzungshinweise Der Hauptbenutzer muss die Prozedur `mysql.rds_skip_repl_error` auf einem Lesereplikat ausführen. Weitere Informationen zu dieser Prozedur finden Sie unter [Überspringen des aktuellen Replikationsfehlers](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.SkipError). Führen Sie den MySQL-Befehl `SHOW REPLICA STATUS\G` aus, um festzustellen, ob Fehler aufgetreten sind. Wenn ein Replikationsfehler nicht als kritisch eingestuft, ist, können Sie `mysql.rds_skip_repl_error` ausführen, um den Fehler zu überspringen. Wenn mehrere Fehler aufgetreten sind, löscht `mysql.rds_skip_repl_error` den ersten Fehler und weist darauf hin, dass weitere Fehlermeldungen anhängig sind. In diesem Fall können Sie mithilfe von `SHOW REPLICA STATUS\G` die angemessene Vorgehensweise bei der Handhabung des nächsten Fehlers ermitteln. Informationen zu den zurückgegebenen Werten finden Sie unter [SHOW REPLICA STATUS-Anweisung](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) in der MySQL-Dokumentation. Weitere Informationen zur Handhabung von Replikationsfehlern mit Aurora MySQL finden Sie unter [Diagnose und Behebung eines MySQL- ](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.RR). #### Fehler „Replication stopped (Replikation gestoppt)“ Wenn Sie die Prozedur `mysql.rds_skip_repl_error` aufrufen, wird möglicherweise eine Fehlermeldung angezeigt, die besagt, dass das Replikat ausgefallen oder deaktiviert ist. Diese Fehlermeldung wird angezeigt, wenn Sie die Prozedur auf der primären Instance statt auf dem Lesereplikat ausführen. Sie müssen diese Prozedur auf dem Lesereplikat ausführen, damit sie funktioniert. Diese Fehlermeldung wird möglicherweise auch angezeigt, wenn Sie die Prozedur zwar auf dem Lesereplikat ausführen, die Replikation jedoch nicht neu gestartet werden kann. Wenn Sie eine größere Anzahl von Fehlern überspringen müssen, kann die Dauer der Replikationsverzögerung den standardmäßigen Aufbewahrungszeitraum für binäre Protokolldateien (binlog) überschreiten. In diesem Fall kann es zu einem schwerwiegenden Fehler kommen, weil Binärprotokolldateien bereinigt werden, bevor ihr Inhalt in das Lesereplikat repliziert wurde. Diese Bereinigung führt zur Beendigung der Replikation, und Sie können den Befehl `mysql.rds_skip_repl_error` nicht mehr aufrufen, um Replikationsfehler zu überspringen und zu ignorieren. Sie können dieses Problem verringern, indem Sie die Anzahl der Stunden erhöhen, die die Binärprotokolldateien auf Ihrer Quelldatenbankinstance aufbewahrt werden. Nachdem Sie die Aufbewahrungsdauer für binäre Protokolldateien verlängert haben, können Sie die Replikation neu starten und nach Bedarf den Befehl `mysql.rds_skip_repl_error` aufrufen. Verwenden Sie zur Festlegung der Aufbewahrungszeit für Binärprotokolldateien die Prozedur [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) und legen Sie einen Konfigurationsparameter für `'binlog retention hours'` zusammen mit der Stundenanzahl für die Aufbewahrung der Binärprotokolldateien im DB-Cluster fest. Beim folgenden Beispiel wird die Aufbewahrungszeit für binäre Protokolle auf 48 Stunden festgelegt. ``` CALL mysql.rds_set_configuration('binlog retention hours', 48); ``` ## mysql.rds\$1start\$1replication Startet die Replikation von einer/einem Aurora-MySQL-DB-Cluster. **Anmerkung** Sie können die gespeicherte Prozedur [mysql.rds\$1start\$1replication\$1until (Aurora MySQL Version 3)](#mysql_rds_start_replication_until) oder [mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL Version 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) verwenden, um die Replikation von einer Aurora-MySQL-DB-Instance zu initiieren und die Replikation an der angegebenen Position der Binärprotokolldatei zu stoppen. ### Syntax ``` CALL mysql.rds_start_replication; ``` ### Nutzungshinweise Die Prozedur `mysql.rds_start_replication` muss vom Hauptbenutzer ausgeführt werden. Um Daten aus einer außerhalb von Amazon RDS ausgeführten MySQL-Instance zu importieren, rufen Sie `mysql.rds_start_replication` für das Lesereplikat auf, um den Replikationsvorgang zu starten, nachdem Sie [mysql.rds\$1set\$1external\$1master (Aurora-MySQL-Version 2)](#mysql_rds_set_external_master) oder [mysql.rds\$1set\$1external\$1source (Aurora-MySQL- Version 3)](#mysql_rds_set_external_source) aufgerufen haben, um die Replikation zu konfigurieren. Weitere Informationen finden Sie unter [Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)](AuroraMySQL.Replication.MySQL.md). Zum Export von Daten in eine außerhalb von Amazon RDS ausgeführte MySQL-Instance rufen Sie `mysql.rds_start_replication` und `mysql.rds_stop_replication` für das Lesereplikat auf, um Replikationsaktionen wie das Bereinigen von Binärprotokollen zu steuern. Weitere Informationen finden Sie unter [Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)](AuroraMySQL.Replication.MySQL.md). Darüber hinaus können Sie `mysql.rds_start_replication` für das Lesereplikat aufrufen, um einen zuvor durch einen Aufruf von `mysql.rds_stop_replication` gestoppten Replikationsprozess wieder zu starten. Weitere Informationen finden Sie unter [Fehler „Replication stopped (Replikation gestoppt)“](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicationStopped). ## mysql.rds\$1start\$1replication\$1until (Aurora MySQL Version 3) Initiiert die Replikation von einem Aurora-MySQL-DB-Cluster und stoppt die Replikation an der angegebenen Position in der Binärprotokolldatei. ### Syntax ``` CALL mysql.rds_start_replication_until ( replication_log_file , replication_stop_point ); ``` ### Parameters *replication\$1log\$1file* Der Name des Binärprotokolls auf der Quelldatenbank-Instance, die die Replikationsinformationen enthält. *replication\$1stop\$1point * Die Position im `replication_log_file`-Binärprotokoll, an der die Replikation stoppt. ### Nutzungshinweise Die Prozedur `mysql.rds_start_replication_until` muss vom Hauptbenutzer ausgeführt werden. Diese Prozedur wird für Aurora-MySQL-Version 3.04 und höher unterstützt. Das gespeicherte `mysql.rds_start_replication_until`-Verfahren wird für die verwaltete Replikation nicht unterstützt, darunter Folgendes: + [Replizieren von Amazon-Aurora-MySQL-DB-Clustern über AWS-Regionen hinweg](AuroraMySQL.Replication.CrossRegion.md) + [Migrieren von Daten aus einer RDS-für-MySQL-DB-Instance zu einem Amazon-Aurora-MySQL-DB-Cluster mittels einer Aurora Read Replica (Lesereplikat)](AuroraMySQL.Migrating.RDSMySQL.Replica.md) Der für den Parameter `replication_log_file` angegebene Dateiname muss mit dem Binlogdateinamen der Quelldatenbankinstance übereinstimmen. Wenn der Parameter `replication_stop_point`eine Stoppposition angibt, die in der Vergangenheit liegt, wird die Replikation sofort gestoppt. ### Beispiele Das folgende Beispiel initiiert die Replikation und repliziert die Änderungen, bis die Position `120` in der Binärprotokolldatei `mysql-bin-changelog.000777` erreicht wird. ``` call mysql.rds_start_replication_until( 'mysql-bin-changelog.000777', 120); ``` ## mysql.rds\$1stop\$1replication Stoppt die Replikation von einer MySQL-DB-Instance. ### Syntax ``` CALL mysql.rds_stop_replication; ``` ### Nutzungshinweise Die Prozedur `mysql.rds_stop_replication` muss vom Hauptbenutzer ausgeführt werden. Wenn Sie die Replikation für den Import von Daten aus einer außerhalb von Amazon RDS ausgeführten MySQL-Instance konfigurieren, stoppen Sie mit einem Aufruf von `mysql.rds_stop_replication` für das Lesereplikat den Replikationsvorgang nach Abschluss des Imports. Weitere Informationen finden Sie unter [Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)](AuroraMySQL.Replication.MySQL.md). Wenn Sie die Replikation für den Export von Daten in eine außerhalb von Amazon RDS ausgeführte MySQL-Instance konfigurieren, rufen Sie `mysql.rds_start_replication` und `mysql.rds_stop_replication` für das Lesereplikat auf, um Replikationsaktionen wie das Bereinigen von Binärprotokollen zu steuern. Weitere Informationen finden Sie unter [Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)](AuroraMySQL.Replication.MySQL.md). Das gespeicherte `mysql.rds_stop_replication`-Verfahren wird für die verwaltete Replikation nicht unterstützt, darunter Folgendes: + [Replizieren von Amazon-Aurora-MySQL-DB-Clustern über AWS-Regionen hinweg](AuroraMySQL.Replication.CrossRegion.md) + [Migrieren von Daten aus einer RDS-für-MySQL-DB-Instance zu einem Amazon-Aurora-MySQL-DB-Cluster mittels einer Aurora Read Replica (Lesereplikat)](AuroraMySQL.Migrating.RDSMySQL.Replica.md) # Beenden einer Sitzung oder Abfrage Die folgenden gespeicherten Prozeduren beenden eine Sitzung oder Abfrage. **Topics** + [mysql.rds\$1kill](#mysql_rds_kill) + [mysql.rds\$1kill\$1query](#mysql_rds_kill_query) ## mysql.rds\$1kill Beendet eine Verbindung zum MySQL-Server. ### Syntax ``` CALL mysql.rds_kill(processID); ``` ### Parameter *processID* Die ID des Verbindungs-Threads, der beendet werden soll. ### Nutzungshinweise Jede Verbindung zum MySQL-Server wird in einem eigenen Thread ausgeführt. Um eine Verbindung zu beenden, verwenden Sie die Prozedur `mysql.rds_kill` und übergeben ihr als Parameter die Thread-ID der Verbindung. Die Thread-ID erhalten Sie mithilfe des MySQL-Befehls [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html). ### Beispiele Im folgenden Beispiel wird eine Verbindung mit der Thread-ID 4243 beendet: ``` CALL mysql.rds_kill(4243); ``` ## mysql.rds\$1kill\$1query Beendet eine an den MySQL-Server übermittelte Abfrage. ### Syntax ``` CALL mysql.rds_kill_query(processID); ``` ### Parameter *processID* Die Identität des Prozesses oder Threads, der die zu beendende Abfrage ausführt. ### Nutzungshinweise Um eine an den MySQL-Server übermittelte Abfrage zu beenden, verwenden Sie die Prozedur `mysql_rds_kill_query` und übergeben die ID des Threads, der die Abfrage ausführt. Die Prozedur beendet dann die Verbindung. Die Abfrage-ID erhalten Sie mithilfe der MySQL-Tabelle [INFORMATION\$1SCHEMA PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/information-schema-processlist-table.html) oder des MySQL-Befehls [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html). Der Wert in der ID-Spalte von `SHOW PROCESSLIST` oder `SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST` ist die *processID*. ### Beispiele Im folgenden Beispiel wird eine Abfrage mit der Thread-ID 230040 beendet: ``` CALL mysql.rds_kill_query(230040); ``` # Transaktionen replizieren mit GTIDs Die folgenden gespeicherten Prozeduren steuern, wie Transaktionen mithilfe globaler Transaktions-Identifikatoren (GTIDs) mit Aurora MySQL repliziert werden. Informationen zur Verwendung der Replikation auf GTIDs Basis von Aurora MySQL finden Sie unter[Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md). **Topics** + [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL Version 3)](#mysql_assign_gtids_to_anonymous_transactions) + [mysql.rds\$1gtid\$1purged (Aurora-MySQL-Version 3)](#mysql_rds_gtid_purged) + [mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL Version 2 und 3)](#mysql_rds_skip_transaction_with_gtid) + [mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL Version 3)](#mysql_rds_start_replication_until_gtid) ## mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL Version 3) Konfiguriert die `ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS`-Option der `CHANGE REPLICATION SOURCE TO`-Anweisung. Dadurch weist der Replikationskanal replizierten Transaktionen, die keine haben, eine GTID zu. Auf diese Weise können Sie die Binärprotokollreplikation von einer Quelle aus, die keine GTID-basierte Replikation verwendet, zu einem Replikat, durchführen, das dies tut. Weitere Informationen finden Sie unter [CHANGE REPLICATION SOURCE TO statement](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html) und [Replication From a Source Without GTIDs to a Replica With GTIDs](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-assign-anon.html) im *MySQL-Referenzhandbuch.* ### Syntax ``` CALL mysql.rds_assign_gtids_to_anonymous_transactions(gtid_option); ``` ### Parameters *gtid\$1option* Zeichenfolgenwert Die erlaubten Werte sind `OFF`, `LOCAL`, oder eine angegebene UUID. ### Nutzungshinweise Dieses Vorgehen hat die gleiche Wirkung wie das Absetzen der Anweisung `CHANGE REPLICATION SOURCE TO ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = gtid_option` in Community MySQL. GTID muss aktiviert werden, `ON` *gtid\$1option* um auf eine bestimmte UUID gesetzt zu `LOCAL` werden. Der Standardwert ist `OFF`, was bedeutet, dass die Funktion nicht verwendet wird. `LOCAL` weist eine GTID einschließlich der eigenen UUID des Replikats (der `server_uuid`-Einstellung) zu. Das Übergeben eines Parameters, bei dem es sich um eine UUID handelt, weist eine GTID zu, die die angegebene UUID enthält, z. B. die `server_uuid`-Einstellung für den Replikationsquellserver. ### Beispiele So deaktivieren Sie diese Funktion: ``` mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('OFF'); +-------------------------------------------------------------+ | Message | +-------------------------------------------------------------+ | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: OFF | +-------------------------------------------------------------+ 1 row in set (0.07 sec) ``` So verwenden Sie die eigene UUID des Replikats: ``` mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('LOCAL'); +---------------------------------------------------------------+ | Message | +---------------------------------------------------------------+ | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: LOCAL | +---------------------------------------------------------------+ 1 row in set (0.07 sec) ``` So verwenden Sie eine angegebene UUID: ``` mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('317a4760-f3dd-3b74-8e45-0615ed29de0e'); +----------------------------------------------------------------------------------------------+ | Message | +----------------------------------------------------------------------------------------------+ | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: 317a4760-f3dd-3b74-8e45-0615ed29de0e | +----------------------------------------------------------------------------------------------+ 1 row in set (0.07 sec) ``` ## mysql.rds\$1gtid\$1purged (Aurora-MySQL-Version 3) Legt den globalen Wert der Systemvariablen `gtid_purged` auf einen bestimmten Satz von globalen Transaktionskennungen (GTID) fest. Die `gtid_purged` Systemvariable ist ein GTID-Satz, GTIDs der aus allen Transaktionen besteht, die auf dem Server festgeschrieben wurden, aber in keiner binären Protokolldatei auf dem Server existieren. Es gibt zwei Möglichkeiten, den Wert `gtid_purged` festzulegen, um Kompatibilität mit MySQL 8.0 zu ermöglichen: + Ersetzen Sie den Wert `gtid_purged` durch Ihren angegebenen GTID-Set. + Fügen Sie Ihren angegebenen GTID-Satz an den GTID-Satz an, den `gtid_purged` bereits enthält. ### Syntax So ersetzen Sie den Wert `gtid_purged` durch Ihren angegebenen GTID-Satz: ``` CALL mysql.rds_gtid_purged (gtid_set); ``` So fügen Sie den Wert `gtid_purged` Ihrem angegebenen GTID-Satz an: ``` CALL mysql.rds_gtid_purged (+gtid_set); ``` ### Parameters *gtid\$1set* Der Wert von *gtid\$1set* muss eine Obermenge des aktuellen Werts von `gtid_purged` sein und darf sich nicht mit diesem überschneiden. `gtid_subtract(gtid_executed,gtid_purged)` Das heißt, der neue GTID-Satz muss alle enthalten GTIDs , die bereits vorhanden waren`gtid_purged`, und darf keine GTID-Sätze enthalten`gtid_executed`, die noch nicht gelöscht wurden. GTIDs Der *gtid\$1set* Parameter darf auch keine Daten enthalten GTIDs , die sich im globalen `gtid_owned` Satz befinden, d. h. GTIDs für Transaktionen, die derzeit auf dem Server verarbeitet werden. ### Nutzungshinweise Die Prozedur `mysql.rds_gtid_purged` muss vom Hauptbenutzer ausgeführt werden. Diese Prozedur wird für Aurora-MySQL-Version 3.04 und höher unterstützt. ### Beispiele Im folgenden Beispiel wird die GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23` der globalen Variable `gtid_purged` zugewiesen. ``` CALL mysql.rds_gtid_purged('3E11FA47-71CA-11E1-9E33-C80AA9429562:23'); ``` ## mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL Version 2 und 3) Überspringt die Replikation einer Transaktion mit der angegebenen globalen Transaktionskennung (GTID) auf einer primären Instance von Aurora. Sie können dieses Verfahren für die Notfallwiederherstellung verwenden, wenn eine bestimmte GTID-Transaktion bekanntermaßen ein Problem verursacht. Verwenden Sie diese gespeicherte Prozedur, um die problematische Transaktion zu überspringen. Problematisch sind beispielsweise Transaktionen, die die Replikation deaktivieren, wichtige Daten löschen oder dafür sorgen, dass die DB-Instance nicht mehr verfügbar ist. ### Syntax ``` CALL mysql.rds_skip_transaction_with_gtid ( gtid_to_skip ); ``` ### Parameters *gtid\$1to\$1skip* Die GTID der zu überspringenden Replikationstransaktion. ### Nutzungshinweise Die Prozedur `mysql.rds_skip_transaction_with_gtid` muss vom Hauptbenutzer ausgeführt werden. Diese Prozedur wird für Aurora-MySQL-Version 2 und 3 unterstützt. ### Beispiele Im folgenden Beispiel wird die Replikation der Transaktion mit der GTID übersprunge `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`. ``` CALL mysql.rds_skip_transaction_with_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23'); ``` ## mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL Version 3) Initiiert die Replikation von einer/einem Aurora-MySQL-DB-Cluster und stoppt die Replikation unmittelbar nach der angegebenen globalen Transaktionskennung (GTID). ### Syntax ``` CALL mysql.rds_start_replication_until_gtid(gtid); ``` ### Parameters *gtid* Die GTID, nach der die Replikation stoppen soll. ### Nutzungshinweise Die Prozedur `mysql.rds_start_replication_until_gtid` muss vom Hauptbenutzer ausgeführt werden. Diese Prozedur wird für Aurora-MySQL-Version 3.04 und höher unterstützt. Die gespeicherte Prozedur `mysql.rds_start_replication_until_gtid` wird für die verwaltete Replikation nicht unterstützt, darunter Folgendes: + [Replizieren von Amazon-Aurora-MySQL-DB-Clustern über AWS-Regionen hinweg](AuroraMySQL.Replication.CrossRegion.md) + [Migrieren von Daten aus einer RDS-für-MySQL-DB-Instance zu einem Amazon-Aurora-MySQL-DB-Cluster mittels einer Aurora Read Replica (Lesereplikat)](AuroraMySQL.Migrating.RDSMySQL.Replica.md) Wenn der Parameter `gtid` eine Transaktion angibt, die bereits von dem Replikat ausgeführt wurde, wird die Replikation sofort gestoppt. ### Beispiele Das folgende Beispiel initiiert die Replikation und repliziert die Änderungen, bis die GTID erreicht wir `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`. ``` call mysql.rds_start_replication_until_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23'); ``` # Rotieren der Abfrageprotokolle Die folgenden gespeicherten Prozeduren rotieren MySQL-Protokolle in Backup-Tabellen. Weitere Informationen finden Sie unter [Aurora MySQL-Datenbank-Logdateien](USER_LogAccess.Concepts.MySQL.md). **Topics** + [mysql.rds\$1rotate\$1general\$1log](#mysql_rds_rotate_general_log) + [mysql.rds\$1rotate\$1slow\$1log](#mysql_rds_rotate_slow_log) ## mysql.rds\$1rotate\$1general\$1log Rotiert die Tabelle `mysql.general_log` in eine Sicherungstabelle. ### Syntax ``` CALL mysql.rds_rotate_general_log; ``` ### Nutzungshinweise Sie können die Tabelle `mysql.general_log` in eine Sicherungstabelle rotieren, indem Sie die Prozedur `mysql.rds_rotate_general_log` aufrufen. Beim Rotieren von Protokolldateien wird die aktuelle Protokolltabelle in eine Sicherungsprotokolltabelle kopiert, und die Einträge in der aktuellen Protokolltabelle werden entfernt. Sofern bereits eine Sicherungsprotokolltabelle vorhanden ist, wird diese gelöscht, bevor die aktuelle Protokolltabelle in die Sicherungsprotokolltabelle kopiert wird. Sie können die Sicherungsprotokolltabelle abfragen, wenn dies nötig ist. Die Backup-Protokolltabelle für die `mysql.general_log`-Tabelle ist als `mysql.general_log_backup` benannt. Sie können dieses Verfahren nur ausführen, wenn der Parameter `log_output` auf `TABLE` eingestellt ist. ## mysql.rds\$1rotate\$1slow\$1log Rotiert die Tabelle `mysql.slow_log` in eine Sicherungstabelle. ### Syntax ``` CALL mysql.rds_rotate_slow_log; ``` ### Nutzungshinweise Sie können die Tabelle `mysql.slow_log` in eine Sicherungstabelle rotieren, indem Sie die Prozedur `mysql.rds_rotate_slow_log` aufrufen. Beim Rotieren von Protokolldateien wird die aktuelle Protokolltabelle in eine Sicherungsprotokolltabelle kopiert, und die Einträge in der aktuellen Protokolltabelle werden entfernt. Sofern bereits eine Sicherungsprotokolltabelle vorhanden ist, wird diese gelöscht, bevor die aktuelle Protokolltabelle in die Sicherungsprotokolltabelle kopiert wird. Sie können die Sicherungsprotokolltabelle abfragen, wenn dies nötig ist. Die Backup-Protokolltabelle für die `mysql.slow_log`-Tabelle ist als `mysql.slow_log_backup` benannt. # Festlegen und Anzeigen der Konfiguration des Binärprotokolls Die folgenden gespeicherten Prozeduren legen Konfigurationsparameter fest und zeigen sie an, z. B. für die Aufbewahrung binärer Protokolldateien. **Topics** + [mysql.rds\$1set\$1configuration](#mysql_rds_set_configuration) + [mysql.rds\$1show\$1configuration](#mysql_rds_show_configuration) ## mysql.rds\$1set\$1configuration Gibt die Anzahl an Stunden an, für die die Binärprotokolle aufbewahrt werden sollen, oder die Anzahl Sekunden, um die die Replikation verzögert werden soll. ### Syntax ``` CALL mysql.rds_set_configuration(name,value); ``` ### Parameters *name* Der Name des festzulegenden Konfigurationsparameters *value* Der Wert des Konfigurationsparameters ### Nutzungshinweise Die Prozedur `mysql.rds_set_configuration` unterstützt die folgenden Konfigurationsparameter: + [binlog retention hours](#mysql_rds_set_configuration-usage-notes.binlog-retention-hours) Die Konfigurationsparameter werden dauerhaft gespeichert und überstehen jeden Neustart oder Failover der DB-Instance. #### binlog retention hours Der Parameter `binlog retention hours` wird verwendet, um die Anzahl der Stunden anzugeben, die Binärprotokolldateien aufbewahrt werden sollen. In der Regel werden binäre Protokolldateien von Amazon Aurora so schnell wie möglich bereinigt. Eine binäre Protokolldatei ist möglicherweise für die Replikation mit einer außerhalb von Aurora ausgeführten MySQL-Datenbank erforderlich. Der Standardwert von `binlog retention hours` ist `NULL`. Für Aurora MySQL `NULL` bedeutet, dass binäre Protokolle faul aufgeräumt werden. Aurora-MySQL-Binärprotokolle können für einen bestimmten Zeitraum im System verbleiben, normalerweise nicht länger als einen Tag. Um die Anzahl der Stunden zu bestimmen, für die Binärprotokolle auf einer/einem DB-Cluster aufbewahrt werden sollen, verwenden Sie die gespeicherte Prozedur `mysql.rds_set_configuration` und geben Sie, wie in dem folgenden Beispiel gezeigt, einen ausreichend großen Zeitraum für die gewünschte Replikation an. `call mysql.rds_set_configuration('binlog retention hours', 24);` **Anmerkung** Sie können den Wert `0` nicht für `binlog retention hours` verwenden. Der maximal zulässige `binlog retention hours`-Wert für DB-Cluster von Aurora MySQL Version 2.11.0 und höher sowie Version 3 ist 2 160 (90 Tage). Nachdem Sie den Aufbewahrungszeitraum festgelegt haben, überwachen Sie die Speichernutzung für die DB-Instance, um sicherzustellen, dass die aufbewahrten binären Protokolle nicht zu viel Speicherplatz beanspruchen. ## mysql.rds\$1show\$1configuration Die Anzahl der Stunden, während der binäre Protokolldateien aufbewahrt werden sollen. ### Syntax ``` CALL mysql.rds_show_configuration; ``` ### Nutzungshinweise Mit der gespeicherten Prozedur `mysql.rds_show_configuration` überprüfen Sie, wie viele Stunden Amazon RDS die binären Protokolldateien aufbewahrt werden. ### Beispiele Nachfolgend sehen Sie ein Beispiel für die Anzeige des Aufbewahrungszeitraums: ``` call mysql.rds_show_configuration; name value description binlog retention hours 24 binlog retention hours specifies the duration in hours before binary logs are automatically deleted. ``` # Aurora-MySQL-spezifische information\$1schema-Tabellen Aurora MySQL verfügt über bestimmte `information_schema`-Tabellen, die für Aurora spezifisch sind. ## information\$1schema.aurora\$1global\$1db\$1instance\$1status Die Tabelle `information_schema.aurora_global_db_instance_status` enthält Informationen über den Status aller DB-Instances in den primären und sekundären DB-Clustern einer globalen Datenbank. Die Spalten, die Sie verwenden können, sind in der folgenden Tabelle aufgeführt. Die übrigen Spalten sind nur für den internen Gebrauch von Aurora bestimmt. **Anmerkung** Diese Informationsschematabelle ist nur mit globalen Aurora-MySQL-Datenbanken ab Version 3.04.0 verfügbar. | Spalte | Datentyp | Beschreibung | | --- | --- | --- | | SERVER\$1ID | varchar(100) | Die ID der DB-Instance. | | SESSION\$1ID | varchar(100) | Eindeutiger Bezeichner für die aktuelle Sitzung. Der Wert MASTER\$1SESSION\$1ID bezeichnet die (primäre) Writer-DB-Instance. | | AWS\$1REGION | varchar(100) | Die AWS-Region, in der diese globale DB-Instance ausgeführt wird. Eine Liste der Regionen finden Sie unter [Verfügbarkeit in Regionen](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability). | | DURABLE\$1LSN | bigint unsigned | Die Log-Sequenznummer (LSN), die dauerhaft gespeichert wurde. Eine Log-Sequenznummer (LSN) ist eine eindeutige fortlaufende Nummer, die einen Datensatz im Datenbank-Transaktionsprotokoll identifiziert. LSNs werden so angeordnet, dass eine größere LSN eine spätere Transaktion darstellt. | | HIGHEST\$1LSN\$1RCVD | bigint unsigned | Die höchste LSN, die die DB-Instance von der Writer-DB-Instance empfangen hat. | | OLDEST\$1READ\$1VIEW\$1TRX\$1ID | bigint unsigned | Die ID der ältesten Transaktion, zu der die Writer-DB-Instance Daten löschen kann. | | OLDEST\$1READ\$1VIEW\$1LSN | bigint unsigned | Die älteste LSN, die von der DB-Instance zum Lesen aus dem Speicher verwendet wird. | | VISIBILITY\$1LAG\$1IN\$1MSEC | float(10,0) unsigned | Für Reader im primären DB-Cluster, wie weit diese DB-Instance der Writer-DB-Instance in Millisekunden hinterherhinkt. Für Reader in einem sekundären DB-Cluster, wie weit diese DB-Instance dem sekundären Volume in Millisekunden hinterherhinkt. | ## information\$1schema.aurora\$1global\$1db\$1status Die Tabelle `information_schema.aurora_global_db_status` enthält Informationen über verschiedene Aspekte der globalen Aurora-Datenbankverzögerung an, insbesondere die Verzögerung des zugrunde liegenden Aurora-Speichers (sogenannte Haltbarkeitsverzögerung) und die Verzögerung zwischen dem Recovery Point Objective (RPO). Die Spalten, die Sie verwenden können, sind in der folgenden Tabelle aufgeführt. Die übrigen Spalten sind nur für den internen Gebrauch von Aurora bestimmt. **Anmerkung** Diese Informationsschematabelle ist nur mit globalen Aurora-MySQL-Datenbanken ab Version 3.04.0 verfügbar. | Spalte | Datentyp | Beschreibung | | --- | --- | --- | | AWS\$1REGION | varchar(100) | Die AWS-Region, in der diese globale DB-Instance ausgeführt wird. Eine Liste der Regionen finden Sie unter [Verfügbarkeit in Regionen](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability). | | HIGHEST\$1LSN\$1WRITTEN | bigint unsigned | Die höchste Log-Sequenznummer (LSN), die derzeit auf diesem DB-Cluster vorhanden ist. Eine Log-Sequenznummer (LSN) ist eine eindeutige fortlaufende Nummer, die einen Datensatz im Datenbank-Transaktionsprotokoll identifiziert. LSNs werden so angeordnet, dass eine größere LSN eine spätere Transaktion darstellt. | | DURABILITY\$1LAG\$1IN\$1MILLISECONDS | float(10,0) unsigned | Die Differenz der Zeitstempelwerte zwischen HIGHEST\$1LSN\$1WRITTEN in einem sekundären DB-Cluster und HIGHEST\$1LSN\$1WRITTEN im primären DB-Cluster. Der Wert ist immer 0 im primären DB-Cluster der globalen Aurora-Datenbank. | | RPO\$1LAG\$1IN\$1MILLISECONDS | float(10,0) unsigned | Die Recovery Point Objective (RPO)-Verzögerung. Die RPO-Verzögerung ist die Zeit, die benötigt wird, bis die letzte Benutzertransaktion COMMIT auf einem sekundären DB-Cluster gespeichert wird, nachdem sie auf dem primären DB-Cluster einer globalen Aurora-Datenbank abgelegt wurde. Der Wert ist immer 0 im primären DB-Cluster der globalen Aurora-Datenbank. Einfach ausgedrückt berechnet diese Metrik das Recovery Point Objective für jeden DB-Cluster voon Aurora MySQL in der globalen Aurora-Datenbank, d. h., wie viele Daten bei einem Ausfall verloren gehen könnten. Wie die Verzögerung wird auch RPO zeitlich gemessen. | | LAST\$1LAG\$1CALCULATION\$1TIMESTAMP | datetime | Der Zeitstempel, der angibt, wann die Werte für DURABILITY\$1LAG\$1IN\$1MILLISECONDS und RPO\$1LAG\$1IN\$1MILLISECONDS zuletzt berechnet wurden. Ein Zeitwert wie 1970-01-01 00:00:00\$100 bedeutet, dass dies der primäre DB-Cluster ist. | | OLDEST\$1READ\$1VIEW\$1TRX\$1ID | bigint unsigned | Die ID der ältesten Transaktion, zu der die Writer-DB-Instance Daten löschen kann. | ## information\$1schema.replica\$1host\$1status Die Tabelle `information_schema.replica_host_status` enthält Replikationsinformationen. Die Spalten, die Sie verwenden können, sind in der folgenden Tabelle aufgeführt. Die übrigen Spalten sind nur für den internen Gebrauch von Aurora bestimmt. | Spalte | Datentyp | Beschreibung | | --- | --- | --- | | CPU | double | Die prozentuale CPU-Auslastung des Replikat-Hosts. | | IS\$1CURRENT | tinyint | Gibt an, ob das Replikat aktuell ist. | | LAST\$1UPDATE\$1TIMESTAMP | datetime(6) | Zeitpunkt, an dem die letzte Aktualisierung stattfand. Wird verwendet, um festzustellen, ob ein Datensatz veraltet ist. | | REPLICA\$1LAG\$1IN\$1MILLISECONDS | double | Die Replikatverzögerung in Millisekunden. | | SERVER\$1ID | varchar(100) | Die ID des Datenbankservers. | | SESSION\$1ID | varchar(100) | Die ID der Datenbanksitzung. Wird verwendet, um festzustellen, ob es sich bei einer DB-Instance um eine Writer- oder Reader-Instance handelt. | **Anmerkung** Wenn eine Replikat-Instance in Verzug gerät, sind die aus ihrer `information_schema.replica_host_status`-Tabelle abgefragten Informationen möglicherweise veraltet. In diesem Fall empfehlen wir, stattdessen eine Abfrage von der Writer-Instance aus durchzuführen. Die Tabelle `mysql.ro_replica_status` enthält zwar ähnliche Informationen, wir raten Ihnen jedoch davon ab, diese zu verwenden. ## information\$1schema.aurora\$1forwarding\$1processlist Die Tabelle `information_schema.aurora_forwarding_processlist` enthält Informationen über Prozesse, die an der Schreibweiterleitung beteiligt sind. Der Inhalt dieser Tabelle ist nur auf der Writer-DB-Instance für einen DB-Cluster sichtbar, bei dem die globale oder clusterinterne Schreibweiterleitung aktiviert ist. Auf Reader-DB-Instances wird ein leerer Ergebnissatz zurückgegeben. | Feld | Datentyp | Beschreibung | | --- | --- | --- | | ID | bigint | Der Bezeichner der Verbindung auf der Writer-DB-Instance. Dieser Bezeichner ist derselbe Wert, der in der Spalte Id der SHOW PROCESSLIST-Anweisung angezeigt wird, und wird von der Funktion CONNECTION\$1ID() innerhalb des Threads zurückgegeben. | | USER | varchar(32) | Der MySQL-Benutzer, der die Anweisung erstellt hat. | | HOST | varchar(255) | Der MySQL-Client, der die Anweisung erstellt hat. Für weitergeleitete Anweisungen zeigt dieses Feld die Hostadresse des Anwendungsclients an, der die Verbindung auf der weiterleitenden Reader-DB-Instance hergestellt hat. | | DB | varchar(64) | Die Standarddatenbank für den Thread. | | COMMAND | varchar(16) | Die Art des Befehls, den der Thread im Namen des Clients ausführt, oder Sleep, wenn die Sitzung inaktiv ist. Eine Beschreibung der Thread-Befehle finden Sie unter [Thread Command Values](https://dev.mysql.com/doc/refman/8.0/en/thread-commands.html) (Thread-Befehlswerte) in der MySQL-Dokumentation . | | TIME | int | Die Zeit in Sekunden, in der sich der Thread in seinem aktuellen Status befand. | | STATE | varchar(64) | Eine Aktion, ein Ereignis oder ein Status, der angibt, welche Aktionen der Thread ausführt. Eine Beschreibung der Statuswerte finden Sie unter [General Thread Status](https://dev.mysql.com/doc/refman/8.0/en/general-thread-states.html) (Allgemeine Thread-Status) in der MySQL-Dokumentation. | | INFO | longtext | Die Anweisung, die der Thread ausführt, oder NULL, wenn er keine Anweisung ausführt. Bei der Anweisung kann es sich um die an den Server gesendete oder um eine innerste Anweisung handeln, wenn die Anweisung andere Anweisungen ausführt. | | IS\$1FORWARDED | bigint | Gibt an, ob der Thread von einer Reader-DB-Instance weitergeleitet wird. | | REPLICA\$1SESSION\$1ID | bigint | Die Verbindungs-ID in der Aurora Replica. Dieser Bezeichner ist derselbe Wert, der in der Spalte Id der SHOW PROCESSLIST-Anweisung auf der weiterleitenden Reader-DB-Instance von Aurora angezeigt wird. | | REPLICA\$1INSTANCE\$1IDENTIFIER | varchar(64) | Die ID der DB-Instance des weiterleitenden Threads. | | REPLICA\$1CLUSTER\$1NAME | varchar(64) | Die ID des DB-Clusters des weiterleitenden Threads. Für die In-Cluster-Schreibweiterleitung ist diese ID derselbe DB-Cluster wie die Writer-DB-Instance. | | REPLICA\$1REGION | varchar(64) | Die AWS-Region, aus der der weiterleitende Thread stammt. Für die In-Cluster-Schreibweiterleitung ist diese Region dieselbe AWS-Region wie die Writer-DB-Instance. |