- 概要
- 利用の開始
- データ ストレージとレプリケーション
- バックアップとリカバリ
- インスタンスの管理
- データベースを拡大または縮小することはできますか?
- Google Cloud SQL を管理するには Google Cloud Platform Console を使用する必要がありますか?
- Google Cloud SQL ではどれくらいの大きさのデータベースまで使用できますか?
- どうすれば削除したテーブルのスペースを再利用できますか?
- どうすればデータの変更を追跡できますか?
- インスタンスではどのような種類のメンテナンス シャットダウンを予期する必要がありますか?
- 特定のデータベースをインポートまたはエクスポートできますか?
- CSV ファイルをインポートまたはエクスポートできますか?
- インスタンスのデータのインポートまたはエクスポートには Google Cloud Storage アカウントが必要ですか?
- インポート オペレーションでの
ERROR_RDBMSは何を意味しますか? - 削除したインスタンスのインスタンス名を再利用できますか?
- cloudsqladmin データベース ユーザーとは何ですか?
GRANT ALLを使用するにはどうすればよいですか?- どうすればインスタンスのトランザクション ログにアクセスできますか?
- 料金と課金
- どうすれば Google Cloud SQL を試すことができますか?
- 料金プランは、従量制とパッケージのどちらがいいですか?
- 料金プランは変更できますか?
- プロジェクトではインスタンスをいくつ作成できますか?
- どれくらいのサイズのデータベース インスタンスが必要ですか?RAM はどれくらい必要ですか?
- インスタンスの使用時間はどのようにして算出されますか?
- ストレージはどのようにして算出されますか?
- 請求額はどこで確認できますか?
- "従量制" プランを使用しているアイドル状態の第 1 世代インスタンスで料金が発生するのはなぜですか?
- インスタンスが上限サイズに達したらどうなりますか?
- インスタンスが停止しているのはなぜですか?
- インスタンスが削除されたのはなぜですか?
- どうすれば Google Cloud SQL アカウントをキャンセルできますか?
- 課金を無効にするにはどうすればよいですか?
- App Engine での Cloud SQL の使用
- App Engine から MySQL 第 2 世代インスタンスに接続できますか?
- App Engine から PostgreSQL インスタンスに接続できますか?
- 米国の App Engine から EU の Google Cloud SQL インスタンスにアクセス(またはその逆)できますか?
- Google Cloud SQL と App Engine Datastore のどちらを使用すればよいですか?
- App Engine 開発サーバーを使用するためにローカルのデータベース サーバーをインストールする必要はありますか?
- インスタンスにアクセスするにはどの言語を使用する必要がありますか?
- Django を Google Cloud SQL で使用できますか?
- Python クエリ文字列ではどのプレースホルダを使用できますか?
- どのように接続を管理する必要がありますか?
- "無効な接続 ID" というメッセージの SQLException の意味は何ですか?
- App Engine の外部にある Google Cloud SQL インスタンスにプログラムでアクセスできますか?
概要
- Google Cloud SQL とはどのようなものですか?
- Google Cloud SQL は、クラウドでフルマネージド SQL データベースを実現する使いやすいサービスです。 Google Cloud SQL は MySQL または PostgreSQL データベースを提供します。Cloud SQL for PostgreSQL は現在ベータ版です。
- Google Cloud SQL を使用するとどのようなメリットがありますか?
- Cloud SQL を使用すると、些末ではあっても必須であり時間がかかることが多いタスク(パッチやアップデートの適用、バックアップの管理、レプリケーションの設定など)を Google に任せて、ユーザーはアプリケーションの開発に意識を集中できます。さらに、標準のワイヤ プロトコルが使用されているため、場所を問わず、ほとんどすべてのアプリケーションから簡単に接続できます。
- Google Cloud SQL ではどのデータベース バージョンが使用できますか?アップデートはどのように管理されますか?
-
Cloud SQL for MySQL の場合、第 2 世代のインスタンスは MySQL 5.6 と 5.7 をサポートし、第 1 世代のインスタンスは MySQL 5.5 と 5.6 をサポートします。 Cloud SQL for PostgreSQL は PostgreSQL 9.6 をサポートします。 マイナーなバージョン アップデートはリリース後直ちにデプロイされ、ユーザー側で何も行う必要はありません。アップデートの詳細については、インスタンスではどのような種類のメンテナンス シャットダウンを予期する必要がありますか?をご覧ください。
インスタンスの現在のバージョンを確認するには、Google Cloud Platform Console でインスタンスを選択して [プロパティ] をご覧ください。もしくは、
gcloud sql instances describeコマンドを使用することもできます。 - Google Cloud SQL ではすべてのデータベース機能がサポートされますか?
- Google Cloud SQL は MySQL または PostgreSQL の最も一般的な機能をサポートしています。標準データベース機能と Cloud SQL が提供する機能とのすべての違いの一覧については、Google Cloud SQL と MySQL の標準機能の違いまたは Google Cloud SQL と PostgreSQL の標準機能の違いをご覧ください。
- サイズや QPS に制限はありますか?
- Google Cloud SQL インスタンスに対して 1 秒あたりのクエリ数(QPS)の制限はありません。ただし、接続数やサイズの制限および App Engine 固有の制限はあります。
Cloud SQL インスタンスの制限
制限 MySQL 第 1 世代インスタンス MySQL 第 2 世代インスタンス PostgreSQL インスタンス 備考 同時接続数 階層によって異なります 4,000 100 キューに入れられる接続リクエスト数 100 該当なし 該当なし 第 1 世代インスタンスのみ。受信接続リクエストは、接続が確立される前にしばらくキューに入れられます。キューが格納できる受信接続リクエスト数は 100 個だけです。 ストレージ サイズ 250 GB 最大 10,230 GB まで。マシンタイプによって異なります。 最大 10,230 GB まで。インスタンスが専用または共有 vCPU を使用するかどうかによって、項目を選択します。 シルバー以上の Google Cloud サポート パッケージをお申込みのお客様の場合、個別の第 1 世代インスタンス制限を 500 GB まで拡大できます。 Google App Engine の制限
Google App Engine アプリケーションから Google Cloud SQL へのリクエストには、次の時間制限と接続制限が適用されます。
- Google App Engine のスタンダード環境で動作するアプリの場合、データベース リクエストはいずれも HTTP リクエスト タイマーの時間(約 60 秒)以内に完了する必要があります。フレキシブル環境で動作するアプリの場合は、すべてのデータベース リクエストは 24 時間以内に完了する必要があります。
- cron タスクのようなオフライン リクエストの制限時間は 10 分です。
- Google Cloud SQL に対するリクエストには、App Engine モジュールのスケーリング タイプおよびインスタンスがメモリ内に留まっていることのできる時間(常駐性)に基づく制限があります。
- スタンダード環境で動作する各 App Engine インスタンスは、Google Cloud SQL インスタンスに対する同時接続数が最大 12 個に制限されます。
Google App Engine アプリケーションには、割り当てページで説明されている追加の App Engine 割り当てと制限も適用されます。
- Google Cloud SQL に変更があった場合、どのようにして通知を受け取ることができますか?
- Google Cloud SQL についてのお知らせとニュースが投稿される google-cloud-sql-announce フォーラムに登録できます。
- バグの報告、機能のリクエスト、質問がある場合はどうすればいいですか?
- google-cloud-sql-discuss グループに対してバグの報告や機能のリクエストを行えます。質問は Stack Overflow で行うことができます。 その他のサポート オプションについては、Google Cloud SQL サポートのページをご覧ください。
利用の開始
- インスタンスを管理するのに最適な MySQL ツールは何ですか?
- Google Cloud SQL ではさまざまな MySQL ツールを利用できます。簡単なステートメントを実行するには、MySQL コマンドライン ツールを使用できます。より複雑なタスクを実行したり、より多機能なデータベース開発環境を使用したりする場合は、Toad for MySQL や MySQL Workbench をお試しください。詳しくは、管理ツールとレポート作成ツールをご覧ください。
- どのようなストレージ エンジンを使用する必要がありますか?
- MySQL 第 2 世代インスタンスの場合、サポートされているストレージ エンジンは InnoDB だけです。MySQL 第 1 世代インスタンスの場合は、データの強整合性を保証する InnoDB ストレージ エンジンをおすすめします。
すべてのテーブルが MyISAM 形式になっている
mysqldumpファイルがある場合は、sed スクリプトでファイルをパイプ処理することにより、InnoDB 形式に変換できます。mysqldump --databases [DATABASE_NAME] \ -h [INSTANCE_IP] -u [USERNAME] -p [PASSWORD] \ --hex-blob --default-character-set=utf8 | sed 's/ENGINE=MyISAM/ENGINE=InnoDB/g' > [DATABASE_FILE].sql
警告:
mysqldumpファイルにmysqlスキーマが含まれている場合は、この変換を行わないでください。これらのファイルは MyISAM のままにする必要があります。 - データが存在しない新しいインスタンスに使用ディスク領域が表示されるのはなぜですか?
- Cloud SQL とデータベースはどちらも、インスタンスの作成時にシステム ファイルとメタデータ用の領域を使用します。
- MySQL 第 1 世代インスタンスの応答がときどき遅くなるのはなぜですか?
- 従量制料金プランでインスタンスの課金額を最小限に抑えるため、デフォルトでは 15 分アクセスがないとインスタンスはパッシブになります。その後インスタンスがアクセスされると、アクティブになるまでの間に多少の遅れが生じます。この動作は、インスタンスのアクティベーション ポリシーを設定することによって変更できます。詳細
- どのアクティベーション ポリシーを使用すればよいですか?
-
MySQL 第 2 世代インスタンスまたは PostgreSQL インスタンス: 一般に、アクティベーション ポリシーは
ALWAYSに設定します。インスタンスを使用していない場合は、アクティベーション ポリシーをNEVERに設定してインスタンスの課金を避けることができます。MySQL 第 1 世代インスタンス: 第 1 世代インスタンスでパッケージ料金プランを使用している場合は、使用していないときにインスタンスをオフにしてもコスト面でのメリットはないため、アクティベーション ポリシーを
ALWAYSに設定します。 第 1 世代インスタンスで従量制料金プランを使用している場合は、アクティベーション ポリシーをON DEMANDに設定することで、コストを節減できます。このポリシーに設定した場合、非アクティブ状態が 15 分間続くとインスタンスは自動的にオフになるため、インスタンスを使用していないときに課金されなくなります。 インスタンスのアクティベーション ポリシーをON DEMANDにした場合、インスタンスがオフのときにアクセス リクエストを受け取ると、リクエストに応える前にインスタンスが起動しなければならないため、若干の遅延が発生します。
データ ストレージとレプリケーション
- データはどこに保存されますか?
- Google Cloud SQL インスタンスは、ユーザーがインスタンスの作成時に選択した場所に応じて、米国、EU、アジアのいずれかのゾーンに保存されます。米国または EU 地域で保存されたデータは、その地域内に保持されます。アジアで作成されたインスタンスについては、このことは保証できません。
- ゾーンとは何ですか?
ゾーンは、リソースを実行できる、特定の地理的な場所にある独立したエンティティです。たとえば、us-central1-a という名前のゾーンは米国中部のロケーションを示します。
デフォルトでは、ゾーンの停止に対するフォールト トレランスを提供するため、MySQL 第 1 世代インスタンスのデータはレプリケーションされ、サービスは複数のゾーンに分散されます。MySQL 第 2 世代インスタンスの場合、ゾーン間のフォールト トレランスは、インスタンスの高可用性を設定する(フェイルオーバー レプリカを追加する)ことで実現できます。すべての本番環境インスタンスで高可用性設定を使用することを強くおすすめします。
ゾーンの詳細については、Google Compute Engine ドキュメントのゾーンリソースをご覧ください。
- ストレージにはどのような制限がありますか?
-
MySQL 第 2 世代インスタンス: インスタンスのストレージ容量を 10 GB から 10,240 GB(共有コア マシンタイプの場合は 3,062 GB)の範囲で設定できます。インスタンスの容量を減らすことはできず、増やすことだけが可能です。また、インスタンスの空き容量が残り少ないときに自動的にストレージ容量を増やすように設定することもできます。 詳細についてはこちらをご覧ください。
MySQL 第 1 世代インスタンス: デフォルトでは、全インスタンスのサイズは 250 GB に制限されます。 最大ストレージ サイズは、障害時にバックアップからインスタンスを復元するのに要する時間によって決まります。250 GB を超えるインスタンスは 24 時間以内に復元できない可能性があります(インスタンスが小さいほど復元に要する時間は短くなります)。シルバー以上の Google Cloud サポート パッケージをお申し込みのお客様は、各インスタンスのサイズを最大 500 GB まで増やすようリクエストできます。
PostgreSQL インスタンス: インスタンスのストレージ容量を 10 GB から 10,240 GB(共有コア マシンタイプの場合は 3,062 GB)の範囲で設定できます。インスタンスの容量を減らすことはできず、増やすことだけが可能です。また、インスタンスの空き容量が残り少ないときに自動的にストレージ容量を増やすように設定することもできます。 詳細についてはこちらをご覧ください。
- どのようにデータをレプリケーションしますか?
-
MySQL 第 2 世代インスタンス: 第 2 世代のリードレプリカは非同期レプリケーションを使用します。 第 2 世代のフェイルオーバー レプリカは準同期レプリケーションを使用します。
MySQL 第 1 世代インスタンス: 第 1 世代インスタンスを作成すると、データはリージョン内のすべてのゾーンに自動的にレプリケーションされます。
PostgreSQL インスタンスはまだレプリケーションをサポートしていません。
- Google Cloud SQL のフェイルオーバーはどのように動作しますか?
-
MySQL 第 2 世代インスタンス: ゾーン間でデータをレプリケーションするかどうかを選択できます。データをレプリケーションしないようにするとコストを節約できますが、データの可用性が必要な場合はインスタンスの高可用性を設定する必要があります。 高可用性が設定された第 2 世代インスタンスは、第 1 世代インスタンスと同じフェイルオーバー機能を持ちます。詳細については、高可用性構成の概要をご覧ください。
MySQL 第 1 世代インスタンス: 第 1 世代インスタンスに存在するすべての Cloud SQL データは複数のゾーンにレプリケーションされます。ゾーンが停止した場合、インスタンスは利用可能な別のゾーンに自動的にフェイルオーバーします。フェイルオーバーはアプリケーションに対して透過的に設計されているので、フェイルオーバー後でも、インスタンスのインスタンス名、IP アドレス、ファイアウォール ルールは同じです。フェイルオーバーの過程で、インスタンスが新しいゾーンで起動する間、数分間のダウンタイムが発生します。
フェイルオーバーが発生すると、インスタンスへの既存の接続は切断されます。インスタンスを再起動することにより、フェイルオーバーに対するアプリケーションの反応をテストできます。フェイルオーバーの発生時に役立つ接続管理の推奨事項については、このよくある質問のどのように接続を管理する必要がありますか?の項目をご覧ください。
高可用性設定はまだ PostgreSQL インスタンスでは使用できません。
- データは暗号化されますか?
- はい。Cloud SQL ユーザーのデータは、Google の内部ネットワーク上にあるときも、データベース テーブル、一時ファイル、バックアップに保存されるときも暗号化されます。 外部接続は、SSL を使用するか、Cloud SQL Proxy を使用して暗号化できます。
- 暗号化はどのように管理されますか?
- データは、128 ビットの Advanced Encryption Standard(AES-128)以上と対称キーを使用して暗号化されます。つまり、データ保存時の暗号化とデータ使用時の復号化に、同じキーが使用されます。これらのデータキーは、それ自体がマスターキーを使用して暗号化され、安全なキーストアに保存されて、定期的に変更されます。
- Google の内部ネットワークではデータは暗号化されますか?
- はい。
- どのような種類のリードレプリカを作成できますか?
-
リードレプリカの詳細については(各タイプの用途など)、レプリケーションのオプションをご覧ください。
レプリケーションはまだ PostgreSQL インスタンスではサポートされていません。
バックアップとリカバリ
- どのようにすればインスタンスを復元できますか?
-
バックアップを復元するには、Google Cloud Platform Console または Cloud SQL コマンドライン ツールを使用します。詳しくは、インスタンスを復元するをご覧ください。
MySQL インスタンスを特定の時点に復元するには、gcloud コマンドライン ツールを使用します。 詳しくは、ポイントインタイム リカバリを行うをご覧ください。
- バックアップにはどのくらいの費用がかかりますか?
-
MySQL 第 2 世代インスタンス: 最新の 7 個の自動バックアップとすべてのオンデマンド バックアップが保持されます。 これらにはバックアップ ストレージの料金がかかります。 バイナリログは(バックアップ領域ではなく)ストレージ領域を使用するため、ストレージとして課金されます。
MySQL 第 1 世代インスタンス: 最新の 7 個のバックアップのストレージがインスタンスのコストに含まれます。バイナリログのスペースは、インスタンスで使用されるストレージにカウントされます。
PostgreSQL インスタンス: 最新の 7 個の自動バックアップとすべてのオンデマンド バックアップが保持されます。これらにはバックアップ ストレージの料金がかかります。
インスタンス ストレージとインスタンスの料金については、料金をご覧ください。
- ポイントインタイム リカバリによってパフォーマンスにはどのような影響がありますか?
- ポイントインタイム リカバリを使用するには、バイナリログを有効にする必要があります。これはデータベースへのすべての更新が独立したログに書き込まれることを意味し、これによって書き込みパフォーマンスがわずかに低下します。読み取りは影響を受けません。
インスタンスの管理
- データベースを拡大または縮小することはできますか?
-
MySQL 第 2 世代インスタンス、PostgreSQL インスタンス: インスタンスに使用できるストレージの量はいつでもダウンタイムなしに増やすことができます。インスタンスのストレージのサイズを減らすことはできません。また、インスタンスの空き容量が残り少ないときに自動的にストレージ容量を増やすように設定することもできます。 詳細についてはこちらをご覧ください。
MySQL 第 1 世代インスタンス: データベースの階層をいつでも変更できます。これにはインスタンスを再起動する必要があり、数秒かかることに注意してください。
- Google Cloud SQL を管理するには Google Cloud Platform Console を使用する必要がありますか?
- いいえ。コンソールから実施できるすべての管理タスクは、Cloud SQL API を使用したプログラムまたは
gcloudコマンドライン ツールを使用したスクリプトによって行うことができます。 - Google Cloud SQL ではどれくらいの大きさのデータベースまで使用できますか?
-
PostgreSQL インスタンス、MySQL 第 2 世代インスタンス: データベース インスタンスの最大サイズは 10,240 GB(共有コア マシンタイプの場合は 3,062 GB)です。
MySQL 第 1 世代インスタンス: データベースの最大サイズは 500 GB です。
- どうすれば削除したテーブルのスペースを再利用できますか?
- データベースからテーブルを削除した後、Google Cloud Platform Console で確認すると、テープルを削除したことで解放されたはずのスペースが、インスタンスの [ストレージの使用量] に反映されていないことがあります。
MySQL 5.5 を実行しているインスタンスでは、
innodb_file_per_tableフラグがデフォルトでOFFに設定されています。そのため、InnoDB によってデフォルトのテーブルスペースが縮小されることはありません。 この設定のスペースを再利用するには、よりサイズの小さいデータベースから新しいインスタンスを作成するか、innodb_file_per_tableフラグの値をONに変更します。 Cloud SQL フラグの変更方法については、Cloud SQL フラグを設定するをご覧ください。 - どうすればデータの変更を追跡できますか?
- データの変更を追跡するには、インスタンスのバイナリログを有効にします。データへの変更を追跡すると、偶発的なデータ損失から回復することができます。
DROP DATABASEコマンドによるものなど、偶発的なデータの損失が発生した場合は、データ損失が発生した直前のバイナリログの時点まで復元できます。詳しくは、ポイントインタイム リカバリをご覧ください。 ポイントインタイム リカバリとバイナリログは、まだ PostgreSQL インスタンスでは使用できません。 - インスタンスではどのような種類のメンテナンス シャットダウンを予期する必要がありますか?
-
MySQL 第 2 世代インスタンス、PostgreSQL インスタンス: インスタンスのメンテナンス時間帯を選択できるので、メンテナンスによる再起動をいつ行うかをユーザーが制御できます。また、あるインスタンスがプロジェクトの他のインスタンスよりアップデートを早く受け取るか遅く受け取るかを指定することもできます。 詳細についてはこちらをご覧ください。
MySQL 第 1 世代インスタンス: アップグレード、ゾーン間の移行、その他のインフラストラクチャ作業を行うため、Cloud SQL インスタンスは定期的に再起動されます。データは複数のロケーションにレプリケートされているので、通常、インスタンスの中断は数秒から数分です。App Engine アプリケーションに従うように設定されている第 1 世代インスタンスも、アプリケーションの移動によるレイテンシを最少にするため、新しい場所で再起動される場合があります。これには、短期間のレイテンシの増加と、通常は数秒間の利用不能時間が伴う場合があります。
メンテナンス シャットダウンなどでインスタンスに短時間アクセスできなくなる状況に対処できるようにアプリケーションを設計することをおすすめします。メンテナンス シャットダウンに対するアプリケーションの動作は、同じ効果のあるインスタンスの再起動によってテストできます。 一般に、短時間だけ有効な接続と、拒否された接続を再試行するための指数的バックオフを使用することをおすすめします。詳しいガイダンスについては、どのように接続を管理する必要がありますか?をご覧ください。
MySQL インスタンスの場合、mysqld のシャットダウンにかかる時間は 1 分に制限されています。 シャットダウンがこの時間内に完了しない場合、mysqld プロセスは強制的に終了されます。この場合、サーバーがクエリを処理できるようになる前に InnoDB ストレージ エンジンによってクラッシュリカバリが行われるため、起動時間が長くなります。クラッシュリカバリが完了するまでの時間はデータベースのサイズによって異なり、データベースが大きいほど復元に要する時間は長くなります。
新しいバージョンのロールアウトが開始されると、Cloud SQL のリリースノートに注記が追加されます。ただし、必ずしもすべてのインスタンスが同時に新しいリリースにアップグレードされるとは限らないことに注意してください。
- 特定のデータベースをインポートまたはエクスポートできますか?
- はい。MySQL インスタンスの場合、単一または複数のデータベースをインポートまたはエクスポートできます。 PostgreSQL インスタンスの場合は特定のデータベースのみをインポートまたはエクスポートできます。
- CSV ファイルをインポートまたはエクスポートできますか?
- MySQL インスタンスの場合、CSV をインポートまたはエクスポートできます。PostgreSQL インスタンスでは、まだ CSV ファイルのインポートまたはエクスポートはサポートされていません。詳細については、CSV ファイルの作成をご覧ください。
- インスタンスのデータのインポートまたはエクスポートには Google Cloud Storage アカウントが必要ですか?
- Cloud SQL は、Google Cloud Storage バケットを使用したデータベース(圧縮または非圧縮の SQL ダンプファイル)および CSV ファイルのインポートとエクスポートをサポートしています。Google Cloud Storage バケットを使用してインポートまたはエクスポートを行うには、Cloud Platform アカウントにサインアップしてバケットを作成するか、別のアカウントの Google Cloud Storage バケットへのアクセス権を持っている必要があります。詳しくは、データのインポートとエクスポートの概要をご覧ください。
- インポート オペレーションでの
ERROR_RDBMSは何を意味しますか? -
このエラーは、データ インポートのオペレーション中に MySQL がエラーを返した場合に発生します。一般的な原因は、無効な構文、定義されていないデータベースやテーブルの使用、
SUPER権限を必要とする MySQL ステートメントの実行などです。 - 削除したインスタンスのインスタンス名を再利用できますか?
- はい、ただし削除直後にはできません。インスタンス名は、最長で 1 週間は再利用できません。
cloudsqladminデータベース ユーザーとは何ですか?- すべての Google Cloud SQL インスタンスには、
cloudsqladminという名前のデータベース ユーザーが含まれます。SHOW GRANTS FOR cloudsqladmin@localhostを行った場合、このユーザーに気付くことがあります。一部のインスタンスでは、システム ユーザー テーブルにもこのユーザーが表示されます。このユーザー アカウントは、自動プロセスがインスタンスのデータにアクセスするときに使用されます(たとえば、インスタンスのバックアップや、インポートまたはエクスポートなど)。 GRANT ALLを使用するにはどうすればよいですか?- Google Cloud SQL は
SUPER権限をサポートしないため、GRANT ALL PRIVILEGESステートメントは動作しません。代わりの方法として、GRANT ALL ON `%`.*を使用できます。 - どうすればインスタンスのトランザクション ログにアクセスできますか?
- MySQL インスタンスでは、インスタンスのバイナリログを有効にして(バイナリログを有効にするを参照)、インスタンスの IP アドレスを設定した場合(IP 接続のためのアクセスを設定するを参照)、MySQL の標準の mysqlbinlog ユーティリティを使用してインスタンスのトランザクション ログを調べることができます。
料金と課金
- どうすれば Google Cloud SQL を試すことができますか?
- 最小のインスタンスは
db-f1-microです。このインスタンスを使用してサービスを試すことができます。 共有コア インスタンスは SLA の対象外であることに注意してください。 - 料金プランは、従量制とパッケージのどちらがいいですか?
- 従量制とパッケージの料金オプションは、第 1 世代のインスタンスにのみ適用されます。 経験則として、インスタンスを 1 か月あたり 450 時間以上使用する場合は、パッケージ プランの方が経済的です。 料金プランの詳細については、料金をご覧ください。
- 料金プランは変更できますか?
- 従量制とパッケージの料金オプションは、第 1 世代のインスタンスにのみ適用されます。インスタンスの料金プランは 1 か月に 3 回まで変更できます。インスタンスの料金は、1 日の終わり(米国太平洋時間)に有効なプランを基に計算されます。1 日のうちに何度でもプランを変更できますが、これは 1 か月に可能な変更回数 3 回のうちの 1 回と数えられます。
第 1 世代インスタンスの料金プランは、設定を編集することによって変更できます。 料金プランを変更するには、Google Cloud Platform Console に移動し、インスタンスを含むプロジェクトを選択した後、Google Cloud SQL を選択します。インスタンスの一覧から料金プランを変更するインスタンスを選択し、料金の設定を編集します。
- プロジェクトではインスタンスをいくつ作成できますか?
-
1 つのプロジェクトに作成できるインスタンスの最大数は 40 個です。削除されたインスタンスは、このインスタンスの制限にはカウントされません。プロジェクトのインスタンス制限を増やす必要がある場合は、cloud-sql@google.com チームにご連絡ください。
ユーザーはすべてのプロジェクトにわたって最大 60 個のインスタンスを作成できます。
- どれくらいのサイズのデータベース インスタンスが必要ですか?RAM はどれくらい必要ですか?
- 一般に、RAM と CPU が多い大きなインスタンスを選択すると、データベースのパフォーマンスが向上します。これにより、結合、ORDER BY、GROUP などを含む計算量の多い多数のクエリのパフォーマンスが向上します。ただし、単一の行が影響を受ける更新のパフォーマンスはそれほど変わりません。 インスタンスのサイズと料金の詳細については、料金をご覧ください。
- インスタンスの使用時間はどのようにして算出されますか?
-
MySQL 第 2 世代インスタンス、PostgreSQL インスタンス: インスタンスがアクティブになっている間、1 分単位で課金されます。
MySQL 第 1 世代インスタンス: 従量制料金プランを使用している場合、インスタンスがアクティブになっている間 1 分単位で課金されます。アクティベーション ポリシーとして
ON_DEMAND(デフォルト値)を使用している場合は、SQL プロンプト、外部アプリケーション、または App Engine アプリケーションからインスタンスへのアクセスが発生したときにインスタンスが起動し、最後のアクセスが完了してから 15 分間はアクティブ状態が維持されます。この時間が過ぎると、インスタンスはシャットダウンされます。インスタンスが非アクティブの間は課金されません。クライアントが接続している限り、インスタンスはアクティブ状態が続くことに注意してください。これにはアイドル接続状態を含みます。MySQL クライアントで SHOW PROCESSLIST コマンドを実行することによって、インスタンスへの接続の一覧を表示できます。その後、KILL コマンドを使用して接続を切断できます。また、インスタンスを再起動してすべての接続を切断することもできます。
アクティベーション ポリシーが
ON_DEMANDでパッケージ料金プランを使用するインスタンスは、最後のアクセスから 12 時間、アクティブ状態を保ちます。アクティベーション ポリシーを修正することで、インスタンスのアクティベーション動作を変更できます。詳細についてはこちらをご覧ください。
- ストレージはどのようにして算出されますか?
-
MySQL 第 2 世代インスタンス、PostgreSQL インスタンス: ストレージは、インスタンスに対してプロビジョニングされたストレージの量を基に算出されます。 バックアップ用のストレージは、バックアップが使用しているスペースの量によって課金されます。ストレージへの課金はインスタンスがアクティブであるかどうかにかかわらず発生します。
MySQL 第 1 世代インスタンス: ストレージは、インスタンスが使用しているファイル スペースの量を基に算出されます。ストレージは GB 単位で課金され、料金と使用量ができる限り一致するように 1 分ごとに測定されます。 ストレージへの課金はインスタンスがアクティブであるかどうかにかかわらず発生します。スケジュール バックアップ サービスを使用して作成されるバックアップのストレージは課金されません。
- 請求額はどこで確認できますか?
- Google Cloud Platform Console の [お支払い] タブに、前回の請求書の発行後に発生したインスタンスの課金額が表示されます。
- "従量制" プランを使用しているアイドル状態の第 1 世代インスタンスで料金が発生するのはなぜですか?
- インスタンスのスケジュール バックアップを有効にしてあるかどうかを確認してください。Google Cloud SQL は、最後のスケジュール バックアップより後にインスタンスのデータが変更された場合にのみ、バックアップを作成します。スケジュール バックアップが行われると、インスタンスはその間だけアクティブになるため、"従量制" の課金が発生します。
- インスタンスが上限サイズに達したらどうなりますか?
-
MySQL 第 2 世代インスタンス、PostgreSQL インスタンス: ストレージの自動増量を有効にしていない場合にインスタンスがプロビジョニングされたストレージ サイズに達したとき、またはインスタンスの設定上限に達した場合、それ以降のデータベースへの書き込みは、ユーザーがストレージ サイズを増やさない限り許可されません。ストレージ サイズを増やすためにインスタンスを再起動する必要はなく、ダウンタイムも発生しません。
MySQL 第 1 世代インスタンス: 選択したプランで許可される最大ストレージ容量にインスタンスが達した場合、それ以降のデータベースへの書き込みは、ユーザーがデータを削除してサイズを減らさない限り許可されません。
- インスタンスが停止しているのはなぜですか?
- おそらく、Google Cloud Platform アカウントでの問題です。課金サポート リクエストを提出することで、課金の状態を確認できます。停止された第 2 世代インスタンスは 90 日後に削除されることに注意してください。
- インスタンスが削除されたのはなぜですか?
-
90 日間停止されている PostgreSQL インスタンスおよび MySQL 第 2 世代インスタンスは削除されます。これは
SUSPENDED状態のインスタンスに適用されます。RUNNABLE状態で停止しているインスタンスは削除されません。 - どうすれば Google Cloud SQL アカウントをキャンセルできますか?
- プロジェクトで Google Cloud SQL を非アクティブ化するには、Google Cloud Platform Console でプロジェクトを選択して [API] サービスを選択し、API ダッシュボードを開きます。Google Cloud SQL API を探し、その API の [無効にする] をクリックします。
- 課金を無効にするにはどうすればよいですか?
- Google Cloud Platform Console で、プロジェクトの [課金と設定] パネルの [課金を無効にする] をクリックすることによって、課金を無効にできます。課金を無効にすると、Google Cloud SQL サービスも無効になります。課金を無効にする前に、Google Cloud SQL サービスを無効にしてもよいことを確認してください。
課金を無効にすると、課金サイクルの初日からキャンセルした時点までに発生した料金に関する最後の請求が届きます。
App Engine での Google Cloud SQL の使用
- App Engine から MySQL 第 2 世代インスタンスに接続できますか?
- はい。App Engine アプリケーションがスタンダード環境とフレキシブル環境のどちらで走行しているかにかかわらず、App Engine アプリケーションから第 2 世代インスタンスに接続できます。詳しくは、Google App Engine から接続するをご覧ください。
- App Engine から PostgreSQL インスタンスに接続できますか?
- はい。App Engine アプリケーションがフレキシブル環境で走行している場合、App Engine アプリケーションから PostgreSQL インスタンスに接続できます。詳しくは、Google App Engine から接続するをご覧ください。
- 米国の App Engine から EU の Google Cloud SQL インスタンスにアクセス(またはその逆)できますか?
-
MySQL 第 1 世代インスタンスに接続する場合、App Engine アプリケーションは Cloud SQL インスタンスと同じリージョンにあり、なおかつスタンダード環境で走行している必要があります。
MySQL 第 2 世代インスタンスに接続する場合、App Engine アプリケーションは同じリージョンになくてかまわず、スタンダード環境とフレキシブル環境のどちらでも実行できます。ただし、Cloud SQL インスタンスと App Engine アプリケーションの距離が大きく離れていると、データベース接続のレイテンシが高くなります。
PostgreSQL インスタンスに接続する場合、App Engine アプリケーションは同じリージョンになくてもかまいませんが、フレキシブル環境で走行している必要があります。ただし、Cloud SQL インスタンスと App Engine アプリケーションの距離が大きく離れていると、データベース接続のレイテンシが高くなります。
- Google Cloud SQL と Google Cloud Datastore のどちらを使用すればよいですか?
- これはアプリケーションの要件によって異なります。データストアは拡張性の高い NoSQL キー / 値ストレージを提供しますが、SQL データベースで実行できるような複雑なクエリはサポートしていません。Cloud SQL は複雑なクエリや ACID トランザクションをサポートしていますが、これはデータベースが「固定されたパイプ」となることを意味し、パフォーマンスの拡張性は劣ります。多くのアプリケーションが両方のタイプのストレージを使用しています。
- App Engine 開発サーバーを使用するためにローカルのデータベース サーバーをインストールする必要はありますか?
- いいえ。開発サーバーで実行するときは、App Engine から Cloud SQL とローカルにインストールされたデータベース サーバーのどちらを使用することもできます。
- インスタンスにアクセスするにはどの言語を使用する必要がありますか?
-
Google App Engine は、インスタンスへの接続に使用できる複数の言語をサポートします。詳細については、Google App Engine から接続するをご覧ください。
Google App Engine を使用していない場合は、対応するコネクタまたは API を持つ任意の言語を使用できます。 サポートされている言語の一覧については、MySQL リファレンス マニュアルのコネクタと API をご覧ください。
- Django を Google Cloud SQL で使用できますか?
- はい、Google Cloud SQL は Django に対応しています。Django スタートガイドをご覧ください。
- Python クエリ文字列ではどのプレースホルダを使用できますか?
- Python の場合、パラメータの置換に使用できるのは
%s形式のコードに限られます。 そのため、次の文は無効です。cursor.execute('INSERT INTO entries (guestAge) VALUES (%d)', (age))。 - どのように接続を管理する必要がありますか?
-
データベース接続の最善の管理方法は使用方法によって異なりますが、一般には、接続プールを使用することをおすすめします。接続プールは、データベース サーバーへの新しい接続が急激に増えるのを防ぎます。新しい接続が急激に増えると、パフォーマンスが低下する可能性があります。
クラウドでホストされた環境では、従来の外部サーバー環境とは異なる方法でデータベース接続を管理する必要があります。指数バックオフのようなエラー処理方法を実装することにより、ときどき発生する接続障害に対処できるようにアプリケーションを設計することをおすすめします。例については、Google Cloud Storage のドキュメントの指数バックオフをご覧ください。
インスタンス接続制限の詳細については、よくある質問のサイズや QPS に制限はありますか?をご覧ください。
- "無効な接続 ID" というメッセージの SQLException の意味は何ですか?
- 接続がサーバーでオープンではなくなり、クライアントで破棄するべきであることを意味しています。このような接続は既にクローズされているため、"close" を呼び出す必要はありません。
- App Engine の外部にある Google Cloud SQL インスタンスにプログラムでアクセスできますか?
- はい。サポートされている任意の言語を使用した外部アプリケーションからプログラムによって Google Cloud SQL インスタンスにアクセスできます。また、JDBC を使用して接続することもできます(Apps Script スクリプトを使用して Google Cloud SQL データベースにアクセスする方法を含む)。 外部アプリケーションから接続するをご覧ください。