# Amazon RDS for MariaDB DB インスタンスへのデータのインポート
さまざまな手法を使用して、RDS for MariaDB DB インスタンスにデータをインポートできます。最善のアプローチは、いくつかの要因によって異なります。
+ データのソース
+ データ量
+ 1 回限りのインポートか継続的なインポートか
+ ダウンタイムの長さ
データと同時にアプリケーションも移行する場合は、ダウンタイムの長さを考慮することが重要です。
次の表は、RDS for MariaDB DB インスタンスにデータをインポートする手法の一覧です。
**注記**
Amazon RDS は、Amazon S3 for MariaDB の `mariadb-backup` またはインポートをサポートしていません。
| ソース | データ量 | 1 回または進行中 | アプリケーションのダウンタイム | 手法 | 詳細情報 |
| --- | --- | --- | --- | --- | --- |
| オンプレミスまたは Amazon EC2 の既存の MariaDB データベース | いずれか | 継続的 | Minimal | レプリケーション元として既存の MariaDB データベースを使用してレプリケーションを設定します。 MariaDB DB インスタンスへのレプリケーションを設定するには、外部インスタンスが MariaDB バージョン 10.0.24 以降の場合は MariaDB グローバルトランザクション識別子 (GTID) を使用し、10.0.24 より前のバージョンでは MariaDB インスタンスのバイナリログ座標を使用できます。MariaDB GTID の実装方法は、Amazon RDS ではサポートされていない MySQL GTID とは異なります。 | [外部のソースインスタンスを使用したバイナリログファイル位置のレプリケーションの設定](MySQL.Procedural.Importing.External.ReplMariaDB.md) [ダウンタイムを短縮して Amazon RDS for MariaDB DB インスタンスにデータをインポートする](mariadb-importing-data-reduced-downtime.md) |
| 既存のデータベース | すべて | 1 回または進行中 | 最小限 | AWS Database Migration Service を使用してダウンタイムを最小限にしてデータベースを移行し、多くのデータベース DB エンジンで継続的なレプリケーションを継続します。 | 「*AWS Database Migration Service ユーザーガイド*」の「[AWS Database Migration Service とは?](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)」および「[MySQL 互換データベースの AWS DMS のターゲットとしての使用](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.MySQL.html)」 |
| 既存の MariaDB DB インスタンス | いずれか | 1 回または進行中 | 最小限 | 継続的なレプリケーション用のリードレプリカを作成します。新しい DB インスタンスの 1 回限りの作成用のリードレプリカを昇格させます。 | [DB インスタンスのリードレプリカの操作](USER_ReadRepl.md) |
| 既存の MariaDB データベース | スモール | 1 回 | ある程度 | コマンドラインユーティリティを使用して、MariaDB DB インスタンスに直接データをコピーします。 | [外部の MariaDB データベースから Amazon RDS for MariaDB DB インスタンスにデータをインポートする](mariadb-importing-data-external-database.md) |
| 既存のデータベースに保存されないデータ | ミディアム | 1 回 | ある程度 | フラットファイルを作成し、MariaDB の `LOAD DATA LOCAL INFILE` ステートメントを使用してインポートします。 | [任意のソースから Amazon RDS for MariaDB DB インスタンスにデータをインポートする](mariadb-importing-data-any-source.md) |
**注記**
`mysql` システムデータベースには、DB インスタンスへのログインとデータへのアクセスに必要な認証と認可の情報が含まれています。DB インスタンスにある `mysql` データベースのテーブル、データ、その他のコンテンツを削除、変更、名前変更、または切り捨てを行うとエラーが発生し、DB インスタンスやデータにアクセスできなくなる場合があります。この場合は、AWS CLI の [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) コマンドを使用して、スナップショットから DB インスタンスを復元できます。DB インスタンスは、[https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) コマンドを使用して復元できます。
# MariaDB のデータインポートに関する考慮事項
以下のコンテンツには、MariaDB へのデータのロードに関連する技術情報が含まれています。このコンテンツは、MariaDB サーバーアーキテクチャに精通しているユーザーを対象としています。
## バイナリログ記録
バイナリログ記録を有効にすると、データロードのパフォーマンスが低下し、ログを無効にした場合と比較して最大 4 倍の追加のディスク領域が必要になります。データのロードに使用されるトランザクションサイズは、システムのパフォーマンスとディスク容量のニーズに直接影響します。トランザクションが大きいほど、より多くのリソースが必要になります。
## トランザクションサイズ
トランザクションサイズは、MariaDB データロードの以下の側面に影響します。
+ リソース消費
+ ディスクスペースの使用率
+ プロセスの再開
+ 復旧時間
+ 入力形式 (フラットファイルまたは SQL)
このセクションでは、トランザクションサイズがバイナリログ作成に与える影響について説明し、大量のデータロード中にバイナリログ作成を無効にするケースを作成します。Amazon RDS 自動バックアップ保持期間を設定することで、バイナリログ作成を有効または無効にすることができます。値が 0 以外の場合はバイナリログ作成が有効になり、0 の場合は無効になります。詳細については、「[バックアップの保存期間](USER_WorkingWithAutomatedBackups.BackupRetention.md)」を参照してください。
このセクションでは、大規模なトランザクションが InnoDB に与える影響と、トランザクションサイズを小さく保つことが重要な理由についても説明します。
### 小さいトランザクション
トランザクションが小さい場合、バイナリログ作成により、データのロードに必要なディスク書き込み数が 2 倍になります。この影響は、他のデータベースセッションのパフォーマンスを著しく低下させ、データのロードに必要な時間を長くします。劣化の程度は、以下の要因に一部依存します。
+ アップロードレート
+ ロード中に発生するその他のデータベースアクティビティ
+ Amazon RDS DB インスタンスの容量
バイナリログは、バックアップおよび削除されるまでにロードされたデータの量とほぼ同じディスク容量を消費します。Amazon RDS は、バイナリログを頻繁にバックアップして削除することで、この容量を最小限に抑えます。
### 大きいトランザクション
大規模なトランザクションの場合、バイナリログによって、次の理由により IOPS とディスク使用量が 3 倍になります。
+ バイナリログキャッシュは、トランザクションデータを一時的にディスクに保存します。
+ このキャッシュはトランザクションのサイズに応じて大きくなり、ディスク領域を消費します。
+ トランザクション (コミットまたはロールバック) が完了すると、システムはキャッシュをバイナリログにコピーします。
このプロセスでは、データのコピーが 3 つ作成されます。
+ 元のデータ
+ ディスク上のキャッシュ
+ 最後のバイナリログエントリ
書き込みオペレーションごとに追加の IO が発生し、パフォーマンスにさらに影響を及ぼします。
このため、バイナリログ記録には、ログ記録を無効にした場合と比較して 3 倍のディスク容量が必要です。例えば、1 つのトランザクションとして 10 GiB のデータをロードすると、次の 3 つのコピーが作成されます。
+ テーブルデータに 10 GiB
+ バイナリログキャッシュに 10 GiB
+ バイナリログファイルに 10 GiB
必要な一時ディスク容量の合計は 30 GiB です。
ディスク容量に関する重要な考慮事項:
+ キャッシュファイルは、セッションが終了するか、新しいトランザクションによって別のキャッシュが作成されるまで保持されます。
+ バイナリログはバックアップされるまで保持され、長期間にわたって 20 GiB (キャッシュとログ) が保持される可能性があります。
`LOAD DATA LOCAL INFILE` を使用してデータをロードする場合、ロード前に行われたバックアップからデータベースを復元する必要がある場合に備えて、データ復旧によって 4 番目のコピーが作成されます。復旧時に、MariaDB はバイナリログからフラットファイルにデータを抽出します。その後 MariaDB は `LOAD DATA LOCAL INFILE` を実行します。上記の例の場合、この復旧には合計 40 GiB、つまりテーブル、キャッシュ、ログ、ローカルファイルごとに 10 GiB の一時ディスク領域が必要です。少なくとも 40 GiB の空きディスク容量がないと、復旧は失敗します。
### 大規模なデータロードの最適化
大量のデータをロードする場合は、バイナリログを無効にして、オーバーヘッドとディスク領域の要件を削減します。バイナリログ記録を無効にするには、バックアップ保持期間を 0 に設定します。ロードが完了したら、バックアップ保持期間を適切なゼロ以外の値に復元します。詳細については、設定テーブルの「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」および「[バックアップ保持期間](USER_ModifyInstance.Settings.md)」を参照してください。
**注記**
DB インスタンスがリードレプリカのソース DB インスタンスである場合、バックアップ保持期間を 0 に設定することはできません。
データをロードする前に、DB スナップショットを作成することをお勧めします。詳細については、「[手動バックアップの管理](USER_ManagingManualBackups.md)」を参照してください。
## InnoDB
undo ログと復旧のオプションに関する以下の情報は、InnoDB トランザクションを小さくしてデータベースのパフォーマンスを最適化することをサポートしています。
### InnoDB の undo ログについて
undo ログは、トランザクションのロールバックを有効にし、マルチバージョン同時実行制御 (MVCC) をサポートするログ記録メカニズムです。
MariaDB 10.11 以前のバージョンでは、undo ログは InnoDB システムテーブルスペース (通常は ibdata1) に保存され、パージスレッドによって削除されるまで保持されます。その結果、大規模なデータロードトランザクションによってシステムテーブルスペースが非常に大きくなり、データベースを再作成しない限り再利用できないディスク領域が消費される可能性があります。
すべての MariaDB バージョンでは、最も古いアクティブなトランザクションがコミットまたはロールバックされるまで、パージスレッドは undo ログの削除を待機する必要があります。データベースが、ロード中に他のトランザクションを処理する場合、そのトランザクションがコミットされ、他のトランザクションが MVCC の undo ログを必要としない場合でも、それらの undo ログも蓄積され、削除できません。この場合、読み取り専用トランザクションを含むすべてのトランザクションが遅くなります。このスローダウンは、すべてのトランザクションが、ロードトランザクションだけでなく、任意のトランザクションが変更するすべての行にアクセスするために発生します。実際には、トランザクションは、長時間実行されるロードトランザクションによって undo ログのクリーンアップ中に消去されなかった undo ログをスキャンする必要があります。これは、変更された行にアクセスするオペレーションのパフォーマンスに影響します。
### InnoDB トランザクション復旧オプション
InnoDB はコミットオペレーションを最適化しますが、大規模なトランザクションのロールバックは遅くなります。復旧を高速化するには、ポイントインタイムリカバリを実行するか、DB スナップショットを復元します。詳細については、「[ポイントインタイムリカバリ](USER_PIT.md)」および「[DB インスタンスへの復元](USER_RestoreFromSnapshot.md)」を参照してください。
## データインポート形式
MariaDB は、フラットファイルと SQL の 2 つのデータインポート形式をサポートしています。各形式に関する情報を確認して、ニーズに最適なオプションを決定します。
### フラットファイル
小規模なトランザクションの場合は、`LOAD DATA LOCAL INFILE` を使用してフラットファイルをロードします。このデータインポート形式は、SQL を使用する場合に比べて次のようなメリットがあります。
+ ネットワークトラフィックの削減
+ データ転送コストの削減
+ データベース処理オーバーヘッドの減少
+ より高速な処理
`LOAD DATA LOCAL INFILE` はフラットファイル全体を 1 つのトランザクションとしてロードします。個々のファイルのサイズを小さく保つと、次の利点があります。
+ **再開機能** - どのファイルがロードされたかを追跡できます。ロード中に問題が発生した場合、中断したところから再開できます。一部のデータを Amazon RDS に再送信する必要がある場合でも、ファイルが小さいと、再送信される量は最小限ですみます。
+ **同時データロード** – 単一ファイルのロードに十分な IOPS とネットワーク帯域幅がある場合、同時にロードすれば時間を節約できます。
+ **ロード速度制御** – データロードが他のプロセスに悪影響を及ぼす場合は、ファイル間の間隔を増やすことでロード速度を制御できます。
大規模なトランザクションでは、`LOAD DATA LOCAL INFILE` を使用してデータをインポートするメリットが減ります。大量のデータを小さなファイルに分割できない場合は、SQL の使用を検討してください。
### SQL
SQL にはフラットファイルに比べて、トランザクションサイズを簡単に小さく保つことができるという大きなメリットがあります。ただし、SQL のロードにはフラットファイルよりもかなり時間がかかる場合があります。また、障害が発生した後、どこから再開するかを判断するのが難しい場合があります。mariadb-dump ファイルを再開することはできません。mariadb-dump ファイルのロード中にエラーが発生した場合、ロードを再開するにはファイルを変更するか置き換える必要があります。または、障害の原因を修正した後、ロード前の時点に復元してファイルを再開する必要があります。詳細については、「[ポイントインタイムリカバリ](USER_PIT.md)」を参照してください。
## データベースチェックポイントに Amazon RDS DB スナップショットを使用する
バイナリログ記録を使用せずに、数時間または数日など長期間にわたってデータをロードする場合は、DB スナップショットを使用して、データの安全性を確保するために定期的なチェックポイントを提供します。各 DB スナップショットは、システム障害やデータ破損イベント時の復旧ポイントとして機能するデータベースインスタンスの一貫したコピーを作成します。DB スナップショットは高速であるため、頻繁なチェックポイント作成によるロードパフォーマンスへの影響は最小限に抑えられます。データベースの耐久性や復旧機能に影響を与えることなく、以前の DB スナップショットを削除できます。DB スナップショットの詳細については、「[手動バックアップの管理](USER_ManagingManualBackups.md)」を参照してください。
## データベースのロード時間を短縮する
以下の項目は、ロード時間を短縮するための追加のヒントです。
+ MariaDB データベースにデータをロードする前に、すべてのセカンダリインデックスを作成します。他のデータベースシステムとは異なり、MariaDB はセカンダリインデックスを追加または変更するときにテーブル全体を再構築します。このプロセスでは、インデックスが変更された新しいテーブルが作成され、すべてのデータがコピーされ、元のテーブルが削除されます。
+ プライマリキーの順序でデータをロードします。InnoDB テーブルの場合、これによりロード時間が 75%～80% 短縮され、データファイルサイズが 50% 短縮されます。
+ `foreign_key_checks` を `0` に設定して、外部キーの制約を無効にします。これは多くの場合、`LOAD DATA LOCAL INFILE` を使用してロードされたフラットファイルで必要となります。どのロードでも、外部キーチェックを無効にすると、データのロードが高速化されます。ロードが完了したら、`foreign_key_checks` を `1` に設定して制約を再度有効にし、データを検証します。
+ リソース制限に近づかない限り、データを同時にロードします。複数のテーブルセグメント間で同時ロードを有効にするには、必要に応じてパーティションテーブルを使用します。
+ SQL 実行のオーバーヘッドを減らすには、複数の `INSERT` ステートメントを単一の複数値 `INSERT` オペレーションに結合します。`mariadb-dump` は、この最適化を自動的に実装します。
+ `innodb_flush_log_at_trx_commit` を `0` に設定することで、InnoDB ログ IO オペレーションを減らします。ロードが完了したら、`innodb_flush_log_at_trx_commit` を `1` に戻します。
**警告**
`innodb_flush_log_at_trx_commit` を `0` に設定すると、InnoDB はコミットごとではなく毎秒ログをフラッシュします。この設定はパフォーマンスを向上させますが、システム障害時にトランザクションが失われるリスクがあります。
+ リードレプリカがない DB インスタンスにデータをロードする場合は、`sync_binlog` を `0` に設定します。ロードが完了したら、`sync_binlog parameter` を `1` に戻します。
+ DB インスタンスをマルチ AZ 配置に変換する前に、シングル AZ DB インスタンスにデータをロードします。DB インスタンスが既にマルチ AZ 配置を使用している場合は、データロードのためにシングル AZ 配置に切り替えることはお勧めしません。これで実現できる改善はわずかだけです。
# 外部の MariaDB データベースから Amazon RDS for MariaDB DB インスタンスにデータをインポートする
既存の MariaDB データベースから RDS for MariaDB DB インスタンスに、データをインポートできます。これを行うには、[mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) または [mariadb-dump](https://mariadb.com/kb/en/mariadb-dump/) を使用してデータベースをコピーし、データベースを RDS for MariaDB DB インスタンスに直接パイプ処理します。`mysqldump` または `mariadb-dump` コマンドラインユーティリティは、データのバックアップや、MariaDB サーバーから別の場所への転送によく使用されます。このユーティリティは、MariaDB クライアントソフトウェアに含まれています。
MariaDB 11.0.1 以降では、`mariadb-dump` を `mysqldump` の代わりに使用する必要があります。
外部のデータベースから Amazon RDS DB インスタンスにデータを移動するための一般的な `mysqldump` コマンドは、次の例のようになります。値を自分の情報に置き換えます。MariaDB 11.0.1 以降のバージョンでは、`mysqldump` を `mariadb-dump` に置き換えます。
```
mysqldump -u local_user \
--databases database_name \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mariadb -u RDS_user \
--port=port_number \
--host=host_name \
-pRDS_password
```
**重要**
`-p` オプションと入力するパスワードの間にスペースを残していないことを確認します。
セキュリティのベストプラクティスとして、この例に表示されているプロンプト以外の認証情報を指定してください。
次の推奨事項と考慮事項に注意してください。
+ ダンプファイルから次のスキーマを除外します。
+ `sys`
+ `performance_schema`
+ `information_schema`
`mysqldump` および `mariadb-dump` ユーティリティは、これらのスキーマをデフォルトで除外します。
+ ユーザーや権限を移行する必要がある場合は、再作成するデータ制御言語 (DCL) を生成するツールの使用を検討します。例えば、[pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html) ユーティリティがあります。
+ インポートを実行するには、そのユーザーに DB インスタンスへのアクセスが許可されていることを確認してください。詳細については、「[セキュリティグループによるアクセス制御](Overview.RDSSecurityGroups.md)」を参照してください。
使用するパラメータは次のとおりです。
+ `-u local_user` - ユーザー名を指定します。このパラメータの初回の使用では、`--databases` パラメータによって識別されたローカル MariaDB データベースのユーザーアカウントの名前を指定します。
+ `--databases database_name` — Amazon RDS にインポートするローカル MariaDB インスタンスのデータベースの名前を指定します。
+ `--single-transaction` - ローカルデータベースからロードされたすべてのデータが、ある時点において一貫していることを確認します。`mysqldump` または `mariadb-dump` によるデータの読み取り中に他のプロセスがデータを変更する場合は、このパラメータを使用することでデータの整合性を維持できます。
+ `--compress` - ローカルデータベースからのデータを、Amazon RDS に送信する前に圧縮することで、ネットワーク帯域幅の消費量を削減します。
+ `--order-by-primary` - 各テーブルのデータをプライマリキーでソートすることで、ロード時間を短縮します。
+ `--routines` − ストアドプロシージャや関数などのルーチンが、コピーするデータベースに存在する場合に使用します。パラメータを `0` に設定し、インポートプロセス中にルーチンを除外します。その後、Amazon RDS データベースでルーチンを手動で再作成します。
+ `--triggers` − コピーするデータベースにトリガーが存在する場合に使用します。パラメータを `0` に設定し、インポートプロセス中にトリガーを除外します。その後、Amazon RDS データベースでトリガーを手動で再作成します。
+ `--events` − コピーするデータベースにイベントが存在する場合に使用します。パラメータを `0` に設定し、インポートプロセス中にイベントを除外します。その後、Amazon RDS データベースでイベントを手動で再作成します。
+ `-plocal_password` - パスワードを指定します。このパラメータの初回の使用では、初期の `-u` パラメータにより識別されるユーザーアカウントのパスワードを指定します。
+ `-u RDS_user` - ユーザー名を指定します。このパラメータの 2 回目の使用では、`--host` パラメータによって識別された MariaDB DB インスタンスのデフォルトデータベースのユーザーアカウントの名前を指定します。
+ `--port port_number` — MariaDB DB インスタンスのポートを指定します。DB インスタンスの作成時に値を変更していない限り、デフォルトでは 3306 です。
+ `--host host_name` — Amazon RDS DB インスタンスのエンドポイント、例えば からのドメインネームシステム (DNS) 名を指定します。`myinstance.123456789012.us-east-1.rds.amazonaws.com`エンドポイントの値は、Amazon RDS コンソールの DB インスタンスの詳細で確認できます。
+ `-pRDS_password` - パスワードを指定します。このパラメータの 2 回目の使用では、2 回目の `-u` パラメータにより識別されるユーザーアカウントのパスワードを指定します。
Amazon RDS データベースで、ストアドプロシージャ、トリガー、関数、イベントを必ず手動で作成してください。これらのオブジェクトのいずれかがコピー対象のデータベースに含まれている場合は、`mysqldump` または `mariadb-dump` の実行時に除外します。これを行うには、`mysqldump` または `mariadb-dump` コマンドに次のパラメータを含めます。
+ `--routines=0`
+ `--triggers=0`
+ `--events=0`
**例**
次の例では、ローカルホストにある `world` サンプルデータベースを、RDS for MariaDB DB インスタンスにコピーします。値を自分の情報に置き換えます。
Linux、macOS、Unix の場合:
```
sudo mariadb-dump -u local_user \
--databases world \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mariadb -u rds_user \
--port=3306 \
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com \
-pRDS_password
```
Windows の場合:
Windows プログラムメニューの **[コマンドプロンプト]** を右クリックし、**[管理者として実行]** を選択して開いたコマンドプロンプトで次のコマンドを実行します。値を自分の情報に置き換えます。
```
mariadb-dump -u local_user ^
--databases world ^
--single-transaction ^
--compress ^
--order-by-primary ^
--routines=0 ^
--triggers=0 ^
--events=0 ^
-plocal_password | mariadb -u RDS_user ^
--port=3306 ^
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com ^
-pRDS_password
```
**注記**
セキュリティのベストプラクティスとして、例に表示されているプロンプト以外の認証情報を指定します。
# ダウンタイムを短縮して Amazon RDS for MariaDB DB インスタンスにデータをインポートする
場合によっては、ライブアプリケーションをサポートする外部 MariaDB データベースから RDS for MariaDB DB インスタンスにデータをインポートする必要がある場合があります。次の手順を使用して、アプリケーションの可用性への影響を最小限に抑えることができます。この手順は、巨大なデータベースを使用する場合にも役立ちます。この手順を使用すると、ネットワーク経由で AWS に渡されるデータ量を削減することで、インポートのコストを削減できます。
この手順では、データベースデータのコピーを Amazon EC2 インスタンスに送信し、そのデータを新しい Amazon RDS データベースにインポートします。次に、レプリケーションを使用して、Amazon RDS データベースをライブ外部インスタンスで最新の状態にした後、アプリケーションを Amazon RDS データベースにリダイレクトします。外部のインスタンスが MariaDB 10.0.24 以降であり、ターゲットインスタンスが RDS for MariaDB である場合は、グローバルトランザクション識別子 (GTID) に基づいて MariaDB のレプリケーションを設定します。それ以外の場合は、バイナリログの調整に基づいてレプリケーションを設定します。外部データベースがサポートしている場合は、GTID ベースのレプリケーションが推奨されます。GTID ベースのレプリケーションは信頼性の高い方法だからです。詳細については、MariaDB ドキュメントの「[グローバルトランザクション ID](http://mariadb.com/kb/en/mariadb/global-transaction-id/)」を参照してください。
次の図は、外部 MariaDB データベースを Amazon RDS 上の MariaDB データベースにインポートする様子を示しています。
![\[外部 MariaDB データベースを Amazon RDS 上の MariaDB データベースにインポートするワークフロー。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_1.png)
## タスク 1: 既存のデータベースのコピーを作成する
最小限のダウンタイムで RDS for MariaDB データベースに大量のデータを移行するプロセスでは、最初のステップとしてソースデータのコピーを作成します。
次の図は、MariaDB データベースのバックアップの作成を示しています。
![\[MariaDB データベースのバックアップを作成するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_2.png)
SQL 形式または区切り文字付きテキスト形式でデータベースのバックアップを作成するには、`mysqldump` または `mariadb-dump` ユーティリティを使用できます。MariaDB 10.5 では、クライアントは [mariadb-dump](https://mariadb.com/kb/en/mariadb-dump/) と呼ばれます。MariaDB 11.0.1 以降では、`mariadb-dump` を `mysqldump` の代わりに使用する必要があります。非運用環境で各形式のテスト実行を行って、どちらの方法が `mysqldump` または `mariadb-dump` の実行時間が短いか確認することをお勧めします。
また、ロードに区切り文字付きテキスト形式を使用することでもたらされるメリットに対して、`mysqldump` または `mariadb-dump` のパフォーマンスの重み付けをすることをお勧めします。区切り文字付きテキスト形式を使用したバックアップでは、ダンプされる各テーブルについてタブ区切りテキストファイルを作成されます。データベースのインポートに必要な時間を短縮するため、`LOAD DATA LOCAL INFILE` コマンドを使用してこれらのファイルを同時にロードできます。詳細については、任意のソースからデータをインポートする手順の「[ステップ 5: データをロードする](mariadb-importing-data-any-source.md#mariadb-importing-data-any-source-load-data)」を参照してください。
バックアップ操作をスタートする前に、Amazon RDS にコピーする MariaDB データベースでレプリケーションのオプションを設定してください。レプリケーションのオプションには、バイナリログ記録の有効化や一意のサーバー ID の設定が含まれます。これらのオプションを設定すると、サーバーはデータベーストランザクションのログ作成をスタートし、このプロセスの後でこのサーバーをソースレプリケーションインスタンスにするために準備します。
次の推奨事項と考慮事項に注意してください。
+ `--single-transaction` オプションは、データベースの一貫した状態をダンプするため、`mysqldump` または `mariadb-dump` と共に使用します。有効なダンプファイルを確保するために、`mysqldump` または `mariadb-dump` の実行中はデータ定義言語 (DDL) ステートメントを実行しないでください。これらのオペレーションに対してメンテナンスウィンドウをスケジュールできます。
+ ダンプファイルから次のスキーマを除外します。
+ `sys`
+ `performance_schema`
+ `information_schema`
`mysqldump` および `mariadb-dump` ユーティリティは、これらのスキーマをデフォルトで除外します。
+ ユーザーや権限を移行する必要がある場合は、再作成するデータ制御言語 (DCL) を生成するツールの使用を検討します。例えば、[pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html) ユーティリティがあります。
### レプリケーションオプションを設定するには
1. `my.cnf` ファイルを編集します。このファイルは `/etc` にあります。
```
sudo vi /etc/my.cnf
```
`log_bin` オプションと `server_id` オプションを `[mysqld]` に追加します。`log_bin` オプションは、バイナリログファイルのファイル名識別子を提供します。`server_id` オプションは、ソースとレプリカの関係のサーバーに一意の識別子を提供します。
次の例は、`my.cnf` ファイルの更新された `[mariadb]` セクションを示しています。
```
[mariadb]
log-bin
server-id=1
log-basename=master1
binlog-format=mixed
```
詳細については、MariaDB ドキュメントの「[Setting the Replication Source Configuration](https://mariadb.com/docs/server/ha-and-performance/standard-replication/setting-up-replication)」を参照してください。
1. マルチ AZ DB クラスターでのレプリケーションでは、`gtid_strict_mode` を有効にします。詳細については、MariaDB のドキュメントの「[gtid\$1strict\$1mode](https://mariadb.com/docs/server/ha-and-performance/standard-replication/gtid#gtid_strict_mode)」を参照してください。
DB インスタンスでのレプリケーションには、`gtid_strict_mode` を有効にする必要はありません。
1. `mariadb` サービスを再起動します。
```
sudo service mariadb restart
```
### 既存のデータベースのバックアップコピーを作成するには
1. `mysqldump` または `mariadb-dump` ユーティリティを使用し、SQL 形式または区切り文字付きテキスト形式を指定して、データのバックアップを作成します。
パフォーマンスを向上させ、データ整合性を確保するために、`mysqldump` または `mariadb-dump` で `--order-by-primary` オプションと `--single-transaction` オプションを使用します。
MySQL システムデータベースをバックアップに含めないためには、`mysqldump` または `mariadb-dump` で `--all-databases` オプションを使用しないでください。詳細については、MySQL ドキュメントの「[Creating a Data Snapshot Using mysqldump](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto-mysqldump.html)」を参照してください。
バックアップファイルが作成されるディレクトリを書き込み可能にするために、必要に応じて `chmod` を使用します。
**重要**
Windows で、管理者としてコマンドウィンドウを実行します。
+ SQL 出力を作成するには、次のコマンドを使用します。MariaDB 10.11 以前のバージョンでは、`mariadb-dump` を `mysqldump` に置き換えます。
Linux、macOS、Unix の場合:
```
sudo mariadb-dump \
--databases database_name \
--master-data=2 \
--single-transaction \
--order-by-primary \
-r backup.sql \
-u local_user \
-ppassword
```
**注記**
セキュリティのベストプラクティスとして、ここに表示されているプロンプト以外の認証情報を指定します。
Windows の場合:
```
mariadb-dump ^
--databases database_name ^
--master-data=2 ^
--single-transaction ^
--order-by-primary ^
-r backup.sql ^
-u local_user ^
-ppassword
```
**注記**
セキュリティのベストプラクティスとして、ここに表示されているプロンプト以外の認証情報を指定します。
+ 区切り文字付きテキスト出力を作成するには、次のコマンドを使用します。MariaDB 11.01 以降のバージョンでは、`mysqldump` を `mariadb-dump` に置き換えます。
Linux、macOS、Unix の場合:
```
sudo mysqldump \
--tab=target_directory \
--fields-terminated-by ',' \
--fields-enclosed-by '"' \
--lines-terminated-by 0x0d0a \
database_name \
--master-data=2 \
--single-transaction \
--order-by-primary \
-ppassword
```
Windows の場合:
```
mysqldump ^
--tab=target_directory ^
--fields-terminated-by "," ^
--fields-enclosed-by """ ^
--lines-terminated-by 0x0d0a ^
database_name ^
--master-data=2 ^
--single-transaction ^
--order-by-primary ^
-ppassword
```
**注記**
セキュリティのベストプラクティスとして、ここに表示されているプロンプト以外の認証情報を指定します。
Amazon RDS データベースで、ストアドプロシージャ、トリガー、関数、イベントを必ず手動で作成してください。これらのオブジェクトのいずれかがコピー対象のデータベースに含まれている場合は、`mysqldump` または `mariadb-dump` の実行時に除外します。これを行うには、`mysqldump` または `mariadb-dump` コマンドで以下の引数を含めます。
`--routines=0`
`--triggers=0`
`--events=0`
`mysqldump` を実行して区切り文字付きテキスト形式を指定すると、`CHANGE MASTER TO` コメントが返されます。このコメントには、マスターログのファイル名と場所が含まれます。外部インスタンスが MariaDB 10.0.23 以前のバージョンの場合は、`MASTER_LOG_FILE` および `MASTER_LOG_POS` の値を書き留めてください。これらの値は、レプリケーションを設定するときに必要です。
MariaDB バージョンでは、次の出力が返されます。
```
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
1. 使用している外部インスタンスが MariaDB バージョン 10.0.24 以降である場合は、GTID ベースのレプリケーションを使用します。外部 MariaDB インスタンスで `SHOW MASTER STATUS` を実行してバイナリログファイル名と場所を取得し、外部 MariaDB インスタンス上で `BINLOG_GTID_POS` を実行してそれらを GTID に変換します。
```
SELECT BINLOG_GTID_POS('binary_log_file_name', binary_log_file_position);
```
返された GTID を書き留めます。これはレプリケーションを設定する際に必要となります。
1. Amazon RDS データベースにデータをコピーするために必要なネットワークリソースの量を減らすために、コピーされたデータを圧縮します。バックアップファイルのサイズをメモします。この情報は、作成する Amazon EC2 インスタンスの大きさを決定するときに必要です。作業が終了したら、GZIP または任意の圧縮ユーティリティを使用してバックアップファイルを圧縮します。
+ SQL 出力を圧縮するには、次のコマンドを使用します。
```
gzip backup.sql
```
+ 区切り文字付きテキスト出力を圧縮するには、次のコマンドを使用します。
```
tar -zcvf backup.tar.gz target_directory
```
## タスク 2: Amazon EC2 インスタンスを作成し、圧縮したデータベースをコピーする
圧縮したデータベースのバックアップファイルを Amazon EC2 インスタンスにコピーする場合、データベースインスタンス間で非圧縮データを直接コピーするよりも必要なネットワークリソースは少なくなります。データを Amazon EC2 にコピーしたら、そこから MariaDB データベースに直接コピーできます。ネットワークリソースのコストを節約するには、Amazon EC2 インスタンスが Amazon RDS DB インスタンスと同じ AWS リージョンに存在している必要があります。Amazon EC2 インスタンスを Amazon RDS データベースと同じ AWS リージョンに配置することで、インポート時のネットワークレイテンシーも低減されます。
次の図は、Amazon EC2 インスタンスへのデータベースバックアップのコピーを示しています。
![\[データベースのバックアップを Amazon EC2 インスタンスにコピーするワークフロー。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_3.png)
### Amazon EC2 インスタンスを作成し、データをコピーするには
1. Amazon RDS データベースを作成する予定の AWS リージョンに、仮想プライベートクラウド (VPC)、VPC セキュリティグループ、および VPC サブネットを作成します。VPC セキュリティグループのインバウンドルールで、アプリケーションが AWS に接続するために必要な IP アドレスを許可していることを確認します。IP アドレスの範囲 (`203.0.113.0/24` など) や別の VPC セキュリティグループを指定できます。[Amazon VPC コンソール](https://console.aws.amazon.com/vpc)を使用して、VPC、サブネット、セキュリティグループを作成および管理できます。詳細については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[Amazon VPC の開始方法](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html#getting-started)」を参照してください。
1. [Amazon EC2 管理コンソール](https://console.aws.amazon.com/ec2)を開き、Amazon EC2 インスタンスと Amazon RDS データベースの両方が含まれる AWS リージョンを選択します。ステップ 1 で作成した VPC、サブネット、セキュリティグループを使用して Amazon EC2 インスタンスを起動します。非圧縮の場合のデータベースバックアップファイルに十分なストレージを備えたインスタンスタイプを選択していることを確認します。Amazon EC2 インスタンスの詳細については、「*Amazon Elastic Compute Cloud ユーザーガイド*」の「[Amazon EC2 の使用を開始する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html)」を参照してください。
1. Amazon EC2 インスタンスから Amazon RDS データベースに接続するには、VPC セキュリティグループを編集します。EC2 インスタンスのプライベート IP アドレスを指定するインバウンドルールを追加します。このプライベート IP アドレスは、EC2 コンソールウィンドウの [**Instance**] ペインの [**Details**] タブで確認できます。VPC セキュリティグループを編集してインバウンドルールを追加するには、EC2 コンソールのナビゲーションペインの **[Security Groups]** (セキュリティグループ) でセキュリティグループを選択してから、EC2 インスタンスのプライベート IP アドレスを指定して MySQL または Aurora のインバウンドルールを追加します。VPC セキュリティグループにインバウンドルールを追加する方法については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[セキュリティグループのルール](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html)」を参照してください。
1. ローカルシステムから Amazon EC2 インスタンスに、圧縮されたデータベースバックアップファイルをコピーします。必要に応じて `chmod` を使用して、Amazon EC2 インスタンスのターゲットディレクトリに対する書き込みアクセス許可があることを確認します。`scp` または Secure Shell (SSH) クライアントを使用してファイルをコピーできます。以下は `scp` コマンドの例です。
```
scp -r -i key pair.pem backup.sql.gz ec2-user@EC2 DNS:/target_directory/backup.sql.gz
```
**重要**
機密データをコピーするときは、必ず安全なネットワーク転送プロトコルを使用してください。
1. Amazon EC2 インスタンスに接続し、次のコマンドを使用して最新のアップデートと MariaDB クライアントツールをインストールします。
```
sudo yum update -y
sudo yum install mariadb1011-client-utils -y
```
詳細については、「*Amazon Elastic Compute Cloud ユーザーガイド*」の Linux インスタンスの「[インスタンスに接続する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux)」および「MariaDB ドキュメント」の「[MariaDB Connectors](https://mariadb.com/docs/connectors)」を参照してください。
1. Amazon EC2 インスタンスに接続されている間に、データベースバックアップファイルを解凍します。次のコマンドはその例です。
+ SQL 出力を解凍するには、次のコマンドを使用します。
```
gzip backup.sql.gz -d
```
+ 区切り文字付きテキスト出力を解凍するには、次のコマンドを使用します。
```
tar xzvf backup.tar.gz
```
## タスク 3: MariaDB データベースを作成し、Amazon EC2 インスタンスからデータをインポートする
Amazon EC2 インスタンスと同じ AWS リージョンで RDS for MariaDB DB インスタンスを作成することによって、インターネット経由でインポートするよりも速く、Amazon EC2 からデータベースのバックアップファイルをインポートできます。
次の図は、Amazon EC2 インスタンスから MariaDB データベースにバックアップをインポートする様子を示しています。
![\[EC2 インスタンスから MariaDB データベースにバックアップをインポートするワークフロー。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_4.png)
### MariaDB データベースを作成し、データをインポートするには
1. この Amazon RDS データベースについて予想されるワークロードをサポートするのに必要な DB インスタンスクラスとストレージ領域の容量を決定します。このプロセスの一環として、データロードの手順に十分な領域と処理能力を決定します。また、本番稼働ワークロードの処理に必要なものも決定します。これは、ソースの MariaDB データベースのサイズおよびリソースに基づいて見積もることができます。詳細については、「[ DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。
1. Amazon EC2 インスタンスを含む AWS リージョンに、DB インスタンスを作成します。「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」の指示に従い、次のガイドラインを使用します。
+ ソース DB インスタンスと互換性のある DB エンジンのバージョンを指定します。
+ Amazon EC2 インスタンスと同じ仮想プライベートクラウド (VPC) と VPC セキュリティグループを指定します。これにより、Amazon EC2 インスタンスと Amazon RDS インスタンスはネットワーク上で相互に表示されることが確認できます。DB インスタンスがパブリックにアクセスできることを確認してください。以下のセクションで説明するように、ソースデータベースでレプリケーションをセットアップするには、DB インスタンスにパブリックアクセス可能である必要があります。
+ データベースのバックアップのインポートが完了するまで、複数のアベイラビリティーゾーン、バックアップ保持、リードレプリカを設定しないでください。インポートが完了したら、本稼働インスタンスについて、マルチ AZ とバックアップ保持を設定できます。
1. Amazon RDS データベースのデフォルトの設定オプションを確認します。データベースのデフォルトパラメータグループに必要な設定オプションがない場合は、別のパラメータグループを検索するか、新しいパラメータグループを作成します。パラメータグループの作成の詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
1. マスターユーザーとして、新しい Amazon RDS データベースに接続します。DB インスタンスにアクセスする必要がある管理者、アプリケーション、およびサービスのサポートに必要なユーザーを作成します。Amazon RDS データベースのホスト名は、この DB インスタンスの **[エンドポイント]** の値からポート番号を除いた値 (例: `mysampledb.123456789012.us-west-2.rds.amazonaws.com`) です。エンドポイントの値は、Amazon RDS コンソールのデータベースの詳細で確認できます。
1. Amazon EC2 インスタンスに接続します。詳細については、「*Amazon Elastic Compute Cloud ユーザーガイド*」の Linux インスタンスの「[インスタンスをクリーンアップする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux)」を参照してください。
1. `mysql` コマンドを使用して、Amazon EC2 インスタンスからリモートホストとして Amazon RDS データベースに接続します。コマンドの例を次に示します。
```
mysql -h host_name -P 3306 -u db_master_user -p
```
*host\$1name* は、Amazon RDS データベースのエンドポイントです。
1. `mysql` プロンプトで、データベースダンプファイルの名前を渡して `source` コマンドを実行します。このコマンドは、Amazon RDS DB インスタンスにデータをロードします。
+ SQL 形式の場合は、次のコマンドを使用します。
```
MariaDB [(none)]> source backup.sql;
```
+ 区切り文字付きテキスト形式の場合は、Amazon RDS データベースをセットアップしたときに作成したデフォルトのデータベースではない場合、まず、データベースを作成します。
```
MariaDB [(none)]> create database database_name;
MariaDB [(none)]> use database_name;
```
次にテーブルを作成します。
```
MariaDB [(none)]> source table1.sql
MariaDB [(none)]> source table2.sql
etc...
```
次にデータをインポートします。
```
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'table1.txt' INTO TABLE table1 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'table2.txt' INTO TABLE table2 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
etc...
```
パフォーマンスを向上させるために、複数の接続からこれらのオペレーションをパラレル実行して、すべてのテーブルを同時に作成およびロードすることができます。
**注記**
最初にテーブルをダンプした際、`mysqldump` または `mariadb-dump` でデータをフォーマットするオプションを使用した場合は、データファイルのコンテンツが適切に解釈できるように、`LOAD DATA LOCAL INFILE` でも必ず同じオプションを使用する必要があります。
1. インポートしたデータベースの単一のテーブルまたは 2 つのテーブルに対してシンプルな `SELECT` クエリを実行して、インポートが正常に完了したかを検証します。
この手順で使用された Amazon EC2 インスタンスが今後不要な場合は、EC2 インスタンスを終了して、AWS リソース使用率を減らします。EC2 インスタンスを終了するには、「*Amazon Elastic Compute Cloud ユーザーガイド*」の「[インスタンスの終了](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#terminating-instances-console)」を参照してください。
## タスク 4: 外部データベースから新しい Amazon RDS データベースにデータをレプリケートする
ソースデータベースは、データをコピーして MariaDB データベースに転送するまでに更新された可能性があります。レプリケーションを使用して、コピーしたデータベースをソースデータベースで最新のものにすることができます。
![\[外部 MariaDB データベースから Amazon RDS 上のデータベースにデータをレプリケートするワークフロー。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_5.png)
Amazon RDS データベースでレプリケーションを開始するために必要なアクセス許可は限定されており、Amazon RDS マスターユーザーは利用できません。このため、適切な Amazon RDS ストアドプロシージャを使用します。
+ [mysql.rds\$1set\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_set_external_master)
+ レプリケーションを設定するには [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md)、レプリケーションを開始するには [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication)
### レプリケーションをスタートするには
タスク 1 の[レプリケーションオプションの設定時](#mariadb-importing-data-reduced-downtime-set-replication-options)に、バイナリログ記録を有効にし、ソースデータベースに一意のサーバー ID を設定しました。これで、ライブデータベースをソースレプリケーションインスタンスとして、Amazon RDS データベースをレプリカとしてセットアップできます。
1. Amazon RDS コンソールで、ソースデータベースをホストするサーバーの IP アドレスを Amazon RDS データベースの VPC セキュリティグループに追加します。VPC セキュリティグループの詳細については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[セキュリティグループのルールを設定する](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html)」を参照してください。
ソースインスタンスと通信できるためには、Amazon RDS データベースの IP アドレスからの接続を許可するようにローカルネットワークを設定することも必要になる場合があります。Amazon RDS データベースの IP アドレスを確認するには、`host` コマンドを使用します。
```
host host_name
```
*host\$1name* は、Amazon RDS データベースのエンドポイントの DNS 名 (例: `myinstance.123456789012.us-east-1.rds.amazonaws.com`) です。エンドポイントの値は、Amazon RDS コンソールの DB インスタンスの詳細で確認できます。
1. 選択したクライアントを使用して、ソースインスタンスに接続し、レプリケーションに使用するユーザーを作成します。このアカウントはレプリケーション専用に使用され、セキュリティを強化するためにドメインに制限する必要があります。コマンドの例を次に示します。
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**注記**
セキュリティのベストプラクティスとして、ここに表示されているプロンプト以外の認証情報を指定してください。
1. ソースインスタンスについて、`REPLICATION CLIENT` と `REPLICATION SLAVE` の特権をレプリケーションユーザーに付与します。たとえば、すべてのデータベースに対する `REPLICATION CLIENT` と `REPLICATION SLAVE` の特権を、「`repl_user`」ユーザーに付与するには、次のコマンドを実行します。
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
1. SQL 形式を使用してバックアップファイルを作成しており、外部インスタンスが MariaDB 10.0.24 以降でない場合は、次のコマンドを実行してファイルのコンテンツを表示します。
```
cat backup.sql
```
このファイルに、マスターログファイルの名前と場所を示す `CHANGE MASTER TO` コメントが含まれています。`--master-data` で `mysqldump` オプションを使用した場合に、バックアップファイルにこのコメントが含まれます。`MASTER_LOG_FILE` と `MASTER_LOG_POS` の値に注意してください。
```
--
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
バックアップファイルの作成に区切りテキスト形式を使用しており、外部のインスタンスが MariaDB 10.0.24 以降でない場合は、[既存のデータベースのバックアップコピーの作成時に](#mariadb-importing-data-reduced-downtime-create-backup)、タスク 1 のステップ 1 でバイナリログ座標を既に取得しているはずです。
外部のインスタンスが MariaDB 10.0.24 以降の場合は、[既存のデータベースのバックアップコピーの作成時](#mariadb-importing-data-reduced-downtime-create-backup)に、タスク 1 のステップ 2 でレプリケーションを開始するための GTID を既に取得しているはずです。
1. Amazon RDS データベースをレプリカにします。外部のインスタンスが MariaDB 10.0.24 以降でない場合、マスターユーザーとして Amazon RDS データベースに接続し、[mysql.rds\$1set\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) ストアドプロシージャを使用して、ソースのレプリケーションインスタンスとしてソースデータベースを特定します。
SQL 形式のバックアップファイルがある場合は、ステップ 4 で確認したマスターログのファイル名とマスターログの位置を使用します。区切り文字テキスト形式を使用した場合は、バックアップファイルの作成時に決定した名前と場所を使用します。コマンドの例を次に示します。
```
CALL mysql.rds_set_external_master ('myserver.mydomain.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**注記**
セキュリティのベストプラクティスとして、ここに表示されているプロンプト以外の認証情報を指定してください。
外部のインスタンスが MariaDB 10.0.24 以降の場合、マスターユーザーとして Amazon RDS データベースに接続し、[mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md) ストアドプロシージャを使用して、ソースのレプリケーションインスタンスとしてソースデータベースを特定します。[既存のデータベースのバックアップコピーの作成時](#mariadb-importing-data-reduced-downtime-create-backup)に、タスク 1 のステップ 2 で確認した GTID を使用します。コマンドの例を次に示します。
```
CALL mysql.rds_set_external_master_gtid ('source_server_ip_address', 3306, 'ReplicationUser', 'password', 'GTID', 1);
```
`source_server_ip_address` は、ソースレプリケーションインスタンスの IP アドレスです。EC2 プライベート DNS アドレスは現在サポートされていません。
**注記**
セキュリティのベストプラクティスとして、ここに表示されているプロンプト以外の認証情報を指定してください。
1. Amazon RDS データベースでレプリケーションを開始するには、[mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) ストアドプロシージャを使用する次のコマンドを実行します。
```
CALL mysql.rds_start_replication;
```
1. Amazon RDS データベースで、レプリカがいつソースレプリケーションインスタンスの最新の状態に更新されるかを特定するには、[SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) コマンドを実行します。`SHOW REPLICA STATUS` コマンドの結果には、`Seconds_Behind_Master` フィールドが含まれます。`Seconds_Behind_Master` フィールドが 0 を返す場合、レプリカはソースレプリケーションインスタンスで最新の状態になります。
MariaDB 10.5、10.6、10.11、11.4 または 11.8 DB インスタンスの場合は、MySQL コマンドを実行する代わりに [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md) ストアドプロシージャを使用します。
1. Amazon RDS データベースが最新の状態になったら、必要に応じてデータベースを復元できるように、自動バックアップを有効にします。[Amazon RDS コンソール](https://console.aws.amazon.com/rds/)を使用して、Amazon RDS データベースの自動バックアップを有効化または変更できます。詳細については、「[バックアップの概要](USER_WorkingWithAutomatedBackups.md)」を参照してください。
## タスク 5: ライブアプリケーションを Amazon RDS インスタンスにリダイレクトする
MariaDB データベースがソースレプリケーションインスタンスで最新の状態になったら、ライブアプリケーションを更新して、Amazon RDS インスタンスを使用できます。
![\[レプリケーションを停止し、ライブアプリケーションを Amazon RDS 上のデータベースにリダイレクトするワークフロー。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/MigrateMariaDBToRDS_6.png)
### ライブアプリケーションを MariaDB データベースにリダイレクトしてレプリケーションを停止するには
1. Amazon RDS データベースの VPC セキュリティグループを追加するには、アプリケーションをホストするサーバーの IP アドレスを追加します。VPC セキュリティグループの変更の詳細については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[セキュリティグループのルールを設定する](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html)」を参照してください。
1. [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) コマンドの結果の `Seconds_Behind_Master` フィールドが 0 であることを確認します。この値は、レプリカがソースレプリケーションインスタンスの最新の状態であることを示します。
```
SHOW REPLICA STATUS;
```
MariaDB 10.5、10.6、10.11、11.4 または 11.8 DB インスタンスの場合は、MySQL コマンドを実行する代わりに [mysql.rds\$1replica\$1status](mysql_rds_replica_status.md) プロシージャを使用します。
1. トランザクションが終了したら、ソースへのすべての接続を閉じます。
1. Amazon RDS データベースを使用するようにアプリケーションを更新します。この更新には、一般に、Amazon RDS データベースのホスト名とポート、接続に使用するユーザーアカウントとパスワード、および使用するデータベースを識別する接続設定の変更が含まれます。
1. DB インスタンスに接続します。
1. [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) ストアドプロシージャを使用する次のコマンドを実行して、Amazon RDS インスタンスのレプリケーションを停止します。
```
CALL mysql.rds_stop_replication;
```
1. Amazon RDS データベースで [mysql.rds\$1reset\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) ストアドプロシージャを使用する次のコマンドを実行して、レプリケーション設定をリセットします。これにより、このインスタンスはレプリカとして識別されなくなります。
```
CALL mysql.rds_reset_external_master;
```
1. マルチ AZ のサポートやリードレプリカなど、Amazon RDS のその他の機能を有効にします。詳細については、「[Amazon RDS でのマルチ AZ 配置の設定と管理](Concepts.MultiAZ.md)」および「[DB インスタンスのリードレプリカの操作](USER_ReadRepl.md)」を参照してください。
# 任意のソースから Amazon RDS for MariaDB DB インスタンスにデータをインポートする
Amazon RDS を使用すると、既存の MariaDB データを任意のソースから RDS for MariaDB DB インスタンスに移行できます。オンプレミスデータベース、他のクラウドプロバイダー、または既存の RDS for MariaDB DB インスタンスからターゲット RDS for MariaDB DB インスタンスにデータを転送できます。この機能を使用すると、データベースの統合、ディザスタリカバリソリューションの実装、セルフマネージド型データベースからの移行を行うことができます。一般的なシナリオには、セルフホスト型の MariaDB サーバーからフルマネージド型の Amazon RDS DB インスタンスへの移行、複数の MariaDB データベースの 1 つの DB インスタンスへの統合、本番データを使用したテスト環境の作成などがあります。以下のセクションでは、`mariadb-dump`、バックアップファイル、レプリケーションなどのメソッドを使用して MariaDB データをインポートする詳細な手順について説明します。
## ステップ 1: ロードするデータを含むフラットファイルを作成する
カンマ区切り値 (CSV) などの一般的な形式を使用して、ロードするデータを保存します。各テーブルには独自のファイルが必要です。複数のテーブルのデータを同じファイルに結合することはできません。各ファイルに、対応するテーブルと同じ名前を付けます。ファイル拡張子は何でもかまいません。例えば、テーブル名が `sales` の場合、ファイル名は `sales.csv` または `sales.txt` になります。
可能であれば、ロードされるテーブルのプライマリキーでデータをソートします。これにより、ロード時間が大幅に短縮され、ディスクストレージの要件が最小限に抑えられます。
この手順の速度と効率は、ファイルのサイズを小さく保つかどうかによって決まります。個々のファイルの非圧縮サイズが 1 GiB を超える場合、複数のファイルに分割して、1 つずつロードしてください。
Unix のようなシステム (Linux など) では、`split` コマンドを使用します。例えば、次のコマンドでは `sales.csv` ファイルが 1 GiB 未満の複数のファイルに分割されます。ただし、分割されるのは改行でのみです (-C 1024m)。新しいファイルの名前には、昇順の数値サフィックスが含まれます。次のコマンドは、`sales.part_00` や `sales.part_01` などの名前のファイルを生成します。
```
split -C 1024m -d sales.csv sales.part_
```
他のオペレーティングシステムにも同様のユーティリティを使用できます。
フラットファイルはどこにでも保存できます。ただし、[ステップ 5](#mariadb-importing-data-any-source-load-data) でデータをロードするときは、ファイルが存在するのと同じ場所から `mysql` シェルを呼び出すか、`LOAD DATA LOCAL INFILE` の実行時にファイルの絶対パスを使用する必要があります。
## ステップ 2: ターゲット DB インスタンスにアクセスしているすべてのアプリケーションを停止する
大きなロードをスタートする前に、ロード先のターゲット DB インスタンスにアクセスするすべてのアプリケーションアクティビティを停止します。特に、他のセッションでロード中のテーブルや参照するテーブルを変更する場合は、これをお勧めします。これにより、ロード中に発生する制約違反のリスクが軽減され、ロードパフォーマンスが向上します。また、ロードに関係しないプロセスによって行われた変更を失うことなく、DB インスタンスをロードの直前の時点に復元することもできます。
もちろん、これは可能でない場合や実用的ではない場合があります。アプリケーションによる DB インスタンスへのアクセスをロード前に停止できない場合は、データの可用性と整合性を確保するための手順を実行してください。必要となる具体的なステップは、実際のユースケースとサイト要件によって大きく異なります。
## ステップ 3: DB スナップショットを作成する
データが含まれない新しい DB インスタンスにデータをロードする場合、このステップをスキップできます。それ以外の場合は、データロードの前後にターゲットの Amazon RDS DB インスタンスの DB スナップショットを作成することをお勧めします。Amazon RDS DB スナップショットは DB インスタンスの完全なバックアップであり、DB インスタンスを既知の状態に復元するために使用できます。DB スナップショットをスタートすると、データベースのバックアップのため DB インスタンスに対する I/O 操作が一時停止されます。
ロード直前に DB スナップショットを作成すると、必要が生じた場合にデータベースをロード前の状態に復元できます。ロード直後に DB スナップショットを作成しておくと、何らかの事故のときにそのスナップショットを使用すれば、データを再ロードせずに済みます。ロード後に DB スナップショットを使用して、新しいデータベースインスタンスにデータをインポートすることもできます。
次の例では、AWS CLI の [create-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-snapshot.html) コマンドを実行して、`AcmeRDS` インスタンスの DB スナップショットを作成し、その DB スナップショットに識別子 `"preload"` を指定します。
Linux、macOS、Unix の場合:
```
aws rds create-db-snapshot \
--db-instance-identifier AcmeRDS \
--db-snapshot-identifier preload
```
Windows の場合:
```
aws rds create-db-snapshot ^
--db-instance-identifier AcmeRDS ^
--db-snapshot-identifier preload
```
DB スナップショットからの復元機能を使用して、リハーサル用のテスト DB インスタンスを作成したり、ロード中に加えられた変更を元に戻すこともできます。
DB スナップショットからデータベースを復元すると、すべての DB インスタンスと同様に一意の識別子とエンドポイントを持つ新しい DB インスタンスが作成される点に留意してください。エンドポイントを変更せずに DB インスタンスを復元するには、エンドポイントを再利用できるように、まず DB インスタンスを削除します。
例えば、リハーサルや他のテスト用の DB インスタンスを作成するには、DB インスタンスに独自の識別子を指定します。この例での識別子は「`AcmeRDS-2`」です。この例では、`AcmeRDS-2` に関連付けられたエンドポイントを使用して DB インスタンスに接続します。詳細については、「[restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)」を参照してください。
Linux、macOS、Unix の場合:
```
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier AcmeRDS-2 \
--db-snapshot-identifier preload
```
Windows の場合:
```
aws rds restore-db-instance-from-db-snapshot ^
--db-instance-identifier AcmeRDS-2 ^
--db-snapshot-identifier preload
```
既存のエンドポイントを再利用するには、まず DB インスタンスを削除してから、復元されたデータベースに同じ識別子を指定します。詳細については、「[delete-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance.html)」を参照してください。
次の例でも、DB インスタンスを削除する前に最終的な DB スナップショットを取得しています。これはオプションですが推奨されます。
Linux、macOS、Unix の場合:
```
aws rds delete-db-instance \
--db-instance-identifier AcmeRDS \
--final-db-snapshot-identifier AcmeRDS-Final
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier AcmeRDS \
--db-snapshot-identifier preload
```
Windows の場合:
```
aws rds delete-db-instance ^
--db-instance-identifier AcmeRDS ^
--final-db-snapshot-identifier AcmeRDS-Final
aws rds restore-db-instance-from-db-snapshot ^
--db-instance-identifier AcmeRDS ^
--db-snapshot-identifier preload
```
## ステップ 4 (オプション): Amazon RDS 自動バックアップをオフにする
**警告**
ポイントインタイムリカバリを実行する必要がある場合は、自動バックアップをオフにしないでください。
自動バックアップをオフにすると、パフォーマンスが最適化します。これはデータのロードに必須ではありません。自動バックアップをオフにすると、既存のバックアップがすべて消去されます。その結果、自動バックアップをオフにすると、ポイントインタイムリカバリができなくなります。自動バックアップを無効にしても、手動 DB スナップショットに影響が及ぶことはありません。既存のすべての手動 DB スナップショットは引き続き復元で使用可能です。
自動バックアップを無効にするとロード時間が約 25% 短縮し、ロード時に必要なストレージ容量が減少します。データが含まれない新しい DB インスタンスにデータをロードする場合、バックアップを無効にすると、ロードを簡単に高速化でき、バックアップに必要な追加のストレージを使用する必要がなくなります。しかし、状況によっては、既にデータが含まれている DB インスタンスにロードする場合もあります。その場合、バックアップを無効にするメリットと、ポイントインタイムリカバリを実行できなくなることの影響を比較検討する必要があります。
DB インスタンスでは、デフォルトで自動バックアップが有効になっています (保持期間は 1 日です)。自動バックアップを無効にするには、バックアップ保持期間を 0 に設定します。ロード後、バックアップ保持期間を 0 以外の値に設定することでバックアップを再度有効にすることができます。バックアップを有効または無効にするには、Amazon RDS で DB インスタンスをシャットダウンおよび再起動して、MariaDB のログ記録を有効または無効にします。
AWS CLI の `modify-db-instance` コマンドを実行し、バックアップ保持期間を 0 に設定して変更をすぐに適用します。保持期間を 0 に設定するには DB インスタンスを再起動する必要があるため、続行前に再起動が完了するまで待っています。詳細については、「[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)」を参照してください。
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier AcmeRDS \
--apply-immediately \
--backup-retention-period 0
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier AcmeRDS ^
--apply-immediately ^
--backup-retention-period 0
```
AWS CLI の [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) コマンドで DB インスタンスのステータスを確認できます。次の例では、`AcmeRDS` DB インスタンスにおける DB インスタンスのステータスを表示します。
```
aws rds describe-db-instances --db-instance-identifier AcmeRDS --query "*[].{DBInstanceStatus:DBInstanceStatus}"
```
DB インスタンスのステータスが `available` になったら、次のステップに進む準備が整いました。
## ステップ 5: データをロードする
フラットファイルから行を読み取ってデータベーステーブルにロードするには、MariaDB の `LOAD DATA LOCAL INFILE` ステートメントを使用します。
**注記**
フラットファイルが存在するのと同じ場所から `mariadb` シェルを呼び出すか、`LOAD DATA LOCAL INFILE` の実行時にファイルの絶対パスを使用する必要があります。
次の例は、`sales.txt` という名前のファイルからデータベース内の `Sales` という名前のテーブルにデータをロードする方法を示しています。
```
MariaDB [(none)]> LOAD DATA LOCAL INFILE 'sales.txt' INTO TABLE Sales FIELDS TERMINATED BY ' ' ENCLOSED BY '' ESCAPED BY '\\';
Query OK, 1 row affected (0.01 sec)
Records: 1 Deleted: 0 Skipped: 0 Warnings: 0
```
`LOAD DATA` ステートメントの詳細については、「MariaDB ドキュメント」の「[LOAD DATA INFILE](https://mariadb.com/docs/server/reference/sql-statements/data-manipulation/inserting-loading-data/load-data-into-tables-or-index/load-data-infile)」を参照してください。
## ステップ 6: Amazon RDS 自動バックアップを再度オンにする
[ステップ 4](#mariadb-importing-data-any-source-turn-off-automated-backups) で Amazon RDS 自動バックアップをオフにした場合は、ロードが完了したら、バックアップ保持期間をロード前の値に戻して、自動バックアップをオンにします。ステップ 4 で説明したように、Amazon RDS は DB インスタンスを再起動するため、短時間の停止に備えてください。
次の例では、AWS CLI の [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) コマンドを実行して、`AcmeRDS` DB インスタンスの自動バックアップをオンにします。保持期間は 1 日に設定します。
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier AcmeRDS \
--backup-retention-period 1 \
--apply-immediately
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier AcmeRDS ^
--backup-retention-period 1 ^
--apply-immediately
```