このページでは、Cloud SQL でデータをインポートおよびエクスポートする際のベスト プラクティスを示します。Cloud SQL にデータをインポートする詳細な手順については、データのインポートをご覧ください。
ご自身が管理する MySQL インスタンスで使用する Cloud SQL からデータをエクスポートするには、SQL ダンプファイルを使用したエクスポートとインポートまたは CSV ファイルを使用したエクスポートとインポートをご覧ください。
インポートとエクスポートのベスト プラクティス
データをインポートおよびエクスポートする際に考慮すべきベスト プラクティスは次のとおりです。
- インポートとエクスポートに同じ SQL モードを使用する
- Cloud Storage リクエスト元による支払いバケットを使用しない
- エクスポートのパフォーマンスへの影響を最小限に抑える
- SQL ダンプファイルの作成時に正しいフラグを使用する
- コスト削減のため、データを圧縮する
- 長時間にわたるインポートおよびエクスポート プロセスを削減する
- InnoDB を使用する
- DEFINER 句で定義したメタデータを含む MySQL インポート ジョブと移行ジョブ
- インポートしたデータベースを確認する
インポートとエクスポートに同じ SQL モードを使用する
SQL モード設定は、Cloud SQL で SQL クエリをどのように解釈するかに影響します。たとえば、[Strict SQL] を有効にせずにデータベースからエクスポートし、Cloud SQL (デフォルトで [Strict SQL] を有効にします)にインポートしようとすると、インポートが失敗することがあります。ベスト プラクティスは、エクスポートで使用したのと同じ SQL モードをインポートで使用することです。
互換性のために、ソース データベースとターゲット データベースの両方で SQL モードを確認します。Strict SQL モードを有効にするフラグに特に注意してください。Strict SQL がデータベースで設定されていない場合は、Cloud SQL で削除することをおすすめします。Strict SQL を削除する場合は、別のフラグを設定する必要があります。
Cloud SQL インスタンスで目的のモードが設定されていることを確認するには、SELECT @@GLOBAL.sql_mode;
を実行します。
Cloud Storage リクエスト元による支払いバケットを使用しない
Cloud SQL からのインポートとエクスポートに、リクエスト元による支払いが有効になっている Cloud Storage バケットは使用できません。
エクスポートのパフォーマンスへの影響を最小限に抑える
Cloud SQL からの標準エクスポートの場合、データベースがオンラインであるときにエクスポートが実行されます。エクスポートされるデータが小さい場合、影響は最小限であると考えられます。しかし、大きなデータベースがある場合や、BLOB などの大きいオブジェクトがデータベースにある場合、エクスポートによってデータベースのパフォーマンスが低下する可能性があります。これは、データベースに対するデータベース クエリとオペレーションの実行にかかる時間に影響します。エクスポートの開始後は、データベースのレスポンスが遅くなっても停止することはできません。
エクスポート中にレスポンスが低速になるのを回避するには、次のようにします。
リードレプリカからエクスポートを取得します。エクスポートを頻繁に(毎日またはそれ以上の頻度で)行う場合、エクスポートされるデータ量が少なければ、これが適切な選択肢になります。リードレプリカからエクスポートするには、Google Cloud コンソール、
gcloud
、または REST API を使用して、リードレプリカ インスタンスに対してエクスポート機能を実行します。リードレプリカの作成と管理の方法については、リードレプリカの作成をご覧ください。サーバーレス エクスポートを使用します。サーバーレス エクスポートを使用すると、エクスポート オペレーションをオフロードするために、個別の一時的なインスタンスが Cloud SQL によって作成されます。エクスポート オペレーションをオフロードすると、プライマリ インスタンスのデータベースでクエリの送信を継続するので、通常のパフォーマンス速度でオペレーションを実行できます。データのエクスポートが完了すると、一時的なインスタンスは自動的に削除されます。大規模なデータベースの 1 回限りのエクスポートを作成する場合は、これが適切な選択肢になります。サーバーレス エクスポート オペレーションを実行するには、Google Cloud コンソール、
gcloud
または REST API で、offload
フラグを指定してエクスポート機能を実行します。サーバーレス エクスポート オペレーションの最中は、インスタンスの編集、インポート、フェイルオーバーなどの他の一部のオペレーションを行えます。ただし、
サーバーレス エクスポート オペレーションの実行中にブロックされる可能性があるオペレーションについては、次の表をご覧ください。delete
を選択すると、インスタンスを削除した後、エクスポート オペレーションはしばらく停止し、その間、データはエクスポートされません。現在のオペレーション 新しいオペレーション ブロックの有無 任意のオペレーション サーバーレス エクスポート あり サーバーレス エクスポート サーバーレス エクスポートを除くオペレーション なし サーバーレス エクスポートを除くオペレーション サーバーレス エクスポートを除くオペレーション あり サーバーレス エクスポートでは、一時インスタンスの作成に時間がかかるため、標準エクスポートよりも時間がかかります。最短でも 5 分以上かかりますが、大規模なデータベースの場合は、さらに時間がかかることもあります。使用するエクスポート方法を決定する前に、時間、パフォーマンス、費用への影響を検討してください。
SQL ダンプファイルの作成時に正しいフラグを使用する
データを SQL ダンプファイルにエクスポートするときに正しいフラグを使用しなかった場合、インポートが失敗する可能性があります。Cloud SQL にインポートする SQL ダンプファイルの作成については、SQL ダンプファイルの作成をご覧ください。コスト削減のためデータを圧縮する
Cloud SQL では、圧縮ファイルと非圧縮ファイルの両方のインポートとエクスポートがサポートされています。特に大きいインスタンスをエクスポートするときは、圧縮すると Cloud Storage の保存容量を大幅に節約でき、ストレージ コストの削減にもなります。
SQL ダンプファイルや CSV ファイルをエクスポートする場合は、ファイル拡張子.gz
を使用してデータを圧縮します。ファイル拡張子 .gz
のファイルは、インポートすると自動的に解凍されます。
長時間にわたるインポートおよびエクスポート プロセスの削減
処理対象のデータのサイズによっては、Cloud SQL へのインポートと Cloud SQL からのエクスポートが長時間にわたる可能性があります。その結果、次の影響があります。
- 長時間実行されている Cloud SQL インスタンス オペレーションを停止できません。
- 各インスタンスに対して実行できるインポートまたはエクスポート オペレーションは、一度に 1 つのみです。長時間にわたるインポートまたはエクスポートにより、毎日の自動バックアップなど、他のオペレーションがブロックされます。サーバーレス エクスポートの場合は、インスタンスの編集、インポート、フェイルオーバー、毎日の自動バックアップのブロック解除など、他のオペレーションを実行できます。
Cloud SQL のインポートまたはエクスポート機能をバッチサイズのより小さいデータで使用して、各オペレーションの完了に要する時間を短縮できます。
エクスポートの場合は、リードレプリカからエクスポートを行うか、サーバーレス エクスポートを使用してデータベースのパフォーマンスへの影響を最小限に抑えつつ、エクスポートの実行中にインスタンスで他のオペレーションを実行できます。
その他のヒントについては、Cloud SQL インスタンスでの問題を診断するをご覧ください。InnoDB を使用する
InnoDB は、MySQL インスタンスでサポートされている唯一のストレージ エンジンです。
次のように sed スクリプトを使って mysqldump の出力をパイプでつなぐことで、MyISAM から InnoDB にテーブルを変換できます。
mysqldump --databases [DATABASE_NAME] \ -h [INSTANCE_IP] -u [USERNAME] -p [PASSWORD] \ --hex-blob --default-character-set=utf8mb4 | sed 's/ENGINE=MyISAM/ENGINE=InnoDB/g' > [DATABASE_FILE].sql
DEFINER 句で定義したメタデータを含む MySQL インポート ジョブと移行ジョブ
MySQL のインポート ジョブまたは移行ジョブでは、ソース、ユーザーデータ、ユーザーが DEFINER
句で定義したメタデータを含むダンプファイルが移行されません。ユーザーがまだ存在しないため、このインポートまたは移行は失敗します。
メタデータに存在する DEFINER
値を確認するには、次のクエリを使用するか、ダンプファイル内を検索して、root%localhost
またはターゲット インスタンスが存在しないユーザーのエントリがあるかどうかを確認します。
SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.EVENTS; SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.ROUTINES; SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.TRIGGERS; SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.VIEWS;
このようなメタデータを含むソースからインポート ジョブまたは移行ジョブを実行するには、次のいずれかの操作を行います。
- インポート ジョブまたは移行ジョブを開始する前に、ターゲット Cloud SQL インスタンスにユーザーを作成します。
- インポート ジョブまたは移行ジョブを開始する前に、ソースの MySQL インスタンスまたはダンプファイルで
DEFINER
句をINVOKER
に更新します。
インポートしたデータベースを確認する
インポートが完了したら、データベースに接続し、該当するデータベース コマンドを実行して内容が正しいことを確認します。たとえば接続して、データベース、テーブル、特定のエントリを一覧表示します。
既知の制限事項
既知の制限事項のリストについては、データのインポートとエクスポートに関する問題をご覧ください。
エクスポート オペレーションの自動化
Cloud SQL にはデータベースのエクスポートを自動化するための組み込みの機能はありませんが、いくつかの Google Cloud コンポーネントを使用して、独自の自動化ツールを構築できます。詳細については、このチュートリアルをご覧ください。
トラブルシューティング
インポート オペレーションのトラブルシューティング
問題 | トラブルシューティング |
---|---|
HTTP Error 409: Operation failed because another operation was already in progress . |
保留中のオペレーションがインスタンスにすでに存在しています。一度に実行できるオペレーションは 1 つだけです。現在のオペレーションが完了してからリクエストを試してください。 |
インポート オペレーションに時間がかかりすぎる。 | アクティブな接続が多すぎると、インポート オペレーションが妨げられる可能性があります。 未使用のオペレーションを終了します。Cloud SQL インスタンスの CPU とメモリ使用量をチェックして、十分なリソースがあることを確認します。インポートに最大限のリソースを確保するため、オペレーションを開始する前にインスタンスを再起動することをおすすめします。 再起動により、次の処理が行われます。
|
ダンプファイルで参照しているユーザーが存在しない場合、インポート オペレーションが失敗することがある。 | ダンプファイルをインポートする前に、オブジェクトを所有しているデータベース ユーザーか、ダンプされたデータベース内のオブジェクトに対する権限が付与されているデータベース ユーザーがターゲット データベース内に存在している必要があります。そうでない場合、インポート オペレーションを実行すると、元の所有権または権限でのオブジェクトの再作成に失敗します。 インポートする前に、データベース ユーザーを作成します。 |
インポート オペレーションが失敗し、テーブルが存在しないというエラーが表示される。 | テーブルに他のテーブルの外部キーと依存関係が存在する場合があります。このため、オペレーションの順序によっては、インポート オペレーション中に 1 つ以上のテーブルがまだ存在しない可能性があります。 次の方法をお試しください。 次の行をダンプファイルの先頭に追加します。 SET FOREIGN_KEY_CHECKS=0; また、次の行をダンプファイルの末尾に追加します。 SET FOREIGN_KEY_CHECKS=1; これらの設定により、インポート オペレーション中のデータの整合性チェックが無効になり、データの読み込み後に再び有効になります。ダンプファイルの作成時にデータがすでに検証されているため、この設定はデータベース上のデータの整合性には影響しません。 |
エクスポート オペレーションのトラブルシューティング
問題 | トラブルシューティング |
---|---|
HTTP Error 409: Operation failed because another operation was
already in progress. |
保留中のオペレーションがインスタンスにすでに存在しています。一度に実行できるオペレーションは 1 つだけです。現在のオペレーションが完了してからリクエストを試してください。 |
HTTP Error 403: The service account does not have the required
permissions for the bucket. |
バケットが存在し、バケットへのエクスポートを許可する Storage Object Creator ロール(roles/storage.objectCreator )が Cloud SQL インスタンス用のサービス アカウント(エクスポートを行っているアカウント)に付与されていることを確認します。Cloud Storage に適用される IAM ロールをご覧ください。 |
CSV のエクスポートは機能したが、SQL エクスポートに失敗した。 | CSV 形式と SQL 形式ではエクスポート方法が異なります。SQL 形式ではデータベース全体がエクスポートされるため、完了までに時間がかかります。CSV 形式ではエクスポートに含めるデータベースの要素を定義できます。 CSV エクスポートを使用して必要なものだけをエクスポートします。 |
エクスポートに時間がかかりすぎる。 | Cloud SQL では同時実行オペレーションの同期がサポートされません。 エクスポートをオフロードします。エクスポートをオフロードするときに、Cloud SQL はソース インスタンスでエクスポートを発行するのではなく、オフロード インスタンスを起動してエクスポートを実行します。エクスポート オフロードには、ソース インスタンスでのパフォーマンス向上、エクスポート実行中の管理オペレーションのブロック解除などの利点があります。エクスポート オフロードでは、合計レイテンシがオフロード インスタンスの起動時間まで増加する可能性があります。一般に、適当なサイズのエクスポートでは、レイテンシは重要ではありません。ただし、エクスポートが小さい場合、レイテンシが増加することがあります。 |
エクスポートを自動化したい。 | Cloud SQL には、エクスポートを自動化する方法がありません。 自動バックアップの自動化に関する記事のように、Google Cloud プロダクト(Cloud Scheduler、Pub/Sub、Cloud Run 関数)を使用して、独自の自動エクスポート システムを構築できます。 |
次のステップ
- SQL ダンプファイルを使用してデータをインポートまたはエクスポートする方法を学習します。
- CSV ファイルを使用してデータのインポートとエクスポートを行う方法を学習します。
- 自動バックアップを有効にする方法を学習します。
- バックアップから復元する方法を学習します。