インスタンスの設定について

このページでは、Cloud SQL インスタンスで使用できる設定について説明します。

Cloud SQL for PostgreSQL の設定

設定 作成後の変更の可否 可能値
インスタンス ID N 小文字、数字、ハイフンで構成し、先頭は小文字にします。長さは合計で 98 文字以下にしてください。
リージョン N Cloud SQL Enterprise エディションの場合:
africa-south1 — ヨハネスブルグ
asia-east1 — 台湾
asia-east2 — 香港
asia-northeast1 — 東京
asia-northeast2 — 大阪
asia-northeast3 — ソウル
asia-south1 — ムンバイ
asia-south2 — デリー
asia-southeast1 — シンガポール
asia-southeast2 — ジャカルタ
australia-southeast1 — シドニー
australia-southeast2 — メルボルン
europe-central2 — ワルシャワ
europe-north1 — フィンランド
europe-southwest1 — マドリッド
europe-west1 — ベルギー
europe-west2 — ロンドン
europe-west3 — フランクフルト
europe-west4 — オランダ
europe-west6 — チューリッヒ
europe-west8 — ミラノ
europe-west9 — パリ
europe-west10 — ベルリン
europe-west12 — トリノ
me-central1 — ドーハ
me-central2 — ダンマーム
me-west1 — テルアビブ
northamerica-northeast1 — モントリオール
northamerica-northeast2 — トロント
southamerica-east1 — サンパウロ
southamerica-west1 — サンティアゴ
us-central1 — アイオワ
us-east1 — サウスカロライナ
us-east4 — 北バージニア
us-east5 — コロンバス
us-south1 — ダラス
us-west1 — オレゴン
us-west2 — ロサンゼルス
us-west3 — ソルトレイクシティ
us-west4 — ラスベガス

Cloud SQL Enterprise エディションの場合:
africa-south1 — ヨハネスブルグ
asia-east1 — 台湾
asia-east2 — 香港
asia-northeast1 — 東京
asia-northeast2 — 大阪
asia-northeast3 — ソウル
asia-south1 — ムンバイ
asia-south2 — デリー
asia-southeast1 — シンガポール
asia-southeast2 — ジャカルタ
australia-southeast1 — シドニー
australia-southeast2 — メルボルン
europe-central2 — ワルシャワ
europe-north1 — フィンランド
europe-north2 — ストックホルム
europe-southwest1 — マドリッド
europe-west1 — ベルギー
europe-west2 — ロンドン
europe-west3 — フランクフルト
europe-west4 — オランダ
europe-west6 — チューリッヒ
europe-west8 — ミラノ
europe-west9 — パリ
europe-west10 — ベルリン
europe-west12 — トリノ
me-central1 — ドーハ
me-central2 — ダンマーム
me-west1 — テルアビブ
northamerica-northeast1 — モントリオール
northamerica-northeast2 — トロント
northamerica-south1 - メキシコ
southamerica-east1 — サンパウロ
southamerica-west1 — サンティアゴ
us-central1 — アイオワ
us-east1 — サウスカロライナ
us-east4 — 北バージニア
us-east5 — コロンバス
us-south1 — ダラス
us-west1 — オレゴン
us-west2 — ロサンゼルス
us-west3 — ソルトレイクシティ
us-west4 — ラスベガス
ゾーン はい 使用できる値は、リージョンによって異なります。
データベースのバージョン N Cloud SQL Enterprise Plus エディションの場合:
Console string           API enum string
PostgreSQL 17            POSTGRES_17
PostgreSQL 16 (default)  POSTGRES_16
PostgreSQL 15            POSTGRES_15
PostgreSQL 14            POSTGRES_14
PostgreSQL 13            POSTGRES_13
PostgreSQL 12            POSTGRES_12
Cloud SQL Enterprise エディションの場合:
Console string          API enum string
PostgreSQL 17           POSTGRES_17
PostgreSQL 16 (default) POSTGRES_16
PostgreSQL 15           POSTGRES_15
PostgreSQL 14           POSTGRES_14
PostgreSQL 13           POSTGRES_13
PostgreSQL 12           POSTGRES_12
PostgreSQL 11           POSTGRES_11
PostgreSQL 10           POSTGRES_10
PostgreSQL 9.6          POSTGRES_9_6
SSL モード はい 次のように SSL を適用（有効化）します。
  • ALLOW_UNENCRYPTED_AND_ENCRYPTED: 非 SSL / 非 TLS 接続と SSL / TLS 接続を許可します。 SSL 接続の場合、クライアント証明書は検証されません。 これがデフォルト値です。
  • ENCRYPTED_ONLY: SSL / TLS で暗号化された接続のみを許可します。
  • TRUSTED_CLIENT_CERTIFICATE_REQUIRED: SSL / TLS と有効なクライアント証明書で暗号化された接続のみを許可します。
