メニュー
Amazon Relational Database Service
ユーザーガイド (API Version 2014-10-31)

MySQL DB インスタンスからのデータのインポートおよびエクスポート

MySQL DB インスタンスとの間でデータのインポートまたはエクスポートを行うには、このセクションの手順に従うことをお勧めします。これらの手順は、他の MySQL DB インスタンス、Amazon RDS の外部で実行されている MySQL インスタンス、他の種類のデータソースからデータをインポートする際に使用できます。レプリケーションを使用して、Amazon RDS の外部で実行されている MySQL のインスタンスにデータをエクスポートするには、「レプリケーションを使用した MySQL データのエクスポート」で説明している手順に従うことをお勧めします。

概要

以下に説明する状況で MySQL DB インスタンスにデータをインポートするには、以下の手順をお勧めします。

  • AWS Database Migration Service を使用すると、非常に効率的にデータを移行できる場合があります。AWS DMS では、ダウンタイムを最小にしながらデータベースを移行できます。ほとんどのデータベースエンジンで、MySQL DB インスタンスに切り替える準備ができるまで、進行中のレプリケーションを継続できます。AWS DMS を使用して、非 MySQL データベースエンジンから Amazon RDS MySQL DB インスタンスへの移行や、MySQL データベースの一部移行を行うことができます。別のデータベースエンジンから MySQL へ移行する場合は、AWS Schema Conversion Tool を使用して、AWS DMS では移行されないスキーマオブジェクトを移行できます。AWS DMS の詳細については、「AWS Database Migration Service とは」を参照してください。

    次の条件がすべて満たされる場合は、AWS DMS ではなく MySQL データベース移行ツールを使用することをお勧めします:

    • MySQL データベースから Amazon RDS MySQL DB インスタンスに移行する同機種間移行がある。

    • データベース全体を移行する。

      AWS DMS は、MySQL データベースからのデータのサブセットを Amazon RDS に移行する場合には最適なオプションです。ただし、データベース全体を移行するときは、AWS DMS でテーブル、プライマリキー、場合によっては一意のインデックスは作成されますが、ソースのデータを効率的に移行するためには不要なその他のオブジェクトは作成されません。たとえば、セカンダリインデックス、非プライマリキーの制約、データデフォルトは作成されません。データベースをすべて移行する場合は、RDS MySQL DB インスタンスにスキーマをコピーしてから、AWS DMS を使用してデータを移行できます。または、このトピックで後述するネイティブの MySQL 移行ツールを使用します。

    • MySQL データベース移行ツールを使用すると、データベースの移行に必要なダウンタイムが軽減されます。例については、「わずかなダウンタイムでの Amazon RDS MySQL または MariaDB DB インスタンスへのデータのインポート」を参照してください。

  • MySQL DB インスタンスの既存のデータベースからデータをインポートするには、リードレプリカを作成してからリードレプリカを昇格させます。詳細については、「PostgreSQL、MySQL、および MariaDB リードレプリカの使用」を参照してください。

  • 少量の MySQL データを移動する場合や、ソース MySQL データベースでサービスの中断が問題にならない場合は、コマンドラインユーティリティを使用して Amazon RDS MySQL DB インスタンスに直接データをコピーするシンプルな手順を使用できます。詳細については、「MySQL DB または MariaDB DB から Amazon RDS MySQL または MariaDB DB インスタンスへのデータのインポート」を参照してください。

  • 大量の MySQL データを移動する場合や、外部の MySQL インスタンスを使用する実際のサイトやアプリケーションでサービス中断を最小限にする必要がある場合は、データをバックアップし、Amazon Elastic Compute Cloud (Amazon EC2) にデータをコピーして、Amazon RDS MySQL DB インスタンスにインポートできます。次に、レプリケーションを使用して、Amazon EC2 へのコピー以降にソースシステムに追加されたすべてのデータについて 2 個のインスタンスを同期します。詳細については わずかなダウンタイムでの Amazon RDS MySQL または MariaDB DB インスタンスへのデータのインポート.

  • 既存の MySQL データベース以外のソースのデータの場合は、フラットファイルを作成し、mysqlimport ユーティリティを使用してインポートできます。詳細については、「任意のソースから MySQL または MariaDB DB インスタンスへのデータのインポート」を参照してください。

  • レプリケーションマスターとして既存の MySQL DB インスタンスを使用するレプリケーションをセットアップする場合は、「Amazon RDS の外部で実行される MySQL または MariaDB インスタンスとのレプリケーション」を参照してください。

注記

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

データのインポートの考慮事項

このセクションには、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 倍の空きディスク容量が必要です。たとえば、1 つのトランザクションとしてロードされる 10 GB のデータは、ロード中に少なくとも 30 GB ディスク容量を消費します (テーブルに 10 GB + バイナリログキャッシュに 10 GB + バイナリログ自体に 10 GB)。キャッシュファイルは、そのキャッシュファイルを作成したセッションが完了するか、別のトランザクション中にセッションによってそのバイナリログキャッシュが再度いっぱいになるまで、ディスクに残ります。バイナリログはバックアップされるまでディスクに残る必要があるため、余分な 20 GB が解放されるまで少し時間がかかることがあります。

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

バイナリログ作成の無効化

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

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

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

InnoDB

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

元に戻す

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 の削減

注記

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