一般的に推奨される利用方法

このページでは、Cloud SQL のパフォーマンス、耐久性、可用性を高めるためのおすすめの方法を示します。

Cloud SQL インスタンスで問題が発生した場合は、トラブルシューティングの際に次の点を確認してください。

インスタンスの構成と管理

ベスト プラクティス 詳細
オペレーション ガイドラインを参照し、その手順に沿ってご使用のインスタンスが Cloud SQL SLA の対象であることを確認してください。
中断更新がいつ発生するかを制御するため、プライマリ インスタンスのメンテナンスの時間枠を構成してください。 メンテナンスの時間枠をご覧ください。
読み取り負荷の高いワークロードについては、リードレプリカを追加してプライマリ インスタンスからトラフィックをオフロードしてください。 必要に応じて、HAProxy などのロードバランサを使用して、レプリカへのトラフィックを管理できます。
インスタンスを定期的に削除して再作成する場合は、新しいインスタンス ID が使用可能になる確率を高めるため、インスタンス ID にタイムスタンプを使用してください。 インスタンスを削除すると、削除したインスタンスの ID は数日間再利用できません。
前のオペレーションが完了する前に管理オペレーションを開始しないでください。

Cloud SQL インスタンスは、前のオペレーションが完了するまで、新しいオペレーション リクエストを受け付けません。準備が整う前に新しいオペレーションを開始しようとすると、オペレーション リクエストは失敗します。こうしたオペレーションには、インスタンスの再起動も含まれます。

Cloud Console のインスタンス ステータスには、オペレーションが実行されているかどうかは反映されません。緑色のチェックマークは、インスタンスが RUNNABLE 状態にあることのみを示します。オペレーションが実行中かどうかを確認するには、[オペレーション] タブに移動して、最新のオペレーションのステータスをチェックします。

システム テーブルを更新したらフラッシュしてください。 MySQL システム テーブル(mysql.user や mysql.db など)は MyISAM ストレージ エンジンを使用します。これらのテーブルは正常でないシャットダウンによって破損するおそれがあります。そのため、mysql クライアントでユーザーを追加または更新するなどの変更をこれらのテーブルに対して行った後は、FLUSH CHANGES コマンドを発行します。MyISAM が破損した場合、インスタンスを再起動できれば、CHECK TABLE コマンドと REPAIR TABLE コマンドを使用して破損への対処を試みることができますが、表の内容が正しくない可能性があります。

データ アーキテクチャ

ベスト プラクティス 詳細
可能であれば、インスタンスのシャーディングを行ってください。 可能であれば、大規模なインスタンスを 1 つ使用するより、小規模な Cloud SQL インスタンスを多数使用することをおすすめします。大規模なモノリシック インスタンスを管理する場合、多数の小規模なインスタンスでは生じない問題に直面します。
あまりに多くのデータベース テーブルを使用しないでください。

データベース テーブルが多すぎると、インスタンスのレスポンス時間に影響するおそれがあります。テーブルの数が 10,000 を超えると、SLA の対象範囲に影響します。詳細については、オペレーション ガイドラインをご覧ください。

テーブルに主キーまたは一意のキーがあることを確認してください。 Cloud SQL は行ベースのレプリケーションを使用します。これは、主キーまたは一意のキーを持つテーブルで最も効果的です。

アプリケーションの実装

