翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 大規模 MySQL データベースと MariaDB データベースの移行オプション
オンプレミスの MySQL または MariaDB データベースから Amazon Relational Database Service (Amazon RDS) または Amazon Aurora MySQL 互換エディションのデータベースインスタンスに移行するには、幅広い選択肢があります。移行を成功させるには、適切な移行アプローチとツールを選択することが不可欠です。このガイドでは、使いやすさ、データサイズ、ダウンタイムの要件に基づいて選択肢を評価できます。
以下に、マルチテラバイトのセルフマネージド MySQL データベースを Amazon RDS、Aurora、または Amazon Elastic Compute Cloud (Amazon EC2) データベースインスタンスに効率的に移行するために使用できる一般的な移行ツールとアプローチを示します。
+ [Percona XtraBackup](percona-xtrabackup.md) (物理)
+ [MyDumper](mydumper.md) (論理)
+ [mysqldump と mysqlpump](mysqldump-and-mysqlpump.md) (論理)
+ [分割バックアップ](split-backup.md) (物理、論理、またはその両方)
以下に、マルチテラバイトの MySQL 互換 (MariaDB など) データベースを Amazon RDS、Aurora、または Amazon EC2 データベースインスタンスに効率的に移行するために使用できる一般的な移行ツールとアプローチを示します。
+ [MyDumper](mydumper.md) (論理)
+ [mysqldump と mysqlpump](mysqldump-and-mysqlpump.md) (論理)
+ [分割バックアップ](split-backup.md) (物理、論理、またはその両方)
移行ツールごとに、大容量のデータベースバックアップファイルを AWS クラウドに転送するために使用できるアプローチがいくつかあります。ツールごとにオプションが用意されているほか、Amazon S3 File Gateway を使用することもできます。詳細については、このガイドの「[Amazon S3 File Gateway を使用したバックアップファイルの転送](amazon-s3-file-gateway.md)」を参照してください。
# Percona XtraBackup
**重要**
Percona XtraBackup は MariaDB バージョン 10.3 以降ではサポートされておらず、バージョン 10.1 および 10.2 では部分的にのみサポートされています。
[Percona XtraBackup](https://docs.percona.com/percona-xtrabackup/8.0/index.html) は、MySQL および MariaDB 用の一般的なオープンソースのウォームバックアップソフトウェアで、InnoDB および XtraDB ストレージエンジンのノンブロッキングバックアップを作成します。MySQL または MariaDB サーバーで動作します。このツールとその機能や利点の詳細については、Percona XtraBackup ドキュメントの「[Percona XtraBackup の概要](https://docs.percona.com/percona-xtrabackup/8.0/about-xtrabackup.html)」を参照してください。
このツールは、物理的な移行アプローチを使用します。MySQL または MariaDB のデータディレクトリとその中のファイルを直接コピーします。そのため、100 GB を超えるような大規模なデータベースでは、他のツールよりも復元時間を大幅に短縮することができます。オンプレミスのソースデータベースのバックアップを作成し、バックアップファイルをクラウドに移行してから、新しいターゲットデータベースインスタンスにバックアップを復元します。
次の図は、Percona XtraBackup バックアップファイルを使用したデータベースの移行に関する大まかな手順を示しています。バックアップファイルのサイズに応じて、 AWS クラウドの Amazon Simple Storage Service (Amazon S3) バケットにバックアップを転送するオプションが 2 つあります。
![\[Percona XtraBackup ファイルの AWS DB インスタンスへの移行と復元を示す図。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/percona-xtrabackup-migration-aws.png)
Percona XtraBackup を使用してデータベースを AWS クラウドに移行する手順は次のとおりです。
1. Percona XtraBackup をオンプレミスサーバーにインストールします。Amazon Aurora MySQL バージョン 2 または Amazon RDS を使用している場合は、「[Installing Percona XtraBackup 2.4](https://docs.percona.com/percona-xtrabackup/2.4/installation.html)」を参照してください。Amazon Aurora MySQL バージョン 3 を使用している場合は、Percona XtraBackup ドキュメントの「[Installing Percona XtraBackup 8.0](https://docs.percona.com/percona-xtrabackup/8.0/installation.html)」を参照してください。
1. ソース MySQL または MariaDB データベースのフルバックアップを作成します。Percona XtraBackup 2.4 の手順については、「[完全バックアップ](https://docs.percona.com/percona-xtrabackup/2.4/backup_scenarios/full_backup.html)」を参照してください。Percona XtraBackup 8.0 の手順については、「[完全バックアップの作成](https://docs.percona.com/percona-xtrabackup/8.0/create-full-backup.html)」を参照してください。
1. 次のような組織内の承認されたサービスまたはツールを使用して、バックアップファイルをインターネット経由で転送します。
+ [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) (詳細については、このガイドの「[Amazon S3 File Gateway を使用したバックアップファイルの転送](amazon-s3-file-gateway.md)」を参照してください。)
+ [AWS Command Line Interface (AWS CLI)](https://aws.amazon.com/getting-started/hands-on/backup-to-s3-cli/)
1. Amazon S3 バケットから、バックアップファイルをターゲットデータベースインスタンスに復元します。手順については、以下を参照してください。
+ Aurora MySQL 互換エディションについては、Amazon RDS ドキュメントの「[Migrating data from MySQL by using an Amazon S3 bucket](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.Restore)」を参照してください。
+ Amazon RDS for MySQL または Amazon EC2 については、「[Importing data into a MySQL DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.Other.html)」を参照してください。
+ Amazon RDS for MariaDB または Amazon EC2 については、「[Importing data into a MariaDB DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MariaDB.Procedural.Importing.html)」を参照してください。
1. (オプション) ソースデータベースとターゲットデータベースインスタンス間のレプリケーションを設定できます。バイナリログ (binlog) レプリケーションを使用すると、ダウンタイムを短縮できます。詳細については次を参照してください:
+ MySQL ドキュメントの「[Setting the Replication Source Configuration](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html)」
+ Amazon Aurora については、以下を参照してください。
+ Aurora ドキュメントの「[Synchronizing the Amazon Aurora MySQL DB cluster with the MySQL database using replication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync)」
+ Aurora ドキュメントの「[Using binlog replication in Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html)」
+ Amazon RDS については、以下を参照してください。
+ Amazon RDS ドキュメントの「[MySQL のレプリケーションの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html)」
+ Amazon RDS ドキュメントの「[MariaDB のレプリケーションの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html)」
+ Amazon EC2 については、以下を参照してください。
+ MySQL ドキュメントの「[Setting Up Binary Log File Position Based Replication](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html)」
+ MySQL ドキュメントの「[Setting Up Replicas](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html)」
+ MariaDB ドキュメントの「[Setting Up Replication](https://mariadb.com/kb/en/setting-up-replication/)」
## 利点
+ Percona XtraBackup は物理的な移行アプローチを使用するため、復元プロセスは通常、論理的な移行アプローチを使用するツールよりも高速になります。これは、パフォーマンスの制限がデータ処理に必要なコンピューティングリソースによるものではなく、ディスクまたはネットワークのスループットによるためです。
+ 復元プロセスでは S3 バケットからターゲットデータベースインスタンスへファイルが直接コピーされるため、Percona XtraBackup ファイルは通常、他のツールで作成されたバックアップファイルよりも短時間で復元されます。
+ Percona XtraBackup は順応性があります。例えば、ファイルをすばやくコピーできるように複数のスレッドをサポートし、バックアップサイズを減らすための圧縮をサポートしています。
## 制限事項
+ Percona XtraBackup はソースデータベースサーバーにアクセスできる必要があるため、オフラインバックアップはできません。
+ Percona XtraBackup は、同一のシステムアーキテクチャを持つシステムでのみ使用できます。例えば、Intel for Windows Server で実行されているソースデータベースのバックアップを、ARM for Linux のターゲットサーバーに復元することはできません。
+ Percona XtraBackup は MariaDB バージョン 10.3 以降ではサポートされておらず、MariaDB バージョン 10.2 およびバージョン 10.1 では部分的にのみサポートされています。詳細については、MariaDB ナレッジベースの「[Percona XtraBackup Overview: Compatibility with MariaDB](https://mariadb.com/kb/en/percona-xtrabackup-overview/#compatibility-with-mariadb)」を参照してください。
+ Percona XtraBackup を使用して、ソース MariaDB データベースを Amazon RDS for MySQL や Aurora MySQL 互換などのターゲット MySQL データベースインスタンスに復元することはできません。
+ S3 バケットに保存できるデータの合計量とオブジェクトの数は無制限ですが、最大ファイルサイズは 5 TB です。バックアップファイルが 5 TB を超える場合は、複数の小さいファイルに分割できます。
+ `innodb_file_per_table` 設定がオフの場合、Percona XtraBackup は、`--tables`、`--tables-exclude`、`--tables-file`、`--databases`、`--databases-exclude`、または `--databases-file` を使用する部分バックアップをサポートしていません。Percona XtraBackup バージョン 2.4 の詳細については、「[部分バックアップ](https://docs.percona.com/percona-xtrabackup/2.4/innobackupex/partial_backups_innobackupex.html)」を参照してください。Percona XtraBackup バージョン 8.0 の詳細については、「[部分バックアップの作成](https://docs.percona.com/percona-xtrabackup/8.0/create-partial-backup.html)」を参照してください。
## ベストプラクティス
+ バックアッププロセスのパフォーマンスを向上させるには、以下を実行します。
+ [--parallel=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-parallel) を使用して複数のファイルを並行してコピーする
+ [--compress-threads=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-compress-threads) を使用して複数のファイルを並行して圧縮する
+ [--use-memory=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-use-memory) を使用してメモリを増やす
+ [--encrypt-threads=](https://docs.percona.com/percona-xtrabackup/2.4/xtrabackup_bin/xbk_option_reference.html#-encrypt-threads) を使用して複数のファイルを並行して暗号化する
+ ソースサーバーに、データベースバックアップファイルを取得するのに十分なスペースがあることを確認します。
+ Percona xbstream (.xbstream) 形式のファイルを使用してデータベースバックアップを生成します。詳細については、Percona XtraBackup ドキュメントの「[The xbstream binary overview](https://docs.percona.com/percona-xtrabackup/8.0/xbstream-binary-overview.html)」を参照してください。
# MyDumper
[MyDumper](https://github.com/mydumper/mydumper#what-is-mydumper) (GitHub) は、2 つのユーティリティで構成されるオープンソースの論理移行ツールです。
+ MyDumper は、MySQL データベースの整合性のあるバックアップをエクスポートします。複数の並列スレッドを使用したデータベースのバックアップが可能で、使用可能な CPU コアごとに最大 1 つのスレッドをサポートします。
+ myloader は、MyDumper によって作成されたバックアップファイルを読み取り、ターゲットデータベースインスタンスに接続してから、データベースを復元します。
次の図は、MyDumper バックアップファイルを使用したデータベースの移行に関する大まかな手順を示しています。このアーキテクチャ図には、バックアップファイルをオンプレミスデータセンターから AWS クラウドの EC2 インスタンスに移行するための 3 つのオプションが含まれています。
![\[MyDumper バックアップファイルを移行し、myloader を使用して AWS DB インスタンスに復元する図。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/mydumper-myloader-migration-aws.png)
MyDumper を使用してデータベースを AWS クラウドに移行する手順は次のとおりです。
1. MyDumper と myloader をインストールします。手順については、「[How to install mydumper/myloader](https://github.com/mydumper/mydumper#how-to-install-mydumpermyloader)」(GitHub) を参照してください。
1. MyDumper を使用して、ソース MySQL または MariaDB データベースのバックアップを作成します。手順については、「[MyDumper の使用方法](https://github.com/mydumper/mydumper#how-to-use-mydumper)」を参照してください。
1. 次のいずれかの方法 AWS クラウド を使用して、バックアップファイルを の EC2 インスタンスに移動します。
**アプローチ 3A** – [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-file-shares.html) または [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/efs-onpremises.html) ファイルシステムを、データベースインスタンスを実行するオンプレミスサーバーにマウントします。 AWS Direct Connect または を使用して接続 Site-to-Site VPN を確立できます。データベースをマウントされたファイル共有に直接バックアップすることも、データベースをローカルファイルシステムにバックアップしてからマウントされた FSx または EFS ボリュームにアップロードする 2 段階の手順でバックアップを実行することもできます。次に、オンプレミスサーバーにマウントされている Amazon FSx または Amazon EFS ファイルシステムを EC2 インスタンスにマウントします。
**アプローチ 3B** – AWS CLI、 AWS SDK、または Amazon S3 REST API を使用して、バックアップファイルをオンプレミスサーバーから S3 バケットに直接移動します。ターゲット S3 バケットがデータセンターから AWS リージョン 離れた にある場合は、[Amazon S3 Transfer Acceleration](https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html) を使用してファイルをより迅速に転送できます。[s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) ファイルシステムを使用して、EC2 インスタンスに S3 バケットをマウントします。
**アプローチ 3C** – オンプレミスデータセンターに AWS DataSync エージェントをインストールし、[AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html) を使用してバックアップファイルを Amazon S3 バケットに移動します。[s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) ファイルシステムを使用して、EC2 インスタンスに S3 バケットをマウントします。
**注記**
Amazon S3 File Gateway を使用して、大容量のデータベースバックアップファイルを AWS クラウドの S3 バケットに転送することもできます。詳細については、このガイドの「[Amazon S3 File Gateway を使用したバックアップファイルの転送](amazon-s3-file-gateway.md)」を参照してください。
1. myloader を使用して、ターゲットデータベースインスタンスのバックアップを復元します。手順については、「[myloader usage](https://github.com/mydumper/mydumper_docs/blob/0e5cd71a5549c8a5de0105adf4d5f95953eadb67/myloader_usage.rst)」(GitHub) を参照してください。
1. (オプション) ソースデータベースとターゲットデータベースインスタンス間のレプリケーションを設定できます。バイナリログ (binlog) レプリケーションを使用すると、ダウンタイムを短縮できます。詳細については次を参照してください:
+ MySQL ドキュメントの「[Setting the Replication Source Configuration](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html)」
+ Amazon Aurora については、以下を参照してください。
+ Aurora ドキュメントの「[Synchronizing the Amazon Aurora MySQL DB cluster with the MySQL database using replication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync)」
+ Aurora ドキュメントの「[Using binlog replication in Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html)」
+ Amazon RDS については、以下を参照してください。
+ Amazon RDS ドキュメントの「[MySQL のレプリケーションの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html)」
+ Amazon RDS ドキュメントの「[MariaDB のレプリケーションの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html)」
+ Amazon EC2 については、以下を参照してください。
+ MySQL ドキュメントの「[Setting Up Binary Log File Position Based Replication](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html)」
+ MySQL ドキュメントの「[Setting Up Replicas](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html)」
+ MariaDB ドキュメントの「[Setting Up Replication](https://mariadb.com/kb/en/setting-up-replication/)」
## 利点
+ MyDumper はマルチスレッドを使用して並列処理に対応しているため、バックアップと復元オペレーションの速度が向上します。
+ MyDumper はコストのかかる文字セットの変換ルーチンを回避し、コードの効率を高めるのに役立ちます。
+ MyDumper は、テーブルとメタデータで別々のファイルをダンプすることで、データビューと解析を簡素化します。
+ MyDumper は、すべてのスレッドにわたってスナップショットを維持し、プライマリログとセカンダリログの正確な位置を提供します。
+ Perl 互換正規表現 (PCRE) を使用して、テーブルまたはデータベースを含めるか除外するかを指定できます。
## 制限事項
+ データ変換プロセスで SQL 形式ではなくフラット形式の中間ダンプファイルが必要な場合は、別のツールを選択することが考えられます。
+ myloader はデータベースユーザーアカウントを自動的にインポートしません。Amazon RDS または Aurora にバックアップを復元する場合は、必要なアクセス許可を持つユーザーを再作成します。詳細については、Amazon RDS ドキュメントの「[Master user account privileges](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.MasterAccounts.html)」を参照してください。Amazon EC2 データベースインスタンスにバックアップを復元する場合は、ソースデータベースユーザーアカウントを手動でエクスポートしてから EC2 インスタンスにインポートできます。
## ベストプラクティス
+ 各テーブルをセグメントに分割し (セグメントごとに 10,000 行など)、各セグメントを個別のファイルに書き込むように MyDumper を設定します。これにより、後でデータを並行してインポートできます。
+ InnoDB エンジンを使用している場合は、`--trx-consistency-only` オプションを使用してロックを最小限に抑えます。
+ MyDumper を使用してデータベースをエクスポートすると、読み取り負荷が高まり、処理が本番データベースの全体的なパフォーマンスに影響を与える可能性があります。レプリカデータベースインスタンスがある場合は、レプリカからエクスポートプロセスを実行します。レプリカからエクスポートを実行する前に、レプリケーション SQL スレッドを停止します。これにより、エクスポートプロセスをより迅速に実行できます。
+ 営業時間のピーク時にデータベースをエクスポートしないでください。ピーク時間を避けることで、データベースのエクスポート中に、プライマリ本番データベースのパフォーマンスを安定させることができます。
+ Amazon RDS for MySQL は `keyring_aws` プラグインをサポートしていません。詳細については、「[既知の問題と制限](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.KnownIssuesAndLimitations.html#MySQL.Concepts.Limits.KeyRing)」を参照してください。オンプレミスの暗号化されたテーブルを Amazon RDS インスタンスに移行するには、バックアップスクリプトで、`CREATE TABLE` 構文から `ENCRYPTION` または `DEFAULT ENCRYPTION` を削除する必要があります。保存時の暗号化には、 AWS Key Management Service (AWS KMS) キーを使用してください。詳細については、「[Amazon RDS リソースの暗号化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)」を参照してください。
# mysqldump と mysqlpump
[mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) と [mysqlpump](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html) は、MySQL のネイティブデータベースバックアップツールです。MariaDB は mysqldump をサポートしていますが、mysqlpump はサポートしていません。これらのツールはいずれも論理バックアップを作成するもので、MySQL クライアントプログラムの一部です。mysqldump はシングルスレッド処理をサポートする一方、mysqlpump はデータベースとデータベース内のオブジェクトの並列処理をサポートし、ダンププロセスを高速化します。mysqlpump は MySQL バージョン 5.7.8 で導入されましたが、MySQL バージョン 8.4 で削除されました。
次の図は、mysqldump または mysqlpump バックアップファイルを使用したデータベースの移行に関する大まかな手順を示しています。
![\[mysqldump または mysqlpump バックアップファイルを移行し、 AWS DB インスタンスで復元する図。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/images/mysqldump-mysqlpump-migration-aws.png)
mysqldump または mysqlpump を使用してデータベースを AWS クラウドに移行する手順は次のとおりです。
1. オンプレミスサーバーに MySQL シェルをインストールします。手順については、MySQL ドキュメントの「[MySQL Shell のインストール](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-install-linux-quick.html)」を参照してください。これにより、mysqldump と mysqlpump の両方がインストールされます。
1. mysqldump または mysqlpump を使用して、ソースのオンプレミスデータベースのバックアップを作成します。手順については、MySQL ドキュメントの「[mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html)」と「[mysqlpump](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html)」を参照するか、または、MariaDB ドキュメントの「[Making Backups with mysqldump](https://mariadb.com/kb/en/making-backups-with-mysqldump/)」を参照してください。MySQL プログラムを呼び出す方法とオプションを指定する方法の詳細については、「[MySQLプログラムの使用](https://dev.mysql.com/doc/refman/8.0/en/programs-using.html)」を参照してください。
1. 次のいずれかの方法 AWS クラウド を使用して、バックアップファイルを の EC2 インスタンスに移動します。
**アプローチ** **3A** – [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-file-shares.html) または [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/efs-onpremises.html) ファイルシステムを、データベースインスタンスを実行するオンプレミスサーバーにマウントします。 AWS Direct Connect または を使用して接続 Site-to-Site VPN を確立できます。データベースをマウントされたファイル共有に直接バックアップすることも、データベースをローカルファイルシステムにバックアップしてからマウントされた FSx または EFS ボリュームにアップロードする 2 段階の手順でバックアップを実行することもできます。次に、オンプレミスサーバーにマウントされている Amazon FSx または Amazon EFS ファイルシステムを EC2 インスタンスにマウントします。
**アプローチ 3B** – AWS CLI、 AWS SDK、または Amazon S3 REST API を使用して、バックアップファイルをオンプレミスサーバーから S3 バケットに直接移動します。ターゲット S3 バケットがデータセンターから AWS リージョン 遠く離れた にある場合は、[Amazon S3 Transfer Acceleration](https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html) を使用してファイルをより迅速に転送できます。[s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) ファイルシステムを使用して、EC2 インスタンスに S3 バケットをマウントします。
**アプローチ 3C** – オンプレミスデータセンターに AWS DataSync エージェントをインストールし、[AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html) を使用してバックアップファイルを Amazon S3 バケットに移動します。[s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) ファイルシステムを使用して、EC2 インスタンスに S3 バケットをマウントします。
**注記**
Amazon S3 File Gateway を使用して、大容量のデータベースバックアップファイルを AWS クラウドの S3 バケットに転送することもできます。詳細については、このガイドの「[Amazon S3 File Gateway を使用したバックアップファイルの転送](amazon-s3-file-gateway.md)」を参照してください。
1. ネイティブ復元メソッドを使用して、ターゲットデータベースのバックアップを復元します。手順については、MySQL ドキュメントの「[Reloading SQL-Format Backups](https://dev.mysql.com/doc/refman/8.0/en/reloading-sql-format-dumps.html)」または MariaDB ドキュメントの「[Restoring Data from Dump Files](https://mariadb.com/kb/en/restoring-data-from-dump-files/)」を参照してください。
1. (オプション) ソースデータベースとターゲットデータベースインスタンス間のレプリケーションを設定できます。バイナリログ (binlog) レプリケーションを使用すると、ダウンタイムを短縮できます。詳細については次を参照してください:
+ MySQL ドキュメントの「[Setting the Replication Source Configuration](https://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html)」
+ Amazon Aurora については、以下を参照してください。
+ Aurora ドキュメントの「[Synchronizing the Amazon Aurora MySQL DB cluster with the MySQL database using replication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync)」
+ Aurora ドキュメントの「[Using binlog replication in Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html)」
+ Amazon RDS については、以下を参照してください。
+ Amazon RDS ドキュメントの「[MySQL のレプリケーションの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.html)」
+ Amazon RDS ドキュメントの「[MariaDB のレプリケーションの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MariaDB.Replication.html)」
+ Amazon EC2 については、以下を参照してください。
+ MySQL ドキュメントの「[Setting Up Binary Log File Position Based Replication](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto.html)」
+ MySQL ドキュメントの「[Setting Up Replicas](https://dev.mysql.com/doc/refman/8.0/en/replication-setup-replicas.html)」
+ MariaDB ドキュメントの「[Setting Up Replication](https://mariadb.com/kb/en/setting-up-replication/)」
## 利点
+ mysqldump と mysqlpump は MySQL Server のインストールに含まれています。
+ これらのツールによって生成されたバックアップファイルは、より読みやすい形式になります。
+ 結果として得られる .sql ファイルは、バックアップファイルを復元する前に、標準のテキストエディタを使用して変更できます。
+ 特定のテーブル、データベース、または特定のデータの選択をバックアップできます。
+ mysqldump と mysqlpump はマシンアーキテクチャに依存しません。
## 制限事項
+ mysqldump はシングルスレッドのバックアッププロセスです。バックアップ取得時のパフォーマンスは、小規模データベースには適していますが、バックアップサイズが 10 GB を超えると非効率になる可能性があります。
+ 論理形式のバックアップファイルは、特にテキストとして保存された場合は大量であり、作成と復元に時間がかかることがよくあります。
+ ターゲット DB インスタンスに SQL ステートメントを再適用するには、挿入、インデックス作成、参照整合性制約の適用のために大量のディスク I/O と CPU 処理が必要になるため、データの復元が遅くなる可能性があります。
+ mysqlpump ユーティリティは、MySQL バージョン 5.7.8 以前またはバージョン 8.4 以降ではサポートされていません。
+ デフォルトでは、mysqlpump は `performance_schema` や `sys` などのシステムデータベースのバックアップを取りません。システムデータベースの一部をバックアップするには、コマンドラインで明示的に名前を指定します。
+ mysqldump は InnoDB `CREATE TABLESPACE` ステートメントをバックアップしません。
**注記**
CREATE TABLESPACE ステートメントとシステムデータベースのバックアップは、MySQL または MariaDB データベースのバックアップを EC2 インスタンスに復元する場合にのみ有用です。これらのバックアップは Amazon RDS または Aurora には使用されません。
## ベストプラクティス
+ データベースバックアップを復元する場合は、ターゲットデータベースのセッションレベルで、`FOREIGN_KEY_CHECKS` などのキーチェックを無効にします。これにより、復元速度が向上します。
+ データベースユーザーにバックアップを作成および復元するための十分な[権限](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html)があることを確認します。
# 分割バックアップ
*分割バックアップ*戦略とは、バックアップを複数のパーツに分割して大規模データベースサーバーを移行することをいいます。バックアップの各パーツを移行するには、さまざまな方法を使用できます。これは、次のユースケースに最適なオプションです。
+ **データベースサーバーは大きいが個々のデータベースは小さい** – データベースサーバーの合計サイズは数 TB であるが、個々の独立したユーザーデータベースのサイズは 1 TB 未満の場合に適しています。移行期間全体を短縮するために、個々のデータベースを個別に移行することも並行して移行することもできます。
オンプレミスの 2 TB データベースサーバーの例を見てみましょう。このサーバーは、それぞれ 0.5 TB の 4 つのデータベースで構成されています。個々のデータベースのバックアップは個別に作成できます。バックアップを復元するときは、インスタンス上のすべてのデータベースを並行して復元するか、データベースが独立している場合は、各バックアップを個別のインスタンスで復元できます。ベストプラクティスは、独立したデータベースを同じインスタンスで復元するのではなく、別のインスタンスで復元することです。詳細については、このガイドの「ベストプラクティス」を参照してください。
+ **データベースサーバーは大きいが個々のデータベーステーブルは小さい** – データベースサーバーの合計サイズが複数 TB であるが、個々の独立したデータベーステーブルのサイズが 1 TB 未満の場合に適しています。移行期間全体を短縮するために、独立したテーブルを個別に移行できます。
1 TB の単一のユーザーデータベースが、オンプレミスデータベースサーバー内の唯一のデータベースである例を見てみましょう。データベースには 10 個のテーブルがあり、それぞれが 100 GB です。個々のテーブルのバックアップはそれぞれ個別に作成できます。バックアップを復元するときは、インスタンス上のすべてのテーブルを並行して復元できます。
+ **データベースにトランザクションワークロードテーブルと非トランザクションワークロードテーブルの両方が含まれている** – 前のユースケースと同様に、同じデータベース内にトランザクションワークロードテーブルと非トランザクションワークロードテーブルの両方がある場合、分割バックアップアプローチを使用できます。
オンライントランザクション処理 (OLTP) に使用される 0.5 TB の重要なワークロードテーブルと、古いデータのアーカイブに使用される単一の 1.5 TB テーブルで構成される、2 TB のデータベースの例を見てみましょう。アーカイブテーブルを除くすべてのデータベースオブジェクトのバックアップを、単一トランザクションの一貫性のあるバックアップとして取得できます。次に、もう 1 つアーカイブテーブルのみの個別のバックアップを取ります。アーカイブテーブルのバックアップでは、条件を使用してバックアップファイルの行数を分割することで、複数の並列バックアップを取ることも検討できます。以下に例を示します。
```
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
```
バックアップファイルを復元するときは、トランザクションワークロードのバックアップとアーカイブテーブルのバックアップを並行して復元できます。
+ **コンピューティングリソースの制限事項** – CPU、メモリ、ディスク I/O など、オンプレミスサーバー内のコンピューティングリソースが限られている場合、バックアップを取る際の安定性とパフォーマンスが影響を受ける可能性があります。完全なバックアップを取る代わりに、パーツに分割できます。
例えば、オンプレミスの本番稼働用サーバーで、ワークロードの負荷が大きく、CPU リソースが限られているとします。このサーバーでマルチテラバイトデータベースのバックアップを一度に実行すると、CPU リソースの消費量が増え、本番稼働用サーバーに悪影響を及ぼす可能性があります。データベース全体のバックアップを取る代わりに、テーブル 2～3 個ずつなど、複数のパーツに分割してバックアップを取ります。