MySQL DB インスタンスへのデータのインポート - Amazon Relational Database Service

MySQL DB インスタンスへのデータのインポート

RDS for MySQL DB インスタンスへのデータのインポートには、さまざまな手法を使用できます。最善の方法は、データのソース、データの量、およびインポートが 1 回実行されているのか、進行中であるのかによって異なります。データとともにアプリケーションを移行する場合は、許容できるダウンタイムの長さも考慮してください。

概要

次の表で、RDS for MySQL DB インスタンスにデータをインポートする方法を見つけてください。

ソース データ量 1 回または進行中 アプリケーションのダウンタイム 手法 詳細情報
オンプレミスまたは Amazon EC2 の既存の MySQL データベース すべて 1 回 ある程度 オンプレミスデータベースのバックアップを作成して Amazon S3 に保存し、次に MySQL を実行する新しい Amazon RDS DB インスタンスにバックアップファイルを復元できます。 MySQL DB インスタンスへのバックアップの復元
既存のデータベース すべて 1 回または進行中 最小限 AWS Database Migration Service を使用してダウンタイムを最小限にしてデータベースを移行し、多くのデータベース DB エンジンで継続的なレプリケーションを継続します。 AWS Database Migration Service ユーザーガイド」の「AWS Database Migration Service とは?」および「MySQL 互換データベースの AWS DMS のターゲットとしての使用
既存の MySQL DB インスタンス すべて 1 回または進行中 最小限 継続的なレプリケーション用のリードレプリカを作成します。新しい DB インスタンスの 1 回限りの作成用のリードレプリカを昇格させます。 DB インスタンスのリードレプリカの操作
既存の MariaDB または MySQL データベース スモール 1 回 ある程度 コマンドラインユーティリティを使用して、MySQL DB インスタンスに直接データをコピーします。 外部の MariaDB または MySQL データベースからのデータを RDS for MariaDB または RDS for MySQL DB インスタンスにインポートする
既存のデータベースに保存されないデータ ミディアム 1 回 ある程度 フラットファイルを作成し、mysqlimport ユーティリティを使用してインポートします。 任意のソースから MariaDB または MySQL DB インスタンスにデータをインポートする
オンプレミスまたは Amazon EC2 の既存の MariaDB または MySQL データベース すべて 継続的 最小限 レプリケーション元として既存の MariaDB または MySQL データベースを使用してレプリケーションを設定します。

外部のソースインスタンスを使用したバイナリログファイル位置のレプリケーションの設定

ダウンタイムを短縮して Amazon RDS MariaDB または MySQL データベースにデータをインポートする

注記

'mysql' システムデータベースには、DB インスタンスへのログインとデータへのアクセスに必要な認証情報が含まれています。DB インスタンスにある 'mysql' データベースのテーブル、データ、または他のコンテンツを削除、変更、名前変更、または切り取りを行うとエラーが発生し、DB インスタンスとデータにアクセスできなくなる場合があります。この場合は、AWS CLI の restore-db-instance-from-db-snapshot コマンドを使用して、スナップショットから DB インスタンスを復元できます。AWS CLI restore-db-instance-to-point-in-time コマンドを使用して、DB インスタンスを復元できます。

データのインポートに関する考慮事項

以下に、MySQL へのデータのロードに関連する追加の技術情報があります。この情報は、MySQL サーバーアーキテクチャを使い慣れた上級ユーザーを対象としています。LOAD DATA LOCAL INFILE に関連するすべてのコメントは、mysqlimport にも適用される点に注意してください。

バイナリログ

バイナリログ作成を有効にすると、データロードによりパフォーマンスが低下し、バイナリログ作成を無効にして同じデータをロードした場合より多くの空きディスク容量 (最大 4 倍) が必要になります。パフォーマンス低下の重要度と必要な空きディスク容量は、データのロードに使用されるトランザクションのサイズに正比例します。

トランザクションサイズ

トランザクションサイズは、MySQL データロードにおいて重要なロールを担います。リソース消費量、ディスク容量の使用率、再開プロセス、回復時間、および入力形式 (フラットファイルまたは SQL) に大きな影響を及ぼします。このセクションでは、トランザクションサイズがバイナリログ作成に与える影響について説明し、大量のデータロード中にバイナリログ作成を無効にするケースを作成します。前述のように、バイナリログ作成は、Amazon RDS 自動バックアップ保持期間を設定することにより有効化および無効化されます。値が 0 以外の場合はバイナリログ作成が有効になり、0 の場合は無効になります。InnoDB に対する大きいトランザクションの影響と、トランザクションサイズを小さくすることが重要な理由についても説明します。

小さいトランザクション

トランザクションが小さい場合、バイナリログ作成により、データのロードに必要なディスク書き込み数が 2 倍になります。この影響は、他のデータベースセッションのパフォーマンスを著しく低下させ、データのロードに必要な時間を長くします。発生する劣化は、アップロード速度、ロード中に発生する他のデータベース活動、Amazon RDS DB インスタンスの容量によって部分的に異なります。