ベスト プラクティス 詳細
接続プーリングや指数バックオフなどの適切な接続管理方法を使用してください。 これらの手法は、アプリケーションのリソース使用を効率化して Cloud SQL の接続上限内に収めるのに役立ちます。詳細とコードサンプルについては、データベース接続の管理をご覧ください。
メンテナンスの時間枠内でいつでも発生する可能性があるメンテナンス更新に対するアプリケーションのレスポンスをテストしてください。 メンテナンス更新に最も近いのは、インスタンスのマシンタイプの変更です。ただし、メンテナンス更新では、最初にフェイルオーバー レプリカが更新されてオフラインになり、続いてレプリカの更新の完了後にプライマリ インスタンスが更新されてオフラインになります。一方、マシンタイプの変更では、レプリカがオフラインになる前にプライマリ インスタンスがオフラインになります。アプリケーションが、メンテナンス イベントの後でオペレーションを再開できるように、可能ならば指数バックオフを使用して、少なくとも 10 分間データベースに再接続を試みて確認します。詳細については、データベース接続の管理をご覧ください。
いつでも発生する可能性があるフェイルオーバーに対するアプリケーションのレスポンスをテストしてください。 手動でフェイルオーバーを開始するには、Cloud Console、gcloud コマンドライン ツール、または API を使用できます。フェイルオーバーの開始をご覧ください。
大規模なトランザクションは回避します。 トランザクションのサイズを小さくして、短時間で終わるようにしてください。大規模なデータベース更新が必要な場合は、1 つの大規模なトランザクションではなく、複数の小規模なトランザクションを使用してください。
Cloud SQL Auth Proxy を使用している場合は、必ず最新のバージョンを使用してください。 Cloud SQL Auth Proxy の最新状態の維持をご覧ください。

データのインポートとエクスポート

ベスト プラクティス 詳細
小規模なインスタンスのインポートを高速化してください。 小規模なインスタンスでは、一時的にインスタンスの CPU と RAM を追加して、大規模なデータセットをインポートする際のパフォーマンスを強化できます。
Cloud SQL にインポートするデータをエクスポートする場合は、適切な手順を使用してください。 外部管理データベース サーバーからデータをエクスポートするをご覧ください。
エクスポートするときには、適切な mysqldump コマンドを使用してインポートを高速化します。 mysqldump ユーティリティを使用して Cloud SQL へのインポート用にデータをエクスポートする場合は、次のオプションを検討します。
  • 自動コミットを無効にし、--single-transaction オプションを使用して単一のトランザクションでファイルまたはテーブルをラップします。
  • --extended-insert オプション(デフォルトではオン)を使用して、各 INSERT ステートメントに多くの行を含めます。
エクスポートとインポートを使用してデータを移行する場合は、エクスポートとまったく同じ SQL モードをインポートに使用します。 インポートとエクスポートに同じ SQL モードを使用するをご覧ください。

バックアップとリカバリ

ベスト プラクティス 詳細
適切な Cloud SQL 機能を使用してデータを保護してください。

バックアップ、ポイントインタイム リカバリ、エクスポートは、データの冗長性を確保して保護するための手段です。これらは異なるシナリオでそれぞれ機能し、堅牢なデータ保護戦略でお互いを補います。

バックアップは簡単で、インスタンスのデータをバックアップ作成時の状態に復元する手段を提供します。ただし、バックアップにはいくつかの制限があります。インスタンスを削除すると、バックアップも削除されます。単一のデータベースまたはテーブルをバックアップすることはできません。また、インスタンスが配置されているリージョンを使用できない場合、使用可能なリージョンにあるバックアップからそのインスタンスを復元することはできません。

ポイントインタイム リカバリにより、インスタンスを特定のポイントインタイムに復旧できます。たとえば、エラーによってデータが失われた場合、エラーが発生する前の状態にデータベースを復旧できます。ポイントインタイム リカバリは、常に新しいインスタンスを作成します。既存のインスタンスには、ポイントインタイムを実行できません。

データの再作成に使用できる外部ファイルが Cloud Storage に作成されるため、エクスポートは作成するのに時間がかかります。インスタンスを削除しても、エクスポートは影響を受けません。また、選択するエクスポート形式に応じて、単一のデータベースまたはテーブルだけをエクスポートすることもできます。

トランザクション ログの保持を考慮してインスタンスのサイズを調整します。 データベースに対する書き込みが多いと、大量のトランザクション ログが生成され、かなりのディスク スペースを消費する可能性があり、ストレージの自動増量が有効になっているインスタンスではディスクが増大する原因になります。インスタンスのストレージ サイズは、トランザクション ログの保持を考慮して調整することをおすすめします。