サーバー CA モード N

インスタンスのサーバー認証局（CA）を構成できます。使用可能なサーバー CA オプションは次のとおりです。

  • GOOGLE_MANAGED_INTERNAL_CA: これは、gcloud CLI、Cloud SQL Admin API、または Terraform で作成されたインスタンスのデフォルト値です。このオプションでは、各 Cloud SQL インスタンス専用の内部 CA が、対象のインスタンスのサーバー証明書に署名します。
  • GOOGLE_MANAGED_CAS_CA: このオプションでは、Cloud SQL によって管理され、 Google Cloud Certificate Authority Service（CA Service）でホストされるルート CA と下位サーバーの CA で構成される CA 階層が使用されます。リージョン内の下位サーバー CA はサーバー証明書に署名し、リージョン内のインスタンス間で共有されます。
  • CUSTOMER_MANAGED_CAS_CA: このオプションを使用すると、CA 階層と CA 証明書のローテーションを管理できます。このオプションでインスタンスを作成する前に、CA Service を使用して、インスタンスと同じリージョンに CA プールを作成し、そのプールに 1 つ以上の CA を作成します。インスタンスを作成するときに、作成した CA プールを指定します。リクエストは、その CA プールを使用する権限を持つプロジェクト固有のサービス アカウントに委任されます。サービス アカウントがプールから CA をリクエストし、Cloud SQL はその CA を使用してインスタンスのサーバー証明書に署名します。

詳細については、認証局（CA）階層をご覧ください。このインスタンスの設定はプレビュー版です。
エディションの設定 はい

ENTERPRISE または ENTERPRISE PLUS
パスワード ポリシーの設定 はい 構成されているかどうか。
プライベート IP 一度有効にすると、無効にはできません。 有効または無効。
パブリック IP はい 有効または無効。
承認済みネットワーク はい パブリック IP が有効な場合、インスタンスへの接続を許可する IP アドレス。この値は IP アドレス範囲（CIDR 表記）としても指定できます。
Google Cloud サービスのプライベート パス はい 有効または無効。
データ キャッシュ はい 有効または無効。
マシンタイプ はい

共有コアまたは専用コアのいずれかを選択します。共有コアの場合、各マシンタイプはインスタンスの CPU（コア）数とメモリ量によって分類されます。

専用コアの場合は、事前定義された構成を選択する代わりに、[カスタム] ラジオボタンを選択してカスタム マシンタイプを作成します。詳細

コア数 はい Cloud SQL Enterprise Plus エディションの場合:
2～128（事前定義されたマシンタイプのみ）

Cloud SQL Enterprise エディションの場合:
1～96（1 または偶数である必要があります）
共有 vCPU の一部分
メモリ はい Cloud SQL Enterprise Plus エディションの場合: vCPU あたり 6.75～8 GB。
6.75 GB 対 1 vCPU の比率は、db-perf-optimized-N-128 マシンタイプにのみ適用されます。他のすべてのマシンタイプには、8 GB 対 1 vCPU の比率が適用されます。
Cloud SQL Enterprise エディションの場合: vCPU あたり 0.9～6.5 GB（256 MB の倍数で、3.75 GB 以上である必要があります）
ストレージの種類 N SSD（デフォルト値）
HDD（Cloud SQL Enterprise エディションのみ）
ストレージ容量 ○
（増加のみ）		 1 つ以上の共有されていない vCPU を持つインスタンスで、最大 64 TB まで使用できます。
共有 vCPU を持つインスタンスは、最大 3,054 GB まで使用できます。