バイナリログは、バックアップおよび削除されるまでにロードされたデータの量とほぼ同じディスク容量を消費します。さいわい、Amazon RDS はバイナリログを頻繁にバックアップおよび削除することにより、この容量を最小限に抑えます。

大きいトランザクション

バイナリログ作成を有効にすると、トランザクションが大きい場合、IOPS とディスク消費量が 3 倍になります。これは、ディスクに書き込まれるバイナリログキャッシュ、ディスク容量の消費、書き込みごとに増える IO が原因です。トランザクションがコミットまたはロールバックされるまでキャッシュは binlog に書き込むことができないため、ロードされたデータ量に比例してディスク容量が消費されます。トランザクションがコミットされたら、キャッシュを binlog にコピーして、ディスクにデータの 3 番目のコピーを作成する必要があります。

このため、バイナリログ作成を無効にした場合のロードと比較して、データのロードに使用できる容量の 3 倍の空きディスク容量が必要です。例えば、単一のトランザクションとしてロードされるデータの 10 GiB は、ロード中に少なくとも 30 GiB のディスク領域を消費します。バイナリログキャッシュでは 10 GiB、バイナリログでは 10 GiB + 10 GiB を消費します。キャッシュファイルは、そのキャッシュファイルを作成したセッションが完了するか、別のトランザクション中にセッションによってそのバイナリログキャッシュが再度いっぱいになるまで、ディスクに残ります。バイナリログはバックアップされるまでディスクに残る必要があるため、余分な 20 GiB が解放されるまで少し時間がかかることがあります。

LOAD DATA LOCAL INFILE を使用してデータがロードされた場合でも、ロード前に作成されたバックアップからデータベースを復元する必要がある場合はデータの別のコピーが作成されます。復旧時に、MySQL はバイナリログからフラットファイルにデータを抽出します。その後、MySQL は元のトランザクションと同様に LOAD DATA LOCAL INFILE を実行します。ただし、今回は入力ファイルがデータベースサーバーのローカルファイルです。上記の例を続行すると、使用可能な空きディスク容量が 40 GiB 以上ないと復元に失敗します。

バイナリログ記録の無効化

可能であれば、リソースのオーバーヘッドとディスク容量要件の増加を回避するために、必ず大きいデータのロード時はバイナリログ作成を無効にします。Amazon RDS では、バックアップ保持期間を 0 に設定するだけでバイナリログ作成を無効にできます。これを行う場合は、ロード直前にデータベースインスタンスの DB スナップショットを取ることをお勧めします。これにより、必要に応じてロード中に加えられた変更を迅速かつ簡単に取り消すことができます。

ロード後、バックアップ保持期間を適切な値 (0 以外) に戻します。

DB インスタンスがリードレプリカのソース DB インスタンスである場合、バックアップ保持期間を 0 に設定することはできません。

InnoDB

このセクションの情報は、InnoDB を使用する場合にトランザクションサイズを小さく保つことに対する強力な反論となっています。

[Undo] (元に戻す)

InnoDB は、トランザクションロールバックや MVCC などの機能をサポートするために undo を生成します。undo は、InnoDB システムのテーブルスペース (通常は ibdata1) に格納され、消去スレッドにより削除されるまで保持されます。消去スレッドは、最も古いアクティブトランザクションの undo より先に進むことができないため、トランザクションがコミットされるか、ロールバックを完了するまで事実上ブロックされます。データベースが、ロード中に他のトランザクションを処理する場合、その undo もシステムのテーブルスペースで累積され、それらのトランザクションがコミットされて MVCC の undo を必要とするトランザクションが他にない場合でも削除できません。この状況では、ロードトランザクションだけでなくトランザクションによって変更された行にアクセスするすべてのトランザクション (読み取り専用トランザクションを含む) が減速します。スローダウンは、トランザクションが長時間実行されているロードトランザクションではない場合に、パージされた可能性のある UNDO をスキャンするために発生します。

UNDO はシステム表領域に保存され、システム表領域は縮小されません。したがって、大量のデータロードトランザクションにより、システム表領域が非常に大きくなり、データベースをゼロから再作成せず、再利用できないディスク領域が消費される可能性があります。

ロールバック

InnoDB は、コミット用に最適化されます。大きいトランザクションをロールバックすると、かなり長い時間がかかる可能性があります。場合によっては、ポイントインタイムリカバリの実行や DB スナップショットの復元をすばやく実行できることがあります。

入力データ形式

MySQL は、2 つの形式 (フラットファイルと SQL) のいずれかの受信データを受け入れることができます。このセクションでは、各形式の重要なメリットとデメリットについていくつか説明します。

フラットファイル

