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

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

次の表は、RDS for MySQL DB インスタンスにデータをインポートする手法の一覧です。

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

以下の内容は、MySQL へのデータのロードに関する追加の技術情報です。この情報は、MySQL サーバーアーキテクチャを使い慣れた上級ユーザーを対象としています。

バイナリログ

バイナリログ作成を有効にすると、データロードによりパフォーマンスが低下し、バイナリログ作成を無効にして同じデータをロードした場合より多くの空きディスク容量 (最大 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 つのトランザクションとしてロードします。これは必ずしも悪いことではありません。個別のファイルのサイズを小さく保てば、多くのメリットがあります。

注意

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

SQL

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

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

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

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

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

ロード時間の短縮

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