64 TB のストレージ容量を作成するか、64 TB に容量を拡大すると、ワークロードに応じて、バックアップなどの一般的なオペレーションのレイテンシが増加する可能性があります。
ストレージの自動増量を有効にする はい オン（デフォルト値）
オフ
データ暗号化方法 N Google-owned and Google-managed encryption key（デフォルト値）
Cloud KMS 鍵
ストレージの自動増量の上限 はい GB 単位の値。0（デフォルト値）は無制限であることを示します。
バックアップ ○
 オン（デフォルト値）
オフ
ロケーション オプション はい マルチリージョン（デフォルト値）
リージョン

また、[マルチ リージョン] を選択すると、マルチリージョンのリストを含むプルダウン メニューが表示され、[リージョン] を選択すると、リージョンのリストを含むプルダウン メニューが表示されます。

インスタンスの削除からの保護 はい 有効または無効。
ポイントインタイム リカバリ（PITR）を有効にする ○
（注を参照）		 オン
オフ

デフォルト値はインスタンスによって異なります。詳細については、PITR を使用するをご覧ください。

可用性: シングルゾーン ○
 オン（デフォルト値）
オフ
高可用性（リージョン） ○
 オン
オフ（デフォルト値）
メンテナンス: メンテナンス ウィンドウ はい 任意（デフォルト値）
曜日と時間
メンテナンス: メンテナンスのタイミング はい 任意（デフォルト値）
Canary（第 1 週（早め）/ プレビュー）
安定版（第 2 週（遅め）/ 本番環境）
第 5 週
データベース フラグ はい データベース フラグを構成するをご覧ください。
インスタンス ID

インスタンス ID はインスタンスの名前です。プロジェクト内で各インスタンスを一意に示すために使用されます。可能な限り、インスタンスの目的に合ったインスタンス名を選択してください。

project-ID:instance-ID の長さは合計で 98 文字以下にしてください。

インスタンス名にプロジェクト ID を含める必要はありません。この処理は必要に応じて自動的に行われます（ログファイルの場合など）。
リージョン
インスタンスが配置されている Google Cloud リージョン。リージョンは、インスタンス作成時にのみ設定できます。パフォーマンスを向上させるには、そのデータを必要とするサービスに近い場所でデータを保存します。詳しくは、インスタンスのロケーションをご覧ください。
ゾーン
インスタンスが配置されている Google Cloud ゾーン。Compute Engine インスタンスから接続する場合は、Compute Engine インスタンスが存在するゾーンを選択します。それ以外の場合は、デフォルトのゾーンをそのまま使用します。必要であれば、後でインスタンスを編集してゾーンを変更できます。詳しくは、インスタンスのロケーションをご覧ください。
マシンタイプ

Cloud SQL インスタンスで利用可能なメモリと仮想コアを決定します。使用可能なマシンタイプは Cloud SQL のエディションによって異なります。

オンライン トランザクション処理（OLTP）などのリアルタイム処理を必要とするワークロードの場合は、インスタンスに作業セット全体を保存するための十分なメモリを確保してください。ただし、メモリ要件に影響を与える可能性がある要素は他にもあります（アクティブな接続や内部のオーバーヘッド プロセスの数など）。本番環境でパフォーマンスの問題が発生しないように、負荷テストを実行する必要があります。

インスタンスの構成時に、ワークロードを処理するのに十分なメモリと vCPU を選択し、ワークロードの増加に合わせてアップグレードしてください。vCPU が不十分なマシン構成では、SLA 範囲外になる可能性があります。詳細については、オペレーション ガイドラインをご覧ください。

