おすすめの方法

このページでは、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 Proxy を使用している場合は、必ず最新のバージョンを使用してください。 Cloud SQL Proxy を最新の状態に保つをご覧ください。

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

おすすめの方法 より詳しく
小規模なインスタンスのインポートを高速化してください。 小規模なインスタンスの場合、一時的にインスタンスの階層を高くすることにより、大規模なデータセットをインポートする際のパフォーマンスを向上させることができます。
Cloud SQL にインポートするデータをエクスポートする場合は、適切な手順を使用してください。 Cloud SQL にインポートするデータをエクスポートするをご覧ください。
エクスポートするときには、適切な mysqldump コマンドを使用してインポートを高速化します。 mysqldump ユーティリティを使用して Cloud SQL へのインポート用にデータをエクスポートする場合は、次のオプションを検討します。
  • 自動コミットを無効にし、--single-transaction オプションを使用して単一のトランザクションでファイルまたはテーブルをラップします。
  • --extended-insert オプション(デフォルトではオン)を使用して、各 INSERT ステートメントに多くの行を含めます。
第 1 世代インスタンスでは、非同期ファイル システムのレプリケーションを使用してください。
データベースへの最初のインポートでは、ファイル システムのレプリケーションで非同期モードを使用します。インポートが完了したら、本番環境用の同期モードに戻します。既存のインスタンスの編集により 2 つのモードを切り替えることができます。
適切な Cloud SQL 機能を使用してデータを保護してください。

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

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

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

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...