engine=innodb, algorithm=copy;
```
In den folgenden Abschnitten richten Sie die Replikation ein, halten die Replikation an, skalieren Lesevorgänge für Ihre Datenbank, optimieren die Binlog-Replikation und richten das erweiterte Binlog ein.
**Topics**
+ [Einrichten einer binären Protokollreplikation für Aurora MySQL](AuroraMySQL.Replication.MySQL.SettingUp.md)
+ [Anhalten einer binären Protokollreplikation für Aurora MySQL](AuroraMySQL.Replication.MySQL.Stopping.md)
+ [Skalieren von Lesevorgängen für Ihre MySQL-Datenbank mit Amazon Aurora](AuroraMySQL.Replication.ReadScaling.md)
+ [Optimieren einer binären Protokollreplikation für Aurora MySQL](binlog-optimization.md)
+ [Einrichten eines erweiterten Binärprotokolls für Aurora MySQL](AuroraMySQL.Enhanced.binlog.md)
# Einrichten einer binären Protokollreplikation für Aurora MySQL
Das Einrichten einer MySQL-Replikation mit Aurora MySQL umfasst die folgenden Schritte, die ausführlich erklärt werden:
**Contents**
+ [1. Aktivieren der Binärprotokollierung für die Replikationsquelle](#AuroraMySQL.Replication.MySQL.EnableBinlog)
+ [2. Beibehaltung der Binärprotokolle für die Replikationsquelle, bis diese nicht mehr erforderlich sind](#AuroraMySQL.Replication.MySQL.RetainBinlogs)
+ [3. Erstellen einer Kopie oder eines Dumps Ihrer Replikationsquelle](#AuroraMySQL.Replication.MySQL.CreateSnapshot)
+ [4. Laden des Dumps in das Replikatziel (falls erforderlich)](#AuroraMySQL.Replication.MySQL.LoadSnapshot)
+ [5. Erstellen Sie einen Replikationsbenutzer auf Ihrer Replikationsquelle](#AuroraMySQL.Replication.MySQL.CreateReplUser)
+ [6. Aktivieren der Replikation für das Replikat-Ziel](#AuroraMySQL.Replication.MySQL.EnableReplication)
+ [Festlegen einer Position zum Stoppen der Replikation zu einer Read Replica](#AuroraMySQL.Replication.StartReplicationUntil)
+ [7. Überwachen Ihres Replikats](#AuroraMySQL.Replication.MySQL.Monitor)
+ [Synchronisierung von Passwörtern zwischen Replikationsquelle und -ziel](#AuroraMySQL.Replication.passwords)
## 1. Aktivieren der Binärprotokollierung für die Replikationsquelle
Im Folgenden finden Sie die Anweisungen zum Aktivieren der Binärprotokollierung an der Replikationsquelle für Ihre Datenbank-Engine.
| Datenbank-Engine | Anleitungen |
| --- | --- |
| Aurora MySQL | **So aktivieren Sie die Binärprotokollierung für einen Aurora-MySQL-DB-Cluster** Legen Sie den Parameter `binlog_format` auf `ROW`, `STATEMENT` oder `MIXED` fest. `MIXED` wird empfohlen, sofern kein bestimmtes Format für das Binärprotokoll notwendig ist. (Der Standardwert ist `OFF`.) Um den`binlog_format`-Parameter zu ändern, erstellen Sie eine benutzerdefinierte DB-Cluster-Parametergruppe und ordnen Sie diese benutzerdefinierte Parametergruppe Ihrem DB-Cluster zu. Sie können die Parameter in einer Standard-DB-Clusterparametergruppe nicht ändern. Wenn Sie den Parameter `binlog_format` von `OFF` zu einem anderen Wert ändern, müssen Sie Ihren Aurora-DB-Cluster neu starten, damit die Änderung wirksam wird. Weitere Informationen erhalten Sie unter [Amazon Aurora-DB-Cluster und DB-Instance-Parameter](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups) und [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.md). |
| RDS für MySQL | **So aktivieren Sie die Binärprotokollierung für eine Amazon-RDS-DB-Instance** Sie können die Binärprotokollierung nicht direkt für eine Amazon-RDS-DB-Instance aktivieren, aber Sie können diese Funktion aktivieren, indem Sie Folgendes tun: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (extern) | **So richten Sie eine verschlüsselte Replikation ein** Wenn Sie Daten sicher mit Aurora-MySQL-Version 2 replizieren möchten, verwenden Sie eine verschlüsselte Replikation. Wenn Sie keine verschlüsselte Replikation benötigen, können Sie diese Schritte überspringen. Folgende Voraussetzungen gelten für die Verwendung einer verschlüsselten Replikation: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) 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. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **So aktivieren Sie die Binärprotokollierung für eine externe MySQL-Datenbank** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 2. Beibehaltung der Binärprotokolle für die Replikationsquelle, bis diese nicht mehr erforderlich sind
Wenn Sie die binäre MySQL-Protokollreplikation verwenden, verwaltet Amazon RDS den Replikationsvorgang nicht. Daher müssen Sie sicherstellen, dass die Binärprotokolldateien an Ihre Replikationsquelle so lange aufbewahrt werden, bis die Änderungen auf das Replica angewandt wurden. Durch diese Pflege können Sie Ihre Quelldatenbank im Fall eines Ausfalls wiederherstellen.
Verwenden Sie folgende Anweisungen zur Beibehaltung von Binärprotokollen für Ihre Datenbank-Engine.
| Datenbank-Engine | Anleitungen |
| --- | --- |
| Aurora MySQL | **So bewahren Sie Binärprotokolle für einen Aurora MySQL-DB-Cluster auf** Sie haben keinen Zugriff auf die Binärprotokolldateien eines Aurora-MySQL-DB-Clusters. Daher müssen Sie für die Aufbewahrung der Binärprotokolldateien an Ihrer Replikationsquelle ein ausreichend langes Zeitfenster festlegen, um sicherzustellen, dass die Änderungen auf Ihr Replica angewandt wurden, bevor die Binärprotokolldatei von Amazon RDS gelöscht wird. Sie können diese Binärprotokolldateien in einem Aurora MySQL-DB-Cluster für bis zu 90 Tage aufbewahren. Wenn Sie eine Replikation mit einer MySQL-Datenbank oder einer RDS für MySQL-DB-Instance als Replica einrichten und die Datenbank, für die Sie eine Replica erstellen, sehr groß ist, wählen Sie ein großes Zeitfenster, um Binärprotokolldateien aufzubewahren, bis die erste Kopie der Datenbank in der Replica abgeschlossen ist und die Replica-Verzögerung den Wert 0 erreicht hat. 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. Der maximal zulässige Wert für Aurora MySQL Version 2.11.0 und höher sowie Version 3 ist 2 160 (90 Tage). Beim folgenden Beispiel wird der Aufbewahrungszeitraum für binäre Protokolle auf 6 Tage festgelegt: CALL mysql.rds_set_configuration('binlog retention hours', 144); Nachdem die Replikation gestartet wurde, können Sie nach dem Ausführen des Befehls `SHOW SLAVE STATUS` (Aurora-MySQL-Version 2) oder `SHOW REPLICA STATUS` (Aurora-MySQL-Version 3) für das Read Replica im Feld `Seconds behind master` überprüfen, ob Änderungen auf Ihr Replica angewandt wurden. Wenn der Wert im Feld `Seconds behind master` 0 ist, gibt es keine Replikatverzögerung. Wenn keine Replica-Verzögerung vorliegt, reduzieren Sie den Aufbewahrungszeitraum für die Binärprotokolldateien, indem Sie den Konfigurationsparameter `binlog retention hours` auf ein kleineres Zeitfenster einstellen. Wenn diese Einstellung nicht angegeben wird, ist der Standardwert für Aurora MySQL 24 (1 Tag). Wenn Sie einen Wert für `'binlog retention hours'` angeben, der den maximal zulässigen Wert überschreitet, dann wird von Aurora MySQL der maximale Wert verwendet. |
| RDS für MySQL | **So bewahren Sie Binärprotokolle einer Amazon-RDS-DB-Instance auf** Sie können binäre Protokolldateien auf einer Amazon-RDS-DB-Instance aufbewahren, indem Sie die Stundenanzahl für die Aufbewahrung einstellen, so wie es bereits für einen Aurora-MySQL-DB-Cluster im vorherigen Anschnitt erläutert wurde. Sie können auch Binärprotokolldateien für eine Amazon-RDS-DB-Instance aufbewahren, indem Sie ein Lesereplikat von dieser DB-Instance erstellen. Dieses Lesereplikat ist temporär und lediglich dazu gedacht, Binärprotokolldateien aufzubewahren. Nachdem das Lesereplikat erstellt wurde, rufen Sie die Prozedur [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) für das Lesereplikat auf. Während die Replikation angehalten wird, löscht Amazon RDS keine der Binärprotokolldateien für die Replikationsquelle. Nachdem Sie die Replikation mit Ihrem permanenten Replikat eingerichtet haben, können Sie das Read-Replikat löschen, sobald die Replikat-Verzögerung (Feld `Seconds behind master`) zwischen Ihrer Replikationsquelle und Ihrem permanenten Replikat den Wert 0 erreicht hat. |
| MySQL (extern) | **So bewahren Sie Binärprotokolle in einer externen MySQL-Datenbank** Da die Binärprotokolldateien in einer externen MySQL-Datenbank nicht von Amazon RDS verwaltet werden, werden diese aufbewahrt, bis Sie sie selbst löschen. Nachdem die Replikation gestartet wurde, können Sie nach dem Ausführen des Befehls `SHOW SLAVE STATUS` (Aurora-MySQL-Version 2) oder `SHOW REPLICA STATUS` (Aurora-MySQL-Version 3) für das Read Replica im Feld `Seconds behind master` überprüfen, ob Änderungen auf Ihr Replica angewandt wurden. Wenn der Wert im Feld `Seconds behind master` 0 ist, gibt es keine Replikatverzögerung. Wenn keine Replica-Verzögerung besteht, können Sie alte Binärprotokolldateien löschen. |
## 3. Erstellen einer Kopie oder eines Dumps Ihrer Replikationsquelle
Sie verwenden einen Snapshot, Klon oder Dump Ihrer Replikationsquelle, um die Baseline-Kopie Ihrer Daten in Ihr Replikat zu kopieren. Dann starten Sie die Replikation ab diesem Punkt.
Verwenden Sie folgende Anleitungen zum Erstellen einer Kopie oder eines Dumps der Replikationsquelle für Ihre Datenbank-Engine.
| Datenbank-Engine | Anleitungen |
| --- | --- |
| Aurora MySQL | **So erstellen Sie eine Kopie eines DB-Clusters von Aurora MySQL** Verwenden Sie eine der folgenden Methoden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **So bestimmen Sie den Namen und die Position der Binlog-Datei** Verwenden Sie eine der folgenden Methoden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **So erstellen Sie einen Dump eines DB-Clusters von Aurora MySQL** Wenn Ihr Replikatziel eine externe MySQL-Datenbank oder eine DB-Instance von RDS für MySQL ist, müssen Sie eine Dump-Datei aus dem Aurora-DB-Cluster erstellen. Stellen Sie sicher, dass der Befehl `mysqldump` für die Kopie des von Ihnen erstellten Quell-DB-Clusters ausgeführt wird. Dadurch werden Sperrüberlegungen beim Erstellen des Dumps vermieden. Wenn der Dump direkt auf dem Quell-DB-Cluster erstellt würde, müssten die Quelltabellen gesperrt werden, um gleichzeitige Schreibvorgänge in diese während des Dump-Vorgangs zu vermeiden. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| RDS für MySQL | **So erstellen Sie einen Snapshot Ihrer Amazon-RDS-DB-Instance** Erstellen Sie ein Lesereplikat Ihrer Amazon-RDS-DB-Instance. Weitere Informationen finden Sie unter [Erstellen einer Read Replica](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create) im *Amazon Relational Database Service-Benutzerhandbuch*. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (extern) | **So erstellen Sie einen Dump einer externen MySQL-Datenbank** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 4. Laden des Dumps in das Replikatziel (falls erforderlich)
Wenn Sie Daten aus einem Dump einer Amazon-RDS-externen MySQL-Datenbank laden möchten, können Sie eine EC2-Instance erstellen, um die Dump-Dateien dorthin zu kopieren. Anschließend können Sie die Daten aus dieser EC2-Instance in den DB-Cluster oder die DB-Instance laden. Bei Verwendung dieses Ansatzes können Sie die Dumpdateien komprimieren, bevor Sie sie in eine EC2-Instance kopieren, um Netzwerkkosten zu minimieren, die in Verbindung mit dem Kopieren von Dateien nach Amazon RDS entstehen. Sie können die Dumpdatei oder -dateien auch verschlüsseln, um sie beim Übermitteln im Netzwerk zu schützen.
**Anmerkung**
Wenn Sie einen neuen DB-Cluster von Aurora MySQL als Replikatziel erstellen, müssen Sie keine Dump-Datei laden:
Sie können aus einem DB-Cluster-Snapshot wiederherstellen, um einen neuen DB-Cluster zu erstellen. Weitere Informationen finden Sie unter [Wiederherstellen aus einem DB-Cluster-Snapshot](aurora-restore-snapshot.md).
Sie können Ihren Quell-DB-Cluster klonen, um einen neuen DB-Cluster zu erstellen. Weitere Informationen finden Sie unter [Klonen eines Volumes für einen Amazon-Aurora-DB-Cluster](Aurora.Managing.Clone.md).
Sie können die Daten aus einem DB-Instance-Snapshot zu einem neuen DB-Cluster migrieren. Weitere Informationen finden Sie unter [Migrieren von Daten zu einem Amazon Aurora MySQL-DB-Cluster](AuroraMySQL.Migrating.md).
Verwenden Sie folgende Anleitungen, um den Dump Ihrer Replikationsquelle in das Replikatziel für Ihre Datenbank-Engine zu laden.
| Datenbank-Engine | Anleitungen |
| --- | --- |
| Aurora MySQL | **So laden Sie einen Dump in einen DB-Cluster von Aurora MySQL** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| RDS für MySQL | **So laden Sie einen Dump in eine DB-Instance von Amazon RDS** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (extern) | **So laden Sie einen Dump in eine externe MySQL-Datenbank** Sie können keinen DB-Snapshot oder DB-Cluster-Snapshot in eine externe MySQL-Datenbank laden. Stattdessen müssen Sie die Ausgabe des `mysqldump`-Befehls verwenden. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 5. Erstellen Sie einen Replikationsbenutzer auf Ihrer Replikationsquelle
Erstellen Sie eine Benutzer-ID an der Quelle, die ausschließlich für die Replikation verwendet wird. Das folgende Beispiel bezieht sich auf RDS für MySQL oder externe MySQL-Quelldatenbanken.
```
mysql> CREATE USER 'repl_user'@'domain_name' IDENTIFIED BY 'password';
```
Für Aurora-MySQL-Quelldatenbanken ist der DB-Cluster-Parameter `skip_name_resolve` auf `1` (`ON`) gesetzt und kann nicht geändert werden. Sie müssen also eine IP-Adresse für den Host anstelle eines Domainnamens verwenden. Weitere Informationen finden Sie unter [skip\$1name\$1resolve](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_skip_name_resolve) in der MySQL-Dokumentation.
```
mysql> CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password';
```
Der Benutzer benötigt die Berechtigungen `REPLICATION CLIENT` und `REPLICATION SLAVE`. Gewähren Sie dem Benutzer diese Berechtigungen.
Wenn die Replikation verschlüsselt durchgeführt werden muss, fordern Sie für den Replikationsbenutzer eine SSL-Verbindung an. Sie können beispielsweise mit einer der folgenden Anweisungen SSL-Verbindungen für das Benutzerkonto `repl_user` erforderlich machen.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address';
```
```
GRANT USAGE ON *.* TO 'repl_user'@'IP_address' REQUIRE SSL;
```
**Anmerkung**
Wenn `REQUIRE SSL` nicht angegeben wird, kann die Replikationsverbindung ohne entsprechende Meldung auf eine unverschlüsselte Verbindung zurückgesetzt werden.
## 6. Aktivieren der Replikation für das Replikat-Ziel
Bevor Sie die Replikation aktivieren, empfehlen wir, manuell einen Snapshot des Aurora-MySQL-DB-Clusters oder des RDS für MySQL-DB-Instance Replica-Ziels zu erstellen. Wenn ein Problem auftritt und Sie den Replikationsvorgang mit dem DB-Cluster oder dem DB-Instance-Replica-Ziel wieder einrichten müssen, können Sie das DB-Cluster bzw. die DB-Instance aus diesem Snapshot wiederherstellen, anstatt erneut Daten in das Replica-Ziel zu importieren.
Verwenden Sie folgende Anweisungen zum Aktivieren der Replikation für Ihre Datenbank-Engine.
| Datenbank-Engine | Anleitungen |
| --- | --- |
| Aurora MySQL | **So aktivieren Sie die Replikation aus einem Aurora-MySQL-DB-Cluster** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Zur Verwendung der SSL-Verschlüsselung legen Sie den endgültigen Wert auf `1` statt auf `0` fest. |
| RDS für MySQL | **So aktivieren Sie die Replikation aus einer Amazon-RDS-DB-Instance** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Zur Verwendung der SSL-Verschlüsselung legen Sie den endgültigen Wert auf `1` statt auf `0` fest. |
| MySQL (extern) | **So aktivieren Sie die Replikation aus einer externen MySQL-Datenbank** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
Schlägt die Replikation fehl, kann dies zu einer starken Zunahme unbeabsichtigter Zugriffe I/O auf das Replikat führen, was wiederum zu Leistungseinbußen führen kann. Wenn die Replikation fehlschlägt oder nicht mehr benötigt wird, können Sie das gespeicherte Verfahren [mysql.rds\$1next\$1master\$1log (Aurora-MySQL-Version 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) oder [mysql.rds\$1next\$1source\$1log (Aurora-MySQL-Version 3)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) zum Entfernen der Replikationskonfiguration durchführen.
### Festlegen einer Position zum Stoppen der Replikation zu einer Read Replica
In der Aurora MySQL-Version 3.04 und höher können Sie die Replikation starten und dann an einem bestimmten Ort in der Binär-Protokolldatei mit der gespeicherten [mysql.rds\$1start\$1replication\$1until (Aurora MySQL Version 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until)-Prozedur anhalten.
**Starten Sie die Replikation für ein Lesereplikat und stoppen Sie die Replikation an einer bestimmten Position wie folgt:**
1. Verwenden Sie einen MySQL-Client, um als Master-Benutzer eine Verbindung zum Replikat-DB-Cluster von Aurora MySQL herzustellen.
1. Führen Sie die gespeicherte Prozedur [mysql.rds\$1start\$1replication\$1until (Aurora MySQL Version 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) aus.
Das folgende Beispiel initiiert die Replikation und repliziert die Änderungen, bis die Position `120` in der Binärprotokolldatei `mysql-bin-changelog.000777` erreicht wird. Beispiel: In einem Szenario der Notfallwiederherstellung liegt die Position `120` unmittelbar vor der Katastrophe.
```
call mysql.rds_start_replication_until(
'mysql-bin-changelog.000777',
120);
```
Die Replikation stoppt automatisch, sobald der Stopppunkt erreicht ist. Das folgende RDS-Ereignis wird generiert: `Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure`.
Wenn Sie die GTID-basierte Replikation verwenden, nutzen Sie die gespeicherte Prozedur [mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL Version 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) anstelle der gespeicherten Prozedur [mysql.rds\$1start\$1replication\$1until (Aurora MySQL Version 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). Weitere Informationen zu GTID-basierten Replikationen finden Sie unter [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md).
## 7. Überwachen Ihres Replikats
Wenn Sie eine MySQL-Replikation mit einem Aurora MySQL-DB-Cluster eingerichtet haben, müssen Sie Failover-Ereignisse für den Aurora MySQL-DB-Cluster überwachen, wenn dieser ein Replica-Ziel ist. Im Falle eines Failovers kann dann das DB-Cluster (das Replica-Ziel) auf einem neuen Host mit einer anderen Netzwerkadresse erneut erstellt werden. Weitere Informationen zum Überwachen von Failover-Ereignissen finden Sie unter [Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen](USER_Events.md).
Sie können außerdem überwachen, wie weit das Replica-Ziel hinter der Replikationsquelle zurückliegt, indem Sie eine Verbindung zum Replica-Ziel herstellen und den Befehl `SHOW SLAVE STATUS` (Aurora-MySQL-Version 2) oder `SHOW REPLICA STATUS` (Aurora-MySQL-Version 3) ausführen. In der Befehlsausgabe wird im Feld `Seconds Behind Master` angezeigt, wie weit das Replica-Ziel hinter der Quelle zurückliegt.
**Wichtig**
Wenn Sie Ihren DB-Cluster aktualisieren und eine benutzerdefinierte Parametergruppe angeben, müssen Sie den Cluster nach Abschluss des Upgrades unbedingt manuell neu starten. Dadurch verwendet der Cluster Ihre neuen benutzerdefinierten Parametereinstellungen und die Binlog-Replikation wird neu gestartet.
## Synchronisierung von Passwörtern zwischen Replikationsquelle und -ziel
Wenn Sie Benutzerkonten und Kennwörter auf der Replikationsquelle mithilfe von SQL-Anweisungen ändern, werden diese Änderungen automatisch auf das Replikationsziel repliziert.
Wenn Sie die AWS-Managementkonsole, oder die RDS-API verwenden AWS CLI, um das Master-Passwort für die Replikationsquelle zu ändern, werden diese Änderungen nicht automatisch auf das Replizierungsziel repliziert. Wenn Sie den Master-Benutzer und das Master-Kennwort zwischen dem Quell- und dem Zielsystem synchronisieren möchten, müssen Sie die gleiche Änderung auf dem Replikationsziel selbst vornehmen.
# Anhalten einer binären Protokollreplikation für Aurora MySQL
Folgen Sie diesen im folgenden Verlauf detailliert beschriebenen Schritten, um eine binäre Protokollreplikation mit einer MySQL-DB-Instance, einer externen MySQL-Datenbank oder einem anderen Aurora-DB-Cluster anzuhalten.
[1. Anhalten der binären Protokollreplikation für das Replikat-Ziel](#AuroraMySQL.Replication.MySQL.Stopping.StopReplication)
[2. Deaktivieren der Binärprotokollierung für die Replikationsquelle](#AuroraMySQL.Replication.MySQL.Stopping.DisableBinaryLogging)
## 1. Anhalten der binären Protokollreplikation für das Replikat-Ziel
Im Folgenden finden Sie die Anweisungen zum Anhalten der binären Protokollreplikation für Ihre Datenbank-Engine.
| Datenbank-Engine | Anleitungen |
| --- | --- |
| Aurora MySQL | **So können Sie die binären Protokollreplikation in einem Aurora MySQL-DB-Cluster-Replica-Ziel anhalten** Stellen Sie eine Verbindung mit dem als Replica-Ziel verwendeten Aurora-DB-Cluster her und rufen Sie die Prozedur [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) auf. |
| RDS für MySQL | **So können Sie eine binären Protokollreplikation in einer Amazon-RDS-DB-Instance anhalten** Stellen Sie eine Verbindung mit der als Replica-Ziel verwendeten RDS-DB-Instance her und rufen Sie die Prozedur [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) auf. |
| MySQL (extern) | **So halten Sie die binären Protokollreplikation für eine externe MySQL-Datenbank an** Stellen Sie eine Verbindung mit der MySQL-Datenbank her und führen Sie den Befehl `STOP SLAVE` (Version 5.7) oder `STOP REPLICA` (Version 8.0) aus. |
## 2. Deaktivieren der Binärprotokollierung für die Replikationsquelle
Im Folgenden finden Sie die Anweisungen zum Deaktivieren der Binärprotokollierung an der Replikationsquelle für Ihre Datenbank-Engine.
| Datenbank-Engine | Anleitungen |
| --- | --- |
| Aurora MySQL | **So deaktivieren Sie die Binärprotokollierung für einen Amazon-Aurora-DB-Cluster** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
| RDS für MySQL | **So deaktivieren Sie die Binärprotokollierung für eine Amazon-RDS-DB-Instance** Sie können die Binärprotokollierung nicht direkt für eine Amazon-RDS-DB-Instance deaktivieren, aber Sie können diese Funktion deaktivieren, indem Sie Folgendes tun: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
| MySQL (extern) | **So deaktivieren Sie die Binärprotokollierung für eine externe MySQL-Datenbank** Verbinden Sie sich mit der MySQL-Datenbank und rufen Sie den Befehl `STOP REPLICATION` auf. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
# Skalieren von Lesevorgängen für Ihre MySQL-Datenbank mit Amazon Aurora
Sie können Amazon Aurora mit Ihrer MySQL-DB-Instance verwenden, um die Möglichkeiten der Skalierung von Lesevorgängen von Amazon Aurora zu nutzen und den Lese-Workload für Ihre MySQL-DB-Instance zu erweitern. Erstellen Sie einen Amazon-Aurora MySQL-DB-Cluster und machen Sie ihn zum Read Replica Ihrer MySQL-DB-Instance, um Aurora für die Skalierung von Lesevorgängen Ihrer MySQL-DB-Instance zu verwenden. Dies gilt für eine RDS für MySQL-DB-Instance oder eine MySQL-Datenbank, die außerhalb von Amazon RDS ausgeführt wird.
Weitere Informationen zum Erstellen eines Amazon Aurora-DB-Clusters finden Sie unter [Erstellen eines Amazon Aurora-DB Clusters](Aurora.CreateInstance.md).
Wenn Sie eine Replikation zwischen Ihrer MySQL-DB-Instance und Ihrem Amazon Aurora-DB-Cluster einrichten, folgen Sie sicherheitshalber bitte diesen Anweisungen:
+ Verwenden Sie die Amazon Aurora-DB-Cluster-Endpunkt-Adresse, wenn Sie Ihr Amazon Aurora MySQL-DB-Cluster referenzieren. Bei einem Failover verwendet die Aurora-Replica, die zur primären Instance for das Aurora MySQL-DB-Cluster hochgestuft wird, weiterhin die DB-Cluster-Endpunkt-Adresse.
+ Bewahren Sie die Binärprotokolle auf Ihrer Schreiber-Instance auf, bis Sie sichergestellt haben, dass sie auf das Aurora Replica angewandet wurden. Durch das Aufbewahren können Sie sicherstellen, dass Sie Ihre Schreiber-Instance im Fall eines Ausfalls wiederherstellen können.
**Wichtig**
Wenn Sie eine von Ihnen verwaltete Replikation verwenden, sind Sie für die Überwachung und Lösung jeglicher auftretender Probleme bei der Replikation verantwortlich. Weitere Informationen finden Sie unter [Diagnose und Lösung bei Verzögerungen zwischen Read Replicas (Lesereplikaten)](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag).
**Anmerkung**
Die erforderlichen Berechtigungen zum Starten einer Replikation in einem Amazon-Aurora-MySQL-DB-Cluster sind beschränkt und für Ihren Amazon-RDS-Hauptbenutzer nicht verfügbar. Aus diesem Grund müssen Sie die Prozeduren[mysql.rds\$1set\$1external\$1master (Aurora-MySQL-Version 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master), [mysql.rds\$1set\$1external\$1source (Aurora-MySQL- Version 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) und [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) verwenden, um eine Replikation zwischen Ihrem Aurora-MySQL-DB-Cluster und Ihrer MySQL-DB-Instance einzurichten.
## Starten der Replikation zwischen einer externen Quell-Instance und einem MySQL-DB-Cluster
1. Legen Sie die Quell-MySQL-DB-Instance als schreibgeschützt fest:
```
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;
```
1. Führen Sie den Befehl `SHOW MASTER STATUS` in der Quell-MySQL-DB-Instance aus, um den Speicherort des Binärprotokolls zu bestimmen. Sie erhalten eine Ausgabe, ähnlich der im folgenden Beispiel:
```
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
```
1. Kopieren Sie die Datenbank mithilfe von aus der externen MySQL-DB-Instance in das Amazon Aurora MySQL-DB-Cluster `mysqldump`. Bei sehr großen Datenbanken empfiehlt es sich, das Verfahren zu verwenden, das im Abschnitt zum [Importieren von Daten in eine Datenbank von Amazon RDS für MySQL mit reduzierter Ausfallzeit](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-reduced-downtime.html) im *Benutzerhandbuch zu Amazon Relational Database Service* beschrieben ist.
Für Linux, macOS oder Unix:
```
mysqldump \
--databases \
--single-transaction \
--compress \
--order-by-primary \
-u local_user \
-p local_password | mysql \
--host aurora_cluster_endpoint_address \
--port 3306 \
-u RDS_user_name \
-p RDS_password
```
Für Windows:
```
mysqldump ^
--databases ^
--single-transaction ^
--compress ^
--order-by-primary ^
-u local_user ^
-p local_password | mysql ^
--host aurora_cluster_endpoint_address ^
--port 3306 ^
-u RDS_user_name ^
-p RDS_password
```
**Anmerkung**
Stellen Sie sicher, dass kein Leezeichen zwischen der Option `-p` und dem eingegebenen Passwort vorhanden ist.
Verwenden Sie die Optionen `--host`, `--user (-u)` `--port` und `-p` im Befehl `mysql`, um den Host-Namen, Benutzernamen, Port und das Passwort für die Verbindung mit Ihrem Aurora-DB-Cluster anzugeben. Der Host-Name ist der DNS-Name aus dem Amazon Aurora-DB-Cluster-Endpunkt, z. B, `mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com`. Sie finden den Endpunktwert in den Cluster-Details in der Amazon-RDS-Managementkonsole.
1. Legen Sie die Quell-MySQL-DB-Instance als wieder beschreibbar fest:
```
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
```
Weitere Informationen zum Erstellen von Backups zur Verwendung mit der Replikation finden Sie unter [http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html](http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html) in der MySQL-Dokumentation.
1. Fügen Sie in der Amazon-RDS-Management Console die IP-Adresse des Servers, der die Quell-MySQL-Datenbank hostet, zu der VPC-Sicherheitsgruppe für das Amazon Aurora-DB-Cluster hinzu. Weitere Informationen zum Ändern einer VPC-Sicherheitsgruppe finden Sie unter [Sicherheitsgruppen für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) im *Amazon Virtual Private Cloud-Benutzerhandbuch*.
Es könnte sein, dass Sie Ihr lokales Netzwerk so konfigurieren müssen, dass es Verbindungen von der IP-Adresse Ihres Amazon Aurora-DB-Clusters zulässt, damit Sie mit Ihrer Quell-MySQL-Datenbank kommunizieren können. Verwenden Sie den Befehl `host`, um die IP-Adresse des Amazon Aurora-DB-Clusters herauszufinden.
```
host aurora_endpoint_address
```
Der Hostname ist der DNS-Name aus dem Amazon Aurora-DB-Cluster-Endpunkt.
1. Verbinden Sie sich mithilfe eines Clients Ihrer Wahl mit der externen MySQL-Instance und erstellen Sie einen MySQL-Benutzer, der für die Replikation verwendet werden soll. Dieses Konto wird ausschließlich für die Replikation verwendet und muss auf Ihre Domäne beschränkt sein, um die Sicherheit zu erhöhen. Im Folgenden wird ein Beispiel gezeigt.
```
CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password';
```
1. Erteilen Sie Ihrem Replikationsbenutzer für die externe MySQL-Instance die Sonderrechte `REPLICATION CLIENT` und `REPLICATION SLAVE`. Erteilen Sie beispielsweise die Sonderrechte `REPLICATION CLIENT` und `REPLICATION SLAVE` in allen Datenbank für den '`repl_user`'-Benutzer für Ihre Domäne, mit dem folgenden Befehl.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com'
IDENTIFIED BY 'password';
```
1. Machen Sie einen manuellen Snapshot des Aurora MySQL-DB-Clusters, der das Read Replica sein soll, bevor Sie eine Replikation einrichten. Wenn Sie erneut eine Replikation mit dem DB-Cluster als Read Replica einrichten müssen, können Sie das Aurora MySQL-DB-Cluster aus diesem Snapshot wiederherstellen, anstatt die Daten aus Ihrer-MySQL-DB-Instance in ein neues Aurora MySQL-DB-Cluster importieren zu müssen.
1. Legen Sie das Amazon Aurora-DB-Cluster als Replica fest. Verbinden Sie sich als Master-Benutzer mit dem DB-Cluster von Amazon Aurora und bestimmen Sie die MySQL-Quelldatenbank mithilfe der Prozeduren [mysql.rds\$1set\$1external\$1master (Aurora-MySQL-Version 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) oder [mysql.rds\$1set\$1external\$1source (Aurora-MySQL- Version 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) und [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) als Replikationsquelle.
Verwenden Sie den Namen und die Position der Binlog-Datei, die Sie in Schritt 2 festgelegt haben. Im Folgenden wird ein -Beispiel gezeigt.
```
For Aurora MySQL version 2:
CALL mysql.rds_set_external_master ('mymasterserver.example.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
For Aurora MySQL version 3:
CALL mysql.rds_set_external_source ('mymasterserver.example.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
```
1. Rufen Sie auf dem Amazon-Aurora-DB-Cluster die [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication)-Prozedur auf, um die Replikation zu starten.
```
CALL mysql.rds_start_replication;
```
Nachdem Sie die Replikation zwischen Ihrer Quell-MySQL-DB-Instance und Ihrem Amazon Aurora-DB-Cluster erneut eingerichtet haben, können Sie Aurora-Replicas zu Ihrem Amazon Aurora-DB-Cluster hinzufügen. Sie können sich anschließend mit dem Aurora Replicas verbinden, um die Lesevorgänge Ihrer Daten zu skalieren. Weitere Informationen über das Erstellen einer Aurora-Replica finden Sie unter [Hinzufügen von Aurora-Replicas zu einem DB-Cluster](aurora-replicas-adding.md).
# Optimieren einer binären Protokollreplikation für Aurora MySQL
Im Folgenden erfahren Sie, wie Sie die Leistung der binären Protokollreplikation optimieren und damit zusammenhängende Probleme in Aurora MySQL beheben können.
**Tipp**
In dieser Erörterung wird davon ausgegangen, dass Sie mit dem Mechanismus der binären MySQL-Protokollreplikation und dessen Funktionsweise vertraut sind. Hintergrundinformationen finden Sie unter [Replication Implementation (Implementierung der Replikation)](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation.html) in der MySQL-Dokumentation.
## Multithread-Replikation für binäre Protokolle
Bei der Multithread-Replikation für binäre Protokolle liest ein SQL-Thread Ereignisse aus dem Relay-Log und stellt sie in die Warteschlange, damit SQL-Worker-Threads angewendet werden können. Die SQL-Worker-Threads werden vom Koordinator-Thread verwaltet. Die binären Protokollereignisse werden nach Möglichkeit parallel angewendet. Der Grad der Parallelität hängt von Faktoren wie Version, Parametern, Schemadesign und Workload-Eigenschaften ab.
Die Multithread-Replikation für binäre Protokolle wird in Aurora-MySQL-Version 3 und Aurora-MySQL-Version 2.12.1 und höher unterstützt. Damit ein Multithread-Replikat Binlog-Ereignisse effizient parallel verarbeiten kann, müssen Sie die Quelle für die Multithread-Replikation für binäre Protokolle konfigurieren, und die Quelle muss eine Version verwenden, die die Parallelitätsinformationen in ihren Binärprotokolldateien enthält.
Wenn eine DB-Instance von Aurora MySQL für die Verwendung der binären Protokollreplikation konfiguriert ist, verwendet die Replikat-Instance standardmäßig die Single-Thread-Replikation für Aurora-MySQL-Versionen niedriger als 3.04. Zum Aktivieren der Multithread-Replikation aktualisieren Sie den Parameter `replica_parallel_workers` in Ihrer benutzerdefinierten Parametergruppe auf einen Wert größer als `1`.
Für Aurora-MySQL-Version 3.04 und höher erfolgt die Replikation standardmäßig mit mehreren Threads, wobei `replica_parallel_workers` auf `4` gesetzt ist. Sie können diesen Parameter in Ihrer benutzerdefinierten Parametergruppe ändern.
Um die Widerstandsfähigkeit Ihrer Datenbank gegen unerwartete Unterbrechungen zu erhöhen, empfehlen wir, die GTID-Replikation auf der Quelle zu aktivieren und auf dem GTIDs Replikat zuzulassen. Zum Zulassen der GTID-Replikation setzen Sie `gtid_mode` sowohl in der Quelle als auch im Replikat auf `ON_PERMISSIVE`. Weitere Informationen zu GTID-basierten Replikationen finden Sie unter [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md).
Die folgenden Konfigurationsoptionen helfen Ihnen bei der Optimierung der Multithread-Replikation. Informationen zur Verwendung finden Sie unter [Replikations- und binäre Protokollierungsoptionen und -Variablen](https://dev.mysql.com/doc/refman/8.0/en/replication-options.html) im *MySQL-Verweishandbuch*. Weitere Informationen zur Multithread-Replikation finden Sie im MySQL-Blog [https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/](https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/).
Optimale Parameterwerte hängen von mehreren Faktoren ab. Beispielsweise wird die Leistung für die Binärprotokollreplikation von Ihren Datenbank-Workload-Merkmalen und der DB-Instance-Klasse beeinflusst, auf der das Replikat ausgeführt wird. Daher empfehlen wir Ihnen, alle Änderungen an diesen Konfigurationsparametern gründlich zu testen, bevor Sie neue Parametereinstellungen auf eine Produktions-Instance anwenden:
+ `binlog_format recommended value` – festlegen auf `ROW`
+ `binlog_group_commit_sync_delay`
+ `binlog_group_commit_sync_no_delay_count`
+ `binlog_transaction_dependency_history_size`
+ `binlog_transaction_dependency_tracking` – empfohlener Wert ist `WRITESET`
+ `replica_preserve_commit_order`
+ `replica_parallel_type` – empfohlener Wert ist `LOGICAL_CLOCK`
+ `replica_parallel_workers`
+ `replica_pending_jobs_size_max`
+ `transaction_write_set_extraction` – empfohlener Wert ist `XXHASH64`
Ihr Schema und Ihre Workload-Eigenschaften sind Faktoren, die sich parallel auf die Replikation auswirken. Zu den häufigsten Faktoren zählen folgende:
+ Fehlen von Primärschlüsseln – RDS kann keine Schreibsatzabhängigkeit für Tabellen ohne Primärschlüssel einrichten. Mit dem `ROW`-Format kann eine einzelne mehrzeilige Anweisung mit einem einzigen vollständigen Tabellenscan in der Quelle ausgeführt werden. Dies führt jedoch zu einem vollständigen Tabellenscan pro Zeile, die im Replikat geändert wurde. Das Fehlen von Primärschlüsseln verringert den Replikationsdurchsatz erheblich.
+ Vorhandensein von Fremdschlüsseln – Wenn Fremdschlüssel vorhanden sind, kann Amazon RDS die Schreibsatzabhängigkeit nicht für die Parallelität der Tabellen mit der FK-Beziehung verwenden.
+ Größe der Transaktionen – Wenn sich eine einzelne Transaktion über Dutzende oder Hunderte von Megabyte oder Gigabyte erstreckt, verbringen der Koordinator-Thread und einer der Worker-Threads möglicherweise viel Zeit damit, nur diese Transaktion zu verarbeiten. Während dieser Zeit können alle anderen Worker-Threads inaktiv bleiben, nachdem sie die Verarbeitung ihrer vorherigen Transaktionen abgeschlossen haben.
In Aurora-MySQL-Version 3.06 und höher können Sie die Leistung für binäre Protokollreplikate verbessern, wenn Sie Transaktionen für große Tabellen mit mehr als einem sekundären Index replizieren. Diese Funktion führt einen Thread-Pool ein, um sekundäre Indexänderungen parallel auf ein Binlog-Replikat anzuwenden. Die Funktion wird durch den DB-Cluster-Parameter `aurora_binlog_replication_sec_index_parallel_workers` gesteuert, der die Gesamtzahl der parallelen Threads steuert, die für die Anwendung der sekundären Indexänderungen verfügbar sind. Der Parameter ist standardmäßig auf `0` (deaktiviert) eingestellt. Für die Aktivierung dieser Funktion ist kein Instance-Neustart erforderlich. Zum Aktivieren dieser Funktion beenden Sie die laufende Replikation, legen die gewünschte Anzahl paralleler Worker-Threads fest und starten die Replikation dann erneut.
## Optimieren einer Binlog-Replikation
In Aurora MySQL 2.10 und höher wendet Aurora automatisch eine Optimierung an, die als I/O Binlog-Cache bezeichnet wird, auf die binäre Protokollreplikation. Durch Zwischenspeichern der zuletzt festgeschriebenen Binlog-Ereignisse soll diese Optimierung die Leistung des Binlog-Dump-Threads verbessern und gleichzeitig die Auswirkungen auf Vordergrundtransaktionen auf der Binlog-Quell-Instance begrenzen.
**Anmerkung**
Dieser für diese Funktion verwendete Speicher ist unabhängig von der `binlog_cache` MySQL-Einstellung.
Diese Funktion gilt nicht für Aurora DB-Instances, die die `db.t2`- und `db.t3`-Instance-Klassen verwenden.
Sie müssen keine Konfigurationsparameter anpassen, um diese Optimierung zu aktivieren. Insbesondere wenn Sie den Konfigurationsparameter `aurora_binlog_replication_max_yield_seconds` in früheren Aurora-MySQL-Versionen auf einen Wert ungleich null eingestellt hatten, setzen Sie ihn für derzeit verfügbare Versionen auf null zurück.
`aurora_binlog_io_cache_read_requests`Mithilfe der Statusvariablen `aurora_binlog_io_cache_reads` können Sie überwachen, wie oft die Daten aus dem I/O Binlog-Cache gelesen werden.
+ `aurora_binlog_io_cache_read_requests`zeigt die Anzahl der I/O Binlog-Leseanfragen aus dem Cache an.
+ `aurora_binlog_io_cache_reads`zeigt die Anzahl der I/O Binlog-Lesevorgänge an, mit denen Informationen aus dem Cache abgerufen werden.
Die folgende SQL-Abfrage berechnet den Prozentsatz der Binlog-Leseanforderungen, die die zwischengespeicherten Informationen nutzen. In diesem Fall ist es umso besser, je näher das Verhältnis an 100 liegt.
```
mysql> SELECT
(SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads')
/ (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests')
* 100
as binlog_io_cache_hit_ratio;
+---------------------------+
| binlog_io_cache_hit_ratio |
+---------------------------+
| 99.99847949080622 |
+---------------------------+
```
Die I/O Binlog-Cache-Funktion enthält auch neue Metriken, die sich auf die Binlog-Dump-Threads beziehen. *Dump-Threads* sind die Threads, die erstellt werden, wenn neue Binlog-Replikate mit der Binlog-Quell-Instance verbunden sind.
Die Metriken des Dump-Threads werden alle 60 Sekunden mit dem Präfix in das Datenbankprotokoll gedruck `[Dump thread metrics]`. Die Metriken umfassen Informationen für jedes Binlog-Replikat wie `Secondary_id`, `Secondary_uuid`, den Namen der Binlog-Datei und die Position, die jedes Replikat liest. Zu den Metriken gehört auch `Bytes_behind_primary`, das den Abstand in Byte zwischen Replikationsquelle und Replikat darstellt. Diese Metrik misst die Verzögerung des Replikat-Threads. I/O Diese Zahl unterscheidet sich von der Verzögerung des Replikat-SQL-Applier-Threads, der durch die `seconds_behind_master` Metrik auf dem Binlog-Replikat dargestellt wird. Sie können feststellen, ob Binlog-Replikate die Quelle aufholen oder zurückfallen, indem Sie überprüfen, ob die Entfernung abnimmt oder zunimmt.
## In-Memory-Relay-Protokoll
In Aurora-MySQL-Version 3.10 und höher führt Aurora eine Optimierung ein, die als In-Memory-Relay-Protokoll bekannt ist, um den Replikationsdurchsatz zu verbessern. Diese Optimierung verbessert die I/O Leistung des Relay-Logs, indem der gesamte Inhalt des Relay-Logs zwischen den Relay-Protokollen im Speicher zwischengespeichert wird. Dadurch wird die Commit-Latenz reduziert, indem I/O Speichervorgänge minimiert werden, da der Inhalt des Relay-Protokolls im Speicher weiterhin leicht zugänglich ist.
Standardmäßig ist die In-Memory-Relay-Protokollfunktion automatisch für von Aurora verwaltete Replikationsszenarien (einschließlich Blau/Grün-Bereitstellungen, Aurora-Aurora-Replikationen und regionsübergreifende Replikate) aktiviert, wenn das Replikat eine der folgenden Konfigurationen erfüllt:
+ Singlethread-Replikationsmodus (replica\$1parallel\$1workers = 0)
+ Multithread-Replikation mit aktiviertem GTID-Modus:
+ Automatische Positionierung aktiviert
+ GTID-Modus im Replikat auf ON gesetzt
+ Dateibasierte Replikation mit replica\$1preserve\$1commit\$1order = ON
Die In-Memory-Relay-Protokollfunktion wird für Instance-Klassen unterstützt, die größer als t3.large sind, ist aber für Aurora Serverless-Instances nicht verfügbar. Der zirkuläre Puffer des Relay-Protokolls hat eine feste Größe von 128 MB. Zum Überwachen des Speicherverbrauchs dieser Funktion können Sie die folgende Abfrage ausführen:
```
SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name = 'memory/sql/relaylog_io_cache';
```
Die In-Memory-Relay-Protokollfunktion wird durch den Parameter aurora\$1in\$1memory\$1relaylog gesteuert, der entweder auf DB-Cluster- oder Instance-Ebene festgelegt werden kann. Sie können diese Funktion dynamisch aktivieren oder deaktivieren, ohne Ihre Instance neu starten zu müssen:
1. Stoppen Sie die laufende Replikation.
1. Setzen Sie aurora\$1in\$1memory\$1relaylog in der Parametergruppe auf ON (zum Aktivieren) oder OFF (zum Deaktivieren).
1. Starten Sie die Replikation neu.
Beispiel:
```
CALL mysql.rds_stop_replication;
set aurora_in_memory_relaylog to ON to enable or OFF to disable in cluster parameter group
CALL mysql.rds_start_replication;
```
Selbst wenn aurora\$1in\$1memory\$1relaylog auf ON gesetzt ist, kann die In-Memory-Relay-Protokollfunktion unter bestimmten Bedingungen immer noch deaktiviert sein. Verwenden Sie den folgenden Befehl, um den aktuellen Status der Funktion zu überprüfen:
```
SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_status';
```
Wenn die Funktion unerwartet deaktiviert wird, können Sie den Grund ermitteln, indem Sie Folgendes ausführen:
```
SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_disabled_reason';
```
Dieser Befehl gibt eine Meldung zurück, in der erklärt wird, warum die Funktion derzeit deaktiviert ist.
# Einrichten eines erweiterten Binärprotokolls für Aurora MySQL
Das erweiterte Binärprotokoll reduziert den durch die Aktivierung des Binärprotokolls verursachten Rechenleistungs-Overhead, der in bestimmten Fällen bis zu 50 % betragen kann. Mit einem erweiterten Binärprotokoll kann dieser Overhead auf etwa 13 % reduziert werden. Damit der Overhead reduziert wird, schreibt das erweiterte Binärprotokoll die Binär- und Transaktionsprotokolle parallel in den Speicher, wodurch die zum Zeitpunkt des Transaktions-Commits geschriebenen Daten minimiert werden.
Die Verwendung des erweiterten Binärprotokolls verbessert außerdem die Datenbankwiederherstellungszeit nach Neustarts und Failovers um bis zu 99 % im Vergleich zum Community-MySQL-Binärprotokoll. Das erweiterte Binärprotokoll ist mit bestehenden binlogbasierten Workloads kompatibel und Sie interagieren damit genauso wie mit dem Community-MySQL-Binärprotokoll.
Das erweiterte Binärprotokoll ist in Aurora-MySQL-Version 3.03.1 und höher verfügbar.
**Topics**
+ [Konfiguration erweiterter Binärprotokollparameter](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters)
+ [Sonstige zugehörige Parameter](#AuroraMySQL.Enhanced.binlog.other.parameters)
+ [Unterschiede zwischen erweitertem Binärprotokoll und Community-MySQL-Binärprotokoll](#AuroraMySQL.Enhanced.binlog.differences)
+ [Amazon-CloudWatch-Metriken für das erweiterte Binärprotokoll](#AuroraMySQL.Enhanced.binlog.cloudwatch.metrics)
+ [Beschränkungen für das erweiterte Binärprotokoll](#AuroraMySQL.Enhanced.binlog.limitations)
## Konfiguration erweiterter Binärprotokollparameter
Sie können zwischen Community-MySQL-Binärprotokoll und erweitertem Binärprotokoll wechseln, indem Sie die Parameter für das erweiterte Binärprotokoll aktivieren/deaktivieren. Die bestehenden Binärprotokollbenutzer können die Binärprotokolldateien weiterhin lesen und verarbeiten, ohne dass es zu Lücken in der Binärprotokolldateifolge kommt.
Stellen Sie die folgenden Parameter ein, um das erweiterte Binärprotokoll zu aktivieren:
| Parameter | Standard | Beschreibung |
| --- | --- | --- |
| binlog\$1format | – | Legen Sie den Parameter binlog\$1format auf das binäre Protokollierungsformat Ihrer Wahl fest, um das erweiterte Binärprotokoll zu aktivieren. Stellen Sie sicher, dass der binlog\$1format parameter nicht auf AUS eingestellt ist. Weitere Informationen finden Sie unter [Konfiguration der binären Protokollierung mit Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.MySQL.BinaryFormat.html). |
| aurora\$1enhanced\$1binlog | 0 | Legen Sie den Wert dieses Parameters in der Parametergruppe des DB-Clusters, die mit dem Aurora-MySQL-Cluster verknüpft ist, auf 1 fest. Wenn Sie den Wert dieses Parameters ändern, müssen Sie die Writer-Instance neu starten, wenn für den Wert DBClusterParameterGroupStatus pending-reboot angezeigt wird. |
| binlog\$1backup | 1 | Deaktivieren Sie diesen Parameter, um das erweiterte Binärprotokoll zu aktivieren. Legen Sie dazu den Wert dieses Parameters auf 0 fest. |
| binlog\$1replication\$1globaldb | 1 | Deaktivieren Sie diesen Parameter, um das erweiterte Binärprotokoll zu aktivieren. Legen Sie dazu den Wert dieses Parameters auf 0 fest. |
**Wichtig**
Sie können die Parameter `binlog_backup` und `binlog_replication_globaldb` nur deaktivieren, wenn Sie das erweiterte Binärprotokoll verwenden.
Stellen Sie die folgenden Parameter ein, um das erweiterte Binärprotokoll zu deaktivieren:
| Parameter | Beschreibung |
| --- | --- |
| aurora\$1enhanced\$1binlog | Legen Sie den Wert dieses Parameters in der Parametergruppe des DB-Clusters, die mit dem Aurora-MySQL-Cluster verknüpft ist, auf 0 fest. Sobald Sie den Wert dieses Parameters ändern, müssen Sie die Writer-Instance neu starten, wenn für den Wert DBClusterParameterGroupStatus pending-reboot angezeigt wird. |
| binlog\$1backup | Aktivieren Sie diesen Parameter, wenn Sie das erweiterte Binärprotokoll deaktivieren. Legen Sie dazu den Wert dieses Parameters auf 1 fest. |
| binlog\$1replication\$1globaldb | Aktivieren Sie diesen Parameter, wenn Sie das erweiterte Binärprotokoll deaktivieren. Legen Sie dazu den Wert dieses Parameters auf 1 fest. |
Um zu überprüfen, ob das erweiterte Binärprotokoll aktiviert ist, verwenden Sie den folgenden Befehl im MySQL-Client:
```
mysql>show status like 'aurora_enhanced_binlog';
+------------------------+--------+
| Variable_name | Value |
+------------------------+--------+
| aurora_enhanced_binlog | ACTIVE |
+------------------------+--------+
1 row in set (0.00 sec)
```
Wenn das erweiterte Binärprotokoll aktiviert ist, wird in der Ausgabe `ACTIVE` für `aurora_enhanced_binlog` angezeigt.
## Sonstige zugehörige Parameter
Wenn Sie das erweiterte Binärprotokoll aktivieren, sind folgende Parameter betroffen:
+ Der Parameter `max_binlog_size` ist sichtbar, kann aber nicht geändert werden. Sein Standardwert `134217728` wird automatisch in `268435456` geändert, wenn das erweiterte Binärprotokoll aktiviert ist.
+ Im Gegensatz zum Community-MySQL-Binärprotokoll fungiert `binlog_checksum` nicht als dynamischer Parameter, wenn das erweiterte Binärprotokoll aktiviert ist. Damit die Änderung an diesem Parameter wirksam wird, müssen Sie den DB-Cluster manuell neu starten, auch wenn für `ApplyMethod` `immediate` festgelegt ist.
+ Der Wert, den Sie für den Parameter `binlog_order_commits` festlegen, hat keinen Einfluss auf die Reihenfolge der Commits, wenn das erweiterte Binärprotokoll aktiviert ist. Die Commits werden immer ohne weitere Auswirkungen auf die Leistung angeordnet.
## Unterschiede zwischen erweitertem Binärprotokoll und Community-MySQL-Binärprotokoll
Das erweiterte Binärprotokoll interagiert anders mit Klonen, Backups und der globalen Aurora-Datenbank als das Community-MySQL-Binärprotokoll. Bevor Sie das erweiterte Binärprotokoll verwenden, sollten Sie sich mit den folgenden Unterschieden vertraut machen.
+ Erweiterte Binärprotokolldateien aus dem Quell-DB-Cluster sind in einem geklonten DB-Cluster nicht verfügbar.
+ Erweiterte Binärprotokolldateien sind in Aurora-Backups nicht enthalten. Daher sind erweiterte Binärprotokolldateien aus dem Quell-DB-Cluster nach der Wiederherstellung eines DB-Clusters trotz einer für ihn festgelegten Aufbewahrungsfrist nicht verfügbar.
+ Bei Verwendung mit einer globalen Aurora-Datenbank werden die erweiterten Binärprotokolldateien des primären DB-Clusters nicht auf den DB-Cluster in den sekundären Regionen repliziert.
****Beispiele****
Die folgenden Beispiele veranschaulichen die Unterschiede zwischen dem erweiterten Binärprotokoll und dem Community-MySQL-Binärprotokoll.
**Auf einem wiederhergestellten oder geklonten DB-Cluster**
Wenn das erweiterte Binärprotokoll aktiviert ist, sind die historischen Binärprotokolldateien im wiederhergestellten oder geklonten DB-Cluster nicht verfügbar. Wenn das Binärprotokoll aktiviert ist, beginnt der neue DB-Cluster nach einem Wiederherstellungs- oder Klonvorgang, seine eigene Reihenfolge von Binärprotokolldateien zu schreiben, beginnend mit 1 (mysql-bin-changelog 000001).
Um das erweiterte Binärprotokoll nach einem Wiederherstellungs- oder Klonvorgang zu aktivieren, legen Sie die erforderlichen DB-Cluster-Parameter auf dem wiederhergestellten oder geklonten DB-Cluster fest. Weitere Informationen finden Sie unter [Konfiguration erweiterter Binärprotokollparameter](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters).
**Example Beispiel: Ausführung des Klon- oder Wiederherstellungsvorgangs, wenn das erweiterte Binärprotokoll aktiviert ist**
Quell-DB-Cluster:
```
mysql> show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No |
| mysql-bin-changelog.000003 | 156 | No |
| mysql-bin-changelog.000004 | 156 | No | --> Enhanced Binlog turned on
| mysql-bin-changelog.000005 | 156 | No | --> Enhanced Binlog turned on
| mysql-bin-changelog.000006 | 156 | No | --> Enhanced Binlog turned on
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
In einem wiederhergestellten oder geklonten DB-Cluster werden Binärprotokolldateien nicht gesichert, wenn das erweiterte Binärprotokoll aktiviert ist. Um Unterbrechungen in den Binärprotokolldaten zu vermeiden, sind die Binärprotokolldateien, die vor dem Aktivieren des erweiterten Binärprotokolls geschrieben wurden, ebenfalls nicht verfügbar.
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No | --> New sequence of Binlog files
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)
```
**Example Beispiel: Ausführung des Klon- oder Wiederherstellungsvorgangs, wenn das erweiterte Binärprotokoll deaktiviert ist**
DB-Quellcluster:
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
Das erweiterte Binärprotokoll wird nach `mysql-bin-changelog.000003` deaktiviert. In einem wiederhergestellten oder geklonten DB-Cluster sind Binärprotokolldateien verfügbar, die nach dem Deaktivieren des erweiterten Binärprotokoll geschrieben wurden.
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)
```
**In einer Amazon Aurora Global Database**
In einer Amazon Aurora Global Database werden die Binärprotokolldaten des primären DB-Clusters nicht auf den sekundären DB-Cluster repliziert. Nach einem regionsübergreifenden Failover-Prozess sind die Binärprotokolldaten im neu hochgestuften primären DB-Cluster nicht verfügbar. Wenn das Binärprotokoll aktiviert ist, beginnt der neu hochgestufte DB-Cluster mit seiner eigenen Reihenfolge von Binärprotokolldateien, beginnend mit 1 (mysql-bin-changelog 000001).
Um das erweiterte Binärprotokoll nach einem Failover zu aktivieren, müssen Sie die erforderlichen DB-Cluster-Parameter auf dem sekundären DB-Cluster festlegen. Weitere Informationen finden Sie unter [Konfiguration erweiterter Binärprotokollparameter](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters).
**Example Beispiel: Ausführen eines globalen Datenbank-Failovers, wenn das erweiterte Binärprotokoll aktiviert ist**
Alter primärer DB-Cluster (vor dem Failover):
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No |
| mysql-bin-changelog.000003 | 156 | No |
| mysql-bin-changelog.000004 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000005 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000006 | 156 | No | --> Enhanced Binlog enabled
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
Neuer primärer DB-Cluster (nach dem Failover):
Binärprotokolldateien werden nicht in sekundäre Regionen repliziert, wenn das erweiterte Binärprotokoll aktiviert ist. Um Unterbrechungen in den Binärprotokolldaten zu vermeiden, sind die Binärprotokolldateien, die vor dem Aktivieren des erweiterten Binärprotokolls geschrieben wurden, nicht verfügbar.
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No | --> Fresh sequence of Binlog files
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)
```
**Example Beispiel: Ausführen eines globalen Datenbank-Failovers, wenn das erweiterte Binärprotokoll deaktiviert ist**
Quell-DB-Cluster:
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
**Wiederhergestellter oder geklonter DB-Cluster:**
Das erweiterte Binärprotokoll wird nach `mysql-bin-changelog.000003` deaktiviert. Binärprotokolldateien, die nach dem Deaktivieren des erweiterten Binärprotokolls geschrieben wurden, werden repliziert und sind im neu hochgestuften DB-Cluster verfügbar.
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
3 rows in set (0.00 sec)
```
## Amazon-CloudWatch-Metriken für das erweiterte Binärprotokoll
Die folgenden Amazon-CloudWatch-Metriken werden nur veröffentlicht, wenn das erweiterte Binärprotokoll aktiviert ist.
| CloudWatch-Metrik | Beschreibung | Einheiten |
| --- | --- | --- |
| ChangeLogBytesUsed | Die Menge des vom Speicherplatzes, der vom erweiterten Binärprotokoll belegt wird. | Bytes |
| ChangeLogReadIOPs | Die Anzahl von Lese-I/O-Operationen, die im erweiterten Binärprotokoll in einem fünfminütigen Intervalls durchgeführt wurden. | Anzahl pro 5 Minuten |
| ChangeLogWriteIOPs | Die Anzahl von Schreib-I/O-Operationen, die im erweiterten Binärprotokoll in einem fünfminütigen Intervalls durchgeführt wurden. | Anzahl pro 5 Minuten |
## Beschränkungen für das erweiterte Binärprotokoll
Die folgenden Einschränkungen gelten für DB-Cluster von Amazon Aurora, wenn das erweiterte Binärprotokoll aktiviert ist.
+ Das erweiterte Binärprotokoll wird nur in Aurora-MySQL-Version 3.03.1 und höher unterstützt.
+ Die auf dem primären DB-Cluster geschriebenen erweiterten Binärprotokolldateien werden nicht in die geklonten oder wiederhergestellten DB-Cluster kopiert.
+ Bei Verwendung mit Amazon Aurora Global Database werden die erweiterten Binärprotokolldateien des primären DB-Clusters nicht auf sekundäre DB-Cluster repliziert. Daher sind die historischen Binärprotokolldaten nach dem Failover-Prozess im neuen primären DB-Cluster nicht verfügbar.
+ Die folgenden Binärprotokoll-Konfigurationsparameter werden ignoriert:
+ `binlog_group_commit_sync_delay`
+ `binlog_group_commit_sync_no_delay_count`
+ `binlog_max_flush_queue_time`
+ Sie können eine beschädigte Tabelle in einer Datenbank nicht löschen oder umbenennen. Um diese Tabellen zu löschen, können Sie sich an Support wenden.
+ Der Binärprotokoll-I/O-Cache ist deaktiviert, wenn das erweiterte Binärprotokoll aktiviert ist. Weitere Informationen finden Sie unter [Optimieren einer binären Protokollreplikation für Aurora MySQL](binlog-optimization.md).
**Anmerkung**
Das erweiterte Binärprotokoll bietet ähnliche Verbesserungen der Leseleistung wie der Binärprotokoll-I/O-Cache und deutliche Verbesserungen der Schreibleistung.
+ Die Rückverfolgungsfunktion wird nicht unterstützt. Das erweiterte Binärprotokoll kann in einem DB-Cluster unter den folgenden Bedingungen nicht aktiviert werden:
+ Für den DB-Cluster ist derzeit die Rückverfolgungsfunktion aktiviert.
+ Für den DB-Cluster wurde die zuvor aktivierte Rückverfolgungsfunktion inzwischen deaktiviert.
+ Der DB-Cluster wurde aus einem Quell-DB-Cluster oder einem Snapshot mit aktivierter Rückverfolgungsfunktion wiederhergestellt.