Cloud SQL Enterprise Plus エディション インスタンスのマシンタイプ Cloud SQL Enterprise Plus エディション インスタンスの場合、マシンタイプは次のように事前定義されています。

Enterprise Plus マシンタイプ vCPU メモリ（GB） ローカル SSD
db-perf-optimized-N-2 2 16 375
db-perf-optimized-N-4 4 32 375
db-perf-optimized-N-8 8 64 375
db-perf-optimized-N-16 16 128 750
db-perf-optimized-N-32 32 256 1500
db-perf-optimized-N-48 48 384 3000
db-perf-optimized-N-64 64 512 6000
db-perf-optimized-N-80 80 640 6000
db-perf-optimized-N-96 96 768 6000
db-perf-optimized-N-128 128 864 9000
Cloud SQL Enterprise エディション インスタンスのマシンタイプ Cloud SQL Enterprise エディション インスタンスの場合は、gcloud sql instances create コマンドを使用してカスタム インスタンス構成を作成することもできます。カスタム インスタンス構成では、インスタンスに必要なメモリと CPU の量を自分で選択できます。この柔軟性により、ワークロードに適した VM のシェイプを選択できます。

マシンタイプ名の形式は db-custom-#-# です。

最初の # プレースホルダはマシンの CPU 数に置き換え、2 番目の # プレースホルダはマシンのメモリ量に置き換えます。

たとえば、マシン名が db-custom で、マシンに 1 つの CPU と 3,840 MB の RAM がある場合、マシンの形式は db-custom-1-3840 になります。

CPU の数とメモリの量を選択する際、選択する構成にはいくつかの制限があります。

  • vCPU は 1 または 2～96 の間の偶数にする必要があります。
  • メモリは次の条件を満たす必要があります。
    • vCPU あたり 0.9～6.5 GB
    • 256 MB の倍数
    • 3.75 GB（3,840 MB）以上

次の表に、以前の各マシンタイプ名、各マシンタイプの CPU と RAM の数、結果としてできるマシンタイプの文字列を示します。

同等のマシンタイプを作成するには、Google Cloud コンソールで同等の CPU と RAM を指定するか、gcloud CLI を使用するか、または API で db-custom-#-# を指定します。

以前のマシンタイプ vCPU メモリ（MB） db-custom-CPU-RAM 文字列（API 階層文字列）
db-n1-standard-1 1 3840 db-custom-1-3840
db-n1-standard-2 2 7680 db-custom-2-7680
db-n1-standard-4 4 15360 db-custom-4-15360
db-n1-standard-8 8 30720 db-custom-8-30720
db-n1-standard-16 16 61440 db-custom-16-61440
db-n1-standard-32 32 122880 db-custom-32-122880
db-n1-standard-64 64 245760 db-custom-64-245760
db-n1-standard-96 96 368640 db-custom-96-368640
db-n1-highmem-2 2 13312 db-custom-2-13312
db-n1-highmem-4 4 26624 db-custom-4-26624
db-n1-highmem-8 8 53248 db-custom-8-53248
db-n1-highmem-16 16 106496 db-custom-16-106496
db-n1-highmem-32 32 212992 db-custom-32-212992
db-n1-highmem-64 64 425984 db-custom-64-425984
db-n1-highmem-96 96 638976 db-custom-96-638976

マシンタイプによりインスタンスの費用が変わります。詳しくは、インスタンスの料金をご覧ください。料金計算ツールでさまざまなシナリオの料金を確認することもできます。

パスワード ポリシーの設定

インスタンスのパスワード ポリシー。これには次のオプションがあります。

  • 最小文字数: パスワードの最小文字数を指定します。
  • パスワードの複雑さ: パスワードが小文字、大文字、数字、英数字以外の文字の組み合わせになっているかどうかを確認します。
  • パスワードの再利用の制限: 再利用できない以前のパスワードの数を指定します。
  • パスワードにユーザー名を許可しない: パスワードにユーザー名を使用できないようにします。
  • パスワードの変更間隔を設定する: パスワードを変更可能になるまでの最小期間を指定します。
