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. # 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: + Deaktivieren Sie die automatischen Backups für die DB-Instance. Sie können automatische Backups aktivieren, wenn Sie eine DB-Instance erstellen, oder Sie können Backups aktivieren, indem Sie eine bestehende DB-Instance ändern. Weitere Informationen finden Sie unter [Erstellen einer DB-Instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html) im *Amazon-RDS-Benutzerhandbuch*.
+ Erstellen Sie ein Lesereplikat für die DB-Instance. Weitere Informationen finden Sie unter [Arbeiten mit Read Replicas](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) im *Amazon-RDS-Benutzerhandbuch*. | | 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: + Secure Sockets Layer (SSL) muss in der externen MySQL-Quelldatenbank aktiviert sein.
+ Ein Clientschlüssel und ein Clientzertifikat müssen für das Aurora MySQL-DB-Cluster vorbereitet werden.
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. 1. Stellen Sie sicher, dass alle Vorbereitungen für die verschlüsselte Replikation getroffen wurden: Wenn SSL auf dem externen Server mit der MySQL-Quelldatenbank nicht aktiviert ist und Sie keinen Clientschlüssel und kein Clientzertifikat vorbereitet haben, aktivieren Sie SSL auf dem MySQL-Datenbankserver und generieren Sie den Clientschlüssel und das Clientzertifikat. Wenn SSL auf der externen Quelle aktiviert ist, geben Sie einen Clientschlüssel und ein Clientzertifikat für das Aurora MySQL-DB-Cluster an. Wenn Sie diese Werte nicht haben, erstellen Sie ein einen neuen Schlüssel und ein neues Zertifikat für das Aurora MySQL-DB-Cluster. Sie benötigen zur Signierung des Clientzertifikats den Zertifizierungsstellenschlüssel, den Sie zum Konfigurieren von SSL auf der externen MySQL-Quelldatenbank verwendet haben.
Weitere Informationen finden Sie unter [ Creating SSL Certificates and Keys Using openssl](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html) in der MySQL-Dokumentation.
Sie benötigen das Zertifizierungsstellenzertifikat, den Clientschlüssel und das Clientzertifikat.
2. Stellen Sie als Masterbenutzer über SSL eine Verbindung zum Aurora MySQL-DB-Cluster her.
Informationen zum Herstellen einer Verbindung mit einem Aurora MySQL-DB-Cluster über SSL finden Sie unter [TLS-Verbindungen mit DB-Clustern von Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL).
3. Führen Sie die gespeicherte Prozedur `mysql.rds_import_binlog_ssl_material` aus, um die SSL-Informationen in das Aurora MySQL-DB-Cluster zu importieren.
Fügen Sie die Informationen aus den PEM-Dateien für das Aurora MySQL-DB-Cluster in die korrekte JSON-Nutzlast für den Parameter `ssl_material_value` ein.
Im folgenden Beispiel werden SSL-Informationen in ein Aurora MySQL-DB-Cluster importiert. Der Code in den PEM-Dateien ist in der Regel länger als in diesem Beispiel. 
call mysql.rds_import_binlog_ssl_material(
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END RSA PRIVATE KEY-----\n"}');

Weitere Informationen erhalten Sie unter [mysql.rds\_import\_binlog\_ssl\_material](mysql-stored-proc-replicating.md#mysql_rds_import_binlog_ssl_material) und [TLS-Verbindungen mit DB-Clustern von Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL). Nach dem Ausführen der Prozedur werden die SSL-Informationen in Dateien gespeichert. Um die Dateien später zu löschen, können Sie die [mysql.rds\_remove\_binlog\_ssl\_material](mysql-stored-proc-replicating.md#mysql_rds_remove_binlog_ssl_material) gespeicherte Prozedur ausführen.
**So aktivieren Sie die Binärprotokollierung für eine externe MySQL-Datenbank** 1. Halten Sie mit dieser Befehlszeile den mysql-Service an. 
sudo service mysqld stop

2. Bearbeiten Sie die `my.cnf`-Datei (diese Datei befindet sich üblicherweise unter `/etc`). 
sudo vi /etc/my.cnf

Fügen Sie die Optionen `log_bin` und `server_id` zum Abschnitt `[mysqld]` hinzu. Die Option `log_bin` bietet eine Dateinamenkennung für Binärprotokolldateien. Die Option `server_id` stellt eine eindeutige Kennung für den Server für Quelle-Replica-Beziehungen bereit.
Wenn keine verschlüsselte Replikation erforderlich ist, muss die externe MySQL-Datenbank mit aktivierten Binärprotokollen und aktiviertem SSL gestartet werden.
Dies sind die relevanten Einträge für unverschlüsselte Daten in der Datei `/etc/my.cnf`. 
log-bin=mysql-bin
server-id=2133421
innodb_flush_log_at_trx_commit=1
sync_binlog=1

Wenn die verschlüsselte Replikation erforderlich ist, muss die externe MySQL-Datenbank mit aktivierten Binärprotokollen und aktiviertem SSL gestartet werden.
Die Einträge in der Datei `/etc/my.cnf` müssen dann die Speicherorte der PEM-Dateien für den MySQL-Datenbankserver enthalten. 
log-bin=mysql-bin
server-id=2133421
innodb_flush_log_at_trx_commit=1
sync_binlog=1

# Setup SSL.
ssl-ca=/home/sslcerts/ca.pem
ssl-cert=/home/sslcerts/server-cert.pem
ssl-key=/home/sslcerts/server-key.pem

Zusätzlich muss die Option `sql_mode` für Ihre MySQL-DB-Instance auf 0 gesetzt oder in Ihrer my.cnf-Datei enthalten sein.
Zeichnen Sie die Position der Binärprotokolle der externen MySQL-Datenbank auf, während Sie mit der Datenbank verbunden sind. 
mysql> SHOW MASTER STATUS;

Die Ausgabe sollte in etwa wie folgt aussehen: 
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000031 |      107 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

Weitere Informationen finden Sie unter [Setting the replication source configuration](http://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterbaseconfig.html) in der MySQL-Dokumentation.
3. Starten Sie den mysql-Service. 
sudo service mysqld start
| ## 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\_set\_configuration](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\_stop\_replication](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:+ Stellen Sie aus einem DB-Cluster-Snapshot wieder her: Erstellen Sie einen DB-Cluster-Snapshot Ihres Amazon Aurora-DB-Clusters. Weitere Informationen finden Sie unter [Erstellen eines DB-Cluster-Snapshots](USER_CreateSnapshotCluster.md). Erstellen Sie ein neues Aurora-DB-Cluster, indem Sie eine Wiederherstellung aus einem kürzlich erstellten DB-Cluster-Snapshot durchführen.
Stellen Sie sicher, dass Sie dieselbe DB-Parametergruppe für Ihr wiederhergestelltes DB-Cluster wie für Ihr ursprüngliches DB-Cluster aufbewahren. Dadurch wird sichergestellt, dass die Binärprotokollierung für die Kopie des DB-Clusters aktiviert ist. Weitere Informationen finden Sie unter [Wiederherstellen aus einem DB-Cluster-Snapshot](aurora-restore-snapshot.md).
+ Klonen Sie Ihren DB-Cluster. Weitere Informationen finden Sie unter [Klonen eines Volumes für einen Amazon-Aurora-DB-Cluster](Aurora.Managing.Clone.md).
**So bestimmen Sie den Namen und die Position der Binlog-Datei**
Verwenden Sie eine der folgenden Methoden:+ In der AWS-Managementkonsole: Wählen Sie **Datenbanken** und anschließend die primäre Instance (Schreiber) für Ihren neuen Aurora-DB-Cluster aus, um Details anzuzeigen. Scrollen Sie zu **Recent Events (Aktuelle Ereignisse)**. Eine Ereignismeldung zeigt den Namen und die Position der Binärprotokolldatei an. Die Ereignismeldung liegt im folgenden Format vor. 
Binlog position from crash recovery is {{binlog-file-name}} {{binlog-position}}
Speichern Sie den Binärprotokolldateinamen- und die -positionswerte für den Beginn einer Replikation.
+ Rufen Sie den AWS CLI Befehl [describe-events](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-events.html) wie im folgenden Beispiel auf. 
aws rds describe-events

{
    "Events": [
        {
            "EventCategories": [],
            "SourceType": "db-instance",
            "SourceArn": "arn:aws:rds:us-west-2:123456789012:db:sample-restored-instance",
            "Date": "2016-10-28T19:43:46.862Z",
            "Message": "Binlog position from crash recovery is mysql-bin-changelog.000003 4278",
            "SourceIdentifier": "sample-restored-instance"
        }
    ]
}

+ Überprüfen Sie das MySQL-Fehlerprotokoll auf die letzte Position der MySQL-Binlog-Datei.
**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.1. Verbinden Sie sich mit Ihrem DB-Cluster mithilfe eines SQL-Clients.
2. Führen Sie den Befehl `mysqldump` aus. Beispiel: 
PROMPT> mysqldump --databases {{database_name}} --single-transaction
--order-by-primary -r backup.sql -u {{local_user}}s -p

3. Nachdem Sie die Dump-Datei erstellt haben, können Sie die DB-Cluster-Kopie löschen. | | 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*. 1. Verbinden Sie sich mit Ihrem Lesereplikat und halten Sie die Replikation mithilfe der Prozedur [mysql.rds\_stop\_replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) an.
2. Während die Read Replica **angehalten** ist, stellen Sie eine Verbindung zur Read Replica her und führen Sie den Befehl `SHOW SLAVE STATUS` (Aurora-MySQL-Version 2) oder `SHOW REPLICA STATUS` (Aurora-MySQL-Version 3) aus. Rufen Sie den aktuellen Namen der Binärprotokolldatei aus dem Feld `Relay_Master_Log_File` und die Position aus dem Feld `Exec_Master_Log_Pos` ab. Speichern Sie diese Werte für den Start einer Replikation.
3. Solange das Lesereplikat im Status **Stopped (Angehalten)** verweilt, erstellen Sie einen DB-Snapshot dieses Lesereplikats. Weitere Informationen finden Sie unter [Erstellen eines DB-Snapshots](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html) im *Amazon Relational Database Service-Benutzerhandbuch*.
4. Löschen Sie das Read Replica. | | MySQL (extern) | **So erstellen Sie einen Dump einer externen MySQL-Datenbank**1. Bevor Sie einen Dump erstellen, müssen Sie sicherstellen, dass der Speicherort Ihres Binärprotokolls für den Dump auf dem aktuellen Stand der Daten Ihrer Quell-Instance ist. Hierfür müssen Sie als Erstes alle Schreibvorgänge für diese Instance mithilfe des folgenden Befehls anhalten: 
mysql> FLUSH TABLES WITH READ LOCK;

2. Erstellen Sie einen Dump Ihrer MySQL-Datenbank mithilfe des Befehls `mysqldump`, wie im Folgenden gezeigt: 
PROMPT> sudo mysqldump --databases {{database_name}} --master-data=2  --single-transaction \
--order-by-primary -r backup.sql -u {{local_user}} -p

3. Nachdem Sie den Dump erstellt haben, entsperren Sie die Tabellen in Ihrer MySQL-Datenbank mit dem folgenden Befehl: 
mysql> UNLOCK TABLES;
| ## 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** 1. Kopieren Sie die Ausgabe des Befehls `mysqldump` von der Replikationsquelle an einen Speicherort, der auch eine Verbindung zum Aurora MySQL-DB-Cluster herstellen kann.
2. Verbinden Sie sich mithilfe des `mysql`-Befehls mit Ihrem Aurora MySQL-DB-Cluster. Im Folgenden wird ein Beispiel gezeigt. 
PROMPT> mysql -h {{host_name}} -port=3306 -u {{db_master_user}} -p

3. Führen Sie in der `mysql`-Eingabeaufforderung den Befehl `source` aus und geben Sie den Namen Ihrer Datenbank-Dumpdatei ein, um die Daten in den Aurora MySQL-DB-Cluster zu laden, zum Beispiel: 
mysql> source backup.sql;
| | RDS für MySQL | **So laden Sie einen Dump in eine DB-Instance von Amazon RDS**1. Kopieren Sie die Ausgabe des Befehls `mysqldump` von Ihrer Replikationsquelle an einen Speicherort, der auch eine Verbindung mit Ihrer MySQL-DB-Instance herstellen kann.
2. Verbinden Sie sich mit Ihrer MySQL-DB-Instance mithilfe des `mysql`-Befehls. Im Folgenden wird ein Beispiel gezeigt. 
PROMPT> mysql -h {{host_name}} -port=3306 -u {{db_master_user}} -p

3. Führen Sie in der `mysql`-Eingabeaufforderung den Befehl `source` aus und geben Sie den Namen Ihrer Datenbank-Dumpdatei mit, um deren Daten in die My-DB-Instance zu laden, zum Beispiel: 
mysql> source backup.sql;
| | 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.1. Kopieren Sie die Ausgabe des Befehls `mysqldump` von der Replikationsquelle an einen Speicherort, der auch eine Verbindung zur MySQL-Datenbank herstellen kann.
2. Verbinden Sie sich mit Ihrer MySQL-Datenbank mithilfe des `mysql`-Befehls. Im Folgenden wird ein Beispiel gezeigt. 
PROMPT> mysql -h {{host_name}} -port=3306 -u {{db_master_user}} -p

3. Führen Sie an der `mysql`-Eingabeaufforderung den Befehl `source` aus und übergeben Sie den Namen der Datenbank-Dumpdatei, deren Daten in die MySQL-Datenbank geladen werden sollen. Im Folgenden wird ein Beispiel gezeigt. 
mysql> source backup.sql;
| ## 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\_name\_resolve](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** 1. Suchen Sie den Startpunkt für die Replikation. Sie benötigen den Namen der Binärprotokolldatei und die Binärprotokollposition.
Wenn Ihr DB-Cluster-Replikatziel auf Folgendem erstellt wurde: DB-Cluster-Snapshot oder -Klon – Rufen Sie den Namen und die Position der Binlog-Datei aus den letzten Ereignissen für Ihren neuen DB-Cluster ab, wie unter [3. Erstellen einer Kopie oder eines Dumps Ihrer Replikationsquelle](#AuroraMySQL.Replication.MySQL.CreateSnapshot) gezeigt. DB-Snapshot – Sie haben den Binärprotokoll-Dateinamen und die -position aus dem Befehl `SHOW SLAVE STATUS` (Aurora MySQL Version 2) oder `SHOW REPLICA STATUS` (Aurora MySQL Version 3) abgerufen, als Sie den Snapshot Ihrer Replikationsquelle erstellt haben.
2. Stellen Sie eine Verbindung mit dem DB-Cluster her und rufen Sie die folgenden Prozeduren auf, um eine Replikation mit Ihrer Replikationsquelle unter Verwendung des Namens und des Speicherorts der Binärprotokolldatei aus dem vorherigen Schritt zu starten: [mysql.rds\_set\_external\_source (Aurora MySQL Version 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) [mysql.rds\_set\_external\_master (Aurora MySQL Version 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) [mysql.rds\_start\_replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) (alle Versionen)
Das folgende Beispiel gilt für Aurora MySQL Version 3. 
CALL mysql.rds_set_external_source ('mydbinstance.123456789012.us-east-1.rds.amazonaws.com', 3306,
    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
CALL mysql.rds_start_replication;

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** 1. Wenn das DB-Instance-Replica-Ziel aus einem DB-Snapshot erstellt wurde, benötigen Sie den Namen der Binärprotokolldatei und die Position in der Datei, ab der die Replikation durchgeführt werden soll. Sie haben diese Werte aus dem Befehl `SHOW SLAVE STATUS` (Aurora-MySQL-Version 2) oder `SHOW REPLICA STATUS` (Aurora-MySQL-Version 3) abgerufen, als Sie den Snapshot Ihrer Replikationsquelle erstellt haben.
2. Stellen Sie eine Verbindung zur DB-Instance her und rufen Sie die Prozeduren [mysql.rds\_set\_external\_master (Aurora MySQL Version 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) oder[mysql.rds\_set\_external\_source (Aurora MySQL Version 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) und [mysql.rds\_start\_replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) auf, um eine Replikation mit Ihrer Replikationsquelle zu starten. Verwenden Sie den Namen und den Speicherort der Binärprotokolldatei aus dem vorherigen Schritt. Im Folgenden wird ein -Beispiel gezeigt. 
CALL mysql.rds_set_external_master ('mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', 3306,
    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
CALL mysql.rds_start_replication;

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** 1. Erhalten Sie den Namen und die Position der Binärprotokolldatei, die der Ausgangspunkt für eine Replikation sind. Sie haben diese Werte aus dem Befehl `SHOW SLAVE STATUS` (Aurora-MySQL-Version 2) oder `SHOW REPLICA STATUS` (Aurora-MySQL-Version 3) abgerufen, als Sie den Snapshot Ihrer Replikationsquelle erstellt haben. Wenn das externe MySQL-Replica-Ziel durch den `mysqldump`-Befehl mit der Option `--master-data=2` mit Daten gefüllt wurde, sind der Name und die Position der Binärprotokolldatei in den ausgegebenen Informationen enthalten. Im Folgenden wird ein -Beispiel gezeigt. 
--
-- Position to start replication or point-in-time recovery from
--

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;

2. Stellen Sie eine Verbindung zum externen MySQL-Replica-Ziel her und führen Sie die Befehle `CHANGE MASTER TO` und `START SLAVE` (Aurora-MySQL-Version 2) oder `START REPLICA` (Aurora-MySQL-Version 3) aus, um eine Replikation mit der Replikationsquelle mithilfe des Namens und der Position der Binärprotokolldatei aus dem vorherigen Schritt zu starten. Beispiel: 
CHANGE MASTER TO
  MASTER_HOST = 'mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com',
  MASTER_PORT = 3306,
  MASTER_USER = 'repl_user',
  MASTER_PASSWORD = 'password',
  MASTER_LOG_FILE = 'mysql-bin-changelog.000031',
  MASTER_LOG_POS = 107;
-- And one of these statements depending on your engine version:
START SLAVE; -- Aurora MySQL version 2
START REPLICA; -- Aurora MySQL version 3
| 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\_reset\_external\_master (Aurora MySQL Version 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) oder [mysql.rds\_reset\_external\_source (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\_start\_replication\_until(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\_start\_replication\_until(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-based Replikation verwenden, verwenden Sie die [mysql.rds\_start\_replication\_until\_gtid (Aurora MySQL Version 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) gespeicherte Prozedur anstelle der gespeicherten Prozedur. [mysql.rds\_start\_replication\_until(Aurora MySQL Version 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) Weitere Hinweise zur GTID-based Replikation finden Sie unter[GTID-based Replikation verwenden](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.