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.
# 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.
```