コア数

インスタンスの CPU 数。CPU（共有コード インスタンス、つまり共有 vCPU）を 1 つも持たないインスタンスを作成することもできます。

メモリ

インスタンスで使用できるメモリ量。オンライン トランザクション処理（OLTP）などのパフォーマンス重視のワークロードの場合、インスタンスに作業セット全体を格納するための十分なメモリを確保してください。ただし、アクティブな接続の数など、その他にもメモリ要件に影響を与える可能性がある要素があります。本番環境でのパフォーマンスの問題を避けるためには、負荷テストを実行してください。

データベースのバージョン
特定のバージョンだけで提供される機能が必要な場合を除き、デフォルトのデータベースのバージョン（PostgreSQL 15）を使用します。gcloud コマンドと REST API の使用方法については、リファレンス ドキュメントをご覧ください。
ストレージの種類
デフォルト値の [SSD] を選択すると、インスタンスのストレージは SSD に設定されます。SSD は低レイテンシ、高データ スループットのストレージです。長期保存データやアクセス頻度の低いデータなど、データへの高パフォーマンス アクセスが不要な場合は、[HDD] を選択してコストを削減できます。
SSL モード

（省略可）データベース接続の SSL / TLS オプション。Cloud SQL は SSL / TLS を使用して、インスタンスへの認証済みで暗号化された安全な接続を確立します。SSL モード設定 sslMode を使用して、インスタンスへのすべてのデータベース接続で SSL / TLS 暗号化を使用するように設定できます。この設定を使用して、クライアント証明書の検証を行うようにすることもできます。この設定では、requireSsl よりも SSL 接続をより詳細に制御できます。sslMode の使用をおすすめします。詳細については、IpConfiguration をご覧ください。インスタンスの作成時や既存のインスタンスの更新時には、SSL を強制適用できます。

サーバー CA モード

（省略可）インスタンスを作成するときに、インスタンスのサーバー CA モードを選択できます。

  • GOOGLE_MANAGED_INTERNAL_CA: これがデフォルト値です。Cloud SQL は、インスタンスごとに新しい自己署名サーバー CA を作成します。
  • GOOGLE_MANAGED_CAS_CA: インスタンスは、Certificate Authority Service によってホストされるサーバー CA 階層を使用し、発行側の CA は同じリージョン内のすべてのインスタンスで共有されます。

これらのオプションの詳細については、認証局（CA）階層をご覧ください。サーバー CA モードはプレビュー版です。

ストレージ容量

データベースのサイズに適した容量を選択します。インスタンスの作成後は、インスタンス構成を編集して手動でストレージ容量を増やすことができますが、減らすことはできません。ストレージ容量を増やしても、ダウンタイムは発生しません。

インスタンスに割り振られるストレージ容量は、インスタンスのコストに影響します。詳細については、ストレージとネットワークの料金をご覧ください。

リードレプリカの場合、ストレージ容量は常にプライマリ インスタンスのストレージ容量以上である必要があります。プライマリ インスタンスのサイズを変更すると、必要に応じて、更新されたプライマリ インスタンスのストレージ容量以上になるように、すべてのリードレプリカのサイズが変更されます。

ストレージの自動増量を有効にする

この設定を有効にすると、Cloud SQL によって利用可能なストレージが 30 秒ごとにチェックされます。利用可能なストレージがしきい値サイズを下回ると、自動的にストレージ容量が追加されます。利用可能なストレージがしきい値サイズを繰り返し下回る場合、最大 64 TB に達するまで続けてストレージが追加されます。

プライマリ インスタンスのストレージの自動増量設定は、そのインスタンスのすべてのリードレプリカに自動的に適用されます。ストレージの自動増量設定は、リードレプリカに対して独立して設定することはできません。

しきい値

