

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.

# Migrationsoptionen für große MySQL- und MariaDB-Datenbanken
<a name="migration-options"></a>

Sie können aus einer Vielzahl von Optionen wählen, um von lokalen MySQL- oder MariaDB-Datenbanken zu Amazon Relational Database Service (Amazon RDS) oder Amazon Aurora MySQL-Compatible Edition-Datenbank-Instances zu migrieren. Die Wahl des richtigen Migrationsansatzes und Tools ist für eine erfolgreiche Migration von entscheidender Bedeutung. In diesem Leitfaden bewerten Sie die Optionen anhand Ihrer Anforderungen an Benutzerfreundlichkeit, Datengröße und Ausfallzeiten.

Im Folgenden sind die gängigen Migrationstools und -ansätze aufgeführt, mit denen selbstverwaltete MySQL-Datenbanken mit mehreren Terabyte effizient zu Amazon RDS-, Aurora- oder Amazon Elastic Compute Cloud (Amazon EC2) -Datenbank-Instances migriert werden können:
+ [Percona XtraBackup](percona-xtrabackup.md)(Physisch)
+ [MyDumper](mydumper.md)(Logisch)
+ [mysqldump und mysqlpump](mysqldump-and-mysqlpump.md)(Logisch)
+ [Geteiltes Backup](split-backup.md)(Physisch, logisch oder beides)

Im Folgenden sind die gängigen Migrationstools und -ansätze aufgeführt, die verfügbar sind, um MySQL-kompatible Datenbanken (wie MariaDB) mit mehreren Terabyte effizient zu Amazon RDS-, Aurora- oder Amazon-Datenbank-Instances zu migrieren: EC2 
+ [MyDumper](mydumper.md)(Logisch)
+ [mysqldump und mysqlpump](mysqldump-and-mysqlpump.md)(Logisch)
+ [Geteiltes Backup](split-backup.md)(Physisch, logisch oder beides)

Für jedes Migrationstool gibt es mehrere Methoden, mit denen Sie die große Datenbank-Backup-Datei auf die übertragen können AWS Cloud. Für jedes Tool stehen Optionen zur Verfügung, und Sie können auch Amazon S3 File Gateway verwenden. Weitere Informationen finden Sie unter [Verwenden von Amazon S3 File Gateway zum Übertragen von Backup-Dateien](amazon-s3-file-gateway.md) in diesem Handbuch.

# Percona XtraBackup
<a name="percona-xtrabackup"></a>