LOAD DATA LOCAL INFILE を使用したフラットファイルのロードは、トランザクションが比較的小さく保たれていれば、最も高速でコストがかからないデータのロード方法となる可能性があります。フラットファイルは、SQL を使用して同じデータをロードする場合と比較して、通常、必要なネットワークトラフィックが少ないために送信コストが下がり、データベースのオーバーヘッドが減るため、かなりロードが高速になります。

1 つの大きいトランザクション

LOAD DATA LOCAL INFILE は、フラットファイル全体を 1 つのトランザクションとしてロードします。これは必ずしも悪いことではありません。個別のファイルのサイズを小さく保てば、多くのメリットがあります。

  • 再開機能 - ロードされたファイルを把握するのが簡単です。ロード中に問題が生じた場合、中止した場所を少ない労力で特定できます。あるデータを Amazon RDS に再送信する必要がある場合でも、ファイルが小さいと、再送信される量は最小限ですみます。

  • データの同時ロード - 単一ファイルのロードにより余分な IOPS とネットワーク帯域幅が生じた場合、同時にロードすると時間を節約できる可能性があります。

  • ロード速度の調整 - 他のプロセスに悪影響を与えるデータロード ファイルの間隔を大きくすることによってロードを調整します。

注意

トランザクションサイズが大きくなると、LOAD DATA LOCAL INFILE のメリットは急速に減ります。大きいデータセットを小さいセットに分割できない場合、SQL が適切な選択肢となる可能性があります。

SQL

SQL には、フラットファイルよりもトランザクションサイズを小さく保ちやすいという主要なメリットがあります。ただし、SQL はフラットファイルよりロードにかなり時間がかかることがあり、エラー後にロードを再開する場所を特定しにくい場合があります。例えば、mysqldump ファイルは再開できません。mysqldump ファイルのロード中にエラーが発生した場合、ロードを再開するにはファイルを変更するか置き換える必要があります。または、ロード前の時点まで復元し、エラーの原因が修正されてからファイルを再開する必要があります。

Amazon RDS スナップショットを使用したチェックポイントの取得

数時間あるいは数日かかるロードがある場合、定期的なチェックポイントを取得できなければ、バイナリログを作成しないロードはあまり魅力的な方法ではありません。このような場合は、Amazon RDS DB スナップショット機能がかなり役立ちます。DB スナップショットは、データベースインスタンスのある時点の一貫したコピーを作成します。クラッシュや他の問題が発生した後、その時点までデータベースを復元するために使用できます。

チェックポイントを作成するには、DB スナップショットを取得するだけです。チェックポイントに取得された以前の DB スナップショットはどれも、耐久性の高いや復元時間に影響を与えずに削除できます。

スナップショットが高速でもあるため、チェックポイントを頻繁に取得してもロード時間はそれほど長くなりません。

ロード時間の短縮

ロード時間を短縮するための他のヒントを以下に示します。

  • ロード前にすべてのセカンダリインデックスを作成します。これは、他のデータベースを使い慣れているユーザーにとっては直観に反する方法です。セカンダリインデックスを追加または変更すると、MySQL はインデックスを変更して新しいテーブルを作成し、既存のテーブルから新しいテーブルにデータをコピーして、元のファイルを削除します。

  • データを PK の順序でロードします。これは、ロード時間を 75-80% 短縮し、データファイルサイズを半分に削減できる InnoDB テーブルに特に役立ちます。

  • 外部キー制約 foreign_key_checks=0 を無効にします。LOAD DATA LOCAL INFILE を使用してロードされたフラットファイルには、多くの場合これが必要です。どのロードでも、FK チェックを無効にするとパフォーマンスが大幅に向上します。必ず、ロード後に制約を有効にしてデータを検証してください。

  • リソース制限に近づいている場合を除き、同時にロードしてください。適切な場合はパーティショニングされたテーブルを使用します。

  • SQL でロードするときは、複数値の挿入を使用して、ステートメントの実行時のオーバーヘッドを最小限に抑えます。これは、mysqldump を使用すると自動的に行われます。

  • InnoDB ログ IO innodb_flush_log_at_trx_commit=0 の削減

  • リードレプリカがない DB インスタンスにデータをロードする場合、データロード中に sync_binlog パラメータを 0 に設定します。データのロードが完了したら、sync_binlog パラメータを 1 に戻します。

  • DB インスタンスをマルチ AZ 配置に変換する前に、データをロードします。ただし、DB インスタンスがすでにマルチ AZ 配置を使用している場合には、データをロードするために単一 AZ 配置に切り替えることは推奨されません。これは、最小限の改善のみの結果となるためです。

注記

innodb_flush_log_at_trx_commit=0 を使用すると、InnoDB はコミットごとではなく 1 秒ごとにログをフラッシュします。これには速度上のメリットがかなりありますが、クラッシュ時にデータが失われる可能性があります。注意して使用してください。