しきい値のサイズは、インスタンスに対して現在プロビジョニングされているストレージの量によって変わりますが、25 GB より大きくすることはできません。

500 GB 以上のストレージがプロビジョニングされているインスタンスの場合、しきい値は常に 25 GB です。

500 GB 未満のストレージがプロビジョニングされているインスタンスの場合、しきい値の計算には次の数式が使用されます。

  5 + (provisioned storage)/25

除算の結果は、最も近い整数に切り捨てられます。

ストレージ容量が 66 GB のインスタンスのしきい値計算は、次のようになります。

5 + (1/25th of 66 GB) = 5 + (66/25) = 5 + 2.6 -> 5 + 2 = 7 GB
ストレージ容量が 1,000 GB のインスタンスのしきい値計算は、次のようになります。
5 + (1/25th of 1000 GB) = 5 + (1000/25) = 5 + 40 = 45 -> rounded down to the
maximum value of 25 GB

追加されるストレージの量

インスタンスに追加されるストレージ容量は、しきい値サイズと等しくなりますが、25 GB より大きくすることはできません。

大容量ディスクに関する考慮事項

500 GB 以上のストレージがプロビジョニングされているインスタンスの場合、しきい値サイズは常に 25 GB で、追加されるストレージ容量は常に 25 GB です。そのため、使用可能な最大空きスペースは 50 GB です。5 TB を超えるディスクを持つインスタンスのサイズを手動で変更しない場合、インスタンスに空きスペースがある場合でも、ディスクは常に 99% の容量を維持できます。

大規模なインポートや、大きい一時テーブルが必要なクエリなど、ディスク使用量が急増するオペレーションを実行する前は、ストレージの自動増量に依存せず、ディスクサイズを手動で変更してください。

ファイル システムは、ファイル システムのメタデータ用に内部的にスペースを使用します。このスペースは、ディスク使用量の指標（database/disk/bytes_used）に含まれません。ディスクが大きい場合、予約済みスペースが合計ディスクサイズの 1～3% を占めることがあるため、ディスク使用量がしきい値に達する前にストレージの自動増量が発生することがあります。

データ暗号化方法

デフォルトでは、Cloud SQL インスタンスは Google-owned and managed keyで暗号化されます。この鍵を管理する場合は、Cloud Key Management Service（KMS）で顧客管理の暗号鍵（CMEK）を使用します。Cloud KMS は Cloud SQL と統合されています。

Cloud KMS 鍵を使用すると、保護レベル、ロケーション、ローテーション スケジュール、使用とアクセスの権限を制御できます。また、リソース間でさまざまな暗号鍵を使用できます。Cloud KMS を使用すると、鍵の使用状況を追跡すること、監査ログを表示すること、鍵のライフサイクルを管理することが可能です。

データを保護する鍵は Google が所有して管理するのではなく、ユーザーが Cloud KMS でこれらの鍵の制御と管理を行います。

CMEK の詳細については、顧客管理の暗号鍵（CMEK）についてをご覧ください。

ストレージの自動増量の上限

ストレージの自動増量の設定を有効にしている場合、インスタンスのストレージが自動的に増量する場合の明確な上限を指定できます。インスタンスのサイズが大きいほど、運用レイテンシが高くなることに留意してください。

ストレージ サイズを減らすことはできないため、この上限を指定することで、（トラフィックの一時的な増大によって）インスタンスのサイズが大きくなりすぎないようにすることが可能です。インスタンスで必要なストレージを追加できなくなった場合、着信接続の受け入れが停止され、インスタンスがオフラインになる可能性があるので注意してください。

この上限をゼロ（デフォルト値）に設定した場合、インスタンスの階層で使用可能な最大ストレージを除き、上限がなくなります。

インスタンスの作成時に上限を設定するには、インスタンスの作成ページで説明されているように、--storage-auto-increase-limit=INTEGER_VALUE_OF_GB パラメータを使用します。既存のインスタンスに上限を設定するには、gcloud beta sql instances patch コマンドで同じパラメータを使用します。

