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.
# Arbeiten mit MySQL-Replikation in Amazon RDS
Sie verwenden Lesereplikate üblicherweise, um die Replikation zwischen Amazon-RDS-DB-Instances zu konfigurieren. Allgemeine Informationen zu Lesereplikaten finden Sie unter [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md). Spezifische Informationen zum Arbeiten mit Lesereplikaten unter Amazon RDS für MySQL finden Sie unter [Arbeiten mit MySQL-Lesereplikaten](USER_MySQL.Replication.ReadReplicas.md).
Sie können globale Transaktions-Identifikatoren (GTIDs) für die Replikation mit RDS for MySQL verwenden. Weitere Informationen finden Sie unter [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md).
Sie können auch eine Replikation zwischen einer RDS für MySQL-DB-Instance und einer MariaDB- oder MySQL-Instance, die außerhalb von Amazon RDS ausgeführt wird, einrichten. Informationen zum Konfigurieren der Replikation mit einer externen Quelle finden Sie unter [Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance](MySQL.Procedural.Importing.External.Repl.md).
Für jede dieser Replikationsoptionen können Sie die Replikation vom Typ „row-based“, „statement-based“ oder „mixed“ verwenden. Die Replikation vom Typ „row-based“ repliziert nur die geänderten Zeilen, die sich aus einer SQL-Anweisung ergeben. Die Replikation vom Typ „statement-based“ repliziert die gesamte SQL-Anweisung. Die Replikation vom Typ „mixed“ verwendet nach Möglichkeit Replikation vom Typ „statement-based“, wechselt aber auf Replikation vom Typ „row-based“, wenn SQL-Anweisungen ausgeführt werden, die bei der Replikation vom Typ „statement-based“ nicht sicher sind. In den meisten Fällen wird eine Replikation vom Typ „mixed“ empfohlen. Das binäre Protokollformat der DB-Instance bestimmt, ob die Replikation vom Typ „row-based“, „statement-based“ oder „mixed“ ist. Weitere Informationen zum Einrichten des binären Protokollformats finden Sie unter [Konfiguration von RDS für MySQL-Binärprotokollierung für Single-AZ-Datenbanken](USER_LogAccess.MySQL.BinaryFormat.md).
**Anmerkung**
Sie können die Replikation zum Importieren von Datenbanken aus einer MariaDB- oder MySQL-Instance, die außerhalb von Amazon RDS ausgeführt wird, oder zum Exportieren von Datenbanken in solche Instances konfigurieren. Weitere Informationen erhalten Sie unter [Importieren von Daten in eine Datenbank von Amazon RDS für MySQL mit reduzierter Ausfallzeit](mysql-importing-data-reduced-downtime.md) und [Exportieren von Daten aus einer MySQL DB-Instance mithilfe der Replikation](MySQL.Procedural.Exporting.NonRDSRepl.md).
Nachdem Sie Ihre DB-Instance aus einem Snapshot wiederhergestellt oder eine point-in-time Wiederherstellung durchgeführt haben, können Sie die zuletzt wiederhergestellte Binlog-Position aus der Quelldatenbank in der RDS-Konsole anzeigen. Geben Sie unter **Protokolle und Ereignisse** **binlog** ein. Die Binlog-Position wird unter **Systemhinweise** angezeigt.
**Topics**
+ [
# Arbeiten mit MySQL-Lesereplikaten
](USER_MySQL.Replication.ReadReplicas.md)
+ [
# Verwenden der GTID-basierten Replikation
](mysql-replication-gtid.md)
+ [
# Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance
](MySQL.Procedural.Importing.External.Repl.md)
+ [
# Konfiguration multi-source-replication für Amazon RDS for MySQL
](mysql-multi-source-replication.md)
# Arbeiten mit MySQL-Lesereplikaten
Im Folgenden finden Sie spezifische Informationen zum Arbeiten mit Lesereplikaten unter RDS für MySQL. Allgemeine Informationen zu Lesereplikaten und Anleitungen zu ihrer Verwendung finden Sie in [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md).
Weitere Informationen zu MySQL-Lesereplikaten finden Sie in den folgenden Themen.
+ [Konfigurieren von Replikationsfiltern mit MySQL](USER_MySQL.Replication.ReadReplicas.ReplicationFilters.md)
+ [Konfigurieren der verzögerten Replikation mit MySQL](USER_MySQL.Replication.ReadReplicas.DelayReplication.md)
+ [Aktualisieren von Lesereplikaten mit MySQL](USER_MySQL.Replication.ReadReplicas.Updates.md)
+ [Arbeiten mit Bereitstellungen von Multi-AZ-Lesereplikaten mit MySQL](USER_MySQL.Replication.ReadReplicas.MultiAZ.md)
+ [Verwendung von kaskadierenden Lesereplikaten mit RDS für MySQL](USER_MySQL.Replication.ReadReplicas.Cascading.md)
+ [Überwachen der Replikationsverzögerung für MySQL-Lesereplikate](USER_MySQL.Replication.ReadReplicas.Monitor.md)
+ [Starten und Stoppen der Replikation mit MySQL Read Replicas](USER_MySQL.Replication.ReadReplicas.StartStop.md)
+ [Fehlerbehebung für ein Problem mit einer MySQL Read Replica](USER_ReadRepl.Troubleshooting.md)
## Konfigurieren von Lesereplikaten mit MySQL
Bevor eine MySQL-DB-Instance als Replikationsquelle dienen kann, stellen Sie sicher, dass automatische Sicherungen für die Quell-DB-Instance aktiviert werden. Hierzu legen Sie für den Aufbewahrungszeitraum für Sicherungen einen anderen Wert als 0 fest. Diese Erfordernis gilt auch für ein Lesereplikat, das die Quell-DB-Instance für ein anderes Lesereplikat ist. Automatische Sicherungen werden nur für Lesereplikate unterstützt, die mit einer beliebigen MySQL-Version ausgeführt werden. Sie können die Replikation basierend auf den Binärprotokollkoordinaten für eine MySQL-DB-Instance konfigurieren.
Sie können die Replikation mithilfe von globalen Transaktionskennungen (GTIDs) in den folgenden Versionen konfigurieren:
+ RDS für MySQL Version 5.7.44 und höhere 5.7-Versionen
+ RDS für MySQL Version 8.0.28 und höhere 8.0-Versionen
+ RDS für MySQL Version 8.4.3 und höhere 8.4-Versionen
Weitere Informationen finden Sie unter [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md).
Sie können bis zu 15 Lesereplikate von einer DB-Instance innerhalb derselben Region erstellen. Damit die Replikation effektiv durchgeführt werden kann, sollte jedes Lesereplikat über die selbe Menge an Rechen- und Speicherressourcen wie die Quell-DB-Instance verfügen. Wenn Sie die Quell-DB-Instance skalieren, skalieren Sie auch die Lesereplikate.
RDS für MySQL unterstützt kaskadierende Lesereplikate. Informationen zum Konfigurieren von kaskadierenden Lesereplikaten finden Sie unter [Verwendung von kaskadierenden Lesereplikaten mit RDS für MySQL](USER_MySQL.Replication.ReadReplicas.Cascading.md).
Sie können mehrere Erstellungs- und Löschaktionen für Lesereplikate gleichzeitig ausführen, die auf die gleiche Quell-DB-Instance verweisen. Halten Sie sich bei der Ausführung dieser Aktionen an die Grenze von 15 Lesereplikaten für jede Quell-Instance.
Eine Lesereplikat einer MySQL-DB-Instance kann keine niedrigere DB-Engine-Version als die Quell-DB-Instance verwenden.
### Vorbereiten von MySQL-DB-Instances, die MyISAM verwenden
Wenn Ihre MySQL-DB-Instance eine nicht-transaktionale Engine, wie MyISAM, verwendet, müssen Sie die folgenden Schritte erfolgreich ausführen, um Ihr Lesereplikat einzurichten. Diese Schritte sind unbedingt notwendig, damit das Lesereplikat eine konsistente Kopie Ihrer Daten enthält. Diese Schritte sind nicht erforderlich, wenn alle Ihre Tabellen eine transaktionale Engine wie InnoDB nutzen.
1. Halten Sie alle Data Manipulation Language (DML)- und Data Definition Language (DDL)-Operationen in nicht-transaktionalen Tabellen in der Quell-DB-Instance an und warten Sie bis diese abgeschlossen sind. SELECT-Anweisungen können weiter ausgeführt werden.
1. Bereinigen und sperren Sie die Tabellen in der Quell-DB-Instance.
1. Erstellen Sie das Lesereplikat mithilfe der Methoden in den folgenden Abschnitten.
1. Überprüfen Sie den Vorgang der Lesereplikat-Erstellung mithilfe von beispielsweise der API-Operation `DescribeDBInstances`. Sobald das Lesereplikat verfügbar ist, entsperren Sie die Tabellen in der Quell-DB-Instance und fahren Sie mit den normalen Datenbank-Operationen fort.
# Konfigurieren von Replikationsfiltern mit MySQL
Sie können Replikationsfilter verwenden, um anzugeben, welche Datenbanken und Tabellen mit einem Lesereplikat repliziert werden. Replikationsfilter können Datenbanken und Tabellen in die Replikation einbeziehen oder sie von der Replikation ausschließen.
Im Folgenden finden Sie einige Anwendungsfälle für Replikationsfilter:
+ Reduzieren der Größe eines Lesereplikats. Mit Replikationsfiltern können Sie die Datenbanken und Tabellen ausschließen, die für das Lesereplikat nicht benötigt werden.
+ Ausschließen von Datenbanken und Tabellen von Lesereplikaten aus Sicherheitsgründen.
+ Replizieren verschiedener Datenbanken und Tabellen für spezifische Anwendungsfälle bei verschiedenen Lesereplikaten. Beispielsweise könnten Sie bestimmte Lesereplikate für Analysen oder Sharding verwenden.
+ Für eine DB-Instance, die Read Replicas in verschiedenen hat AWS-Regionen, um verschiedene Datenbanken oder Tabellen in verschiedenen zu replizieren. AWS-Regionen
**Anmerkung**
Sie können Replikationsfilter auch verwenden, um anzugeben, welche Datenbanken und Tabellen mit einer primären MySQL -DB-Instance repliziert werden, die als Replikat in einer eingehenden Replikationstopologie konfiguriert ist. Weitere Informationen zu dieser Konfiguration finden Sie unter [Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance](MySQL.Procedural.Importing.External.Repl.md).
**Topics**
+ [
## Einrichten der Parameter der Replikationsfilter bei RDS für MySQL
](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Configuring)
+ [
## Einschränkungen der Replikationsfilter bei RDS für MySQL
](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Limitations)
+ [
## Beispiele für Replikationsfilter bei RDS für MySQL
](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Examples)
+ [
## Anzeigen der Replikationsfilter für ein Lesereplikat
](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Viewing)
## Einrichten der Parameter der Replikationsfilter bei RDS für MySQL
Um Replikationsfilter zu konfigurieren, legen Sie die folgenden Filterparameter für die Replikation fest:
+ `replicate-do-db` – Repliziert Änderungen der angegebenen Datenbanken. Wenn Sie diesen Parameter für ein Lesereplikat festlegen, werden nur die im Parameter angegebenen Datenbanken repliziert.
+ `replicate-ignore-db` – Repliziert keine Änderungen der angegebenen Datenbanken. Wenn der Parameter `replicate-do-db` für ein Lesereplikat festgelegt ist, wird dieser Parameter nicht ausgewertet.
+ `replicate-do-table` – Repliziert Änderungen der angegebenen Tabellen. Wenn Sie diesen Parameter für ein Lesereplikat festlegen, werden nur die im Parameter angegebenen Tabellen repliziert. Wenn der Parameter `replicate-do-db` oder `replicate-ignore-db` festgelegt ist, müssen Sie die Datenbank, welche die angegebenen Tabellen enthält, in die Replikation mit dem Lesereplikat einbeziehen.
+ `replicate-ignore-table` – Repliziert keine Änderungen der angegebenen Tabellen. Wenn der Parameter `replicate-do-table` für ein Lesereplikat festgelegt ist, wird dieser Parameter nicht ausgewertet.
+ `replicate-wild-do-table` – Repliziert Tabellen basierend auf den angegebenen Namensmustern für Datenbanken und Tabellen. Die Platzhalterzeichen `%` und `_` werden unterstützt. Wenn der Parameter `replicate-do-db` oder `replicate-ignore-db` festgelegt ist, müssen Sie die Datenbank, welche die angegebenen Tabellen enthält, in die Replikation mit dem Lesereplikat einbeziehen.
+ `replicate-wild-ignore-table` – Repliziert keine Tabellen basierend auf den angegebenen Namensmustern für Datenbanken und Tabellen. Die Platzhalterzeichen `%` und `_` werden unterstützt. Wenn die Parameter `replicate-do-table` oder `replicate-wild-do-table` für ein Lesereplikat festgelegt sind, wird dieser Parameter nicht ausgewertet.
Die Parameter werden in der angegebenen Reihenfolge ausgewertet. Weitere Informationen zur Funktionsweise dieser Parameter finden Sie in der MySQL-Dokumentation:
+ Allgemeine Informationen finden Sie unter [Optionen und Variablen für Replikatserver](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html).
+ Informationen darüber, wie Filterparameter für die Datenbankreplikation ausgewertet werden, finden Sie unter [Optionen zur Auswertung der Replikation auf Datenbankebene und für die binäre Protokollierung](https://dev.mysql.com/doc/refman/8.0/en/replication-rules-db-options.html).
+ Informationen darüber, wie Filterparameter für die Tabellenreplikation ausgewertet werden, finden Sie unter [Optionen zur Auswertung der Replikation auf Tabellenebene](https://dev.mysql.com/doc/refman/8.0/en/replication-rules-table-options.html).
Standardmäßig hat jeder dieser Parameter einen leeren Wert. Sie können diese Parameter auf jedem Lesereplikat verwenden, um Replikationsfilter festzulegen, zu ändern und zu löschen. Wenn Sie einen dieser Parameter festlegen, trennen Sie die einzelnen Filter durch ein Komma voneinander.
Sie können die Platzhalterzeichen `%` und `_` in den Parametern `replicate-wild-do-table` und `replicate-wild-ignore-table` verwenden. Der Platzhalter `%` entspricht einer beliebigen Anzahl von Zeichen, und der Platzhalter `_` entspricht nur einem Zeichen.
Das binäre Protokollierungsformat der Quell-DB-Instance ist wichtig für die Replikation, da es den Datensatz der Datenänderungen bestimmt. Die Einstellung des Parameters `binlog_format` bestimmt, ob die Replikation zeilenbasiert oder anweisungsbasiert ist. Weitere Informationen finden Sie unter [Konfiguration von RDS für MySQL-Binärprotokollierung für Single-AZ-Datenbanken](USER_LogAccess.MySQL.BinaryFormat.md).
**Anmerkung**
Alle DDL-Anweisungen (Data Definition Language) werden unabhängig von der Einstellung `binlog_format` für die Quell-DB-Instance als Anweisungen repliziert.
## Einschränkungen der Replikationsfilter bei RDS für MySQL
Folgende Einschränkungen gelten für Replikationsfilter bei RDS für MySQL:
+ Jeder Filterparameter für die Replikation hat ein Limit von 2 000 Zeichen.
+ Kommas werden in Replikationsfiltern für Parameterwerte nicht unterstützt. In einer Liste mit Parametern können Kommas nur als Werttrennzeichen verwendet werden. Beispiel: `ParameterValue='`a,b`'` wird unterstützt, `ParameterValue='a,b'` jedoch nicht.
+ Die Optionen `--binlog-do-db` und `--binlog-ignore-db` von MySQL für binäre Protokollfilter werden nicht unterstützt.
+ Die Replikationsfilterung unterstützt keine XA-Transaktionen.
Weitere Informationen finden Sie unter [Einschränkungen bei XA-Transaktionen](https://dev.mysql.com/doc/refman/8.0/en/xa-restrictions.html) in der MySQL-Dokumentation.
## Beispiele für Replikationsfilter bei RDS für MySQL
Um die Replikationsfilter für ein Lesereplikat zu konfigurieren, ändern Sie die Parameter der Replikationsfilter in der Parametergruppe, die dem Lesereplikat zugeordnet ist.
**Anmerkung**
Eine Standard-Parametergruppe kann nicht modifiziert werden. Erstellen Sie eine neue Parametergruppe und ordnen Sie diese der Lesereplika zu, wenn die Lesereplika eine Standardparametergruppe verwendet. Weitere Informationen zu DB-Parametergruppen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
Sie können Parameter in einer Parametergruppe mithilfe der AWS-Managementkonsole AWS CLI, oder RDS-API festlegen. Weitere Informationen zum Festlegen von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). Wenn Sie Parameter in einer Parametergruppe festlegen, verwenden alle DB-Instances, die der Parametergruppe zugeordnet sind, diese Parametereinstellungen. Wenn Sie Parameter der Replikationsfilter in einer Parametergruppe festlegen, stellen Sie sicher, dass die Parametergruppe nur Lesereplikaten zugeordnet ist. Lassen Sie die Parameter der Replikationsfilter für Quell-DB-Instances leer.
In den folgenden Beispielen werden die Parameter mithilfe von festgeleg AWS CLI. Diese Beispiele legen `ApplyMethod` auf `immediate` fest, sodass die Parameteränderungen unmittelbar nach Abschluss des CLI-Befehls erfolgen. Wenn Sie möchten, dass eine ausstehende Änderung nach dem Neustart des Lesereplikats angewendet wird, legen Sie `ApplyMethod` auf `pending-reboot` fest.
In den folgenden Beispielen werden Replikationsfilter festgelegt:
+ [Including databases in replication](#rep-filter-in-dbs-mysql)
+ [Including tables in replication](#rep-filter-in-tables-mysql)
+ [Including tables in replication with wildcard characters](#rep-filter-in-tables-wildcards-mysql)
+ [Excluding databases from replication](#rep-filter-ex-dbs-mysql)
+ [Excluding tables from replication](#rep-filter-ex-tables-mysql)
+ [Excluding tables from replication using wildcard characters](#rep-filter-ex-tables-wildcards-mysql)
**Example Einschließen von Datenbanken in die Replikation**
Das folgende Beispiel schließt die Datenbanken `mydb1` und `mydb2` in die Replikation ein.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate"
```
Für Windows:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate"
```
**Example Einschließen von Tabellen in die Replikation**
Das folgende Beispiel schließt die Tabellen `table1` und `table2` in der Datenbank `mydb1` in die Replikation ein.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate"
```
Für Windows:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate"
```
**Example Einschließen von Tabellen in die Replikation mit Platzhalterzeichen**
Das folgende Beispiel schließt Tabellen mit Namen, die mit `order` und `return` beginnen, in Datenbank `mydb` in die Replikation ein.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate"
```
Für Windows:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate"
```
**Example Ausschließen von Datenbanken von der Replikation**
Das folgende Beispiel schließt die Datenbanken `mydb5` und `mydb6` von der Replikation aus.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate"
```
Für Windows:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate"
```
**Example Ausschließen von Tabellen von der Replikation**
Das folgende Beispiel schließt die Tabellen `table1` in Datenbank `mydb5` und `table2` in Datenbank `mydb6` von der Replikation aus.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate"
```
Für Windows:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate"
```
**Example Ausschließen von Tabellen von der Replikation mit Platzhalterzeichen**
Das folgende Beispiel schließt Tabellen mit Namen, die mit `order` und `return` beginnen, in Datenbank `mydb7` von der Replikation aus.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate"
```
Für Windows:
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate"
```
## Anzeigen der Replikationsfilter für ein Lesereplikat
Sie können die Replikationsfilter für ein Lesereplikat wie folgt anzeigen:
+ Überprüfen Sie die Einstellungen der Parameter der Replikationsfilter in der dem Lesereplikat zugeordneten Parametergruppe.
Detaillierte Anweisungen finden Sie unter [Anzeigen von Parameterwerten für eine DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Viewing.md).
+ Stellen Sie in einem MySQL-Client eine Verbindung zum Read-Replikat her und führen Sie die`SHOW REPLICA STATUS` Anweisung aus.
In der Ausgabe werden in den folgenden Feldern die Replikationsfilter für das Lesereplikat angezeigt:
+ `Replicate_Do_DB`
+ `Replicate_Ignore_DB`
+ `Replicate_Do_Table`
+ `Replicate_Ignore_Table`
+ `Replicate_Wild_Do_Table`
+ `Replicate_Wild_Ignore_Table`
Weitere Informationen zu diesen Feldern finden Sie unter [Überprüfen des Replikationsstatus](https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html) in der MySQL-Dokumentation.
# Konfigurieren der verzögerten Replikation mit MySQL
Sie können die verzögerte Replikation als Strategie für die Notfallwiederherstellung einsetzen. Für die verzögerte Replikation geben Sie die Mindestanzahl von Sekunden an, um welche die Replikation von der Quelle in das Lesereplikat verzögert werden soll. Wenn es zu einem Notfall kommt, weil beispielsweise eine Tabelle versehentlich gelöscht wurde, können Sie das Problem mit den folgenden Schritten schnell beheben:
+ Beenden Sie die Replikation im Lesereplikat, bevor die Änderung, die den Notfall verursacht hat, an das Lesereplikat gesendet wird.
Verwenden Sie die gespeicherte Prozedur [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication), um die Replikation zu stoppen.
+ Starten Sie die Replikation und geben Sie an, dass die Replikation automatisch an einer bestimmten Position in der Protokolldatei stoppen soll.
Mit der gespeicherten Prozedur [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) geben Sie eine Position unmittelbar vor Eintreten des Notfalls an.
+ Stufen Sie das Lesereplikat zur neuen Quell-DB-Instance hoch, indem Sie der Anleitung unter folge [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md).
**Anmerkung**
Unter RDS für MySQL 8.4 wird die verzögerte Replikation für MySQL ab 8.4.3 unterstützt. In RDS für MySQL 8.0 wird die verzögerte Replikation für MySQL ab 8.0.28 unterstützt. Unter RDS für MySQL 5.7 wird die verzögerte Replikation für MySQL ab 5.7.44 unterstützt.
Verwenden Sie gespeicherte Prozeduren, um die verzögerte Replikation zu konfigurieren. Sie können die verzögerte Replikation nicht mit der AWS-Managementkonsole AWS CLI, der oder der Amazon RDS-API konfigurieren.
Sie können die Replikation auf der Grundlage globaler Transaktions-Identifikatoren (GTIDs) in einer Konfiguration mit verzögerter Replikation für die folgenden Versionen verwenden:
RDS für MySQL Version 5.7.44 und höhere 5.7-Versionen
RDS für MySQL Version 8.0.28 und höhere 8.0-Versionen
RDS für MySQL Version 8.4.3 und höhere 8.4-Versionen
Wenn Sie die GTID-basierte Replikation verwenden, nutzen Sie die gespeicherte Prozedur [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) anstelle der gespeicherten Prozedur [](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).
**Topics**
+ [
## Konfigurieren der verzögerten Replikation während der Erstellung von Read Replicas
](#USER_MySQL.Replication.ReadReplicas.DelayReplication.ReplicaCreation)
+ [
## Ändern der verzögerten Replikation einer vorhandenen Read Replica
](#USER_MySQL.Replication.ReadReplicas.DelayReplication.ExistingReplica)
+ [
## Festlegen einer Position zum Stoppen der Replikation zu einer Read Replica
](#USER_MySQL.Replication.ReadReplicas.DelayReplication.StartUntil)
+ [
## Hochstufen eines Lesereplikats
](#USER_MySQL.Replication.ReadReplicas.DelayReplication.Promote)
## Konfigurieren der verzögerten Replikation während der Erstellung von Read Replicas
Um die verzögerte Replikation für zukünftig aus einer DB-Instance erstellte Lesereplikate zu konfigurieren, führen Sie die gespeicherte Prozedur [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) mit dem Parameter `target delay` aus.
**Konfigurieren Sie die verzögerte Replikation während der Lesereplikat-Erstellung wie folgt:**
1. Stellen Sie als Master-Benutzer mit einem MySQL-Client eine Verbindung zu der MySQL-DB-Instance her, die als Quelle für Lesereplikate verwendet werden soll.
1. Führen Sie die gespeicherte Prozedur [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) mit dem Parameter `target delay` aus.
Führen Sie beispielsweise die folgende gespeicherte Prozedur aus, um anzugeben, dass die Replikation um mindestens eine Stunde (3.600 Sekunden) für jedes Lesereplikat verzögert werden soll, das aus der aktuellen DB-Instance erstellt wird.
```
call mysql.rds_set_configuration('target delay', 3600);
```
**Anmerkung**
Nachdem Sie diese gespeicherte Prozedur ausgeführt haben, wird jedes Lesereplikat, das Sie mit der AWS CLI oder der Amazon RDS-API erstellen, so konfiguriert, dass die Replikation um die angegebene Anzahl von Sekunden verzögert wird.
## Ändern der verzögerten Replikation einer vorhandenen Read Replica
Führen Sie die gespeicherte Prozedur [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay) aus, um die verzögerte Replikation eines vorhandenen Lesereplikats zu ändern.
**Ändern Sie die verzögerte Replikation eines existierenden Lesereplikats wie folgt:**
1. Verwenden Sie einen MySQL-Client, um als Master-Benutzer eine Verbindung zum Lesereplikat herzustellen.
1. Verwenden Sie die gespeicherte Prozedur [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication), um die Replikation zu stoppen.
1. Führen Sie die gespeicherte Prozedur [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay) aus.
Führen Sie beispielsweise die folgende gespeicherte Prozedur aus, um anzugeben, dass die Replikation für das Lesereplikat um mindestens eine Stunde (3600 Sekunden) verzögert werden soll.
```
call mysql.rds_set_source_delay(3600);
```
1. Verwenden Sie die gespeicherte Prozedur [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication), um die Replikation zu starten.
## Festlegen einer Position zum Stoppen der Replikation zu einer Read Replica
Nachdem Sie die Replikation für ein Lesereplikat gestoppt haben, können Sie die Replikation mit der gespeicherten Prozedur [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) starten und dann an einer angegebenen Position in der Binärprotokolldatei stoppen lassen.
**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 Masterbenutzer eine Verbindung zur MySQL-DB-Instance herzustellen.
1. Führen Sie die gespeicherte Prozedur [](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`.
## Hochstufen eines Lesereplikats
Nachdem die Replikation gestoppt wurde, können Sie in einem Szenario der Notfallwiederherstellung ein Lesereplikat zur neuen Quell-DB-Instance hochstufen. Weitere Informationen zum Hochstufen eines Lesereplikats finden Sie unter [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md).
# Aktualisieren von Lesereplikaten mit MySQL
Lesereplikate wurden zur Unterstützung von Leseabfragen entwickelt. Jedoch könnten gelegentliche Updates notwendig sein. Sie könnten beispielsweise einen Index hinzufügen, um die spezifischen Abfragetypen zu optimieren, die auf das Replica zugreifen.
Zwar können Sie Updates aktivieren, indem Sie den Parameter `read_only` in der DB-Parametergruppe für das Lesereplikat auf `0` setzen. Wir raten jedoch davon ab, da Probleme auftreten können, wenn das Lesereplikat nicht mehr mit der Quell-DB-Instance kompatibel ist. Für Wartungsarbeiten empfehlen wir, blue/green Bereitstellungen zu verwenden. Weitere Informationen finden Sie unter [Verwendung von Blue/Green Bereitstellungen für Datenbankaktualisierungen](blue-green-deployments.md).
Wenn Sie den Schreibschutz für ein Lesereplikat deaktivieren, ändern Sie den Wert des Parameters `read_only` sobald wie möglich wieder in `1`.
# Arbeiten mit Bereitstellungen von Multi-AZ-Lesereplikaten mit MySQL
Sie können ein Lesereplikat aus Single-AZ- oder Multi-AZ-DB-Instance-Bereitstellungen erstellen. Sie können Multi-AZ-Bereitstellungen verwenden, um die Haltbarkeit und Verfügbarkeit kritischer Daten zu verbessern, aber Sie können Multi-AZ nicht zweitranging noch für schreibgeschützte Abfragen verwenden. Stattdessen können Sie Lesereplikate aus Multi-AZ-DB-Instances mit hohem Datenverkehr erstellen, um schreibgeschützte Abfragen auslagern zu können. Wenn die Quell-Instance einer Multi-AZ-Bereitstellung ein Failover zur sekundären Instance durchführt, werden alle zugehörigen Lesereplikate automatisch auf die Verwendung der sekundären (jetzt primären) Instance als Replikationsquelle umgeschaltet. Weitere Informationen finden Sie unter [Konfigurieren und Verwalten einer Multi-AZ-Bereitstellung für Amazon RDS](Concepts.MultiAZ.md).
Sie können ein Lesereplikat als Multi-AZ-DB-Instance erstellen. Amazon RDS erstellt eine Standby-Version des Replikats in einer anderen Availability Zone, um ein Failover für das Replikat zu unterstützen. Das Erstellen Ihres Lesereplikats als Multi-AZ-DB-Instance ist unabhängig davon, ob die Quelldatenbank eine Multi-AZ-DB-Instance ist.
# Verwendung von kaskadierenden Lesereplikaten mit RDS für MySQL
RDS für MySQL unterstützt kaskadierende Lesereplikate. Mit *kaskadierenden Lesereplikaten* können Sie Lesereplikate skalieren, ohne dass Sie zusätzlichen Overhead für Ihre Quell-DB-Instance von RDS für MySQL verursachen.
Bei kaskadierenden Lesereplikaten sendet Ihre DB-Instance von RDS für MySQL Daten an das erste Lesereplikat in der Kette. Dieses Lesereplikat sendet dann Daten an das zweite Replikat in der Kette usw. Das Endergebnis ist, dass alle Lesereplikate in der Kette die Änderungen von der DB-Instance von RDS für MySQL aufweisen, jedoch ohne Overhead ausschließlich auf der Quell-DB-Instance zu verursachen.
Sie können eine Reihe von bis zu drei Lesereplikaten in einer Kette von einer Quell-DB-Instance von RDS für MySQL erstellen. Angenommen, Sie haben eine DB-Instance von RDS für MySQL, `mysql-main`. Sie haben die folgenden Möglichkeiten:
+ Beginnend mit `mysql-main` erstellen Sie das erste Lesereplikat in der Kette `read-replica-1`.
+ Als Nächstes erstellen Sie ab `read-replica-1` das nächste Lesereplikat in der Kette `read-replica-2`.
+ Schließlich erstellen Sie ab `read-replica-2` das nächste Lesereplikat in der Kette `read-replica-3`.
Sie können kein weiteres Lesereplikat über dieses dritte kaskadierende Lesereplikat hinaus in der Reihe für `mysql-main` erstellen. Eine vollständige Reihe von Instances aus einer Quell-DB-Instance von RDS für MySQL bis zum Ende einer Reihe kaskadierender Lesereplikate kann aus höchstens vier DB-Instances bestehen.
Damit die Kaskadierung von Lesereplikaten funktioniert, müssen automatische Backups für jede Quell-DB-Instance von RDS für MySQL aktiviert sein. Erstellen Sie zuerst das Lesereplikat und ändern Sie es dann, um automatische Backups für das Lesereplikat für zu aktivieren. Weitere Informationen finden Sie unter [Erstellen eines Lesereplikats](USER_ReadRepl.Create.md).
Wie bei jedem Lesereplikat können Sie ein Lesereplikat, das Teil einer Kaskade ist, hochstufen. Wenn Sie ein Lesereplikat aus einer Kette von Lesereplikaten hochstufen, wird dieses Replikat aus der Kette entfernt. Angenommen, Sie möchten einen Teil der Workload von Ihrer `mysql-main`-DB-Instance zu einer neuen Instance verschieben, die nur von der Buchhaltung verwendet wird. Ausgehend von der Kette von drei Lesereplikaten aus dem Beispiel entscheiden Sie sich, `read-replica-2` hochzustufen. Die Kette ist wie folgt betroffen:
+ Durch Hochstufen von `read-replica-2` wird es aus der Replikationskette entfernt.
+ Es ist jetzt eine vollständige DB-Instance mit Lese-/Schreibzugriff.
+ Die Replizierung auf `read-replica-3` wird fortgesetzt wie vor der Hochstufung.
+ Ihre `mysql-main` setzt die Replizierung auf `read-replica-1` fort.
Weitere Informationen über das Hochstufen von Lesereplikaten finden Sie unter [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md).
# Überwachen der Replikationsverzögerung für MySQL-Lesereplikate
Für MySQL-Lesereplikat können Sie die Replikationsverzögerung in Amazon CloudWatch überwachen, indem Sie sich die Amazon-RDS-Metrik `ReplicaLag` ansehen. Die Kennzahl `ReplicaLag` meldet den Wert des Feldes `Seconds_Behind_Master` des Befehls `SHOW REPLICA STATUS`.
Häufige Ursachen für Replikationsverzögerungen in MySQL:
+ Ein Netzwerkausfall.
+ Schreiben in Tabellen, die verschiedene Indizes in einem Lesereplikat haben. Wenn der Parameter `read_only` in einem Lesereplikat auf `0` gesetzt ist, kann die Replikation fehlschlagen, wenn das Lesereplikat nicht mehr mit der Quell-DB-Instance kompatibel ist. Nachdem Sie Wartungsarbeiten für ein Lesereplikat durchgeführt haben, sollten Sie den Parameter `read_only` wieder zurück auf `1` setzen.
+ Die Verwendung einer nicht-transaktionalen Speicher-Engine wie MyISAM: Die Replikation wird nur für die InnoDB-Speicher-Engine für MySQL unterstützt.
Wenn die Metrik `ReplicaLag` 0 erreicht, hat das Replica den Stand der Quell-DB-Instance erreicht. Wenn die Metrik `ReplicaLag` -1 zurückgibt, ist die Replikation aktuell nicht aktiv. `ReplicaLag` = -1 ist gleich `Seconds_Behind_Master` = `NULL`.
# Starten und Stoppen der Replikation mit MySQL Read Replicas
Sie können den Replikationsvorgang für eine Amazon-RDS-DB-Instance anhalten oder neustarten, indem Sie die gespeicherten Systemprozeduren [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) und [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) aufrufen. Dies können Sie tun, wenn Sie eine Replikation zwischen Amazon-RDS-Instances für langandauernde Operationen, wie dem Erstellen von großen Indexen, durchführen. Sie müssen Replikation auch anhalten und starten, wenn Sie Datenbanken importieren oder exportieren. Weitere Informationen erhalten Sie unter [Importieren von Daten in eine Datenbank von Amazon RDS für MySQL mit reduzierter Ausfallzeit](mysql-importing-data-reduced-downtime.md) und [Exportieren von Daten aus einer MySQL DB-Instance mithilfe der Replikation](MySQL.Procedural.Exporting.NonRDSRepl.md).
Wenn eine Replikation für mehr als 30 aufeinanderfolgende Tage manuell oder aufgrund eines Replikationsfehlers gestoppt wird, beendet Amazon RDS die Replikation zwischen der Quell-DB-Instance und allen Lesereplikaten. um erhöhten Speicheranforderungen in der Quell-DB-Instance vorzubeugen und lange Failover-Zeiten zu vermeiden. Die Lesereplikat-DB-Instance ist weiterhin verfügbar. Die Replikation kann jedoch nicht fortgesetzt werden, da die vom Lesereplikat benötigten Binärprotokolle aus der Quell-DB-Instance nach Beendigung der Replikation gelöscht wurden. Sie können ein neues Lesereplikat für die Quell-DB-Instance erstellen, um die Replikation erneut aufzunehmen.
# Fehlerbehebung für ein Problem mit einer MySQL Read Replica
Im Fall von MySQL-DB-Instances zeigen Lesereplikate manchmal Replikationsfehler oder Dateninkonsistenzen (oder beides) zwischen dem Lesereplikat und seiner DB-Quell-Instance an. Dieses Problem tritt auf, wenn einige Binärprotokoll (Binlog)-Ereignisse oder InnoDB-Wiederholungsprotokolle während eines Fehlers des Lesereplikats oder der Quell-DB-Instance nicht bereinigt werden. In diesen Fällen müssen Sie die Lesereplikate manuell löschen und neu erstellen. Sie können das Risiko minimieren, indem Sie die folgenden Parameterwerte einstellen: `sync_binlog=1` und `innodb_flush_log_at_trx_commit=1`. Diese Einstellungen könnten die Leistung reduzieren, daher ist es ratsam, sie vor der Implementierung in einer Produktionsumgebung ausgiebig zu testen.
**Warnung**
In der Parametergruppe, die mit der Quell-DB-Instance verknüpft ist, sollten diese Parameterwerte beibehalten werden: `sync_binlog=1` und `innodb_flush_log_at_trx_commit=1`. Diese Parameter sind dynamisch. Wenn Sie diese Einstellungen nicht verwenden möchten, empfehlen wir Ihnen, diese Werte vorübergehend festzulegen, bevor Sie einen Vorgang für die Quell-DB-Instance ausführen, der einen Neustart verursachen könnte. Zu diesen Vorgängen gehören unter anderem Neustart, Neustart mit Failover, das Aktualisieren der Datenbankversion und das Ändern der DB-Instance-Klasse oder ihres Speichers. Die gleiche Empfehlung gilt für das Erstellen neuer Lesereplikate für die Quell-DB-Instance.
Die Nichteinhaltung dieser Anleitung erhöht das Risiko, dass Lesereplikate Replikationsfehler oder Dateninkonsistenzen (oder beides) zwischen dem Lesereplikat und seiner DB-Quell-Instance aufweisen.
Die Replikationstechnologien in MySQL funktionieren nach einem asynchronen Prinzip. Da sie asynchron sind, steigt gelegentlich `BinLogDiskUsage` in der Quell-DB-Instance an und `ReplicaLag` ist im Lesereplikat zu erwarten. Beispielsweise kann auf der Quell-DB-Instance eine große Anzahl von Schreibvorgängen gleichzeitig ausgeführt werden. Dagegen werden Schreibvorgänge zum Lesereplikat über einen einzigen I/O-Thread seriell abgearbeitet. Dies kann zu einer Verzögerung zwischen der Quell-DB-Instance und dem Lesereplikat führen. Weitere Informationen über schreibgeschützte Replikate in der MySQL-Dokumentation finden Sie unter [Details zur Implementierung der Replikation](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation-details.html).
Sie können folgende Dinge tun, um die Verzögerungszeit zwischen Aktualisierungen einer Quell-DB-Instance und der nachfolgenden Aktualisierung des Lesereplikats zu reduzieren:
+ Passen Sie die Speichergröße und die DB-Instance-Klasse eines Lesereplikats an die der Quell-DB-Instance an.
+ Stellen Sie sicher, dass Parametereinstellungen in den DB-Parametergruppen, die von der Quell-DB-Instance und den Lesereplikaten verwendet werden, kompatibel sind. Weitere Informationen und ein Beispiel finden Sie in der Beschreibung des `max_allowed_packet`-Parameters weiter unten in diesem Abschnitt.
Amazon RDS überwacht den Replikationsstatus Ihrer Lesereplikate und setzt den `Replication State` der Lesereplikat-Instance auf `Error`, wenn die Replikation aus irgendeinem Grund beendet wird. Ein Beispiel wären auf Ihrem Lesereplikat ausgeführte DML-Abfragen, die mit den Aktualisierungen auf der Quell-DB-Instance in Konflikt treten.
Sie können die Details des von der MySQL-Engine zurückgegebenen Fehlers dem Feld `Replication Error` entnehmen. Ereignisse, die den Status des Lesereplikats angeben, werden ebenfalls generiert, einschließlich [RDS-EVENT-0045](USER_Events.Messages.md#RDS-EVENT-0045), [RDS-EVENT-0046](USER_Events.Messages.md#RDS-EVENT-0046) und [RDS-EVENT-0047](USER_Events.Messages.md#RDS-EVENT-0047). Weitere Informationen über Ereignisse und Abonnements zu Ereignissen finden Sie unter [Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen](USER_Events.md). Wenn eine MySQL-Fehlermeldung zurückgegeben wird, überprüfen Sie die Fehlernummer in der [MySQL-Fehlermeldungsdokumentation](https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html).
Ein häufiges Problem, das Replikationsfehler verursachen kann, besteht, wenn der Wert für den `max_allowed_packet`-Parameter eines Lesereplikats niedriger ist als der Wert für den `max_allowed_packet`-Parameter der Quell-DB-Instance. Der `max_allowed_packet`-Parameter ist ein benutzerdefinierter Parameter, den Sie in einer DB-Parametergruppe festlegen können. Sie verwenden `max_allowed_packet`, um die maximale Größe von DML-Code anzugeben, der in der Datenbank ausgeführt werden kann. In einigen Fällen ist der `max_allowed_packet`-Wert in der mit einer Quell-DB-Instance verknüpften DB-Parametergruppe kleiner als der `max_allowed_packet`-Wert in der mit dem Lesereplikat der Quelle verknüpften DB-Parametergruppe. In diesen Fällen kann der Replikationsprozess den Fehler `Packet bigger than 'max_allowed_packet' bytes` auslösen und die Replikation beenden. Um den Fehler zu beheben, lassen Sie die DB-Quell-Instance und das Lesereplikat DB-Parametergruppen mit denselben `max_allowed_packet`-Parameterwerten verwenden.
Weitere Situationen, bei denen Replikationsfehler auftreten können, sind die Folgenden:
+ Schreibvorgänge auf Tabellen in einem Lesereplikat. In einigen Fällen können Sie Indizes für ein Lesereplikat erstellen, die sich von den Indizes in der Quell-DB-Instance unterscheiden. Wenn Sie dies tun, setzen Sie den Parameter `read_only` auf `0`, um die Indizes zu erstellen. Wenn Sie in einem Lesereplikat in Tabellen schreiben, kann die Replikation unterbrochen werden, wenn das Lesereplikat nicht mehr mit der Quell-DB-Instance kompatibel ist. Nachdem Sie Wartungsarbeiten für ein Lesereplikat durchgeführt haben, sollten Sie den Parameter `read_only` wieder zurück auf `1` setzen.
+ Die Verwendung einer nicht-transaktionalen Speicher-Engine wie MyISAM: Read Replicas erfordern eine transaktionale Speicher-Engine. Die Replikation wird nur für die InnoDB-Speicher-Engine für MySQL unterstützt.
+ Verwenden von nicht-deterministischen Abfragen wie `SYSDATE()`. Weitere Informationen finden Sie unter [Erkennen sicherer und nicht sicherer Anweisungen in der binären Protokollierung](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html).
Wenn Sie entscheiden, dass Sie einen Fehler problemlos überspringen können, folgen Sie den Schritten im Abschnitt [Überspringen des aktuellen Replikationsfehlers für RDS für MySQL](Appendix.MySQL.CommonDBATasks.SkipError.md). Andernfalls können Sie zuerst das Lesereplikat löschen. Anschließend erstellen Sie eine Instance mit derselben DB-Instance-Kennung, sodass der Endpunkt mit dem des alten Lesereplikats übereinstimmt. Wird ein Replikationsfehler behoben, ändert sich das Feld `Replication State` zu *Replicating*.
# Verwenden der GTID-basierten Replikation
Der folgende Inhalt beschreibt, wie Sie globale Transaktionskennungen (Global Transaction Identifiers, GTIDs) mit Binärprotokoll (binlog)-Replikation unter DB-Instances von Amazon RDS für MySQL verwenden.
Wenn Sie die binlog-Replikation verwenden und nicht mit der GTID-basierten Replikation mit MySQL vertraut sind, finden Sie unter [Replikation mit globalen Transaktionskennungen](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html) in der MySQL-Dokumentation weitere Informationen.
Die GTID-basierte Replikation wird für die folgenden Versionen unterstützt:
+ RDS für MySQL 8.4 (alle Versionen)
+ RDS für MySQL 8.0 (alle Versionen)
+ RDS für MySQL 5.7 (alle Versionen)
Alle MySQL-DB-Instances in einer Replikationskonfiguration müssen diese Versionsanforderung erfüllen.
**Topics**
+ [
## Übersicht über globale Transaktionskennungen (GTIDs)
](#mysql-replication-gtid.overview)
+ [
## Parameter für die GTID-basierte Replikation
](#mysql-replication-gtid.parameters)
+ [
# Aktivieren der GTID-basierten Replikation für neue Lesereplikate für RDS für MySQL
](mysql-replication-gtid.configuring-new-read-replicas.md)
+ [
# Aktivieren der GTID-basierten Replikation für vorhandene Lesereplikate für RDS für MySQL
](mysql-replication-gtid.configuring-existing-read-replicas.md)
+ [
# Deaktivieren einer GTID-basierten Replikation für eine MySQL-DB-Instance mit Read Replicas
](mysql-replication-gtid.disabling.md)
## Übersicht über globale Transaktionskennungen (GTIDs)
*Globale Transaktionskennungen (GTIDs)* sind eindeutige IDs, die für festgeschriebene MySQL-Transaktionen generiert werden. Sie können GTIDs verwenden, um die Fehlerbehebung für die binlog-Replikation zu erleichtern.
MySQL verwendet für die binlog-Replikation zwei verschiedene Arten von Transaktionen:
+ *GTID-Transaktionen* – Transaktionen, die durch eine GTID gekennzeichnet sind.
+ *Anonyme Transaktionen* – Transaktionen, denen keine GTID zugeordnet ist.
In einer Replikationskonfiguration sind GTIDs bei allen DB-Instances eindeutig. GTIDs vereinfachen die Replikationskonfiguration, weil Sie nicht auf die Protokolldateipositionen verweisen müssen, wenn Sie diese verwenden. GTIDs erleichtern das Verfolgen von replizierten Transaktionen und legen fest, ob die Quellinstance und Replikate konsistent sind.
Zur Replikation von Daten mit RDS-MySQL-Lesereplikaten können Sie die GTID-basierte Replikation verwenden. Sie können beim Erstellen neuer Lesereplikate die GTID-basierte Replikation konfigurieren oder bestehende Lesereplikate zum Verwenden der GTID-basierten Replikation konvertieren.
Sie können die GTID-basierte Replikation in einer zeitlich verzögerten Replikationskonfiguration mit RDS für MySQL verwenden. Weitere Informationen finden Sie unter [Konfigurieren der verzögerten Replikation mit MySQL](USER_MySQL.Replication.ReadReplicas.DelayReplication.md).
## Parameter für die GTID-basierte Replikation
Mit den folgenden Parametern konfigurieren Sie die GTID-basierte Replikation.
| Parameter | Zulässige Werte | Beschreibung |
| --- | --- | --- |
| `gtid_mode` | `OFF`, `OFF_PERMISSIVE`, `ON_PERMISSIVE`, `ON` | `OFF` gibt an, dass neue Transaktionen anonyme Transaktionen sind (d. h. keine GTIDs haben). Eine Transaktion muss anonym sein, um repliziert werden zu können. `OFF_PERMISSIVE` gibt an, dass neue Transaktionen anonyme Transaktionen sind und alle Transaktionen repliziert werden können. `ON_PERMISSIVE` gibt an, dass neue Transaktionen GTID-Transaktionen sind und alle Transaktionen repliziert werden können. `ON` gibt an, dass neue Transaktionen GTID-Transaktionen sind. Eine Transaktion muss eine GTID-Transaktion sein, um repliziert zu werden. |
| `enforce_gtid_consistency` | `OFF`, `ON`, `WARN` | `OFF` erlaubt es Transaktionen, gegen die GTID-Konsistenz zu verstoßen. `ON` verhindert das Verstoßen von Transaktionen gegen die GTID-Konsistenz. `WARN` erlaubt es Transaktionen, gegen die GTID-Konsistenz zu verstoßen, generiert aber eine Warnung, wenn ein Verstoß auftritt. |
**Anmerkung**
In der AWS-Managementkonsole erscheint der Parameter `gtid_mode` als `gtid-mode`.
Bei einer GTID-basierten Replikation verwenden Sie diese Einstellungen für die Parametergruppe für Ihre DB-Instance oder Lesereplikate:
+ `ON` und `ON_PERMISSIVE` gelten nur für die ausgehende Replikation von einer RDS-DB-Instance. Beide Werte bewirken, dass Ihre RDS-DB-Instance GTIDs für Transaktionen verwenden, die repliziert werden. `ON` erfordert, dass die Zieldatenbank ebenfalls die GTID-basierte Replikation verwendet. Mit `ON_PERMISSIVE` ist die GTID-basierte Replikation auf der Zieldatenbank optional.
+ Wenn `OFF_PERMISSIVE` eingestellt ist, bedeutet dies, dass Ihre RDS-DB-Instances die eingehende Replikation von einer Quelldatenbank akzeptieren können. Dabei ist unerheblich, ob die Quelldatenbank eine GTID-basierte Replikation verwendet.
+ Wenn `OFF` eingestellt ist, bedeutet dies, dass Ihre RDS-DB-Instance nur eingehende Replikation von Quelldatenbanken akzeptieren, die keine GTID-basierte Replikation verwenden.
Weitere Informationen zu Parametergruppen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
# Aktivieren der GTID-basierten Replikation für neue Lesereplikate für RDS für MySQL
Wenn die GTID-basierte Replikation für eine RDS für MySQL-DB-Instance aktiviert ist, wird die GTID-basierte Replikation automatisch für Lesereplikate der DB-Instance konfiguriert.
**So aktivieren Sie die GTID-basierte Replikation für neue Lesereplikate**
1. Die Parametergruppe, die der DB-Instance zugeordnet ist, muss über die folgenden Parametereinstellungen verfügen:
+ `gtid_mode` – `ON` oder `ON_PERMISSIVE`
+ `enforce_gtid_consistency` – `ON`
Weitere Informationen zum Einstellen von Konfigurationsparametern unter Verwendung von Parametergruppen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
1. Wenn Sie die Parametergruppe der DB-Instance geändert haben, müssen Sie die DB-Instance neu starten. Weitere Information dazu finden Sie unter [Eine DB-Instance DB-Cluster neu starten](USER_RebootInstance.md).
1. Erstellen Sie mindestens ein Lesereplikat der DB-Instance. Weitere Information dazu finden Sie unter [Erstellen eines Lesereplikats](USER_ReadRepl.Create.md).
Amazon RDS versucht, mithilfe von eine GTID-basierte Replikation zwischen der MySQL-DB-Instance und den Lesereplikaten herzustelle `MASTER_AUTO_POSITION`. Wenn der Versuch fehlschlägt, verwendet Amazon RDS Protokolldateipositionen für die Replikation mit den Lesereplikaten. Weitere Informationen zu `MASTER_AUTO_POSITION` finden Sie unter [ Automatische GTID-Positionierung](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-auto-positioning.html) in der MySQL-Dokumentation.
# Aktivieren der GTID-basierten Replikation für vorhandene Lesereplikate für RDS für MySQL
Für eine vorhandene MySQL-DB-Instance mit Lesereplikaten, die keine GTID-basierte Replikation verwendet, können Sie eine GTID-basierte Replikation zwischen der DB-Instance und den Lesereplikaten konfigurieren.
**So aktivieren Sie die GTID-basierte Replikation für bestehende Lesereplikate**
1. Wenn die DB-Instance oder eine Read Replica eine 8.0-Version von RDS für MySQL unter 8.0.26 verwendet, aktualisieren Sie die DB-Instance oder Read Replica auf 8.0.26 oder eine höhere MySQL 8.0-Version. Alle Versionen von RDS für MySQL 8.4 und 5.7 unterstützen die GTID-basierte Replikation.
Weitere Informationen finden Sie unter [Upgrades der DB-Engine von RDS für MySQL](USER_UpgradeDBInstance.MySQL.md).
1. (Optional) Setzen Sie die GTID-Parameter zurück und testen Sie das Verhalten der DB-Instance und der Lesereplikate:
1. Die Parametergruppe, die der DB-Instance zugeordnet ist, und jedes Lesereplikat muss den Wert für den Parameter `enforce_gtid_consistency` auf `WARN` gesetzt haben.
Weitere Informationen zum Einstellen von Konfigurationsparametern unter Verwendung von Parametergruppen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
1. Wenn Sie die Parametergruppe der DB-Instance geändert haben, müssen Sie die DB-Instance neu starten. Wenn Sie die Parametergruppe des Lesereplikats geändert haben, müssen Sie das Lesereplikat neu starten.
Weitere Informationen finden Sie unter [Eine DB-Instance DB-Cluster neu starten](USER_RebootInstance.md).
1. Führen Sie Ihre DB-Instance und Lesereplikate mit Ihrem normalen Workload aus und überwachen Sie die Protokolldateien.
Wenn Ihnen Warnungen über GTID-inkompatible Transaktionen angezeigt werden, passen Sie Ihre Anwendung so an, dass sie nur GTID-kompatible Funktionen verwendet. Die DB-Instance darf keine Warnungen über GTID-inkompatible Transaktionen erzeugen, bevor Sie mit dem nächsten Schritt fortfahren.
1. Setzen Sie die GTID-Parameter für die GTID-basierte Replikation zurück, die anonyme Transaktionen erlaubt, bis die Lesereplikate alle verarbeitet haben.
1. Die Parametergruppe, die der DB-Instance zugeordnet ist, und jedes Lesereplikat muss die folgenden Parametereinstellungen haben:
+ `gtid_mode` – `ON_PERMISSIVE`
+ `enforce_gtid_consistency` – `ON`
1. Wenn Sie die Parametergruppe der DB-Instance geändert haben, müssen Sie die DB-Instance neu starten. Wenn Sie die Parametergruppe des Lesereplikats geändert haben, müssen Sie das Lesereplikat neu starten.
1. Warten Sie, bis alle anonymen Transaktionen abgeschlossen sind. Um zu überprüfen, ob diese repliziert sind, gehen Sie wie folgt vor:
1. Führen Sie die folgende Anweisung auf Ihrer Quell-DB-Instance aus.
**MySQL 8.4**
```
SHOW BINARY LOG STATUS;
```
**MySQL 5.7 und 8.0**
```
SHOW MASTER STATUS;
```
Notieren Sie die Werte in den Spalten `File` und `Position`.
1. Verwenden Sie bei jedem Lesereplikat die Datei- und Positionsinformationen der Quell-Instance im vorherigen Schritt, um die folgende Abfrage auszuführen.
```
SELECT MASTER_POS_WAIT('file', position);
```
Führen Sie die folgende Anweisung aus, wenn der Dateiname `mysql-bin-changelog.000031` lautet und die Position `107` ist.
```
SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107);
```
Wenn das Lesereplikat über die angegebene Position hinausgeht, wird die Abfrage sofort zurückgegeben. Andernfalls wartet die Funktion. Gehen Sie zum nächsten Schritt über, wenn die Abfrage für alle Lesereplikate zurückgegeben wird.
1. Setzen Sie die GTID-Parameter ausschließlich für die GTID-basierte Replikation zurück.
1. Die Parametergruppe, die der DB-Instance zugeordnet ist, und jedes Lesereplikat muss die folgenden Parametereinstellungen haben:
+ `gtid_mode` – `ON`
+ `enforce_gtid_consistency` – `ON`
1. Starten Sie die DB-Instance und jedes Lesereplikat neu.
1. Führen Sie auf jedem Lesereplikat die folgende Prozedur aus.
**MySQL 8.4 und höhere Hauptversionen**
```
CALL mysql.rds_set_source_auto_position(1);
```
**MySQL 8.0 und niedrigere Hauptversionen**
```
CALL mysql.rds_set_master_auto_position(1);
```
# Deaktivieren einer GTID-basierten Replikation für eine MySQL-DB-Instance mit Read Replicas
Sie können eine GTID-basierte Replikation für die eine GTID-basierte Replikation für eine MySQL-DB-Instance mit Lesereplikaten verwenden.
**So deaktivieren Sie die GTID-basierte Replikation für eine MySQL-DB-Instance mit Lesereplikaten**
1. Führen Sie auf jedem Lesereplikat die folgende Prozedur aus:
**MySQL 8.4 und höhere Hauptversionen**
```
CALL mysql.rds_set_source_auto_position(0);
```
**MySQL 8.0 und niedrigere Hauptversionen**
```
CALL mysql.rds_set_master_auto_position(0);
```
1. Setzen Sie den Wert für `gtid_mode` auf `ON_PERMISSIVE` zurück.
1. Die Parametergruppe, die der MySQL-DB-Instance zugeordnet ist, und jedes Read Replica muss den Wert für den Parameter `gtid_mode` auf `ON_PERMISSIVE` gesetzt haben.
Weitere Informationen zum Einstellen von Konfigurationsparametern unter Verwendung von Parametergruppen finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md).
1. Starten Sie die MySQL-DB-Instance und jedes Read Replica neu. Weitere Informationen zum Neustarten finden Sie unter [Eine DB-Instance DB-Cluster neu starten](USER_RebootInstance.md).
1. Setzen Sie den Wert für `gtid_mode` auf `OFF_PERMISSIVE` zurück.
1. Die Parametergruppe, die der MySQL-DB-Instance zugeordnet ist, und jedes Read Replica muss den Wert für den Parameter `gtid_mode` auf `OFF_PERMISSIVE` gesetzt haben.
1. Starten Sie die MySQL-DB-Instance und jedes Read Replica neu.
1. Warten Sie, bis alle GTID-Transaktionen auf alle Lesereplikate angewendet wurden. Um zu überprüfen, ob diese angewendet werden, führen Sie die folgenden Schritte aus:
1. Führen Sie für die MySQL-DB-Instance den folgenden Befehl aus:
**MySQL 8.4**
```
SHOW BINARY LOG STATUS
```
**MySQL 5.7 und 8.0**
```
SHOW MASTER STATUS
```
Die Ausgabe sollte in etwa wie folgt aussehen.
```
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
```
Notieren Sie die Datei und Position in Ihrer Ausgabe.
1. Verwenden Sie bei jedem Lesereplikat die Datei- und Positionsinformationen der Quell-Instance im vorherigen Schritt, um die folgende Abfrage auszuführen.
**MySQL 8.4 und MySQL 8.0.26 und höhere MySQL-8.0-Versionen**
```
SELECT SOURCE_POS_WAIT('file', position);
```
**MySQL 5.7**
```
SELECT MASTER_POS_WAIT('file', position);
```
Führen Sie die folgende Anweisung aus, wenn der Dateiname `mysql-bin-changelog.000031` lautet und die Position `107` ist:
**MySQL 8.4 und MySQL 8.0.26 und höhere MySQL-8.0-Versionen**
```
SELECT SOURCE_POS_WAIT('mysql-bin-changelog.000031', 107);
```
**MySQL 5.7**
```
SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107);
```
1. Setzen Sie die GTID-Parameter zurück, um die GTID-basierte Replikation zu deaktivieren:
1. Die Parametergruppe, die der MySQL-DB-Instance zugeordnet ist, und jedes Read Replica muss die folgenden Parametereinstellungen haben:
+ `gtid_mode` – `OFF`
+ `enforce_gtid_consistency` – `OFF`
1. Starten Sie die MySQL-DB-Instance und jedes Read Replica neu.
# Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance
Sie können eine Replikation zwischen einer RDS für MySQL- oder MariaDB-DB-Instance und einer MySQL- oder MariaDB-Instance, die außerhalb von Amazon RDS ausgeführt wird, mit der Binärprotokolldatei-Replikation einrichten.
**Topics**
+ [
## Bevor Sie beginnen
](#MySQL.Procedural.Importing.External.Repl.BeforeYouBegin)
+ [
## Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance
](#MySQL.Procedural.Importing.External.Repl.Procedure)
## Bevor Sie beginnen
Sie konfigurieren die Replikation mithilfe der Position der Binärprotokolldatei von replizierten Transaktionen.
Die erforderlichen Berechtigungen für das Starten einer Replikation in einer Amazon-RDS-DB-Instance sind beschränkt und für Ihre Amazon-RDS-Hauptbenutzer nicht verfügbar. Achten Sie daher darauf, dass Sie die Amazon-RDS-Befehle [mysql.rds\$1set\$1external\$1master (RDS-für-MariaDB- und RDS-für-MySQL-Hauptversionen 8.0 und niedriger)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) oder [mysql.rds\$1set\$1external\$1source (RDS-für-MySQL-Hauptversionen 8.4 und höher)](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 Ihrer Live-Datenbank und Ihrer Amazon-RDS-Datenbank einzurichten.
Aktualisieren Sie den Parameter `binlog_format`, um das binäre Protokollierungsformat für eine MySQL- oder MariaDB-Datenbank festzulegen. Wenn Ihre DB-Instance die standardmäßige DB-Instance-Parametergruppe verwendet, erstellen Sie eine neue DB-Parametergruppe, um den Parameter `binlog_format` zu ändern. In MariaDB sowie MySQL 8.0 und früheren Versionen ist `binlog_format` standardmäßig auf `MIXED` festgelegt. Sie können `binlog_format` jedoch auch auf `ROW` oder `STATEMENT` einstellen, wenn Sie ein spezifisches Format des Binärprotokolls (binlog) benötigen. Starten Sie Ihre DB-Instance neu, damit die Änderungen übernommen werden. In MySQL 8.4 und höheren Versionen ist `binlog_format` standardmäßig auf `ROW` festgelegt.
Informationen zum Einstellen des Parameters `binlog_format` erhalten Sie unter [Konfiguration von RDS für MySQL-Binärprotokollierung für Single-AZ-Datenbanken](USER_LogAccess.MySQL.BinaryFormat.md). Informationen über die Auswirkungen der Verwendung unterschiedlicher MySQL-Replikationstypen finden Sie unter [Vor- und Nachteile einer auf Anweisungen und einer auf Zeilen basierenden Replikation](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) in der MySQL-Dokumentation.
## Konfigurieren der Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance
Befolgen Sie diese Richtlinien, wenn Sie eine externe Quellinstance und ein Replikat auf Amazon RDS einrichten:
+ Überwachen Sie Failover-Ereignisse für die Amazon-RDS-DB-Instance, die Ihr Replica ist. Tritt ein Failover auf, kann die DB-Instance, die Ihr Replikat ist, auf einem neuen Host mit einer anderen Netzwerkadresse wiederhergestellt werden. Weitere Informationen zum Überwachen von Failover-Ereignissen finden Sie unter [Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen](USER_Events.md).
+ Bewahren Sie die Binärprotokolle auf Ihrer Quell-Instance auf, bis Sie sichergestellt haben, dass sie auf das Replikat angewendet wurden. Durch das Aufbewahren können Sie sicherstellen, dass Sie Ihre Quell-Instance im Fall eines Ausfalls wiederherstellen können.
+ Schalten Sie automatische Backups in Ihrer Amazon-RDS-DB-Instance ein. Das Einschalten automatischer Sicherungen stellt sicher, dass Sie Ihr Replikat zu einem bestimmten Zeitpunkt wiederherstellen können, wenn Sie die Quell-Instance und das Replikat neu synchronisieren müssen. Informationen zu Sicherungen und point-in-time Wiederherstellungen finden Sie unter[Sichern, Wiederherstellen und Exportieren von Daten](CHAP_CommonTasks.BackupRestore.md).
**Konfigurieren Sie die Replikation der Binärprotokolldateiposition mit einer externen Quell-Instance wie folgt:**
1. Legen Sie die Quell-MySQL- oder MariaDB-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 MySQL- oder MariaDB-Quell-Instance aus, um die Position des Binärprotokolls zu ermitteln.
Sie erhalten eine Ausgabe, ähnlich der im folgenden Beispiel.
```
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
```
1. Kopieren Sie die Datenbank aus der externen Instance in die Amazon-RDS-DB-Instance mithilfe von `mysqldump`. Für große Datenbanken empfiehlt es sich, die Prozedur in zu verwende [Importieren von Daten in eine Datenbank von Amazon RDS für MySQL mit reduzierter Ausfallzeit](mysql-importing-data-reduced-downtime.md).
Für Linux, macOS oder Unix:
```
mysqldump --databases database_name \
--single-transaction \
--compress \
--order-by-primary \
-u local_user \
-plocal_password | mysql \
--host=hostname \
--port=3306 \
-u RDS_user_name \
-pRDS_password
```
Für Windows:
```
mysqldump --databases database_name ^
--single-transaction ^
--compress ^
--order-by-primary ^
-u local_user ^
-plocal_password | mysql ^
--host=hostname ^
--port=3306 ^
-u RDS_user_name ^
-pRDS_password
```
**Anmerkung**
Zwischen der Option `-p` und dem eingegebenen Passwort darf kein Leerzeichen vorhanden sein.
Zum Festlegen von Host-Name, Benutzername, Port und Passwort für die Verbindung mit Ihrer Amazon-RDS-DB-Instance verwenden Sie die Optionen `--host`, `--user (-u)`, `--port` und `-p` im Befehl `mysql`. Der Hostname ist der DNS-Name (Domain Name Service) aus dem Endpunkt der Amazon-RDS-DB-Instance, z. B `myinstance.123456789012.us-east-1.rds.amazonaws.com`. Sie finden den Endpunktwert in den Instance-Details in der AWS-Managementkonsole.
1. Legen Sie die Quell-MySQL- oder MariaDB-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 [in der MySQL-Dokumentation](https://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html).
1. Fügen Sie im die IP-Adresse des Servers AWS-Managementkonsole, der die externe Datenbank hostet, der Sicherheitsgruppe Virtual Private Cloud (VPC) für die Amazon RDS-DB-Instance 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*.
Die IP-Adresse kann sich ändern, wenn die folgenden Bedingungen erfüllt sind:
+ Sie verwenden eine öffentliche IP-Adresse für die Kommunikation zwischen der externen Quell-Instance und der DB-Instance.
+ Die externe Quell-Instance wurde gestoppt und neu gestartet.
Wenn diese Bedingungen erfüllt sind, überprüfen Sie die IP-Adresse, bevor Sie sie hinzufügen.
Es könnte sein, dass Sie Ihr lokales Netzwerk so konfigurieren müssen, dass es Verbindungen von der IP-Adresse Ihrer Amazon-RDS-DB-Instance zulässt. Sie tun dies, damit Ihr lokales Netzwerk mit Ihrer externen MySQL- oder MariaDB-Instance kommunizieren kann. Verwenden Sie den Befehl `host`, um die IP-Adresse Ihrer Amazon-RDS-DB-Instance herauszufinden.
```
host db_instance_endpoint
```
Der Hostname ist der DNS-Name aus dem Endpunkt der Amazon-RDS-DB-Instance.
1. Stellen Sie mit einem Client Ihrer Wahl eine Verbindung zur Quell-Instance her und erstellen Sie den für die Replikation zu verwendenden Benutzer. Verwenden Sie dieses Konto ausschließlich für die Replikation und beschränken Sie es auf Ihre Domäne, um die Sicherheit zu erhöhen. 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 für die externe Instance die Sonderrechte `REPLICATION CLIENT` und `REPLICATION SLAVE` für Ihren Replikationsbenutzer. 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'@'mydomain.com';
```
1. Machen Sie die Amazon-RDS-DB-Instance zum Replica. Stellen Sie dazu zunächst als Master-Benutzer eine Verbindung zur Amazon-RDS-DB-Instance her. Identifizieren Sie dann die externe MySQL- oder MariaDB-Datenbank mithilfe des Befehls [mysql.rds\$1set\$1external\$1source (RDS-für-MySQL-Hauptversionen 8.4 und höher)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) oder [mysql.rds\$1set\$1external\$1master (RDS-für-MariaDB- und RDS-für-MySQL-Hauptversionen 8.0 und niedriger)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) als Quell-Instance. Verwenden Sie den Namen und die Position der Protokolldatei, die Sie in Schritt 2 festgelegt haben. Die folgenden Befehle sind Beispiele.
**MySQL 8.4**
```
CALL mysql.rds_set_external_source ('mysourceserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**MariaDB und MySQL 8.0 und 5.7**
```
CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**Anmerkung**
Unter RDS für MySQL können Sie stattdessen die verzögerte Replikation wählen, indem Sie die gespeicherte Prozedur [mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS-für-MySQL-Hauptversionen 8.4 und höher)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source_with_delay) oder [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS-für-MariaDB- und RDS-für-MySQL-Hauptversionen 8.0 und niedriger)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master_with_delay) ausführen. Unter RDS für MySQL besteht ein Grund für die Verwendung einer verzögerten Replikation darin, die Notfallwiederherstellung mit der gespeicherten Prozedur [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) zu aktivieren. Derzeit unterstützt RDS für MariaDB verzögerte Replikation, aber nicht die `mysql.rds_start_replication_until`-Prozedur.
1. Verwenden Sie für die Amazon-RDS-DB-Instance den Befehl [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication), um die Replikation zu starten.
```
CALL mysql.rds_start_replication;
```
# Konfiguration multi-source-replication für Amazon RDS for MySQL
Bei der Multi-Source-Replikation können Sie eine DB-Instance von Amazon RDS für MySQL als Replikat einrichten, das binäre Protokollereignisse aus mehreren Quell-DB-Instances von RDS für MySQL empfängt. Die Multi-Source-Replikation wird für DB-Instances von RDS für MySQL unterstützt, auf denen die folgenden Engine-Versionen ausgeführt werden:
+ Alle MySQL 8.4-Versionen
+ 8.0.35 und höhere Nebenversionen
+ 5.7.44 und höhere Nebenversionen
Informationen zur MySQL-Multi-Source-Replikation finden Sie unter [MySQL-Multi-Source-Replikation](https://dev.mysql.com/doc/refman/8.0/en/replication-multi-source.html) in der MySQL-Dokumentation. Die MySQL-Dokumentation enthält detaillierte Informationen zu dieser Funktion. In diesem Thema wird beschrieben, wie Sie die Multi-Source-Replikationskanäle auf den DB-Instances von RDS für MySQL konfigurieren und verwalten.
## Anwendungsfälle für die Multi-Source-Replikation
Die folgenden Fälle eignen sich gut für die Verwendung der Multi-Source-Replikation in RDS für MySQL:
+ Anwendungen, die mehrere Shards auf separaten DB-Instances mit einem einzigen Shard zusammenführen oder kombinieren müssen.
+ Anwendungen, die Berichte anhand von Daten generieren müssen, die aus mehreren Quellen zusammengefasst wurden.
+ Anforderungen zum Erstellen zusammengefasster langfristiger Backups von Daten, die auf mehreren DB-Instances von RDS für MySQL verteilt sind.
## Voraussetzungen für eine Multi-Source-Replikation
Damit Sie die Multi-Source-Replikation konfigurieren können, müssen die folgenden Voraussetzungen erfüllt sein.
+ Vergewissern Sie sich, dass für jede Quell-DB-Instance von RDS für MySQL automatische Backups aktiviert sind. Durch die Aktivierung automatischer Backups wird die binäre Protokollierung ermöglicht. Informationen zum Aktivieren von automatischen Backups finden Sie unter [Aktivieren von automatisierten Backups](USER_WorkingWithAutomatedBackups.Enabling.md).
+ Um Replikationsfehler zu vermeiden, wird empfohlen, Schreibvorgänge in die Quell-DB-Instances zu blockieren. Legen Sie hierzu den Parameter `read-only` in einer benutzerdefinierten Parametergruppe, die mit der Quell-DB-Instance von RDS für MySQL verbunden ist, auf `ON` fest. Sie können das AWS-Managementkonsole oder das verwenden AWS CLI , um eine neue benutzerdefinierte Parametergruppe zu erstellen oder eine bestehende zu ändern. Weitere Informationen erhalten Sie unter [Erstellen einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Creating.md) und [Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
+ Fügen Sie für die jeweilige Quell-DB-Instance die IP-Adresse der Instance zur Sicherheitsgruppe von Amazon Virtual Private Cloud (VPC) für die Multi-Source-DB-Instance hinzu. Um die IP-Adresse einer Quell-DB-Instance zu identifizieren, können Sie den Befehl `dig RDS Endpoint` ausführen. Führen Sie den Befehl von einer Amazon-EC2-Instance aus, die sich in derselben VPC wie die Ziel-Multi-Source-DB-Instance befindet.
+ Verwenden Sie für die jeweilige Quell-DB-Instance einen Client, um eine Verbindung mit der DB-Instance herzustellen und einen Datenbankbenutzer mit den erforderlichen Berechtigungen für die Replikation zu erstellen, wie im folgenden Beispiel gezeigt.
```
CREATE USER 'repl_user' IDENTIFIED BY 'password';
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user';
```
**Anmerkung**
Ab MySQL 8.4 wurde die Berechtigung `REPLICATION SLAVE` eingestellt und durch `REPLICATION REPLICA` ersetzt. Verwenden Sie für MySQL 8.4 und höhere Versionen stattdessen die folgende Syntax:
```
CREATE USER 'repl_user' IDENTIFIED BY 'password';
GRANT REPLICATION CLIENT, REPLICATION REPLICA ON *.* TO 'repl_user';
```
## Konfigurieren von Multi-Source-Replikationskanälen auf DB-Instances von RDS für MySQL
Die Konfiguration von Multi-Source-Replikationskanälen ähnelt der Konfiguration einer Single-Source-Replikation. Bei der Multi-Source-Replikation aktivieren Sie zunächst die Binärprotokollierung für die Quell-Instance. Importieren Sie anschließend die Daten aus den Quellen in das Multi-Source-Replikat. Starten Sie danach die Replikation von jeder Quelle aus, indem Sie die Binärprotokollkoordinaten oder die automatische GTID-Positionierung verwenden.
Führen Sie die folgenden Schritte aus, um eine DB-Instance von RDS für MySQL als Multi-Source-Replikat von zwei oder mehr DB-Instances von RDS für MySQL zu konfigurieren.
**Topics**
+ [
### Schritt 1: Importieren von Daten aus den Quell-DB-Instances in das Multi-Source-Replikat
](#mysql-multi-source-replication-import)
+ [
### Schritt 2: Starten der Replikation von den Quell-DB-Instances in das Multi-Source-Replikat
](#mysql-multi-source-replication-setting-up-start-replication-other)
### Schritt 1: Importieren von Daten aus den Quell-DB-Instances in das Multi-Source-Replikat
Führen Sie die folgenden Schritte für jede Quell-DB-Instance aus.
Bevor Sie die Daten einer Quelle in das Multi-Source-Replikat importieren, ermitteln Sie die aktuelle Binärprotokolldatei und Position, indem Sie den Befehl `SHOW MASTER STATUS` ausführen. Notieren Sie sich diese Details zwecks Verwendung im nächsten Schritt. In dieser Beispielausgabe ist die Datei `mysql-bin-changelog.000031` und die Position `107`.
**Anmerkung**
Ab MySQL 8.4 wurde der Befehl `SHOW MASTER STATUS` nicht mehr verwendet und durch `SHOW BINARY LOG STATUS` ersetzt. Verwenden Sie für MySQL 8.4 und höhere Versionen stattdessen `SHOW BINARY LOG STATUS`.
```
File Position
-----------------------------------
mysql-bin-changelog.000031 107
-----------------------------------
```
Kopieren Sie nun die Datenbank von der Quell-DB-Instance mithilfe von `mysqldump` in das Multi-Source-Replikat, wie im folgenden Beispiel aufgeführt.
```
mysqldump --databases database_name \
--single-transaction \
--compress \
--order-by-primary \
-u RDS_user_name \
-p RDS_password \
--host=RDS Endpoint | mysql \
--host=RDS Endpoint \
--port=3306 \
-u RDS_user_name \
-p RDS_password
```
Nach dem Kopieren der Datenbank können Sie den schreibgeschützten Parameter in der Quell-DB-Instance auf `OFF` festlegen.
### Schritt 2: Starten der Replikation von den Quell-DB-Instances in das Multi-Source-Replikat
Verwenden Sie für die jeweilige Quell-DB-Instance die Anmeldeinformationen des Administratorbenutzers, um eine Verbindung mit der Instance herzustellen, und führen Sie die folgenden zwei gespeicherten Prozeduren aus. Mit diesen gespeicherten Prozeduren wird die Replikation auf einem Kanal konfiguriert und dann gestartet. In diesem Beispiel wird der Name und die Position der Binärprotokolldatei aus der Beispielausgabe im vorherigen Schritt verwendet.
```
CALL mysql.rds_set_external_source_for_channel('mysourcehost.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1, 'channel_1');
CALL mysql.rds_start_replication_for_channel('channel_1');
```
Weitere Informationen zur Verwendung dieser und anderer gespeicherten Prozeduren zum Einrichten und Verwalten der Replikationskanäle finden Sie unter [Verwalten der Multi-Source-Replikation](mysql-stored-proc-multi-source-replication.md).
## Verwenden von Filtern bei der Multi-Source-Replikation
Sie können Replikationsfilter verwenden, um festzulegen, welche Datenbanken und Tabellen mit einem Lesereplikat repliziert werden. Replikationsfilter können Datenbanken und Tabellen in die Replikation einbeziehen oder sie von der Replikation ausschließen. Weitere Informationen zu Replikationsfiltern finden Sie unter [Konfigurieren von Replikationsfiltern mit MySQL](USER_MySQL.Replication.ReadReplicas.ReplicationFilters.md).
Bei der Multi-Source-Replikation können Sie Replikationsfilter global oder auf Kanalebene konfigurieren. Die Filterung auf Kanalebene ist nur für unterstützte DB-Instances verfügbar, auf denen Version 8.0 oder Version 8.4 ausgeführt wird. In den folgenden Beispielen ist die Konfiguration von Filtern global oder auf Kanalebene angegeben.
Beachten Sie die folgenden Anforderungen und das folgende Verhalten bei der Filterung von Multi-Source-Replikationen:
+ Die Kanalnamen müssen in invertierte Anführungszeichen (``) gesetzt werden.
+ Wenn Sie die Replikationsfilter in der Parametergruppe ändern, werden die Multi-Source-Replikate von `sql_thread` für alle Kanäle mit den Aktualisierungen neu gestartet, um die Änderungen dynamisch zu übernehmen. Wenn eine Aktualisierung einen globalen Filter einbezieht, werden alle Replikationskanäle im Ausführungszustand neu gestartet.
+ Alle globalen Filter werden vor jeglichen kanalspezifischen Filtern angewendet.
+ Wenn ein Filter global und auf Kanalebene angewendet wird, wird nur der Filter auf Kanalebene übernommen. Wenn die Filter beispielsweise `replicate_ignore_db="db1,`channel_22`:db2"` lauten, wird der auf `db1` festgelegte Parameter `replicate_ignore_db` auf alle Kanäle angewendet, mit Ausnahme von `channel_22`, und nur `channel_22` ignoriert Änderungen von `db2`.
Beispiel 1: Festlegen eines globalen Filters
Im folgenden Beispiel wird die Datenbank `temp_data` in jedem Kanal von der Replikation ausgeschlossen.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-ignore-db,ParameterValue='temp_data',ApplyMethod=immediate"
```
Beispiel 2: Festlegen eines Filters auf Kanalebene
Im folgenden Beispiel sind Änderungen der Datenbank `sample22` nur im Kanal `channel_22` enthalten. Ebenso sind Änderungen der Datenbank `sample99` nur im Kanal `channel_99` enthalten.
Für Linux, macOS oder Unix:
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-do-db,ParameterValue='\`channel_22\`:sample22,\`channel_99\`:sample99',ApplyMethod=immediate"
```
## Überwachen von Multi-Source-Replikationskanälen
Sie können einzelne Kanäle in einem Multi-Source-Replikat mithilfe der folgenden Methoden überwachen:
+ Um den Status aller Kanäle oder eines bestimmten Kanals zu überwachen, stellen Sie eine Verbindung mit dem Multi-Source-Replikat her und führen Sie den Befehl `SHOW REPLICA STATUS` oder `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'` aus. Weitere Informationen finden Sie unter [Überprüfen des Replikationsstatus](https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html) in der MySQL-Dokumentation.
+ Verwenden Sie die RDS-Ereignisbenachrichtigung, um eine Benachrichtigung zu erhalten, wenn ein Replikationskanal gestartet, gestoppt oder entfernt wird. Weitere Informationen finden Sie unter [Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen](USER_Events.md).
+ Um die Verzögerung für einen bestimmten Kanal zu überwachen, überprüfen Sie dessen Metrik `ReplicationChannelLag`. Datenpunkte für diese Metrik mit einem Zeitraum von 60 Sekunden (1 Minute) stehen 15 Tage lang zur Verfügung. Zum Ermitteln der Replikationskanalverzögerung für einen Kanal verwenden Sie die Instance-ID und den Namen des Replikationskanals. Um eine Benachrichtigung zu erhalten, wenn diese Verzögerung einen bestimmten Schwellenwert überschreitet, können Sie einen CloudWatch Alarm einrichten. Weitere Informationen finden Sie unter [Überwachung von Amazon RDS mit Amazon CloudWatch](monitoring-cloudwatch.md).
## Überlegungen und bewährte Methoden bei der Multi-Source-Replikation
Bevor Sie die Multi-Source-Replikation von RDS für MySQL verwenden, machen Sie sich mit den folgenden Faktoren und bewährten Methoden vertraut:
+ Vergewissern Sie sich, dass eine als Multi-Source-Replikat konfigurierte DB-Instance über ausreichende Ressourcen wie Durchsatz, Arbeitsspeicher, CPU und IOPS verfügt, um den Workload mehrerer Quell-Instances zu verarbeiten.
+ Überwachen Sie die Ressourcennutzung für das Multi-Source-Replikat regelmäßig und passen Sie die Speicher- oder Instance-Konfiguration an, um den Workload zu verarbeiten, ohne die Ressourcen zu belasten.
+ Sie können die Multi-Thread-Replikation für ein Multi-Source-Replikat konfigurieren, indem Sie die Systemvariable `replica_parallel_workers` auf einen Wert größer als `0` festlegen. In diesem Fall entspricht die Anzahl der Threads, die jedem Kanal zugewiesen sind, dem Wert dieser Variablen zuzüglich eines Koordinator-Threads zur Verwaltung der Anwender-Threads.
+ Konfigurieren Sie die Replikationsfilter entsprechend, um Konflikte zu vermeiden. Um eine gesamte Datenbank in eine andere Datenbank eines Replikats zu replizieren, können Sie die Option `--replicate-rewrite-db` verwenden. Sie können beispielsweise alle Tabellen von Datenbank A in Datenbank B einer Replikat-Instance replizieren. Diese Vorgehensweise kann hilfreich sein, wenn alle Quell-Instances dieselbe Schema-Benennungskonvention verwenden. Informationen zur Option `--replicate-rewrite-db` finden Sie unter [Optionen und Variablen für Replikatserver](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html) in der MySQL-Dokumentation.
+ Um Replikationsfehler zu vermeiden, sollten Sie nicht in das Replikat schreiben. Es wird empfohlen, den Parameter `read_only` in Multi-Source-Replikaten zu aktivieren, um Schreibvorgänge zu blockieren. Auf diese Weise können Replikationsprobleme vermieden werden, die durch widersprüchliche Schreibvorgänge verursacht werden.
+ Um die Leistung von Lesevorgängen wie Sortierungen und Verknüpfungen mit hoher Auslastung zu verbessern, die auf dem Multi-Source-Replikat ausgeführt werden, erwägen Sie die Verwendung von RDS-optimierten Lesevorgängen. Diese Funktion kann bei Abfragen hilfreich sein, die von großen temporären Tabellen oder Sortierdateien abhängen. Weitere Informationen finden Sie unter [Verbesserung der Abfrageleistung für RDS für MySQL mit Amazon RDS Optimized Reads](rds-optimized-reads.md).
+ Um die Replikationsverzögerung zu minimieren und die Leistung eines Multi-Source-Replikats zu verbessern, erwägen Sie die Aktivierung optimierter Schreibvorgänge. Weitere Informationen finden Sie unter [Verbesserung der Schreibleistung mit RDS-optimierten Schreibvorgängen für MySQL](rds-optimized-writes.md).
+ Führen Sie Verwaltungsvorgänge (z. B. Konfigurationsänderungen) jeweils auf einem Kanal durch und vermeiden Sie es, an mehreren Kanälen von mehreren Verbindungen aus Änderungen vorzunehmen. Diese Vorgehensweisen können zu Konflikten bei Replikationsvorgängen führen. Beispielsweise kann die gleichzeitige Ausführung der Prozeduren `rds_skip_repl_error_for_channel` und `rds_start_replication_for_channel` von mehreren Verbindungen aus dazu führen, dass Ereignisse auf einem anderen Kanal als vorgesehen übersprungen werden.
+ Sie können Backups auf einer Multi-Source-Replikations-Instance aktivieren und Daten dieser Instance in einen Amazon-S3-Bucket exportieren, um sie für langfristige Zwecke zu speichern. Es ist jedoch wichtig, auch Backups mit entsprechender Aufbewahrungsdauer für die einzelnen Quell-Instances zu konfigurieren. Informationen zum Exportieren von Snapshot-Daten nach Amazon S3 finden Sie unter [Exportieren von DB-Snapshot-Daten nach Amazon S3 für Amazon RDS](USER_ExportSnapshot.md).
+ Um den Workload des Lesevorgangs auf ein Multi-Source-Replikat zu verteilen, können Sie Lesereplikate eines Multi-Source-Replikats erstellen. Sie können diese Read Replicas AWS-Regionen je nach den Anforderungen Ihrer Anwendung an unterschiedlichen Orten lokalisieren. Weitere Informationen über Lesereplikate finden Sie unter [Arbeiten mit MySQL-Lesereplikaten](USER_MySQL.Replication.ReadReplicas.md).
## Einschränkungen für die Multi-Source-Replikation bei RDS für MySQL
Folgende Einschränkungen gelten für die Multi-Source-Replikation bei RDS für MySQL:
+ Derzeit unterstützt RDS für MySQL die Konfiguration von maximal 15 Kanälen für ein Multi-Source-Replikat.
+ Eine Lesereplikat-Instance kann nicht als Multi-Source-Replikat konfiguriert werden.
+ Um die Multi-Source-Replikation bei RDS für MySQL zu konfigurieren, auf dem Engine-Version 5.7 ausgeführt wird, muss das Leistungsschema auf der Replikat-Instance aktiviert sein. Die Aktivierung des Leistungsschemas ist bei RDS für MySQL mit Engine-Version 8.0 oder 8.4 optional.
+ Bei RDS für MySQL mit Engine-Version 5.7 gelten Replikationsfilter für alle Replikationskanäle. Bei RDS für MySQL mit Engine-Version 8.0 oder 8.4 können Sie Filter konfigurieren, die für alle Replikationskanäle oder für einzelne Kanäle gelten.
+ Durch das Wiederherstellen eines RDS-Snapshots oder das Durchführen eines Point-in-time-Restore (PITR) werden keine Replikatkanalkonfigurationen mit mehreren Quellen wiederhergestellt.
+ Wenn Sie ein Lesereplikat eines Multi-Source-Replikats erstellen, werden nur Daten der Multi-Source-Instance repliziert. Kanalkonfigurationen werden nicht wiederhergestellt.
+ MySQL unterstützt nicht die Einrichtung einer unterschiedlichen Anzahl paralleler Worker des jeweiligen Kanals. Basierend auf dem Wert `replica_parallel_workers` erhält der Kanal die gleiche Anzahl paralleler Worker.
Die folgenden zusätzlichen Einschränkungen gelten, wenn das Multi-Source-Replikationsziel ein Multi-AZ-DB-Cluster ist:
+ Ein Kanal muss für eine Quell-Instance von RDS für MySQL konfiguriert werden, bevor Schreibvorgänge auf diese Instance ausgeführt werden.
+ Für die jeweilige Quell-Instance von RDS für MySQL muss die GTID-basierte Replikation aktiviert sein.
+ Durch ein Failover-Ereignis auf dem DB-Cluster wird die Konfiguration der Multi-Source-Replikation entfernt. Um diese Konfiguration wiederherzustellen, müssen die Konfigurationsschritte wiederholt werden.