- 概要
- スタートガイド
- データストレージ、レプリケーション、認証
- データはどこに保存されますか?
- ストレージにソリッド ステート ドライブ(SSD)またはハードディスク ドライブ(HDD)を使用する必要がありますか?
- ゾーンとは?
- ストレージにはどのような制限がありますか?
- どのようにデータをレプリケーションしますか?
- Cloud SQL のフェイルオーバーはどのように動作しますか?
- データは暗号化されますか?
- 保存されているデータの暗号化はどのように管理されますか?
- 転送中のデータの暗号化はどのように管理されますか?
- どのような種類のリードレプリカを作成できますか?
- インスタンスがリードレプリカであるかどうかはどうすればわかりますか?
- Cloud SQL では、リードレプリカに対するリクエストのロード バランシングを行いますか?
- Cloud SQL for SQL Server は Managed Service for Microsoft Active Directory と統合されますか?
- バックアップと復元
- インスタンスの管理
- Cloud SQL インスタンスを再起動する原因となるアクションはどれですか?
- 再起動時のインスタンスのシャットダウン時間はどの程度ですか?
- データベースを拡大または縮小することはできますか?
- vCPU をアップグレードしてダウングレードできますか?
- Cloud SQL の管理には Google Cloud Console を使用する必要がありますか?
- どうすれば削除したテーブルのスペースを再利用できますか?
- 一時ファイルによって使用されるスペースを再利用するにはどうすればよいですか?
- 特定のデータベースをインポートまたはエクスポートできますか?
- CSV ファイルをインポートまたはエクスポートできますか?
- インスタンスのデータのインポートまたはエクスポートには Cloud Storage アカウントが必要ですか?
- インポート オペレーションでの
ERROR_RDBMS
は何を意味しますか? - 削除したインスタンスのインスタンス名を再使用できますか?
- cloudsqladmin データベース ユーザーとは何ですか?
GRANT ALL
を使用するにはどうすればよいですか?- どうすればインスタンスのトランザクション ログにアクセスできますか?
- Cloud SQL ではどの程度のトランザクション分離が可能ですか?
- インスタンスを誤って削除しないようにするにはどうすればよいですか?
- Insights
- 料金と課金
- App Engine での Cloud SQL の使用
- App Engine から MySQL インスタンスに接続できますか?
- App Engine から PostgreSQL インスタンスに接続できますか?
- App Engine から SQL Server インスタンスに接続できますか?
- 米国の App Engine アプリケーションから EU の Cloud SQL インスタンスにアクセスできますか(またはその逆は可能ですか)?
- どの Google Cloud データベース サービスが適していますか?
- App Engine 開発用サーバーを使用するためにローカルのデータベース サーバーをインストールする必要はありますか?
- インスタンスにアクセスするにはどの言語を使用する必要がありますか?
- Django を Cloud SQL で使用できますか?
- Python クエリ文字列ではどのプレースホルダを使用できますか?
- 接続を管理するにはどうすればよいですか?
- 「無効な接続 ID」というメッセージの SQLException の意味は何ですか?
- App Engine の外部からプログラムで Cloud SQL インスタンスにアクセスすることはできますか?
概要
- Cloud SQL とは?
- Cloud SQL は、クラウドでフルマネージドの SQL データベースを提供するサービスです。Cloud SQL では PostgreSQL、SQL Server、MySQL データベースを使用できます。
- Cloud SQL を使用するとどのようなメリットがありますか?
- Cloud SQL を使用すると、些末ではあっても必要であり時間がかかることが多いタスク(パッチの適用、アップデート、バックアップの管理、レプリケーションの構成など)を Google に任せることができ、ユーザーは優れたアプリケーションの開発に集中できます。さらに、標準のワイヤ プロトコルを使用しているため、アプリケーションやロケーションを問わずに接続できます。
- Cloud SQL ではどのデータベース バージョンを使用できますか?アップデートはどのように管理されますか?
-
Cloud SQL for MySQL は MySQL 8.0(デフォルト)、5.7、5.6 をサポートしています。
Cloud SQL for PostgreSQL は、PostgreSQL 9.6、10、11、12、13、14、15(デフォルト)、16 をサポートします。
Cloud SQL for SQL Server は、SQL Server: SQL Server 2017 Standard、SQL Server 2017 Enterprise、SQL Server 2017 Express、SQL Server 2017 Web、SQL Server 2019 Standard(デフォルト)、SQL Server 2019 Enterprise、SQL Server 2019 Express、SQL Server 2019 Web をサポートします。
マイナーなバージョン更新は定期メンテナンスの一環としてデプロイされるため、ユーザー側で行う必要がある操作はありません。更新の詳細については、Cloud SQL インスタンスでのメンテナンスの概要をご覧ください。
インスタンスの現在のバージョンを確認するには、Google Cloud Console に移動し、インスタンス名をクリックして [インスタンスの詳細] ページを開きます。または、
gcloud sql instances describe
コマンドを使用することもできます。 - Cloud SQL はすべてのデータベース機能をサポートしていますか?
- Cloud SQL は、MySQL、PostgreSQL、SQL Server の一般的な機能をサポートしています。標準データベース機能と Cloud SQL が提供する機能の違いの一覧については、Cloud SQL と標準 MySQL の機能の違いなどをご覧ください。Cloud SQL と標準の PostgreSQL 機能の違いもご覧ください。Cloud SQL で使用できない SQL Server の機能もご覧ください。
- サイズや QPS に上限はありますか?
- Cloud SQL インスタンスの秒間クエリ数(QPS)に上限はありません。接続数やサイズの上限と App Engine 固有の上限については、割り当てと上限をご覧ください。
- Cloud SQL に変更があった場合、どのようにして通知を受け取ることができますか?
- google-cloud-sql-announce フォーラムに登録し、そこに投稿された Cloud SQL に関するお知らせやニュースを受け取ることができます。
- バグの報告、機能のリクエスト、質問がある場合はどうすればいいですか?
- google-cloud-sql-discuss グループに対してバグの報告や機能のリクエストを行えます。質問は Stack Overflow で行うことができます。その他のサポート オプションについては、Cloud SQL のサポートのページをご覧ください。
スタートガイド
- インスタンスを管理するのに最適な MySQL ツールは何ですか?
- Cloud SQL ではさまざまな MySQL ツールが用意されています。個々のステートメントの実行には MySQL コマンドライン ツールを使用できます。より複雑なタスクを行う場合や、より多機能なデータベース開発環境を使用する場合は、Toad for MySQL や MySQL Workbench をお試しください。詳細については、管理ツールとレポート作成ツールをご覧ください。
- どのようなストレージ エンジンを使用しますか?
- MySQL インスタンスの場合、サポートされているストレージ エンジンは InnoDB のみです。
すべてのテーブルが MyISAM 形式になっている
mysqldump
ファイルがある場合は、sed スクリプトでファイルをパイプ処理することにより、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
警告:
mysqldump
ファイルにmysql
スキーマが含まれている場合は、この変換を行わないでください。これらのファイルは、MyISAM のままにする必要があります。 - データが存在しない新しいインスタンスに使用ディスク領域が表示されるのはなぜですか?
- Cloud SQL とデータベースはどちらも、インスタンスの作成時にシステム ファイル用とメタデータ用の領域を使用します。 トップへ戻る
- データはどこに保存されますか?
-
インスタンス データは、そのインスタンスが存在するリージョンに保存されます。ストレージ ロケーションを指定しない場合、バックアップは Cloud SQL インスタンスのロケーションに最も近いマルチリージョン ロケーションに保存されます。たとえば、Cloud SQL インスタンスが
us-central1
にある場合、デフォルトではus
マルチリージョンにバックアップが保存されます。ただし、australia-southeast1
のようなデフォルトのロケーションはマルチリージョンのいずれにも該当しません。最も近いマルチリージョンはasia
です。 - ゾーンとは?
ゾーンは、リソースを実行できる、特定の地理的な場所にある独立したエンティティです。たとえば、us-central1-a という名前のゾーンは米国中部のロケーションを示します。
MySQL インスタンスの場合、ゾーン間のフォールト トレラントは、インスタンスの高可用性を構成することで実現できます。すべての本番環境インスタンスで高可用性構成を使用することを強くおすすめします。
ゾーンの詳細については、Compute Engine のドキュメントのゾーンリソースをご覧ください。
- ストレージにはどのような制限がありますか?
- ストレージの上限については、割り当てと上限をご覧ください。
- どのようにデータをレプリケーションしますか?
-
MySQL インスタンス: MySQL インスタンスでは、高可用性構成と MySQL リードレプリカが提供されます。MySQL リードレプリカは、非同期レプリケーションを使用します。
- どのような種類のリードレプリカを作成できますか?
-
リードレプリカの詳細については(各タイプの用途など)、レプリケーションのオプションをご覧ください。
- Cloud SQL のフェイルオーバーはどのように動作しますか?
-
フェイルオーバーの詳細については、高可用性構成の概要をご覧ください。
- データは暗号化されますか?
- Cloud SQL 顧客データは、データベース テーブル、一時ファイル、バックアップに保存されるときに暗号化されます。外部接続は、SSL を使用するか、Cloud SQL Auth Proxy を使用して暗号化できます。
- 保存されているデータの暗号化はどのように管理されますか?
データの暗号化には、256 ビットの Advanced Encryption Standard(AES-256)以上の暗号化方式と対称鍵が使用されます。つまり、データ保存時の暗号化とデータ使用時の復号に同じ鍵が使用されます。これらのデータ鍵はそれ自体が、安全なキーストアに保存されている鍵を使用して暗号化され、定期的に変更されます。
詳しくは、Google Cloud での保存時の暗号化をご覧ください。
- 転送中のデータの暗号化はどのように管理されますか?
-
すべての転送中のデータは、Google が管理している物理的境界または Google のために管理されている物理的境界の外へ出るときに、1 つ以上のネットワーク レイヤで暗号化され認証されます。これらの物理的境界の内部で転送されるデータについては、認証は通常行われますが、暗号化はデフォルトでは行われない場合があります。パブリック IP アドレスを使用してインスタンスに接続する場合は、SSL / TLS 証明書を使用して、転送中のデータを保護します。そのため、ユーザーの判断で、脅威モデルに基づいて追加のセキュリティ対策を適用できます。たとえば、Cloud SQL へのゾーン内接続に対して SSL を構成できます。
詳しくは、Google Cloud での転送データの暗号化をご覧ください。
- インスタンスがリードレプリカであるかどうかはどうすればわかりますか?
- Google Cloud コンソールを使用してすべての Cloud SQL インスタンスを表示し、インスタンスがプライマリ インスタンスであるか、リードレプリカ インスタンスであるかを確認できます。gcloud CLI を使用して、インスタンスがプライマリ レプリカとリードレプリカかを確認することもできます。詳細については、レプリケーション ステータスの確認をご覧ください。
- Cloud SQL では、リードレプリカに対するリクエストのロード バランシングを行いますか?
- Cloud SQL では、負荷分散の提供や構成を自動的には行いません。接続プールを使用すると、複数の接続エンドポイント間で切り替えを行うことによって、リードレプリカ間で読み取りリクエストを分散できます。
- Cloud SQL for SQL Server は Managed Service for Microsoft Active Directory と統合されますか?
- はい。認証や認可なども利用できます。概要をご覧ください。
- どのようにすればインスタンスを復元できますか?
-
バックアップに復元するには、Google Cloud Console か
gcloud
コマンドライン ツールを使用します。詳しくは、インスタンスを復元するをご覧ください。インスタンスを特定の時点に復元するには、ポイントインタイム リカバリを使用します。 詳細については、ポイントインタイム リカバリを使用するをご覧ください。
- バックアップにはどのくらいの費用がかかりますか?
-
バックアップはインスタンス ストレージの料金に基づいて課金されます。
インスタンス ストレージとインスタンスの料金については、料金をご覧ください。
- 7 日以上前の自動バックアップにアクセスできますか?
-
自動バックアップは毎日行われ、デフォルトでは 7 日間保持されます。バックアップ保持期間の値は、1~365 に構成できます。保持期間が終了すると、最も古いバックアップは削除されます。自動バックアップは増分バックアップです。このバックアップには、前回のバックアップの作成後に変更されたデータのみが含まれます。最も古いバックアップはデータベースと同程度のサイズです。最も古いバックアップが削除されると、完全なバックアップを維持するため、その次に古いバックアップのサイズが増加します。
オンデマンド バックアップは手動で削除するまで削除されないことに注意してください。
- ポイントインタイム リカバリによってパフォーマンスにはどのような影響がありますか?
- Cloud SQL for MySQL でポイントインタイム リカバリを使用するには、バイナリ ロギングを有効にする必要があります。これはデータベースへのすべての更新が独立したログに書き込まれることを意味し、これによって書き込みパフォーマンスがわずかに低下します。バイナリログ ファイルのサイズに関係なく、読み取りオペレーションのパフォーマンスはバイナリ ロギングの影響を受けません。
- リージョンの障害保護に対して、外部レプリケーションとクロスリージョン レプリケーションは、それぞれどのような場合に適していますか?
-
外部レプリケーション クロスリージョン レプリケーション お客様による自己管理 Cloud SQL マネージド クロスリージョン レプリカ Google Cloud 以外のインスタンスと Google Cloud インスタンスの間で複製可能 Cloud SQL インスタンス間でのみ複製可能 Google Cloud に対する移行を行うことで、ダウンタイムの最小化や、ハイブリッド / マルチクラウド データ保護を行う Google Cloud のリージョン間でデータを移行してダウンタイムを最小限に抑える メジャー バージョン間レプリケーションがサポートされている メジャー バージョン間レプリケーションはサポートされていない - Cloud SQL インスタンスを再起動する原因となるアクションはどれですか?
-
Cloud SQL で次の操作を行うと、Cloud SQL インスタンスが再起動される場合があります。
- 更新
- 作成
- レプリカのプロモート
- メンテナンス
- レプリカの再作成
- フェイルオーバー
- 再起動
- バックアップからのインスタンスの復元
- 既存のインスタンスでの高可用性の有効化(インスタンスへの更新)
- 再起動が必要なデータベース フラグの追加
インスタンスを再起動しても、インスタンスのパブリック IP アドレスやプライベート IP アドレスは変更されません。
再起動時のインスタンスのシャットダウン時間はどの程度ですか?をご覧ください。
- 再起動時のインスタンスのシャットダウン時間はどの程度ですか?
-
インスタンスが再起動されると、インスタンスの大部分は 1~2 分間シャットダウンされます。インスタンスがシャットダウンされる前に、すべての接続が終了し、現在の作業はディスクからフラッシュされます。
負荷が大きいインスタンスの場合、このプロセスには時間がかかり、インスタンスが停止しているように見えることがあります。このような場合、インスタンスがシャットダウンして再起動するまで 1 時間ほどかかることがあります。書き込みトランザクションが多数存在する場合や、トランザクションが長時間実行されている場合は、インスタンスのシャットダウンと再起動に時間がかかります。
- データベースを拡大または縮小することはできますか?
-
インスタンスに使用できるストレージの量はいつでもダウンタイムなしに増やすことができます。インスタンスのストレージのサイズを減らすことはできません。また、インスタンスの空き容量が残り少ないときに自動的にストレージ容量を増やすように構成することもできます。詳細
- vCPU をアップグレードしてダウングレードできますか?
-
はい。インスタンスで使用する vCPU の数を変更できます。使用するコアの数は必要に応じて増減できます。通常、vCPU 数の変更には 5 分もかかりません。Cloud SQL Enterprise Plus エディションのプライマリ インスタンスの vCPU の数を増やす場合は、ダウンタイムはほぼゼロでこの変更が有効になります。
- Cloud SQL の管理には Google Cloud コンソールを使用する必要がありますか?
- いいえ。Console を使用して実行できるすべての管理タスクは、Cloud SQL Admin API を使用してプログラムで行うことや、
gcloud
コマンドライン ツールを使用したスクリプト化が可能です。 - どうすれば削除したテーブルのスペースを再利用できますか?
- データベースからテーブルを削除した後に Google Cloud Console で確認したとき、テーブルを削除したことで解放されたはずのスペースが、インスタンスの [ストレージの使用量] に反映されていないことがあります。MySQL 5.5 を実行するインスタンスでは、
innodb_file_per_table
フラグがデフォルトでOFF
に設定されています。このため、InnoDB によってデフォルトのテーブル スペースが縮小されることはありません。この構成でスペースを再利用するには、より小さなデータベースから新しいインスタンスを作成するか、またはinnodb_file_per_table
フラグの値をON
に変更します。データベース フラグの変更については、データベース フラグを構成するをご覧ください。 - 一時ファイルによって使用されるスペースを再利用するにはどうすればよいですか?
- SQL クエリで多数の一時テーブルが作成されると、一時ファイルが大きくなる可能性があります。一時テーブルによって使用されるスペースを再利用するには、データベースを再起動する必要があります。データベースを再起動して一時ファイルが増えても、プロビジョニングされるディスク スペースは減少しません。
- どうすればデータの変更を追跡できますか?
- データの変更を追跡するには、インスタンスのバイナリ ロギングを有効にします。データの変更を追跡しておくと、誤ってデータが失われたときに元に戻すことができます。
DROP DATABASE
コマンドによるものなど、偶発的なデータの損失が発生した場合は、データ損失が発生した直前のバイナリログの時点まで復元できます。詳しくは、ポイントインタイム リカバリをご覧ください。バイナリ ロギングは、まだ PostgreSQL インスタンスでは使用できません。 - 特定のデータベースをインポートまたはエクスポートできますか?
- はい。MySQL インスタンスと SQL Server インスタンスでは、1 つまたは複数のデータベースをインポートおよびエクスポートできます。PostgreSQL インスタンスの場合は、特定のデータベースのみをインポートまたはエクスポートできます。
- CSV ファイルをインポートまたはエクスポートできますか?
-
MySQL または PostgreSQL の CSV ファイルをインポートまたはエクスポートできます。詳細については、CSV ファイルの作成をご覧ください。
現在、Cloud SQL for SQL Server で CSV はサポートされていません。
- インスタンスのデータのインポートまたはエクスポートには Cloud Storage アカウントが必要ですか?
- Cloud SQL は、Cloud Storage バケットを使用したデータベース(圧縮または非圧縮の SQL ダンプファイル)および CSV ファイルのインポートとエクスポートをサポートしています。Cloud Storage バケットを使用してインポートまたはエクスポートするには、Google Cloud アカウントを登録してバケットを作成するか、別のアカウントの Cloud Storage バケットにアクセスできる必要があります。詳細については、SQL ダンプファイルを使用したエクスポートとインポート、pg_dump と pg_restore を使用したエクスポートとインポート、BAK ファイルを使用したエクスポートとインポート、または CSV ファイルを使用したエクスポートとインポートをご覧ください。
- インポート オペレーションでの
ERROR_RDBMS
は何を意味しますか? -
このエラーは、データ インポートのオペレーション中に MySQL がエラーを返した場合に発生します。一般的な原因は、無効な構文、定義されていないデータベースやテーブルの使用、
SUPER
権限を必要とする MySQL ステートメントの実行などです。 - 削除したインスタンスのインスタンス名を再使用できますか?
- はい。
cloudsqladmin
データベース ユーザーとは何ですか?- すべての Cloud SQL インスタンスには
cloudsqladmin
というデータベース ユーザーが存在します。SHOW GRANTS FOR cloudsqladmin@localhost
を指定すると、このユーザーに気付くことがあります。一部のインスタンスでは、システム ユーザー テーブルにもこのユーザーが表示されます。このユーザー アカウントは、インスタンスのデータにアクセスする必要のある自動プロセス(インスタンスのバックアップや、インポートまたはエクスポートなど)によって使用されます。 GRANT ALL
を使用するにはどうすればよいですか?- Cloud SQL は
SUPER
権限をサポートしないため、GRANT ALL PRIVILEGES
ステートメントは機能しません。代わりの方法として、GRANT ALL ON `%`.*
を使用できます。 - どうすればインスタンスのトランザクション ログにアクセスできますか?
- MySQL インスタンスでは、インスタンスのバイナリログを有効にしていて(バイナリ ロギングを有効にするを参照)、インスタンスの IP アドレスを構成している場合(IP 接続のためのアクセスを構成するを参照)、MySQL の標準の mysqlbinlog ユーティリティを使用してインスタンスのトランザクション ログを調べることができます。
- Cloud SQL ではどの程度のトランザクション分離が可能ですか?
-
MySQL インスタンス: Cloud SQL では
REPEATABLE READ
トランザクション分離が可能です。現行のセッションに対してトランザクションの分離レベルを変更することはできますが、通常はデフォルト値の使用が推奨されます。詳細については、MySQL ドキュメントでトランザクション分離レベルをご覧ください。PostgreSQL インスタンス: Cloud SQL では
Read committed
トランザクション分離が可能です。特定のセッションに対してトランザクションの分離レベルを変更することはできますが、通常はデフォルト値の使用が推奨されます。詳細については、PostgreSQL ドキュメントでトランザクション分離をご覧ください。SQL Server インスタンス: Cloud SQL ではすべてのレベルのトランザクション分離が可能です。そのため、
UNCOMMITTED
、READ COMMITTED
、REPEATABLE READ
、SNAPSHOT
、SERIALIZABLE
がサポートされています。 - インスタンスを誤って削除しないようにするにはどうすればよいですか?
- 削除保護は、インスタンスの作成時または後で有効にできます。この設定が有効になっている場合は、インスタンスを削除する前に無効にする必要があります。インスタンスの削除を防止するをご覧ください。
- Insights でクエリプランのサンプルが見つからないのはなぜですか?
- クエリに対するパフォーマンスへの影響があるため、クエリプランを取得するためのサンプルクエリのみを用意しています。その結果、クエリプランのサンプルが表示されない場合があります。
- Cloud SQL を試すにはどうすればよいですか?
- 最小インスタンスは
db-f1-micro
です。このインスタンスを使用してサービスを試すことができます。共有コア インスタンスは SLA の対象外であるので注意してください。 - プロジェクトではインスタンスをいくつ作成できますか?
- インスタンスの上限については、割り当てと上限をご覧ください。
- どれくらいのサイズのデータベース インスタンスが必要ですか?RAM はどれくらい必要ですか?
- 一般に、RAM と CPU が多い大きなインスタンスを選択すると、データベースのパフォーマンスが向上します。これにより、結合、ORDER BY、GROUP などを含む計算量の多い多数のクエリのパフォーマンスが向上します。ただし、単一の行が影響を受ける更新のパフォーマンスはそれほど変わりません。ただし、インスタンスのサイズが大きいほど、処理のレイテンシは大きくなります。インスタンスのサイズと料金の詳細については、料金をご覧ください。
- インスタンスの使用時間はどのようにして算出されますか?
-
インスタンスがアクティブになっている間、1 分単位で課金されます。
SQL Server インスタンス: Microsoft SQL Server ライセンスでは、インスタンスの vCPU ごとに 1 つのコアライセンスが必要になります。各インスタンスのコア数の下限は 4 個です。これらの要件を満たすため、vCPU が 4 個未満のインスタンスは、ライセンス レートの 4 倍で SQL Server に対して課金されます。4 つ以上の vCPU を持つインスタンスの場合、課金対象となる SQL Server ライセンスの数は vCPU の数と同じです。
- ストレージはどのようにして算出されますか?
- ストレージは、インスタンスに対してプロビジョニングされたストレージの量を基に算出されます。バックアップ用のストレージは、バックアップが使用しているスペースの量によって課金されます。ストレージはインスタンスがアクティブであってもなくても課金されます。
- 請求額はどこで確認できますか?
- Google Cloud Console の [お支払い] タブに、前回の請求書の発行後に発生したインスタンスの課金額が表示されます。
- インスタンスが上限サイズに達したらどうなりますか?
- プロビジョニングされているストレージ サイズにインスタンスが達し、ストレージの自動増量が有効にされていないかまたは構成されている上限に達した場合、ユーザーがストレージ サイズを増やすまで、データベースへのそれ以上の書き込みは許可されません。ストレージ サイズを増やすためにインスタンスを再起動する必要はなく、ダウンタイムも発生しません。
- インスタンスが一時停止しているのはなぜですか?
- おそらく Google Cloud アカウントに関する問題が原因です。請求サポート リクエストを提出することで、課金のステータスを確認できます。請求に関する問題を解決してから数時間以内に、インスタンスは実行可能なステータスに戻ります。一時停止された MySQL インスタンスは 90 日後に削除されることに注意してください。
- インスタンスが削除されたのはなぜですか?
- 90 日間停止されているインスタンスは削除されます。これは
SUSPENDED
状態のインスタンスに適用されます。RUNNABLE
状態で停止しているインスタンスは削除されません。 - Cloud SQL アカウントをキャンセルするにはどうすればよいですか?
- プロジェクトで Cloud SQL を無効にするには、Google Cloud Console に移動し、プロジェクトを選択してから、[API] サービスを選択して API ダッシュボードを開きます。Cloud SQL API を探し、その API の [無効にする] をクリックします。
- 課金を無効にするにはどうすればよいですか?
- [課金と設定] ペインで、Google Cloud Console の [課金を無効にする] をクリックすると、課金を無効にできます。課金を無効にすると、Cloud SQL サービスも無効になります。課金を無効にする前に、Cloud SQL サービスを無効にしてもよいことを確認してください。
課金を無効にすると、課金サイクルの初日からキャンセルした時点までに発生した料金に関する最後の請求が届きます。
- App Engine から MySQL インスタンスに接続できますか?
- App Engine アプリケーションがスタンダード環境とフレキシブル環境のどちらで実行されているかにかかわらず、App Engine アプリケーションから MySQL インスタンスに接続できます。詳細については、App Engine スタンダード環境からの接続または App Engine フレキシブル環境からの接続をご覧ください。
- App Engine から PostgreSQL インスタンスに接続できますか?
- 環境と使用している言語によっては、App Engine アプリケーションから PostgreSQL インスタンスに接続できます。詳細については、App Engine スタンダード環境からの接続または App Engine フレキシブル環境からの接続をご覧ください。
- App Engine から SQL Server インスタンスに接続できますか?
- 環境と使用している言語によっては、App Engine アプリケーションから SQL Server インスタンスに接続できます。詳細については、App Engine スタンダード環境からの接続または App Engine フレキシブル環境からの接続をご覧ください。
- 米国の App Engine アプリケーションから EU の Cloud SQL インスタンスにアクセスできますか(またはその逆は可能ですか)?
-
MySQL インスタンスに接続する場合、App Engine アプリケーションは同じリージョンにある必要はなく、スタンダード環境とフレキシブル環境のどちらで実行されていてもかまいません。ただし、Cloud SQL インスタンスと App Engine アプリケーションの距離が大きく離れていると、データベース接続のレイテンシが高くなります。
Cloud SQL インスタンスに接続する場合、App Engine アプリケーションは同じリージョン内に存在していなくてもかまいません。ただし、Cloud SQL インスタンスと App Engine アプリケーションの距離が大きく離れていると、データベース接続のレイテンシが高くなります。
- どの Google Cloud データベース サービスが適していますか?
- これはアプリケーションの要件によって異なります。Google Cloud には、データを保存、管理、取得するためのさまざまなオプションが用意されています。詳細については、Google Cloud データベースをご覧ください。
- App Engine 開発用サーバーを使用するためにローカルのデータベース サーバーをインストールする必要はありますか?
- いいえ。開発用サーバーで実行するときは、App Engine から Cloud SQL とローカルにインストールされたデータベース サーバーのどちらを使用するかを構成できます。
- インスタンスにアクセスするにはどの言語を使用する必要がありますか?
-
App Engine スタンダード環境では、インスタンスへの接続に使用できる複数の言語がサポートされています。詳細については、App Engine スタンダード環境からの接続または App Engine フレキシブル環境からの接続をご覧ください。
App Engine を使用しない場合は、対応するコネクタまたは API が用意されている任意の言語を使用できます。サポートされている言語の一覧については、MySQL リファレンス マニュアルのコネクタと API の章をご覧ください。
- Django を Cloud SQL で使用できますか?
- はい。Cloud SQL は Django に対応しています。Django スタートガイドをご覧ください。
- Python クエリ文字列ではどのプレースホルダを使用できますか?
- Python の場合、パラメータの置換に使用できるのは
%s
形式のコードだけです。このため、次のステートメントは無効です。cursor.execute('INSERT INTO entries (guestAge) VALUES (%d)', (age))
- 接続を管理するにはどうすればよいですか?
-
データベース接続を効果的に管理することは、データベース アプリケーション開発の重要な側面です。効果的な接続管理には、接続プールや指数バックオフの使用が含まれます。これらの手法をさまざまな言語とフレームワークで使用する例については、データベース接続を管理するをご覧ください。
インスタンス接続制限の詳細については、割り当てと制限をご覧ください。
- 「無効な接続 ID」というメッセージの SQLException の意味は何ですか。
- 接続がサーバーでオープンではなくなり、クライアントで破棄されることを意味しています。このような接続はすでにクローズされているため、「close」を呼び出す必要はありません。
- App Engine の外部からプログラムで Cloud SQL インスタンスにアクセスすることはできますか?
- はい。サポートされている任意の言語を使用して、外部アプリケーションからプログラムで Cloud SQL インスタンスにアクセスできます。接続の概要をご覧ください。