プライマリ インスタンスのストレージの自動増量上限設定は、そのインスタンスのすべてのリードレプリカに自動的に適用されます。ストレージの自動増量の上限設定をリードレプリカに独立して設定することはできません。

自動的なバックアップとポイントインタイム リカバリ

これらのオプションにより、自動バックアップが実行されるかどうか、および write-ahead log 書き込みを有効にするかどうかが決まります。どちらのオプションでも若干のパフォーマンス コストと追加のストレージが発生しますが、レプリカとクローンの作成およびポイントインタイム リカバリには必要です。このオプションを選択すると、自動バックアップを実行する時間帯も選択できます。

自動バックアップは、選択した時間帯に毎日行われます。7 日後に、最も古いバックアップが削除されます。

ポイントインタイム リカバリについては、ポイントインタイム リカバリの概要をご覧ください。

レプリケーションについては、レプリケーション オプションをご覧ください。インスタンスのクローン作成については、インスタンスのクローンを作成するをご覧ください。

自動バックアップ保持期間の設定

保持されるバックアップ数のデフォルト値は 7 ですが、1～365 の範囲内で任意の値に変更できます。

詳細については、自動バックアップとトランザクション ログの保持をご覧ください。

ロケーションのオプション

バックアップは複数のリージョンに保存するか、単一のリージョンに保存するかを選択できます。デフォルトはマルチリージョンです。リージョンが利用できなくなった場合の予備を用意するため、これをおすすめします。バックアップは、インスタンスに最も近いリージョンに保存されます。

バックアップ用のカスタム ロケーションを選択することもできます。このオプションは、規則上必要な場合や、組織のポリシーにより複数または単一のリージョンへのバックアップが個別に決められている場合にのみ使用します。詳しくは、カスタム ロケーションをご覧ください。

インスタンスの削除からの保護

インスタンスが誤って削除されないように保護します。この設定が有効になっている場合は、この設定を無効にしてからインスタンスを削除する必要があります。インスタンスの削除を防止するをご覧ください。

ポイントインタイム リカバリを有効にする

ポイントインタイム リカバリを使用すると、特定の時点でのバックアップを復元できます。

ポイントインタイム リカバリについては、ポイントインタイム リカバリの概要をご覧ください。

可用性: ゾーン

インスタンスとバックアップを 1 つのゾーンに配置します。このオプションを選択すると、停止時にフェイルオーバーは発生しません。テストと開発の目的でのみ使用することをおすすめします。

高可用性（リージョン）

[高可用性（リージョン）] を選択した場合、フェイルオーバー ゾーンが停止していない限り、インスタンスはリージョン内の別のゾーンにフェイル オーバーします。本番環境のインスタンスには [高可用性（リージョン）] を選択することをおすすめします。

高可用性構成の概要をご覧ください。

メンテナンスの時間枠

Cloud SQL インスタンスのメンテナンス イベントがスケジュールされている曜日と時刻です。Cloud SQL Enterprise Plus エディションのプライマリ インスタンスの場合、通常、メンテナンス ダウンタイムは 1 秒未満です。それ以外の場合、通常、メンテナンスのダウンタイムは平均 60 秒以内です。

現在、リードレプリカはメンテナンスの時間枠の設定をサポートしていません。

メンテナンスの詳細については、Cloud SQL インスタンスでのメンテナンスについてをご覧ください。

メンテナンスのタイミング

メンテナンス更新の適用タイミングの設定。通知から 1～2 週間後に更新を受け取り、本番環境インスタンスで更新が行われる前に、テスト環境でメンテナンス更新をテストできます。通知が送信されてから 5 週間（week5）後にメンテナンス更新を受け取ることもできます。メンテナンスのタイミングの設定内容によって、インスタンスに適用されるメンテナンス バージョンが変わることはありません。

メンテナンスのタイミングを設定しない場合、インスタンスに対する更新のタイミングは Cloud SQL によって選択されます（メンテナンスの時間枠が指定されている場合はその範囲内で行われます）。

