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. # Replikation mit Amazon Aurora My SQL Die Aurora-MySQL-Replikationsfunktionen sind für die hohe Verfügbarkeit und Leistung Ihres Clusters entscheidend. Ein Aurora erleichtert das Erstellen und Skalieren von Clustern mit bis zu 15 Aurora-Replikaten. Alle Replicas arbeiten mit denselben zugrunde liegenden Daten. Wenn einige Datenbank-Instances offline gehen, bleiben andere verfügbar, um die Verarbeitung von Abfragen fortzusetzen oder bei Bedarf als Writer zu übernehmen. Aurora verteilt Ihre schreibgeschützten Verbindungen automatisch auf mehrere Datenbank-Instances und hilft einem Aurora-Cluster, abfrageintensive Workloads zu unterstützen. In den folgenden Themen finden Sie Informationen darüber, wie die Aurora-MySQL-Replikation funktioniert, und wie Sie die Replikationseinstellungen für beste Verfügbarkeit und Leistung anpassen. **Topics** + [Verwendung von Aurora-Replicas](#AuroraMySQL.Replication.Replicas) + [Replikationsoptionen für Amazon Aurora MySQL](#AuroraMySQL.Replication.Options) + [Performance-Überlegungen zur Amazon Aurora MySQL-Replikation](#AuroraMySQL.Replication.Performance) + [Konfigurieren von Replikationsfiltern mit Aurora MySQL](AuroraMySQL.Replication.Filters.md) + [Überwachung der Amazon Aurora MySQL-Replikation](#AuroraMySQL.Replication.Monitoring) + [Replizieren von Amazon-Aurora-MySQL-DB-Clustern über AWS-Regionen hinweg](AuroraMySQL.Replication.CrossRegion.md) + [Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)](AuroraMySQL.Replication.MySQL.md) + [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md) ## Verwendung von Aurora-Replicas Aurora-Replicas sind unabhängige Endpunkte in einem Aurora-DB-Cluster, die die beste Methode für das Skalieren von Leseoperationen und Erhöhen der Verfügbarkeit darstellen. Es können bis zu 15 Aurora-Replikate über die Availability Zones verteilt werden, über die sich ein DB-Cluster innerhalb einer AWS-Region erstreckt. Obwohl das DB-Cluster-Volume aus mehreren Kopien der Daten in Ihrem DB-Cluster besteht, werden die Daten im Cluster-Volume als ein zusammengefasstes einzelnes logisches Volume der primären Instance und den Aurora Replicas im DB-Cluster dargestellt. Weitere Informationen über Aurora-Replicas finden Sie unter [Aurora-Replikate](Aurora.Replication.md#Aurora.Replication.Replicas). Aurora Replicas funktionieren für das Skalieren von Lesevorgängen, da sie in Ihrem Cluster-Volume vollständig für Lesevorgänge bereit stehen. Schreibvorgänge werden von der primären Instance verwaltet. Da das Cluster-Volume zwischen allen Instances in Ihrem Aurora MySQL-DB-Cluster geteilt wird, ist kein zusätzlicher Arbeitsaufwand erforderlich, um eine Kopie Ihrer Daten für jedes Aurora-Replica zu erstellen. Im Gegensatz dazu müssen MySQL-Read Replicas in einem einzelnen Thread alle Schreiboperationen aus der Quell-DB-Instance in ihrem lokalen Datenspeicher wiedergeben. Dies kann sich auf die Leistungsfähigkeit der unterstützten Lesevorgänge im Datenverkehr mit großem Volumen in Ihren MySQL-Lesereplikaten auswirken. Mit Aurora MySQL wird beim Löschen eines Aurora-Replica der Instance-Endpunkt sofort entfernt und das Aurora-Replica vom Leser-Endpunkt entfernt. Wenn Anweisungen vorhanden sind, die auf dem Aurora-Replica ausgeführt werden, das gerade gelöscht wird, besteht eine Übergangsfrist von drei Minuten. Vorhandene Anweisungen können während der Nachfrist geordnet beendet werden. Nach Ablauf der Nachfrist wird das Aurora-Replikat geschlossen und gelöscht. **Wichtig** Aurora-Replicas für Aurora MySQL verwenden immer die standardmäßige Transaktionsisolationsebene `REPEATABLE READ` für Vorgänge in InnoDB-Tabellen. Sie können den Befehl `SET TRANSACTION ISOLATION LEVEL` verwenden, um die Transaktionsebene nur für die primäre Instance eines Aurora MySQL-DB-Clusters zu ändern. Diese Beschränkung vermeidet Sperren auf Benutzerebene in Aurora-Replicas und ermöglicht eine Skalierung der Aurora-Replicas, um tausende aktive Benutzerverbindungen bei gleichzeitig minimaler Replica-Verzögerung zu ermöglichen. **Anmerkung** Durch DDL-Anweisungen, die auf der primären Instance ausgeführt werden, können Datenbankverbindungen auf den verknüpften Aurora-Replikaten unterbrochen werden. Wenn eine Aurora-Replica-Verbindung aktiv ein Datenbankobjekt (z. B. eine Tabelle) verwendet und dieses Objekt auf der primären Instance mithilfe einer DDL-Anweisung geändert wird, führt das zu einer Unterbrechung der Aurora-Replica-Verbindung. **Anmerkung** Die Region China (Ningxia) unterstützt keine regionsübergreifenden Lesereplikate. ## Replikationsoptionen für Amazon Aurora MySQL Sie können eine Replikation zwischen allen folgenden Optionen einrichten: + Zwei Aurora-MySQL-DB-Cluster in verschiedenen AWS-Regionen, indem Sie ein regionsübergreifendes Lesereplikat eines Aurora-MySQL-DB-Clusters erstellen. Weitere Informationen finden Sie unter [Replizieren von Amazon-Aurora-MySQL-DB-Clustern über AWS-Regionen hinweg](AuroraMySQL.Replication.CrossRegion.md). + Zwei Aurora-MySQL-DB-Cluster in der gleichen AWS-Region, indem Sie mit dem MySQL-Binärprotokoll (binlog) eine Replikation einrichten. Weitere Informationen finden Sie unter [Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)](AuroraMySQL.Replication.MySQL.md). + Eine RDS for MySQL-DB-Instance als Quelle und ein Aurora MySQL-DB-Cluster, indem Sie ein Aurora-Read Replica einer RDS for MySQL-DB-Instance erstellen. Sie können diesen Ansatz verwenden, um bestehende und laufende Datenänderungen in Aurora MySQL während der Migration zu Aurora zu bringen. Weitere Informationen finden Sie unter [Migrieren von Daten aus einer RDS-für-MySQL-DB-Instance zu einem Amazon-Aurora-MySQL-DB-Cluster mittels einer Aurora Read Replica (Lesereplikat)](AuroraMySQL.Migrating.RDSMySQL.Replica.md). Sie können diesen Ansatz auch verwenden, um die Skalierbarkeit von Leseabfragen für Ihre Daten zu erhöhen. Sie tun dies, indem Sie die Daten mit einer oder mehreren DB-Instances in einem schreibgeschützten Aurora MySQL-Cluster abfragen. Weitere Informationen finden Sie unter [Skalieren von Lesevorgängen für Ihre MySQL-Datenbank mit Amazon Aurora](AuroraMySQL.Replication.ReadScaling.md). + Ein Aurora-MySQL-DB-Cluster in einer AWS-Region und bis zu fünf schreibgeschützte Aurora-MySQL-DB-Cluster in verschiedenen Regionen durch Erstellen einer globalen Aurora-Datenbank. Sie können eine Aurora globale Datenbank verwenden, um Anwendungen mit einem weltweiten Fußabdruck zu unterstützen. Der primäre Aurora MySQL-DB-Cluster verfügt über eine Writer-Instance und bis zu 15 Aurora Replikate. Die schreibgeschützten sekundären Aurora MySQL-DB-Cluster können jeweils aus bis zu 16 Aurora Replikaten bestehen. Weitere Informationen finden Sie unter [Verwenden von Amazon Aurora Global Database](aurora-global-database.md). **Anmerkung** Durch einen Neustart der primären Instance eines Amazon Aurora-DB-Clusters werden auch automatisch die Aurora-Replicas für diesen DB-Cluster neu gestartet, um einen Einstiegspunkt wiederherzustellen, der die Lese-/Schreibkonsistenz innerhalb des DB-Clusters hinweg gewährleistet. ## Performance-Überlegungen zur Amazon Aurora MySQL-Replikation Die folgenden Funktionen helfen Ihnen bei der Optimierung der Leistung der Aurora MySQL-Replikation. Die Funktion Replica-Protokollkompression reduziert automatisch die Netzwerkbandbreite für Replikationsbenachrichtigungen. Weil jede Benachrichtigung an alle Aurora-Replicas gesendet wird, sind die Vorteile bei umfangreicheren Clustern größer. Diese Funktion beinhaltet einen gewissen CPU-Overhead im Schreiber-Knoten, um die Kompression durchzuführen. In Aurora MySQL Version 2 und Version 3 ist sie immer aktiviert. Die Funktion Binärprotokollfilterung reduziert automatisch die Netzwerkbandbreite für Replikationsbenachrichtigungen. Da Aurora-Replicas die in den Replikationsbenachrichtigungen enthaltene Binärprotokollinformation nicht verwenden, sind diese Daten in den an diese Knoten gesendeten Benachrichtigungen nicht enthalten. In Aurora MySQL Version 2 steuern Sie diese Funktion durch eine Änderung des `aurora_enable_repl_bin_log_filtering`-Parameters. Dieser Parameter ist standardmäßig aktiviert. Da diese Optimierung transparent sein soll, können Sie diese Einstellung nur während der Diagnose oder Fehlersuche bei Problemen im Zusammenhang mit der Replikation deaktivieren. Beispielsweise können Sie so das Verhalten eines älteren Aurora MySQL-Clusters anzupassen, bei dem diese Funktion nicht verfügbar war. Die Binlog-Filterung ist in Aurora MySQL Version 3 immer aktiviert. # Konfigurieren von Replikationsfiltern mit Aurora 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 einen DB-Cluster mit Read Replicas in verschiedenen AWS-Regionen, um unterschiedliche Datenbanken oder Tabellen in verschiedenen AWS-Regionen zu replizieren. + Um anzugeben, welche Datenbanken und Tabellen mit einem Aurora-MySQL-DB-Cluster repliziert werden, der als Replikat in einer eingehenden Replikationstopologie konfiguriert ist. Weitere Informationen zu dieser Konfiguration finden Sie unter [Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)](AuroraMySQL.Replication.MySQL.md). **Topics** + [Einrichten der Parameter der Replikationsfilter für Aurora MySQL](#AuroraMySQL.Replication.Filters.Configuring) + [Einschränkungen der Replikationsfilter für Aurora MySQL](#AuroraMySQL.Replication.Filters.Limitations) + [Beispiele für Replikationsfilter bei Aurora MySQL](#AuroraMySQL.Replication.Filters.Examples) + [Anzeigen der Replikationsfilter für ein Lesereplikat](#AuroraMySQL.Replication.Filters.Viewing) ## Einrichten der Parameter der Replikationsfilter für Aurora MySQL Zur Konfiguration von Replikationsfiltern legen Sie die folgenden Parameter fest: + `binlog-do-db` – Repliziert Änderungen in die angegebenen Binärprotokolle. Wenn Sie diesen Parameter für einen Binlog-Quell-Cluster festlegen, werden nur die im Parameter angegebenen Binärprotokolle repliziert. + `binlog-ignore-db` – Repliziert keine Änderungen in die angegebenen Binärprotokolle. Wenn der Parameter `binlog-do-db` für einen Binlog-Quell-Cluster festgelegt ist, wird dieser Parameter nicht ausgewertet. + `replicate-do-db` – Repliziert Änderungen der angegebenen Datenbanken. Wenn Sie diesen Parameter für einen Binlog-Replikat-Cluster 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 einen Binlog-Replikat-Cluster 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 Binlog-Replikat-Cluster einbeziehen. + `replicate-ignore-table` – Repliziert keine Änderungen der angegebenen Tabellen. Wenn der Parameter `replicate-do-table` für einen Binlog-Replikat-Cluster 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 Binlog-Replikat-Cluster 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 der Parameter `replicate-do-table` oder `replicate-wild-do-table` für einen Binlog-Replikat-Cluster festgelegt ist, 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 Binlog-Cluster 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 Aurora MySQL 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 für Aurora MySQL Folgende Einschränkungen gelten für Replikationsfilter bei Aurora MySQL: + Replikationsfilter werden nur für Aurora MySQL Version 3 unterstützt. + Jeder Filterparameter für die Replikation hat ein Limit von 2 000 Zeichen. + Kommas werden in Replikationsfiltern 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 Aurora MySQL Um die Replikationsfilter für ein Lesereplikat zu konfigurieren, ändern Sie die Parameter der Replikationsfilter in der DB-Cluster-Parametergruppe, die dem Lesereplikat zugeordnet ist. **Anmerkung** Eine Standard-DB-Cluster-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-Cluster-Parametergruppen finden Sie unter [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.md). Sie können Parameter in einer DB-Cluster-Parametergruppe mithilfe der AWS-Managementkonsole-, AWS CLI- oder der RDS-API festlegen. Weitere Informationen zum Festlegen von Parametern finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md). Wenn Sie Parameter in einer Parametergruppe festlegen, verwenden alle DB-Cluster, die der Parametergruppe zugeordnet sind, diese Parametereinstellungen. Wenn Sie Parameter der Replikationsfilter in einer Parametergruppe festlegen, stellen Sie sicher, dass die Parametergruppe nur Replica-Clustern 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-ams) + [Including tables in replication](#rep-filter-in-tables-ams) + [Including tables in replication with wildcard characters](#rep-filter-in-tables-wildcards-ams) + [Excluding databases from replication](#rep-filter-ex-dbs-ams) + [Excluding tables from replication](#rep-filter-ex-tables-ams) + [Excluding tables from replication using wildcard characters](#rep-filter-ex-tables-wildcards-ams) **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-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate" ``` Für Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-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-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate" ``` Für Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-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-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate" ``` Für Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-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-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate" ``` Für Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-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-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate" ``` Für Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-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-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate" ``` Für Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-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 Aurora](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: + `Binlog_Do_DB` + `Binlog_Ignore_DB` + `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. ## Überwachung der Amazon Aurora MySQL-Replikation Skalieren von Lesevorgängen und hohe Verfügbarkeit hängen von der minimalen Verzögerungszeit ab. Sie können überwachen, wie stark ein Aurora-Replica gegenüber der primären Instance Ihrer Aurora MySQL-DB-Cluster verzögert ist, indem Sie die `AuroraReplicaLag`-Metrik von Amazon CloudWatch überwachen. Die `AuroraReplicaLag`-Metrik wird in jedem Aurora-Replikat aufgezeichnet. Die primäre DB-Instance zeichnet auch die Amazon CloudWatch-Metriken `AuroraReplicaLagMaximum` und `AuroraReplicaLagMinimum` auf. Die `AuroraReplicaLagMaximum`-Metrik zeichnet die maximale Verzögerung zwischen der primären DB-Instance und jedem Aurora-Replikat im DB-Cluster auf. Die `AuroraReplicaLagMinimum`-Metrik zeichnet die minimale Verzögerung zwischen der primären DB-Instance und jedem Aurora-Replikat im DB-Cluster auf. Wenn Sie den aktuellen Wert für die Aurora-Replica-Verzögerung benötigen, können Sie die `AuroraReplicaLag`-Metrik in Amazon CloudWatch überprüfen. Die Aurora-Replica-Verzögerung wird auch für jedes Aurora-Replikat Ihres DB-Clusters von Aurora MySQL in der `information_schema.replica_host_status`-Tabelle aufgezeichnet. Weitere Informationen zu dieser Tabelle finden Sie unter [information\$1schema.replica\$1host\$1status](AuroraMySQL.Reference.ISTables.md#AuroraMySQL.Reference.ISTables.replica_host_status). Weitere Informationen über die Überwachung von RDS-Instances und CloudWatch-Metriken finden Sie unter [Überwachung von Metriken in einem Amazon-Aurora-Cluster](MonitoringAurora.md). # Replizieren von Amazon-Aurora-MySQL-DB-Clustern über AWS-Regionen hinweg Sie können einen Amazon-Aurora-MySQL-DB-Cluster als Lesereplikat in einer anderen AWS-Region als der Ihres Quell-DB-Clusters erstellen. Durch diesen Ansatz können Sie das Potenzial von Notfallwiederherstellungen steigern, Lesevorgänge in einer Ihren Nutzern näher liegenden AWS-Region skalieren und einfacher zwischen einer AWS-Region und anderen Regionen migrieren. Sie können Lesereplikate sowohl von verschlüsselten als auch von unverschlüsselten DB-Clustern erstellen. Das Lesereplikat muss verschlüsselt sein, wenn der Quell-DB-Cluster verschlüsselt ist. Für jeden Quell-DB-Cluster können Sie über höchstens fünf regionsübergreifende DB-Cluster-Lesereplikate verfügen. **Anmerkung** Als Alternative zu regionsübergreifenden Lesereplikaten können Sie Lesevorgänge mit minimaler Verzögerung skalieren, indem Sie eine globale Aurora-Datenbank verwenden. Eine globale Aurora-Datenbank hat einen primären Aurora-DB-Cluster in einer AWS-Region und bis zu 10 sekundäre schreibgeschützte DB-Cluster in verschiedenen Regionen. Jeder sekundäre DB-Cluster kann bis zu 16 (statt 15) Aurora-Replikate enthalten. Die Replikation vom primären DB-Cluster zu allen sekundären wird von der Aurora-Speicherschicht und nicht von der Datenbank-Engine durchgeführt, so dass die Verzögerung für die Replikation von Änderungen in der Regel weniger als 1 Sekunde beträgt. Wenn Sie die Datenbank-Engine aus dem Replikationsprozess heraushalten, verarbeitet die Datenbank-Engine nur Workloads. Dies bedeutet auch, dass Sie die Aurora-MySQL-Binärprotokoll-Replikation (Binary Logging) nicht konfigurieren oder verwalten müssen. Weitere Informationen hierzu finden Sie unter [Verwenden von Amazon Aurora Global Database](aurora-global-database.md). Wenn Sie eine Aurora-MySQL-DB-Cluster-Read-Replica in einer anderen AWS-Region erstellen, sollten Sie Folgendes beachten: + Sowohl Ihr Quell-DB-Cluster als auch Ihr regionsübergreifender Lesereplikat-DB-Cluster kann bis zu 15 Aurora-Replikate zusammen mit der primären Instance im DB-Cluster haben. Dank dieser Funktionalität können Lesevorgänge sowohl für die Quell-AWS-Region als auch für die Ziel-AWS-Region der Replikation skaliert werden. + In einem regionsübergreifenden Szenario besteht eine höhere Verzögerung zwischen dem Quell-DB-Cluster und der Read Replica aufgrund der längeren Netzwerkkanäle zwischen den AWS-Regionen. + Für Daten, die für eine regionsübergreifende Replikation weitergeleitet werden, fallen Amazon-RDS-Datenübertragungskosten an. Die folgenden regionsübergreifenden Replikationsaktionen generieren Gebühren für die übermittelten Daten aus der Quell-AWS-Region: + Wenn Sie das Lesereplikat erstellen, erstellt Amazon RDS einen Snapshot des Quell-Clusters und leitet den Snapshot an die AWS-Region weiter, die das Lesereplikat enthält. + Für jede in den Quell-Datenbanken durchgeführte Datenänderung übermittelt Amazon RDS Daten aus der Quellregion an die AWS-Region, die das Lesereplikat enthält. Weitere Informationen zu den Kosten von Amazon-RDS-Datenübertragungen finden Sie unter [Amazon Aurora – Preise](https://aws.amazon.com/rds/aurora/pricing/). + Sie können mehrere gleichzeitige Erstellungs- oder Löschaktionen für Lesereplikate ausführen, die auf den gleichen Quell-DB-Cluster verweisen. Sie müssen jedoch das Limit von höchstens fünf Lesereplikaten für jeden Quell-DB-Cluster einhalten. + Damit die Replikation effektiv durchgeführt werden kann, sollte jedes Lesereplikat über dieselbe Menge an Ressourcen für Datenverarbeitung und Speicher wie der Quell-DB-Cluster verfügen. Wenn Sie den Quell-DB-Cluster skalieren, sollten Sie auch die Lesereplikate skalieren. **Topics** + [Bevor Sie beginnen](#AuroraMySQL.Replication.CrossRegion.Prerequisites) + [Erstellen eines regionsübergreifenden Lesereplikat-DB-Clusters für Aurora MySQL](AuroraMySQL.Replication.CrossRegion.Creating.md) + [Hochstufen eines Lesereplikats zu einem DB-Cluster für Aurora MySQL](AuroraMySQL.Replication.CrossRegion.Promote.md) + [Fehlerbehebung bei regionsübergreifenden Replikaten für Amazon Aurora MySQL](AuroraMySQL.Replication.CrossRegion.Troubleshooting.md) ## Bevor Sie beginnen Bevor Sie einen Aurora-MySQL-DB-Cluster erstellen können, der ein regionsübergreifendes Lesereplikat darstellt, müssen Sie die Binärprotokollierung für Ihren Quell-Aurora-MySQL-DB-Cluster aktivieren. Die regionsübergreifende Replikation für Aurora MySQL verwendet die MySQL-Binärreplikation, um Änderungen im regionsübergreifenden Lesereplikat-DB-Cluster wiederzugeben. Aktualisieren Sie den `binlog_format`-Parameter für Ihren Quell-DB-Cluster, um die Binärprotokollierung in einem Aurora-MySQL-DB-Cluster zu aktivieren. Der Parameter `binlog_format` ist ein Parameter auf Cluster-Ebene, der sich in der Cluster-Standardparametergruppe befindet. Wenn der DB-Cluster die Standard-DB-Cluster-Parametergruppe verwendet, müssen Sie eine neue DB-Cluster-Parametergruppe erstellen, um die `binlog_format`-Einstellungen ändern zu können. Wir empfehlen Ihnen, das `binlog_format` auf `MIXED` einzustellen. Jedoch können Sie `binlog_format` auch auf `ROW` oder auf `STATEMENT` einstellen, wenn Sie ein spezifisches Format des Binärprotokolls benötigen. Starten Sie Ihren Aurora-DB-Cluster neu, damit die Änderungen übernommen werden. Weitere Informationen zur Verwendung der binären Protokollierung mit Aurora MySQL finden Sie unter [Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)](AuroraMySQL.Replication.MySQL.md). Weitere Informationen zum Ändern der Aurora MySQL-Konfigurationsparameter finden 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). # Erstellen eines regionsübergreifenden Lesereplikat-DB-Clusters für Aurora MySQL Sie können mithilfe der AWS-Managementkonsole, der AWS Command Line Interface (AWS CLI) oder der Amazon-RDS-API ein regionsübergreifendes Lesereplikat eines Aurora-DB-Clusters erstellen. Sie können regionsübergreifende Lesereplikate sowohl aus verschlüsselten als auch aus unverschlüsselten DB-Clustern erstellen. Wenn Sie mithilfe der AWS-Managementkonsole ein regionsübergreifendes Lesereplikat für Aurora MySQL erstellen, erstellt Amazon RDS einen DB-Cluster in der Ziel-AWS-Region und anschließend automatisch eine DB-Instance als primäre Instance für diesen DB-Cluster. Wenn Sie ein regionsübergreifendes Lesereplikat mithilfe der AWS CLI oder RDS-API erstellen, müssen Sie zuerst den DB-Cluster in der Ziel-AWS-Region erstellen und anschließend warten, bis er aktiviert wird. Sobald es aktiviert ist, erstellen Sie eine DB-Instance, die die primäre Instance für diesen DB-Cluster ist. Die Replikation beginnt, wenn die primäre Instance des Lesereplikat-DB-Clusters verfügbar wird. Verwenden Sie die folgenden Prozeduren, um ein regionsübergreifendes Lesereplikat für einen Aurora MySQL-DB-Cluster zu erstellen. Diese Prozeduren funktionieren für das Erstellen von Lesereplikaten aus verschlüsselten oder unverschlüsselten DB-Clustern. ## Konsole **So erstellen Sie mithilfe der AWS-Managementkonsole einen Aurora-MySQL-DB-Cluster, der ein regionsübergreifendes Lesereplikat ist** 1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Wählen Sie in der rechten oberen Ecke der AWS-Managementkonsole die AWS-Region aus, die Ihr Quell-DB-Cluster hostet. 1. Wählen Sie im Navigationsbereich **Datenbanken** aus. 1. Wählen Sie den DB-Cluster aus, um ein regionsübergreifendes Lesereplikat dafür zu erstellen. 1. Wählen Sie unter **Aktionen** die Option **Regionsübergreifende Read Replica erstellen** aus. 1. Wählen Sie auf der Seite **Regionsübergreifende Read Replica erstellen** die Optionseinstellungen für Ihren regionsübergreifenden Lesereplikat-DB-Cluster aus, wie in der folgenden Tabelle beschrieben. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.Creating.html) 1. Wählen Sie **Create (Erstellen)** aus, um ein regionsübergreifendes Lesereplikat für Aurora zu erstellen. ## AWS CLI **So erstellen Sie mithilfe der CLI einen Aurora MySQL-DB-Cluster, der ein regionsübergreifendes Lesereplikat ist:** 1. Rufen Sie den AWS CLI-Befehl [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) in der AWS-Region auf, in der Sie den Lesereplikat-DB-Cluster erstellen möchten. Fügen Sie die Option `--replication-source-identifier` ein und legen Sie den Amazon-Ressourcennamen (ARN) des Quell-DB-Clusters fest, für den Sie ein Lesereplikat erstellen möchten. Für die regionsübergreifende Replikation, bei der der durch `--replication-source-identifier` identifizierte DB-Cluster verschlüsselt ist, geben Sie die Optionen `--kms-key-id` und `--storage-encrypted` an. **Anmerkung** Sie können eine regionsübergreifende Replikation aus einem unverschlüsselten DB-Cluster zu einem verschlüsselten Lesereplikat einrichten, indem Sie `--storage-encrypted` festlegen und einen Wert für `--kms-key-id` angeben. Sie können die Parameter `--master-username` und `--master-user-password` nicht angeben. Diese Werte werden aus dem Quell-DB-Cluster übernommen. Im folgenden Code-Beispiel wird ein Lesereplikat in der Region us-east-1 aus einem unverschlüsselten DB-Cluster-Snapshot in der Region us-west-2 erstellt. Der Befehl wird in der Region us-east-1 aufgerufen. In diesem Beispiel wird die Option `--manage-master-user-password` zum Generieren des Hauptbenutzerpassworts und zum Verwalten dieses Passworts in Secrets Manager angegeben. Weitere Informationen finden Sie unter [Passwortverwaltung mit , Amazon Aurora und AWS Secrets Manager](rds-secrets-manager.md). Alternativ können Sie die Option `--master-password` verwenden, um das Passwort selbst festzulegen und zu verwalten. Für Linux, macOS oder Unix: ``` aws rds create-db-cluster \ --db-cluster-identifier sample-replica-cluster \ --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.08.0 \ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ``` Für Windows: ``` aws rds create-db-cluster ^ --db-cluster-identifier sample-replica-cluster ^ --engine aurora-mysql ^ --engine-version 8.0.mysql_aurora.3.08.0 ^ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ``` Im folgenden Code-Beispiel wird ein Lesereplikat in der Region us-east-1 aus einem verschlüsselten DB-Cluster-Snapshot in der Region us-west-2 erstellt. Der Befehl wird in der Region us-east-1 aufgerufen. Für Linux, macOS oder Unix: ``` aws rds create-db-cluster \ --db-cluster-identifier sample-replica-cluster \ --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.08.0 \ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster \ --kms-key-id my-us-east-1-key \ --storage-encrypted ``` Für Windows: ``` aws rds create-db-cluster ^ --db-cluster-identifier sample-replica-cluster ^ --engine aurora-mysql ^ --engine-version 8.0.mysql_aurora.3.08.0 ^ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ^ --kms-key-id my-us-east-1-key ^ --storage-encrypted ``` Die Option `--source-region` ist für die regionsübergreifende Replikation zwischen den Region AWS GovCloud (USA-Ost) und AWS GovCloud (USA West) erforderlich, in denen der durch `--replication-source-identifier` identifizierte DB-Cluster verschlüsselt ist. Geben Sie für `--source-region` die AWS-Region des Quell-DB-Clusters an. Wenn `--source-region` nicht festgelegt ist, geben Sie einen `--pre-signed-url`-Wert an. Eine *vorsignierte URL* ist eine URL, die eine mit der Signaturversion 4 signierte Anforderung für den Befehl `create-db-cluster` enthält, der in der Quell-AWS-Region aufgerufen wird. Weitere Informationen über die Option `pre-signed-url` finden Sie unter [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) in der *AWS CLI-Befehlsreferenz*. 1. Überprüfen Sie die Verfügbarkeit des DB-Clusters, indem Sie den AWS CLI-Befehl [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) verwenden, wie im folgenden Beispiel gezeigt. ``` aws rds describe-db-clusters --db-cluster-identifier sample-replica-cluster ``` Wenn der Befehl **`describe-db-clusters`** den Status `available` anzeigt, erstellen Sie die primäre Instance für den DB-Cluster, damit die Replikation gestartet werden kann. Verwenden Sie dazu den AWS CLI-Befehl [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html), wie im folgenden Beispiel gezeigt. Für Linux, macOS oder Unix: ``` aws rds create-db-instance \ --db-cluster-identifier sample-replica-cluster \ --db-instance-class db.r5.large \ --db-instance-identifier sample-replica-instance \ --engine aurora-mysql ``` Für Windows: ``` aws rds create-db-instance ^ --db-cluster-identifier sample-replica-cluster ^ --db-instance-class db.r5.large ^ --db-instance-identifier sample-replica-instance ^ --engine aurora-mysql ``` Wenn die DB-Instance erstellt wurde und verfügbar ist, wird die Replikation gestartet. Sie können feststellen, ob die DB-Instance verfügbar ist, indem Sie den AWS CLI-Befehl [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) aufrufen. ## RDS-API **So erstellen Sie mithilfe der API einen Aurora MySQL-DB-Cluster, der ein regionsübergreifendes Lesereplikat ist:** 1. Rufen Sie die RDS-API-Aktion [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) in der AWS-Region auf, in der Sie einen Read-Replica-DB-Cluster erstellen möchten. Fügen Sie den Parameter `ReplicationSourceIdentifier` ein und legen Sie den Amazon-Ressourcennamen (ARN) des Quell-DB-Clusters fest, für den Sie ein Lesereplikat erstellen möchten. Für die regionsübergreifende Replikation, bei der der durch `ReplicationSourceIdentifier` identifizierte DB-Cluster verschlüsselt ist, geben Sie den Parameter `KmsKeyId` an und legen den Parameter `StorageEncrypted` auf `true` fest. **Anmerkung** Sie können eine regionsübergreifende Replikation aus einem unverschlüsselten DB-Cluster zu einem verschlüsselten Lesereplikat einrichten, indem Sie für `StorageEncrypted` den Wert **true** festlegen und einen Wert für `KmsKeyId` angeben. In diesem Fall müssen Sie nicht festlege `PreSignedUrl`. Sie müssen die Parameter `MasterUsername` und `MasterUserPassword` nicht mit einschließen, da diese Werte aus dem Quell-DB-Cluster bezogen werden. Im folgenden Code-Beispiel wird ein Lesereplikat in der Region us-east-1 aus einem unverschlüsselten DB-Cluster-Snapshot in der Region us-west-2 erstellt. Die Aktion wird in der Region us-east-1 aufgerufen. ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBCluster &ReplicationSourceIdentifier=arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster &DBClusterIdentifier=sample-replica-cluster &Engine=aurora-mysql &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T001547Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=a04c831a0b54b5e4cd236a90dcb9f5fab7185eb3b72b5ebe9a70a4e95790c8b7 ``` Im folgenden Code-Beispiel wird ein Lesereplikat in der Region us-east-1 aus einem verschlüsselten DB-Cluster-Snapshot in der Region us-west-2 erstellt. Die Aktion wird in der Region us-east-1 aufgerufen. ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBCluster &KmsKeyId=my-us-east-1-key &StorageEncrypted=true &PreSignedUrl=https%253A%252F%252Frds.us-west-2.amazonaws.com%252F %253FAction%253DCreateDBCluster %2526DestinationRegion%253Dus-east-1 %2526KmsKeyId%253Dmy-us-east-1-key %2526ReplicationSourceIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-west-2%25253A123456789012%25253Acluster%25253Asample-master-cluster %2526SignatureMethod%253DHmacSHA256 %2526SignatureVersion%253D4 %2526Version%253D2014-10-31 %2526X-Amz-Algorithm%253DAWS4-HMAC-SHA256 %2526X-Amz-Credential%253DAKIADQKE4SARGYLE%252F20161117%252Fus-west-2%252Frds%252Faws4_request %2526X-Amz-Date%253D20161117T215409Z %2526X-Amz-Expires%253D3600 %2526X-Amz-SignedHeaders%253Dcontent-type%253Bhost%253Buser-agent%253Bx-amz-content-sha256%253Bx-amz-date %2526X-Amz-Signature%253D255a0f17b4e717d3b67fad163c3ec26573b882c03a65523522cf890a67fca613 &ReplicationSourceIdentifier=arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster &DBClusterIdentifier=sample-replica-cluster &Engine=aurora-mysql &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T001547Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=a04c831a0b54b5e4cd236a90dcb9f5fab7185eb3b72b5ebe9a70a4e95790c8b7 ``` Geben Sie für die regionsübergreifende Replikation zwischen den Regionen AWS GovCloud (USA-Ost) und AWS GovCloud (USA West), in denen der durch `ReplicationSourceIdentifier` identifizierte DB-Cluster verschlüsselt ist, außerdem den Parameter `PreSignedUrl` an. Die vorsignierte URL muss eine gültige Anforderung für die API-Operation `CreateDBCluster` sein, die in der Quell-AWS-Region mit dem zu replizierenden verschlüsselten DB-Cluster ausgeführt werden kann. Der KMS-Schlüsselbezeichner wird zur Verschlüsselung des Lesereplikats verwendet und muss ein für die Ziel-AWS-Region gültiger KMS-Schlüssel sein. Verwenden Sie stattdessen den AWS CLI-Befehl [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) mit der Option `--source-region`, um eine vorsignierte URL automatisch (und nicht manuell) zu generieren. 1. Überprüfen Sie die Verfügbarkeit des DB-Clusters, indem Sie die RDS-API-Operation [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) verwenden, wie im folgenden Beispiel gezeigt. ``` https://rds.us-east-1.amazonaws.com/ ?Action=DescribeDBClusters &DBClusterIdentifier=sample-replica-cluster &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T002223Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=84c2e4f8fba7c577ac5d820711e34c6e45ffcd35be8a6b7c50f329a74f35f426 ``` Wenn die Ergebnisse von `DescribeDBClusters` den Status `available` anzeigen, erstellen Sie die primäre Instance für den DB-Cluster, damit die Replikation gestartet werden kann. Verwenden Sie dafür die RDS-API-Operation [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html), wie im folgenden Beispiel gezeigt. ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBInstance &DBClusterIdentifier=sample-replica-cluster &DBInstanceClass=db.r5.large &DBInstanceIdentifier=sample-replica-instance &Engine=aurora-mysql &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T003808Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=125fe575959f5bbcebd53f2365f907179757a08b5d7a16a378dfa59387f58cdb ``` Wenn die DB-Instance erstellt wurde und verfügbar ist, wird die Replikation gestartet. Sie können feststellen, ob die DB-Instance verfügbar ist, indem Sie den AWS CLI-Befehl [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) aufrufen. ## Anzeigen von regionsübergreifenden Amazon Aurora MySQL-Replikaten Sie können die regionsübergreifenden Replikationsbeziehungen Ihres Amazon-Aurora-MySQL-DB-Clusters anzeigen, indem Sie den AWS CLI-Befehl [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) oder die RDS-API-Operation [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) aufrufen. In der Antwort sind die DB-Clusterkennungen aller regionsübergreifenden Lesereplikat-DB-Cluster im Feld `ReadReplicaIdentifiers` aufgeführt. Das Element `ReplicationSourceIdentifier` gibt Aufschluss über den ARN des Quell-DB-Clusters, der die Replikationsquelle ist. # Hochstufen eines Lesereplikats zu einem DB-Cluster für Aurora MySQL Sie können ein Aurora MySQL-Lesereplikat zu einem eigenständigen DB-Cluster hochstufen. Wenn Sie ein Aurora MySQL-Lesereplikat hochstufen, werden ihre DB-Instances neu gestartet, bevor sie verfügbar werden. Typischerweise stufen Sie ein Aurora MySQL-Lesereplikat zu einem eigenständigen DB-Cluster als Datenwiederherstellungsschema hoch, wenn der Quell-DB-Cluster ausfällt. Erstellen Sie dazu zuerst ein Lesereplikat und überwachen Sie anschließend den Quell-DB-Cluster auf Fehler. Im Fall eines Ausfalls machen Sie Folgendes: 1. Stufen Sie das Lesereplikat hoch. 1. Leiten Sie den Datenverkehr der Datenbank an den hochgestuften DB-Cluster weiter. 1. Erstellen Sie ein Ersatz-Lesereplikat mit dem hochgestuften DB-Cluster als Quelle. Wenn Sie ein Lesereplikat hochstufen, wird das Lesereplikat zu einem eigenständigen Aurora-DB-Cluster. Das Hochstufen kann einige Minuten oder mehr in Anspruch nehmen, abhängig von der Größe des Lesereplikats. Nachdem Sie das Lesereplikat zu einem neuen DB-Cluster hochgestuft haben, ist es wie bei jedem anderen DB-Cluster. Beispielsweise können Sie daraus Lesereplikate erstellen und zeitpunktbezogene Wiederherstellungsoperationen durchführen. Sie können auch Aurora-Replicas für den DB-Cluster erstellen. Da der hochgestufte DB-Cluster kein Lesereplikat mehr ist, können Sie ihn nicht mehr als Replikationsziel verwenden. Die folgenden Schritte zeigen den allgemeinen Vorgang für das Hochstufen eines Lesereplikats zu einem DB-Cluster: 1. Halten Sie alle Schreibvorgänge von Transaktionen im Lesereplikat-Quell-DB-Cluster an und warten Sie anschließend, bis alle Updates für das Lesereplikat abgeschlossen wurden. Datenbank-Updates werden im Lesereplikat durchgeführt, nachdem Sie im Quell-DB-Cluster aufgetreten sind; diese Replikationsverzögerung kann beträchtlich variieren. Verwenden Sie die Metrik `ReplicaLag`, um zu bestimmen, wann alle Aktualisierungen am Lesereplikat vorgenommen wurden. Die Metrik `ReplicaLag` zeichnet die Zeit auf, die eine Lesereplikat-DB-Instance hinter der Quell-DB-Instance zurückbleibt. Wenn die Metrik `ReplicaLag` den Wert `0` erreicht, hat das Lesereplikat den Stand der Quell-DB-Instance erreicht. 1. Stufen Sie das Lesereplikat mit der Option **Hochstufen** in der Amazon-RDS-Konsole, dem AWS CLI- Befehl [promote-read-replica-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html) oder der Amazon-RDS-API Operation [PromoteReadReplicaDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplicaDBCluster.html) hoch. Sie wählen eine Aurora MySQL-DB-Instance aus, um das Lesereplikat hochzustufen. Nachdem das Lesereplikat hochgestuft wurde, wird der Aurora MySQL-DB-Cluster zu einem eigenständigen DB-Cluster hochgestuft. Die DB-Instance mit der höchsten Failover-Priorität wird zu der primären DB-Instance für den DB-Cluster hochgestuft. Die anderen dB-Instances werden zu Aurora-Replicas. **Anmerkung** Das Hochstufen kann einige Minuten in Anspruch nehmen. Wenn Sie ein Lesereplikat hochstufen, wird die Replikation gestoppt und die DB-Instances werden neu gestartet. Sobald der Neustart abgeschlossen ist, steht das Lesereplikat als neuer DB-Cluster zur Verfügung. ## Konsole **So stufen Sie ein Aurora MySQL-Lesereplikat zu einem DB-Cluster hoch:** 1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Wählen Sie in der Konsole **Instances** aus. Der Bereich **Instance** wird angezeigt. 1. Wählen Sie im Bereich **Instances** das Lesereplikat aus, das Sie hochstufen möchten. Die Lesereplikate werden als Aurora MySQL-DB-Instances angezeigt. 1. Wählen Sie unter **Aktionen** **Promote read replica (Read Replica hochstufen)** aus. 1. Wählen Sie auf der Bestätigungsseite **Read Replica hochstufen** aus. ## AWS CLI Verwenden Sie den AWS CLI-Befehl [promote-read-replica-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html), um ein Lesereplikat zu einem eigenständigen DB-Cluster hochzustufen. **Example** Für Linux, macOS oder Unix: ``` aws rds promote-read-replica-db-cluster \ --db-cluster-identifier mydbcluster ``` Für Windows: ``` aws rds promote-read-replica-db-cluster ^ --db-cluster-identifier mydbcluster ``` ## RDS-API Rufen Sie [PromoteReadReplicaDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplicaDBCluster.html) auf, um ein Lesereplikat zu einem DB-Cluster hochzustufen. # Fehlerbehebung bei regionsübergreifenden Replikaten für Amazon Aurora MySQL Im Folgenden finden Sie eine Liste der häufigen Fehlermeldungen, die Sie beim Erstellen eines regionsübergreifenden Amazon Aurora-Lesereplikats erhalten könnten, und wie Sie die angegebenen Fehler beheben können. ## Für Quell-Cluster [DB-Cluster-ARN] sind Binärprotokolle nicht aktiviert Um dieses Problem zu lösen, aktivieren Sie die Binärprotokollierung für das Quell-DB-Cluster. Weitere Informationen finden Sie unter [Bevor Sie beginnen](AuroraMySQL.Replication.CrossRegion.md#AuroraMySQL.Replication.CrossRegion.Prerequisites). ## Quell-Cluster [DB-Cluster-ARN] verfügt über keine Cluster-Parametergruppe, die zu einem Writer synchron ist Diese Fehlermeldung erhalten Sie, wenn Sie den DB-Cluster-Parameter `binlog_format` aktualisiert haben, aber die primäre Instance für das DB-Cluster nicht neu gestartet haben. Starten Sie die primäre Instance (die schreibende Instance) für das DB-Cluster neu und versuchen Sie es erneut. ## Quell-Cluster [DB-Cluster-ARN] verfügt bereits über ein Lesereplikat in dieser Region Sie können über bis zu fünf regionsübergreifende DB-Cluster verfügen, die Lesereplikate für jeden Quell-DB-Cluster in jeder AWS-Region darstellen. Wenn in einer bestimmten AWS-Region bereits die maximale Anzahl von Lesereplikaten für einen DB-Cluster vorhanden ist, müssen Sie ein vorhandenes löschen, bevor Sie einen neuen regionsübergreifenden DB-Cluster in dieser Region erstellen können. ## Für DB-Cluster [DB-Cluster-ARN] ist ein Upgrade der Datenbank-Engine für die Unterstützung einer regionsübergreifenden Replikation erforderlich Führen Sie ein Upgrade der Datenbank-Engine-Version für alle Instances im Quell-DB-Cluster auf die aktuelle Datenbank-Engine-Version durch und versuchen Sie erneut, eine regionsübergreifende Lesereplikat-DB zu erstellen. # Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation) Da Amazon Aurora MySQL mit MySQL kompatibel ist, können Sie eine Replikation zwischen einer MySQL-Datenbank und einem Amazon Aurora MySQL-DB-Cluster einrichten. Bei diesem Replikationstyp wird die binäre MySQL-Protokoll-Replikation verwendet, die auch als *Binärprotokoll-Replikation* bezeichnet wird. Wenn Sie die binäre Protokollreplikation mit Aurora verwenden, sollte Ihre MySQL-Datenbank MySQL-Version 5.5 oder höher verwenden. Sie können eine Replikation einrichten, bei der Ihr Aurora MySQL DB-Cluster die Replikationsquelle oder das Replica ist. Sie können mit einer Amazon-RDS-MySQL-DB-Instance, einer MySQL-Datenbank außerhalb von Amazon RDS oder einem anderen Aurora MySQL-DB-Cluster replizieren. **Anmerkung** Sie können die an bestimmte Arten von Aurora-Clustern gesendete oder davon empfangene Binlog-Replikation nicht verwenden. Insbesondere ist die Binlog-Replikation nicht für Aurora Serverless v1-Cluster verfügbar. Wenn die Anweisungen `SHOW MASTER STATUS` und `SHOW SLAVE STATUS` (Aurora-MySQLVersion 2) oder `SHOW REPLICA STATUS` (Aurora-MySQL-Version 3) keine Ausgabe zurückgeben, überprüfen Sie, ob der von Ihnen verwendete Cluster die Binlog-Replikation unterstützt. Sie können eine Replikation auch mit einer RDS-for-MySQL-DB-Instance oder einem Aurora-MySQL-DB-Cluster in einer anderen AWS-Region vornehmen. Wenn Sie eine Replikation durchführen AWS-Regionen, stellen Sie sicher, dass Ihre DB-Cluster und DB-Instances öffentlich zugänglich sind. Wenn sich die Aurora MySQL-DB-Cluster in privaten Subnetzen in Ihrer VPC befinden, verwenden Sie VPC-Peering zwischen den AWS-Regionen. Weitere Informationen finden Sie unter [Ein DB- Cluster in einer VPC, auf den eine EC2-Instance in einer anderen VPC zugreift](USER_VPC.Scenarios.md#USER_VPC.Scenario3). Wenn Sie die Replikation zwischen einem Aurora MySQL-DB-Cluster und einem Aurora MySQL-DB-Cluster in einem anderen konfigurieren möchten AWS-Region, können Sie einen Aurora MySQL-DB-Cluster als Read Replica in einem anderen als AWS-Region dem Quell-DB-Cluster erstellen. Weitere Informationen finden Sie unter [Replizieren von Amazon-Aurora-MySQL-DB-Clustern über AWS-Regionen hinweg](AuroraMySQL.Replication.CrossRegion.md). Mit Aurora MySQL Version 2 und 3 können Sie zwischen Aurora MySQL und einer externen Quelle oder einem externen Ziel replizieren, das globale Transaktions-Identifikatoren (GTIDs) für die Replikation verwendet. Stellen Sie sicher, dass die Einstellungen der GTID-bezogenen Parameter im Aurora MySQL-DB-Cluster mit dem GTID-Staus der externen Datenbank kompatibel sind. Weitere Informationen zur Vorgehensweise finden Sie unter [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md). In Aurora MySQL Version 3.01 und höher können Sie wählen, wie Transaktionen zugewiesen GTIDs werden sollen, die aus einer Quelle repliziert werden, die nicht verwendet wird. GTIDs Informationen zur gespeicherten Prozedur, die diese Einstellung steuert, finden Sie unter [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL Version 3)](mysql-stored-proc-gtid.md#mysql_assign_gtids_to_anonymous_transactions). **Warnung** Wenn Sie zwischen Aurora MySQL und MySQL replizieren, dürfen Sie nur InnoDB-Tabellen verwenden. Wenn Sie MyISAM-Tabellen replizieren möchten, müssen Sie diese mit dem folgenden Befehl in das InnoDB-Format konvertieren, bevor Sie die Replikation einrichten. ``` alter table . 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. # Verwenden der GTID-basierten Replikation Der folgende Inhalt beschreibt, wie Sie globale Transaktionskennungen (Global Transaction Identifiers, GTIDs) mit Binärprotokoll (binlog)-Replikation zwischen einem Aurora-MySQL-Cluster und einer externen Quelle verwenden. **Anmerkung** Bei Aurora können Sie diese Funktion nur mit Aurora-MySQL-Clustern verwenden, welche die binlog-Replikation in eine externe oder aus einer externen MySQL-Datenbank nutzen. Bei der anderen Datenbank kann es sich um eine Amazon-RDS-MySQL-Instance, eine lokale MySQL-Datenbank oder einen Aurora-DB-Cluster in einer anderen AWS-Region handeln. Weitere Informationen zum Konfigurieren dieser Art von Replikation finden Sie unter [Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)](AuroraMySQL.Replication.MySQL.md). Wenn Sie die binlog-Replikation verwenden und nicht mit der GTID-basierten Replikation mit MySQL vertraut sind, finden Sie unter [Replication with Global Transaction Identifiers](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html) in der MySQL-Dokumentation Hintergrundinformationen. Die GTID-basierte Replikation wird für Aurora-MySQL-Version 2 und 3 unterstützt. **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 einen Aurora-MySQL-Cluster](mysql-replication-gtid.configuring-aurora.md) + [Deaktivieren einer GTID-basierten Replikation für einen Aurora MySQL-DB-Cluster](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. **Anmerkung** Wenn Aurora Daten unter den DB-Instances in einem Cluster synchronisiert, steht dieser Replikationsmechanismus in keinem Zusammenhang mit dem Binärprotokoll (binlog). Bei Aurora MySQL ist die GTID-basierte Replikation nur anwendbar, wenn Sie auch eine binlog-Replikation verwenden, um eine Replikation aus einer externen MySQL-kompatiblen Datenbank in einen oder aus einem Aurora MySQL-DB-Cluster durchführen. 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 Quell-Instance und Replikate konsistent sind. Sie verwenden die GTID-basierte Replication gewöhnlich mit Aurora, wenn Sie eine Replikation aus einer externen MySQL-kompatiblen Datenbank in einen Aurora-Cluster durchführen. Sie können diese Replikationskonfiguration als Teil einer Migration von einer lokalen oder einer Amazon-RDS-Datenbank in Aurora MySQL einrichten. Wenn die externe Datenbank bereits GTIDs verwendet, kann der Replikationsvorgang durch Aktivieren der GTID-basierten Replikation für den Aurora-Cluster vereinfacht werden. Sie konfigurieren die GTID-basierte Replikation für einen Aurora MySQL-Cluster, indem Sie zuerst die relevanten Konfigurationsparameter in einer DB-Clusterparametergruppe festlegen. Sie ordnen diese Parametergruppe dann dem Cluster zu. ## 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 DB-Cluster-Parametergruppe für Ihren Aurora MySQL-DB-Cluster: + `ON` und `ON_PERMISSIVE` gelten nur für die ausgehende Replikation von einem Aurora-MySQL-Cluster. Beide Werte bewirken, dass Ihr Aurora-DB-Cluster GTIDs für Transaktionen verwenden, die zu einer externen Datenbank repliziert werden. `ON` erfordert, dass die externe Datenbank ebenfalls die GTID-basierte Replikation verwendet. Mit `ON_PERMISSIVE` ist die GTID-basierte Replikation auf der externen Datenbank optional. + Wenn `OFF_PERMISSIVE` eingestellt ist, bedeutet dies, dass Ihr Aurora-DB-Cluster die eingehende Replikation von einer externen Datenbank akzeptieren kann. Dies ist ungeachtet davon möglich, ob die externe Datenbank eine GTID-basierte Replikation verwendet oder ob nicht. + Wenn `OFF` eingestellt ist, bedeutet dies, dass Ihr Aurora-DB-Cluster nur eingehende Replikation von externen Datenbanken akzeptiert, die keine GTID-basierte Replikation verwenden. **Tipp** Eingehende Replikation ist das geläufigste binlog-Replikationsszenario für Aurora MySQL-Cluster. Für eine eingehende Replikation empfehlen wir, dass Sie den GTID-Modus auf einzustelle `OFF_PERMISSIVE`. Diese Einstellung ermöglicht eine eingehende Replikation aus externen Datenbanken ungeachtete der GTID-Einstellungen an der Replikationsquelle. Weitere Informationen zu Parametergruppen finden Sie unter [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.md). # Aktivieren der GTID-basierten Replikation für einen Aurora-MySQL-Cluster Wenn die GTID-basierte Replikation für einen Aurora MySQL-DB-Cluster aktiviert ist, gelten die GTID-Einstellungen sowohl für eine eingehende als auch für eine ausgehende binlog-Replikation. **So aktivieren Sie eine GTID-basierte Replikation für einen Aurora MySQL-Cluster** 1. Erstellen oder bearbeiten Sie eine DB-Clusterparametergruppe unter Verwendung der folgenden Parametereinstellungen: + `gtid_mode` – `ON` oder `ON_PERMISSIVE` + `enforce_gtid_consistency` – `ON` 1. Ordnen Sie die DB-Clusterparametergruppe dem Aurora MySQL-Cluster zu. Befolgen Sie hierzu die Verfahren unter [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.md). 1. (Optional) Geben Sie an, wie GTIDs Transaktionen zugewiesen werden, die sie nicht enthalten. Rufen Sie dazu die Gespeicherte Prozedur in [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL Version 3)](mysql-stored-proc-gtid.md#mysql_assign_gtids_to_anonymous_transactions) auf. # Deaktivieren einer GTID-basierten Replikation für einen Aurora MySQL-DB-Cluster Sie können eine GTID-basierte Replikation für einen Aurora-MySQL-DB-Cluster deaktivieren. Dies bedeutet, dass der Aurora-Cluster keine ein- oder ausgehende binlog-Replikation mit externen Datenbanken ausführen kann, die . **Anmerkung** Im folgenden Verfahren bezieht sich *Lesereplikat* auf das Replikationsziel in einer Aurora-Konfiguration mit binlog-Replikation in eine externe oder aus einer externen Datenbank. Es bezieht sich nicht auf die schreibgeschützten Aurora Replica-DB-Instances. Wenn ein Aurora-Cluster beispielsweise eine eingehende Replikation aus einer externen Quelle akzeptiert, dann fungiert die primäre Aurora-Instance als Lesereplikat der binlog-Replikation. Weitere Informationen zu den in diesem Abschnitt erwähnten gespeicherten Verfahren finden Sie unter [Referenz für gespeicherte Aurora-MySQL-Prozeduren](AuroraMySQL.Reference.StoredProcs.md). **So deaktivieren Sie die GTID-basierte Replikation für einen Aurora MySQL-DB-Cluster** 1. Führen Sie die folgende Prozedur für die Aurora-Replikate aus: Für Version 3 ``` CALL mysql.rds_set_source_auto_position(0); ``` Für Version 2 ``` CALL mysql.rds_set_master_auto_position(0); ``` 1. Setzen Sie den Wert für `gtid_mode` auf `ON_PERMISSIVE` zurück. 1. Stellen Sie sicher, das bei der DB-Clusterparametergruppe, die dem Aurora MySQL-Cluster zugeordnet ist, `gtid_mode` auf `ON_PERMISSIVE` eingestellt ist. Weitere Informationen zum Einstellen von Konfigurationsparametern unter Verwendung von Parametergruppen finden Sie unter [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.md). 1. Starten Sie den Aurora MySQL-DB-Cluster neu. 1. Setzen Sie den Wert für `gtid_mode` auf `OFF_PERMISSIVE` zurück. 1. Stellen Sie sicher, das bei der DB-Clusterparametergruppe, die dem Aurora MySQL-Cluster zugeordnet ist, `gtid_mode` auf `OFF_PERMISSIVE` eingestellt ist. 1. Starten Sie den Aurora MySQL-DB-Cluster neu. 1. Warten Sie, bis alle GTID-Transaktionen auf die primäre Aurora-Instance angewendet wurden. Um zu überprüfen, ob diese angewendet werden, führen Sie die folgenden Schritte aus: 1. Führen Sie auf der primären Aurora-Instance den Befehl `SHOW MASTER STATUS` aus. 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. Für Version 3 ``` SELECT SOURCE_POS_WAIT('file', position); ``` Für Version 2 ``` 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: Für Version 3 ``` SELECT SOURCE_POS_WAIT('mysql-bin-changelog.000031', 107); ``` Für Version 2 ``` 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 DB-Clusterparametergruppe, die dem Aurora MySQL-Cluster zugeordnet ist, muss über die folgenden Parametereinstellungen verfügen: + `gtid_mode` – `OFF` + `enforce_gtid_consistency` – `OFF` 1. Starten Sie den Aurora MySQL-DB-Cluster neu.