[Percona XtraBackup](https://docs.percona.com/percona-xtrabackup/8.0/index.html) ist eine gängige Open-Source-Warm-Backup-Software für MySQL und MariaDB, die blockierungsfreie Backups für InnoDB- und XtraDB-Speicher-Engines erstellt. Es funktioniert mit MySQL- oder MariaDB-Servern. Weitere Informationen über das Tool und einige seiner Funktionen und Vorteile finden Sie XtraBackup in der [Percona-Dokumentation unter Über Percona](https://docs.percona.com/percona-xtrabackup/8.0/about-xtrabackup.html). XtraBackup 

Dieses Tool verwendet den Ansatz der physischen Migration. Es kopiert direkt das MySQL- oder MariaDB-Datenverzeichnis und die darin enthaltenen Dateien. Bei großen Datenbanken, z. B. solchen, die größer als 100 GB sind, kann dies zu einer deutlich besseren Wiederherstellungszeit führen als bei einigen anderen Tools. Sie erstellen eine Sicherungskopie der lokalen Quelldatenbank, migrieren die Sicherungsdateien in die Cloud und stellen die Sicherung dann auf der neuen Zieldatenbank-Instance wieder her.

Das folgende Diagramm zeigt die allgemeinen Schritte, die bei der Migration einer Datenbank mithilfe einer XtraBackup Percona-Backup-Datei erforderlich sind. Abhängig von der Größe der Sicherungsdatei stehen zwei Optionen für die Übertragung der Sicherung in einen Amazon Simple Storage Service (Amazon S3) -Bucket im zur Verfügung AWS Cloud.



![\[Diagramm der Migration einer XtraBackup Percona-Datei und ihrer Wiederherstellung auf einer AWS DB-Instance.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/percona-xtrabackup-migration-aws.png)


Im Folgenden sind die Schritte aufgeführt, um mit Percona eine Datenbank XtraBackup zu migrieren: AWS Cloud

1. Installieren Sie Percona XtraBackup auf dem lokalen Server. Wenn Sie Amazon Aurora MySQL Version 2 oder Amazon RDS verwenden, finden Sie weitere Informationen unter [Percona XtraBackup 2.4 installieren](https://docs.percona.com/percona-xtrabackup/2.4/installation.html). Wenn Sie Amazon Aurora MySQL Version 3 verwenden, finden Sie weitere Informationen unter [Percona XtraBackup 8.0](https://docs.percona.com/percona-xtrabackup/8.0/installation.html) installieren in der Percona-Dokumentation XtraBackup.

1. Erstellen Sie eine vollständige Sicherung der MySQL- oder MariaDB-Quelldatenbank. [Anweisungen für Percona XtraBackup 2.4 finden Sie unter Vollständige Sicherung.](https://docs.percona.com/percona-xtrabackup/2.4/backup_scenarios/full_backup.html) Anweisungen für Percona XtraBackup 8.0 finden Sie unter [Erstellen Sie ein vollständiges Backup](https://docs.percona.com/percona-xtrabackup/8.0/create-full-backup.html).

1. Übertragen Sie die Sicherungsdateien mithilfe eines zugelassenen Dienstes oder Tools in Ihrer Organisation über das Internet, z. B. den folgenden:
   + [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)
   + [AWS Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-user/client-vpn-user-what-is.html)
   + [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)
   + [Amazon S3 File Gateway](https://docs.aws.amazon.com/filegateway/latest/files3/what-is-file-s3.html) (Weitere Informationen finden Sie [Verwenden von Amazon S3 File Gateway zum Übertragen von Backup-Dateien](amazon-s3-file-gateway.md) in diesem Handbuch.)
   + [AWS Command Line Interface (AWS CLI)](https://aws.amazon.com/getting-started/hands-on/backup-to-s3-cli/)

1. Stellen Sie die Sicherungsdateien aus dem Amazon S3 S3-Bucket auf der Zieldatenbank-Instance wieder her. Detaillierte Informationen finden Sie hier:
   + Informationen zur Aurora MySQL-Compatible Edition finden Sie unter [Migrieren von Daten aus MySQL mithilfe eines Amazon S3 S3-Buckets in der Amazon](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.Restore) RDS-Dokumentation.
   + Informationen zu Amazon RDS for MySQL oder Amazon EC2 finden Sie unter [Daten in eine MySQL-DB-Instance importieren](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.Other.html).
   + Informationen zu Amazon RDS for MariaDB oder Amazon EC2 finden Sie unter [Daten in eine MariaDB-DB-Instance importieren](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MariaDB.Procedural.Importing.html).

1. (Optional) Sie können die Replikation zwischen der Quelldatenbank und der Zieldatenbank-Instance einrichten. Sie können die Replikation von Binärprotokollen (Binlog) verwenden, um Ausfallzeiten zu reduzieren. Weitere Informationen finden Sie hier:
   + [Einstellung der Konfiguration der Replikationsquelle](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) in der MySQL-Dokumentation
   + Für Amazon Aurora finden Sie Folgendes:
     + [Synchronisieren des Amazon Aurora MySQL-DB-Clusters mit der MySQL-Datenbank mithilfe der Replikation](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) in der Aurora-Dokumentation
     + [Verwendung der Binlog-Replikation in Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html) in der Aurora-Dokumentation
   + Informationen zu Amazon RDS finden Sie im Folgenden:
     + [Arbeiten mit der MySQL-Replikation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html) in der Amazon RDS-Dokumentation
     + [Arbeiten mit der MariaDB-Replikation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html) in der Amazon RDS-Dokumentation
   + Informationen zu Amazon EC2 finden Sie unter:
     + [Einrichtung der positionsbasierten Replikation von binären Logdateien](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html) in der MySQL-Dokumentation
     + [Repliken einrichten](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html) in der MySQL-Dokumentation
     + [Einrichtung der Replikation](https://mariadb.com/kb/en/setting-up-replication/) in der MariaDB-Dokumentation

## Vorteile
<a name="advantages-percona-xtrabackup"></a>
+ Da Percona einen physischen Migrationsansatz XtraBackup verwendet, ist der Wiederherstellungsprozess in der Regel schneller als bei Tools, die einen logischen Migrationsansatz verwenden. Dies liegt daran, dass die Leistung eher durch den Festplatten- oder Netzwerkdurchsatz als durch die für die Datenverarbeitung erforderlichen Rechenressourcen begrenzt wird.
+ Da der Wiederherstellungsprozess eine direkte Kopie der Dateien aus dem S3-Bucket zur Zieldatenbankinstanz ist, werden XtraBackup Percona-Dateien in der Regel schneller wiederhergestellt als Sicherungsdateien, die mit anderen Tools erstellt wurden.
+ Percona XtraBackup ist anpassungsfähig. Es unterstützt beispielsweise mehrere Threads, damit Sie Dateien schneller kopieren können, und unterstützt die Komprimierung, um die Größe des Backups zu reduzieren.

## Einschränkungen
<a name="limitations-percona-xtrabackup"></a>
+ Eine Offline-Sicherung ist nicht möglich, da Percona Zugriff auf den Quelldatenbankserver haben XtraBackup muss.
+ Percona XtraBackup kann nur auf Systemen mit identischen Systemarchitekturen verwendet werden. Es ist beispielsweise nicht möglich, eine Sicherungskopie einer Quelldatenbank, die auf Intel für Windows Server läuft, auf einem ARM für Linux-Zielserver wiederherzustellen.
+ Percona wird für Maria DB Version 10.3 XtraBackup nicht unterstützt, und es wird nur teilweise für Maria DB Version 10.2 und Version 10.1 unterstützt. Weitere Informationen finden Sie unter [Percona XtraBackup Overview: Compatibility with MariaDB in der MariaDB-Wissensdatenbank](https://mariadb.com/kb/en/percona-xtrabackup-overview/#compatibility-with-mariadb).
+ Sie können Percona nicht verwenden XtraBackup , um eine MariaDB-Quelldatenbank auf einer MySQL-Zieldatenbank-Instance wie Amazon RDS for MySQL oder Aurora MySQL-Compatible wiederherzustellen.
+ Das Gesamtdatenvolumen und die Anzahl der Objekte, die Sie in einem S3-Bucket speichern können, sind unbegrenzt, die maximale Dateigröße beträgt jedoch 5 TB. Wenn Ihre Backup-Datei 5 TB überschreitet, können Sie sie in mehrere kleinere Dateien aufteilen.
+ Wenn die `innodb_file_per_table` Einstellung deaktiviert ist, unterstützt Percona XtraBackup keine Teilsicherungen, die`--tables`,`--tables-exclude`, `--tables-file` `--databases``--databases-exclude`, oder `--databases-file` verwenden. Weitere Informationen zu Percona XtraBackup Version 2.4 finden Sie unter [Partielle](https://docs.percona.com/percona-xtrabackup/2.4/innobackupex/partial_backups_innobackupex.html) Backups. Weitere Informationen für Percona XtraBackup Version 8.0 finden Sie unter [Erstellen einer teilweisen Sicherung](https://docs.percona.com/percona-xtrabackup/8.0/create-partial-backup.html).

## Best Practices
<a name="best-practices-percona-xtrabackup"></a>
+ Gehen Sie wie folgt vor, um die Leistung des Backup-Vorgangs zu verbessern:
  + Kopieren Sie mehrere Dateien parallel mit [--parallel=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-parallel) <threads>
  + Komprimieren Sie mehrere Dateien parallel mit [--compress-threads=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-compress-threads) <threads>
  + [Erhöhen Sie den Speicher mit --use-memory=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-use-memory) <size>
  + [Verschlüsseln Sie mehrere Dateien parallel mit --encrypt-threads=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-encrypt-threads) <threads>
+ Stellen Sie sicher, dass auf dem Quellserver ausreichend Speicherplatz für die Datenbanksicherungsdateien vorhanden ist.
+ Generieren Sie die Datenbanksicherung mit der Percona-Datei im xbstream-Format (.xbstream). Weitere Informationen finden Sie in der Percona-Dokumentation unter [Die xbstream-Binärdatei](https://docs.percona.com/percona-xtrabackup/8.0/xbstream-binary-overview.html) im Überblick. XtraBackup

# MyDumper
<a name="mydumper"></a>

[MyDumper](https://github.com/mydumper/mydumper#what-is-mydumper)(GitHub) ist ein logisches Open-Source-Migrationstool, das aus zwei Dienstprogrammen besteht:
+ MyDumper exportiert ein konsistentes Backup von MySQL-Datenbanken. Es unterstützt das Sichern der Datenbank mithilfe mehrerer parallel Threads, bis zu einem Thread pro verfügbarem CPU-Kern.
+ myloader liest die von erstellten Sicherungsdateien MyDumper, stellt eine Verbindung zur Zieldatenbankinstanz her und stellt dann die Datenbank wieder her.

Das folgende Diagramm zeigt die wichtigsten Schritte, die bei der Migration einer Datenbank mithilfe einer MyDumper Sicherungsdatei erforderlich sind. Dieses Architekturdiagramm enthält drei Optionen für die Migration der Sicherungsdatei vom lokalen Rechenzentrum zu einer EC2 Instanz im. AWS Cloud



![\[Diagramm der Migration einer MyDumper Sicherungsdatei und der Verwendung von myloader zur Wiederherstellung auf der DB-Instance. AWS\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/mydumper-myloader-migration-aws.png)


Im Folgenden finden Sie die Schritte MyDumper zur Migration einer Datenbank auf die: AWS Cloud

1. Install MyDumper und Myloader. Anweisungen finden Sie unter [So installieren Sie mydumper/myloader](https://github.com/mydumper/mydumper#how-to-install-mydumpermyloader) (). GitHub

1. Wird verwendet MyDumper , um eine Sicherungskopie der MySQL- oder MariaDB-Quelldatenbank zu erstellen. Anweisungen finden Sie unter [Wie benutzt man](https://github.com/mydumper/mydumper#how-to-use-mydumper). MyDumper

1. Verschieben Sie die Sicherungsdatei AWS Cloud mithilfe einer der folgenden Methoden in eine EC2 Instanz in der:

   **Ansatz 3A** — Mounten Sie ein [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-file-shares.html) - oder [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/efs-onpremises.html) -Dateisystem auf dem lokalen Server, auf dem Ihre Datenbank-Instance ausgeführt wird. Sie können AWS Direct Connect oder verwenden Site-to-Site VPN , um die Verbindung herzustellen. Sie können die Datenbank direkt auf der bereitgestellten Dateifreigabe sichern, oder Sie können die Sicherung in zwei Schritten durchführen, indem Sie die Datenbank in einem lokalen Dateisystem sichern und sie dann auf das gemountete FSx oder EFS-Volume hochladen. Mounten Sie als Nächstes das Amazon FSx - oder Amazon EFS-Dateisystem, das ebenfalls auf dem lokalen Server bereitgestellt ist, auf einer EC2 Instance.

   **Ansatz 3B** — Verwenden Sie das AWS CLI AWS SDK oder die Amazon S3 S3-REST-API, um die Sicherungsdatei direkt vom lokalen Server in einen S3-Bucket zu verschieben. Befindet sich der Ziel-S3-Bucket in einem AWS-Region , der weit vom Rechenzentrum entfernt ist, können Sie [Amazon S3 Transfer Acceleration](https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html) verwenden, um die Datei schneller zu übertragen. Verwenden Sie das [s3fs-fuse-Dateisystem](https://github.com/s3fs-fuse/s3fs-fuse), um den S3-Bucket auf der Instance zu mounten. EC2 

   **Methode 3C** — Installieren Sie den AWS DataSync Agenten im lokalen Rechenzentrum und verwenden Sie ihn dann, [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)um die Sicherungsdatei in einen Amazon S3 S3-Bucket zu verschieben. Verwenden Sie das [s3fs-fuse-Dateisystem](https://github.com/s3fs-fuse/s3fs-fuse), um den S3-Bucket auf der Instance zu mounten. EC2 
**Anmerkung**  
Sie können Amazon S3 File Gateway auch verwenden, um die großen Datenbank-Backup-Dateien in einen S3-Bucket im zu übertragen AWS Cloud. Weitere Informationen finden Sie unter [Verwenden von Amazon S3 File Gateway zum Übertragen von Backup-Dateien](amazon-s3-file-gateway.md) in diesem Handbuch.

1. Verwenden Sie myloader, um das Backup auf der Zieldatenbank-Instance wiederherzustellen. Anweisungen finden Sie unter [Verwendung von myloader](https://github.com/mydumper/mydumper_docs/blob/0e5cd71a5549c8a5de0105adf4d5f95953eadb67/myloader_usage.rst) ()GitHub.

1. (Optional) Sie können die Replikation zwischen der Quelldatenbank und der Zieldatenbankinstanz einrichten. Sie können die Replikation von Binärprotokollen (Binlog) verwenden, um Ausfallzeiten zu reduzieren. Weitere Informationen finden Sie hier:
   + [Einstellung der Konfiguration der Replikationsquelle](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) in der MySQL-Dokumentation
   + Für Amazon Aurora finden Sie Folgendes:
     + [Synchronisieren des Amazon Aurora MySQL-DB-Clusters mit der MySQL-Datenbank mithilfe der Replikation](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) in der Aurora-Dokumentation
     + [Verwendung der Binlog-Replikation in Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html) in der Aurora-Dokumentation
   + Informationen zu Amazon RDS finden Sie im Folgenden:
     + [Arbeiten mit der MySQL-Replikation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html) in der Amazon RDS-Dokumentation
     + [Arbeiten mit der MariaDB-Replikation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html) in der Amazon RDS-Dokumentation
   + Informationen zu Amazon EC2 finden Sie unter:
     + [Einrichtung der positionsbasierten Replikation von binären Logdateien](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html) in der MySQL-Dokumentation
     + [Repliken einrichten](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html) in der MySQL-Dokumentation
     + [Einrichtung der Replikation](https://mariadb.com/kb/en/setting-up-replication/) in der MariaDB-Dokumentation

## Vorteile
<a name="advantages-mydumper"></a>
+ MyDumper unterstützt Parallelität mithilfe von Multithreading, wodurch die Geschwindigkeit von Sicherungs- und Wiederherstellungsvorgängen verbessert wird.
+ MyDumper vermeidet teure Routinen zur Zeichensatzkonvertierung, wodurch sichergestellt wird, dass der Code hocheffizient ist.
+ MyDumper vereinfacht das Anzeigen und Analysieren von Daten, indem separate Dumping-Dateien für Tabellen und Metadaten verwendet werden.
+ MyDumper verwaltet Schnappschüsse für alle Threads und stellt genaue Positionen der primären und sekundären Protokolle bereit.
+ Sie können Perl Compatible Regular Expressions (PCRE) verwenden, um anzugeben, ob Tabellen oder Datenbanken ein- oder ausgeschlossen werden sollen.

## Einschränkungen
<a name="limitations-mydumper"></a>
+ Sie können ein anderes Tool wählen, wenn Ihre Datentransformationsprozesse Zwischenspeicherdateien im Flatformat statt im SQL-Format erfordern.
+ myloader importiert Datenbankbenutzerkonten nicht automatisch. Wenn Sie das Backup auf Amazon RDS oder Aurora wiederherstellen, erstellen Sie die Benutzer mit den erforderlichen Berechtigungen neu. Weitere Informationen finden Sie unter [Rechte für Master-Benutzerkonten](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.MasterAccounts.html) in der Amazon RDS-Dokumentation. Wenn Sie das Backup auf einer EC2 Amazon-Datenbank-Instance wiederherstellen, können Sie die Benutzerkonten der Quelldatenbank manuell exportieren und in die EC2 Instance importieren.

## Best Practices
<a name="best-practices-mydumper"></a>
+ Konfigurieren MyDumper Sie es so, dass jede Tabelle in Segmente unterteilt wird, z. B. 10.000 Zeilen in jedem Segment, und jedes Segment in eine separate Datei geschrieben wird. Dadurch ist es möglich, die Daten später parallel zu importieren.
+ Wenn Sie die InnoDB-Engine verwenden, verwenden Sie die `--trx-consistency-only` Option, um das Sperren zu minimieren.
+ Die Verwendung MyDumper zum Exportieren der Datenbank kann leseintensiv werden, und der Vorgang kann sich auf die Gesamtleistung der Produktionsdatenbank auswirken. Wenn Sie über eine Replikatdatenbankinstanz verfügen, führen Sie den Exportvorgang vom Replikat aus aus. Bevor Sie den Export aus dem Replikat ausführen, beenden Sie den Replikations-SQL-Thread. Dadurch kann der Exportvorgang schneller ausgeführt werden.
+ Exportieren Sie die Datenbank nicht während der Hauptgeschäftszeiten. Durch die Vermeidung von Spitzenzeiten kann die Leistung Ihrer primären Produktionsdatenbank während des Datenbankexports stabilisiert werden.
+ Amazon RDS for MySQL unterstützt das `keyring_aws` Plugin nicht. Weitere Informationen finden Sie unter [Bekannte Probleme und Einschränkungen](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.KnownIssuesAndLimitations.html#MySQL.Concepts.Limits.KeyRing). Um die lokalen verschlüsselten Tabellen zur Amazon RDS-Instance zu migrieren, müssen Sie in den Backup-Skripten `ENCRYPTION` oder `DEFAULT ENCRYPTION` aus der `CREATE TABLE` Syntax entfernen. Für die Verschlüsselung im Ruhezustand können Sie einen AWS Key Management Service (AWS KMS) -Schlüssel verwenden. Weitere Informationen finden Sie unter [Verschlüsseln von Amazon-RDS-Ressourcen](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html).

# mysqldump und mysqlpump
<a name="mysqldump-and-mysqlpump"></a>

[mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) und [mysqlpump](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html) sind native Datenbank-Backup-Tools für MySQL. MariaDB unterstützt mysqldump, aber nicht mysqlpump. Beide Tools erstellen logische Backups und sind Teil der MySQL-Client-Programme. mysqldump unterstützt Single-Thread-Verarbeitung. mysqlpump unterstützt die parallel Verarbeitung von Datenbanken und Objekten innerhalb von Datenbanken, um den Dump-Prozess zu beschleunigen. Es wurde in MySQL Version 5.7.8 eingeführt. mysqlpump wurde in MySQL Version 8.4 entfernt.

Das folgende Diagramm zeigt die wichtigsten Schritte bei der Migration einer Datenbank mithilfe einer mysqldump- oder mysqlpump-Backup-Datei.



![\[Diagramm der Migration einer Mysqldump- oder Mysqlpump-Backup-Datei und deren Wiederherstellung auf einer DB-Instance. AWS\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/mysqldump-mysqlpump-migration-aws.png)


Im Folgenden finden Sie die Schritte zur Verwendung von mysqldump oder mysqlpump zur Migration einer Datenbank auf die: AWS Cloud

1. Installieren Sie MySQL Shell auf dem lokalen Server. Anweisungen finden Sie in der [MySQL-Dokumentation unter Installation von MySQL Shell](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-install-linux-quick.html). Dadurch werden sowohl mysqldump als auch mysqlpump installiert.

1. Erstellen Sie mit mysqldump oder mysqlpump eine Sicherungskopie der lokalen Quelldatenbank. Anweisungen finden Sie unter [mysqldump und mysqlpump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) [in der MySQL-Dokumentation](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html) oder unter [Backups mit mysqldump erstellen in der MariaDB-Dokumentation](https://mariadb.com/kb/en/making-backups-with-mysqldump/). Weitere Hinweise zum Aufrufen von MySQL-Programmen und zum Angeben von Optionen finden Sie unter [MySQL-Programme verwenden](https://dev.mysql.com/doc/refman/8.0/en/programs-using.html).

1. Verschieben Sie die Sicherungsdatei AWS Cloud mithilfe einer der folgenden Methoden in eine EC2 Instanz in der:

   **Ansatz** **3A** — Mounten Sie ein [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-file-shares.html) - oder [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/efs-onpremises.html) -Dateisystem auf dem lokalen Server, auf dem Ihre Datenbank-Instance ausgeführt wird. Sie können AWS Direct Connect oder verwenden Site-to-Site VPN , um die Verbindung herzustellen. Sie können die Datenbank direkt auf der bereitgestellten Dateifreigabe sichern, oder Sie können die Sicherung in zwei Schritten durchführen, indem Sie die Datenbank in einem lokalen Dateisystem sichern und sie dann auf das gemountete FSx oder EFS-Volume hochladen. Mounten Sie als Nächstes das Amazon FSx - oder Amazon EFS-Dateisystem, das ebenfalls auf dem lokalen Server bereitgestellt ist, auf einer EC2 Instance.

   **Ansatz 3B** — Verwenden Sie das AWS CLI AWS SDK oder die Amazon S3 S3-REST-API, um die Sicherungsdatei direkt vom lokalen Server in einen S3-Bucket zu verschieben. Befindet sich der Ziel-S3-Bucket in einem AWS-Region , der weit vom Rechenzentrum entfernt ist, können Sie [Amazon S3 Transfer Acceleration](https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html) verwenden, um die Datei schneller zu übertragen. Verwenden Sie das [s3fs-fuse-Dateisystem](https://github.com/s3fs-fuse/s3fs-fuse), um den S3-Bucket auf der Instance zu mounten. EC2 

   **Methode 3C** — Installieren Sie den AWS DataSync Agenten im lokalen Rechenzentrum und verwenden Sie ihn dann, [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)um die Sicherungsdatei in einen Amazon S3 S3-Bucket zu verschieben. Verwenden Sie das [s3fs-fuse-Dateisystem](https://github.com/s3fs-fuse/s3fs-fuse), um den S3-Bucket auf der Instance zu mounten. EC2 
**Anmerkung**  
Sie können Amazon S3 File Gateway auch verwenden, um die großen Datenbank-Backup-Dateien in einen S3-Bucket im zu übertragen AWS Cloud. Weitere Informationen finden Sie unter [Verwenden von Amazon S3 File Gateway zum Übertragen von Backup-Dateien](amazon-s3-file-gateway.md) in diesem Handbuch.

1. Verwenden Sie die native Wiederherstellungsmethode, um das Backup in der Zieldatenbank wiederherzustellen. Anweisungen finden Sie unter [Reloading Backups im SQL-Format](https://dev.mysql.com/doc/refman/8.0/en/reloading-sql-format-dumps.html) in der MySQL-Dokumentation oder unter [Daten aus Dump-Dateien wiederherstellen](https://mariadb.com/kb/en/restoring-data-from-dump-files/) in der MariaDB-Dokumentation.

1. (Optional) Sie können die Replikation zwischen der Quelldatenbank und der Zieldatenbank-Instance einrichten. Sie können die Replikation von Binärprotokollen (Binlog) verwenden, um Ausfallzeiten zu reduzieren. Weitere Informationen finden Sie hier:
   + [Einstellung der Konfiguration der Replikationsquelle](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html) in der MySQL-Dokumentation
   + Für Amazon Aurora finden Sie Folgendes:
     + [Synchronisieren des Amazon Aurora MySQL-DB-Clusters mit der MySQL-Datenbank mithilfe der Replikation](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync) in der Aurora-Dokumentation
     + [Verwendung der Binlog-Replikation in Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html) in der Aurora-Dokumentation
   + Informationen zu Amazon RDS finden Sie im Folgenden:
     + [Arbeiten mit der MySQL-Replikation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html) in der Amazon RDS-Dokumentation
     + [Arbeiten mit der MariaDB-Replikation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html) in der Amazon RDS-Dokumentation
   + Informationen zu Amazon EC2 finden Sie unter:
     + [Einrichtung der positionsbasierten Replikation von binären Logdateien](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html) in der MySQL-Dokumentation
     + [Repliken einrichten](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html) in der MySQL-Dokumentation
     + [Einrichtung der Replikation](https://mariadb.com/kb/en/setting-up-replication/) in der MariaDB-Dokumentation

## Vorteile
<a name="advantages-mysqlpump-mysqldump"></a>
+ mysqldump und mysqlpump sind in der MySQL Server-Installation enthalten
+ Die von diesen Tools generierten Sicherungsdateien haben ein besser lesbares Format.
+ Bevor Sie die Sicherungsdatei wiederherstellen, können Sie die resultierende .sql-Datei mit einem Standard-Texteditor ändern.
+ Sie können eine bestimmte Tabelle, Datenbank oder sogar eine bestimmte Datenauswahl sichern.
+ mysqldump und mysqlpump sind unabhängig von der Maschinenarchitektur.

## Einschränkungen
<a name="limitations-mysqlpump-mysqldump"></a>
+ mysqldump ist ein Backup-Prozess mit einem einzigen Thread. Die Leistung bei der Erstellung von Backups ist für kleine Datenbanken gut, kann jedoch ineffizient werden, wenn die Backup-Größe größer als 10 GB ist.
+ Sicherungsdateien im logischen Format sind umfangreich, insbesondere wenn sie als Text gespeichert werden, und lassen sich oft nur langsam erstellen und wiederherstellen.
+ Die Datenwiederherstellung kann langsam sein, da das erneute Anwenden von SQL-Anweisungen in der Ziel-DB-Instance eine intensive Festplatten I/O - und CPU-Verarbeitung für das Einfügen, die Indexerstellung und die Durchsetzung von Einschränkungen der referentiellen Integrität erfordert.
+ Das Hilfsprogramm mysqlpump wird für MySQL-Versionen vor 5.7.8 oder für Versionen 8.4 und höher nicht unterstützt.
+ Standardmäßig erstellt mysqlpump keine Sicherungskopie der Systemdatenbanken, wie z. B. oder. `performance_schema` `sys` Um einen Teil der Systemdatenbank zu sichern, geben Sie ihm in der Befehlszeile einen expliziten Namen.
+ mysqldump sichert keine InnoDB-Anweisungen. `CREATE TABLESPACE`

**Anmerkung**  
Backups von CREATE TABLESPACE-Anweisungen und Systemdatenbanken sind nur nützlich, wenn Sie MySQL- oder MariaDB-Datenbanksicherungen auf einer Instanz wiederherstellen. EC2 Diese Backups werden nicht für Amazon RDS oder Aurora verwendet.

## Best Practices
<a name="best-practices-mysqlpump-mysqldump"></a>
+ Wenn Sie die Datenbanksicherung wiederherstellen, deaktivieren Sie die Schlüsselprüfungen`FOREIGN_KEY_CHECKS`, z. B. auf Sitzungsebene in der Zieldatenbank. Dadurch wird die Wiederherstellungsgeschwindigkeit erhöht.
+ Stellen Sie sicher, dass der Datenbankbenutzer über ausreichende [Rechte](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html) verfügt, um das Backup zu erstellen und wiederherzustellen.

# Geteiltes Backup
<a name="split-backup"></a>

Bei einer *Split-Backup-Strategie* migrieren Sie einen großen Datenbankserver, indem Sie das Backup in mehrere Teile aufteilen. Sie können unterschiedliche Ansätze verwenden, um jeden Teil des Backups zu migrieren. Dies kann die beste Option für die folgenden Anwendungsfälle sein:
+ **Großer Datenbankserver, aber kleine Einzeldatenbanken** — Dies ist ein guter Ansatz, wenn die Größe des gesamten Datenbankservers mehrfach ist, die Größe jeder einzelnen, unabhängigen Benutzerdatenbank TBs jedoch weniger als 1 TB beträgt. Um den Gesamtmigrationszeitraum zu verkürzen, können Sie einzelne Datenbanken separat und parallel migrieren.

  Lassen Sie uns ein Beispiel für einen lokalen Datenbankserver mit 2 TB verwenden. Dieser Server besteht aus vier Datenbanken mit jeweils 0,5 TB. Sie können Backups jeder einzelnen Datenbank separat erstellen. Beim Wiederherstellen der Sicherung können Sie entweder alle Datenbanken auf einer Instanz parallel wiederherstellen, oder wenn die Datenbanken unabhängig sind, können Sie jede Sicherung auf einer separaten Instanz wiederherstellen. Es hat sich bewährt, unabhängige Datenbanken auf separaten Instanzen wiederherzustellen, anstatt sie auf derselben Instanz wiederherzustellen. Weitere Informationen finden Sie unter Bewährte Methoden in diesem Handbuch.
+ **Großer Datenbankserver, aber kleine einzelne Datenbanktabellen** — Dies ist ein guter Ansatz, wenn die Größe des gesamten Datenbankservers mehrfach ist, die Größe jeder unabhängigen Datenbanktabelle TBs jedoch weniger als 1 TB beträgt. Um den Gesamtmigrationszeitraum zu verkürzen, können Sie unabhängige Tabellen einzeln migrieren.

  Lassen Sie uns ein Beispiel für eine Einzelbenutzerdatenbank verwenden, die 1 TB groß ist und die einzige Datenbank auf einem lokalen Datenbankserver ist. Es gibt 10 Tabellen in der Datenbank, von denen jede 100 GB groß ist. Sie können Backups jeder einzelnen Tabelle separat erstellen. Beim Wiederherstellen des Backups können Sie alle Tabellen auf einer Instanz parallel wiederherstellen.
+ **Eine Datenbank enthält sowohl transaktionale als auch nicht-transaktionale Workload-Tabellen**. Ähnlich wie im vorherigen Anwendungsfall können Sie einen Split-Backup-Ansatz verwenden, wenn Sie sowohl transaktionale als auch nicht-transaktionale Workload-Tabellen in derselben Datenbank haben.

  Lassen Sie uns ein Beispiel für eine 2-TB-Datenbank verwenden, die aus 0,5 TB an Tabellen für kritische Workloads besteht, die für die Online-Transaktionsverarbeitung (OLTP) verwendet werden, und einer einzelnen 1,5-TB-Tabelle, die für die Archivierung alter Daten verwendet wird. Sie können die Sicherung aller Datenbankobjekte mit Ausnahme der Archivtabelle als konsistente Sicherung mit einer einzigen Transaktion durchführen. Dann erstellen Sie eine weitere, separate Sicherung nur der Archivtabelle. Für die Sicherung der Archivtabelle können Sie auch erwägen, mehrere parallel Sicherungen zu erstellen, indem Sie Bedingungen verwenden, um die Anzahl der Zeilen in der Sicherungsdatei aufzuteilen. Im Folgenden wird ein Beispiel gezeigt:

  ```
  mysqldump -p your_db1 --tables your_table1 --where="column1 between 1 and 1000000 " > your_table1_part1.sql
  mysqldump -p your_db1 --tables your_table1 --where="column1 between 1000001 and 2000000 " > your_table1_part2.sql
  mysqldump -p your_db1 --tables your_table1 --where="column1 > 2000000 " > your_table1_part3.sql
  ```

  Beim Wiederherstellen der Sicherungsdateien können Sie die transaktionale Workload-Backup und die Sicherung der Archivtabelle parallel wiederherstellen.
+ **Einschränkungen der Rechenressourcen** — Wenn Sie auf dem lokalen Server nur begrenzte Rechenressourcen wie CPU, Arbeitsspeicher oder Festplatten-I/O haben, kann dies die Stabilität und Leistung bei der Erstellung des Backups beeinträchtigen. Anstatt ein vollständiges Backup zu erstellen, können Sie es in Teile aufteilen.

  Beispielsweise kann ein lokaler Produktionsserver stark mit Workloads belastet sein und über begrenzte CPU-Ressourcen verfügen. Wenn Sie ein Backup einer Datenbank mit mehreren Terabyte auf diesem Server in einem einzigen Durchlauf erstellen, kann dies zusätzliche CPU-Ressourcen verbrauchen und sich negativ auf den Produktionsserver auswirken. Anstatt die gesamte Datenbanksicherung zu erstellen, teilen Sie die Sicherung in mehrere Teile auf, z. B. jeweils 2—3 Tabellen.