メンテナンスの詳細については、Cloud SQL インスタンスでのメンテナンスについてをご覧ください。

プライベート IP
プライベート IP を使用するようにインスタンスを構成します。詳細
パブリック IP
有効にすると、インスタンスにはパブリック IPv4 アドレスが割り振られます。パブリック IP を無効にすると、インスタンスに割り振られたアドレスは解放されます。後でパブリック IP を再有効化できますが、前と同じ IPv4 アドレスは割り振られません。デフォルトでは、パブリック IP アドレスはすべてのアドレスに対してブロックされます。アクセスを有効にするには、承認済みネットワークを使用します。
承認済みネットワーク
特定の IP アドレスまたはアドレス範囲を追加し、それらのアドレスに対してインスタンスを開くことができます。

IP アドレスの構成については、IP 接続を構成するをご覧ください。

Google Cloud サービスのプライベート パス

このチェックボックスをオンにすると、他の Google Cloudサービス（BigQuery など）が Cloud SQL 内のデータにアクセスし、プライベート接続でこのデータに対してクエリを実行できるようになります。

このチェックボックスは、[プライベート IP] チェックボックスをオンにして、プライベート接続を作成するように承認済みネットワークを追加または選択した場合にのみ有効になります。

データ キャッシュ

Cloud SQL for PostgreSQL Enterprise Plus エディションのインスタンスでは、データ キャッシュはオプションです。データ キャッシュは、ローカル SSD を利用して、OS のページ キャッシュをメモリから SSD 階層に拡張します。この設定は Cloud SQL が管理します。作業セット全体をキャッシュに保存すると、データ キャッシュを使用する際に最大のパフォーマンスが得られます。Cloud SQL for PostgreSQL Enterprise Plus エディションのインスタンスでは、この設定の有効 / 無効を、Google Cloud コンソール、gcloud CLI、または Cloud SQL Admin API を使用して切り替えることができます。

アクティベーション ポリシー
アクティベーション ポリシーを変更するには、インスタンスを起動および停止します。インスタンスを停止すると、インスタンスの追加料金が発生しなくなります。
データベース フラグ

Cloud SQL インスタンスに特定のデータベース フラグを設定できます。

設定できるデータベース フラグのリストについては、データベース フラグを構成するをご覧ください。

インスタンス設定の変更による影響

インスタンスのほとんどの設定では、Cloud SQL はすぐに変更を適用し、インスタンスへの接続は影響を受けません。

Cloud SQL Enterprise エディションを使用する場合、CPU 数またはメモリサイズを変更すると、インスタンスが 60 秒未満の間、オフラインになります。変更が有効になるまで合計で数分かかることがあります。インスタンスのゾーンの変更、プライベート IP の構成、ネットワークの変更、高可用性の有効化の結果、インスタンスが数分間オフラインになります。

Cloud SQL Enterprise Plus エディションを使用している場合は、vCPU のスケールアップやデータ キャッシュの有効化または無効化など、インスタンス設定の変更をほぼゼロのダウンタイムで行うことができます。詳細については、Cloud SQL での可用性をご覧ください。

Cloud SQL は、インスタンスのメモリ容量に基づいて、max_connections フラグの値を自動的に管理します（詳細については、サポートされているフラグをご覧ください）。PostgreSQL では、リードレプリカの max_connections の値が、常にプライマリ以上でなければなりません。そのため、リードレプリカのメモリがプライマリのメモリよりも少ない場合、プライマリのメモリ量を変更すると、リードレプリカが 60 秒弱の間オフラインになる可能性があります。これは、リードレプリカでプライマリの変更との整合性を維持するために、max_connections の新しい値を受け取ることが必要になる場合があり、max_connections の値を更新するには、PostgreSQL を再起動する必要があるためです。これを回避するには、プライマリの max_connections フラグを任意の値に設定します。

この種の変更は、サービスがこの期間の停止に対応できるときに行うように計画します。

次のステップ