このページでは、Cloud SQL インスタンスを古いネットワーク アーキテクチャから新しいネットワーク アーキテクチャにアップグレードする方法について説明します。
この Cloud SQL ネットワーク アーキテクチャのアップグレード ページは、特定の Cloud SQL インスタンスにのみ適用されます。Cloud SQL インスタンスが、2021 年 8 月より前に作成された Virtual Private Cloud(VPC)ネットワーク プロジェクトを使用している場合は、インスタンスの Cloud SQL ネットワーク アーキテクチャをアップグレードする必要があります。
概要
次の表に、以前のネットワーク アーキテクチャと比較した新しいネットワーク アーキテクチャの利点を示します。
機能 | 以前のネットワーク アーキテクチャ | 新しいネットワーク アーキテクチャ |
---|---|---|
Database Migration Service を使用した Cloud SQL から AlloyDB for PostgreSQL への移行、および AlloyDB for PostgreSQL から Cloud SQL への移行 | 移行用にプライベート IP アドレスを構成する必要があります。 | 追加のネットワーク構成は不要です。 たとえば、Cloud SQL から AlloyDB for PostgreSQL への移行、AlloyDB for PostgreSQL から Cloud SQL への移行などが該当します。 |
プライベート IP を使用して、Cloud SQL インスタンスを Cloud Build や Vertex AI などの限定公開サービスに接続する | ネットワーク ピアリングの非推移性のため、サポート対象外 | サポート対象 |
Assured Workloads に準拠したインスタンス | サポート対象外 | サポート対象 |
Managed Microsoft AD | サポート対象外 | サポート対象 |
Private Service Connect | サポート対象外 | サポート対象 |
プロジェクトあたりのデフォルトの Cloud SQL インスタンスの割り当て | 100 | 1,000 |
アップグレードを計画する
Cloud SQL インスタンスのネットワーク アーキテクチャをアップグレードする前に、次のアップグレードの制約に合わせてアップグレードを計画します。
ネットワーク アーキテクチャをアップグレードすると、データベース インスタンスのダウンタイムが最大 4 分間発生します。
データの移行が進行中の場合、その間は、ソース インスタンスを新しいアーキテクチャにアップグレードできません。
外部ソースからインスタンスに接続する場合は、すべてのピアリング接続が更新され、カスタムルートのエクスポートが有効になっていることを確認します。
Cloud SQL インスタンスの数が 300 個を超えるネットワークでは、インスタンスのネットワーク アーキテクチャをアップグレードすることはできません。
ネットワークの同じリージョン内に、プライベート IP アドレスを使用するインスタンスが 2 つ以上含まれている場合、Cloud SQL は、割り振られた限定公開サービス アクセスの IP アドレス範囲から追加の /24 範囲を使用して、新しいネットワーク アーキテクチャのインスタンスをホストする必要があります。この追加の使用は一時的なもので、その後の Cloud SQL メンテナンス イベントで削除されます。
フェイルオーバー レプリカを使用した以前の高可用性(HA)インスタンスはアップグレードでサポートされていません。
ネットワーク アーキテクチャをアップグレードすると、アップグレードされたインスタンスの以前の HA フェイルオーバー レプリカを作成できなくなります。
ネットワーク プロジェクト内の Cloud SQL インスタンスすべてのアップグレードを計画する
Cloud SQL インスタンスは、VPC ネットワークと同じプロジェクトに配置することも、別のプロジェクトでホストすることもできます。VPC ネットワークをホストするプロジェクトは、ネットワーク プロジェクトです。
ネットワーク プロジェクト内で Cloud SQL インスタンスが一つでも以前のネットワーク アーキテクチャを使用していれば、プロジェクト全体で以前のネットワーク アーキテクチャが使用されます。この場合、プロジェクトは、新しいネットワーク アーキテクチャに完全にはアップグレードされません。
プロジェクト内のすべての Cloud SQL インスタンスのネットワーク アーキテクチャは、gcloud CLI または Cloud SQL Admin API を使用して確認できます。
インスタンスのプライベート ネットワークを変更する場合や、インスタンスのプライベート IP を有効にする場合、同じリクエストでネットワーク アーキテクチャを変更することはできません。そのようなリクエストは拒否されます。これを回避するため、ネットワーク プロジェクトを変更する前に、ネットワーク プロジェクトのすべてのインスタンスをアップグレードすることをおすすめします。
Cloud SQL のネットワーク アーキテクチャをアップグレードする
Cloud SQL インスタンスのネットワーク アーキテクチャをアップグレードする手順は次のとおりです。
- 1 つの Cloud SQL インスタンスまたは複数の Cloud SQL インスタンスのネットワーク アーキテクチャを確認します。
- Cloud SQL インスタンスのネットワーク アーキテクチャをアップグレードします。
1 つの Cloud SQL インスタンスのネットワーク アーキテクチャを確認する
1 つのインスタンスの現在のネットワーク アーキテクチャを確認するには、gcloud sql instances describe
コマンドまたは instances.get
メソッドを使用します。
gcloud
gcloud CLI のインストールと使用開始については、gcloud CLI をインストールするをご覧ください。Cloud Shell の起動については、Cloud Shell を使用するをご覧ください。
1 つのインスタンスのネットワーク アーキテクチャを確認するには、次のコマンドを実行します。
gcloud sql instances describe INSTANCE_NAME
インスタンスが以前のネットワーク アーキテクチャを使用している場合、レスポンスは次のようになります。
name: INSTANCE_NAME project: PROJECT_ID ... sqlNetworkArchitecture: OLD_NETWORK_ARCHITECTURE
インスタンスが新しいネットワーク アーキテクチャを使用している場合、レスポンスは次のようになります。
name: INSTANCE_NAME project: PROJECT_ID ... sqlNetworkArchitecture: NEW_NETWORK_ARCHITECTURE
sqlNetworkArchitecture
パラメータにより、インスタンスが以前のネットワーク アーキテクチャ(OLD_NETWORK_ARCHITECTURE
)を使用しているのか、それとも新しいネットワーク アーキテクチャ(NEW_NETWORK_ARCHITECTURE
)を使用しているのかが示されます。
REST v1
インスタンスのネットワーク アーキテクチャを確認するには、Cloud SQL Admin API の instances.get
メソッドを使用します。
リクエストのデータを使用する前に、次のように置き換えます。
- PROJECT_ID: プロジェクト ID。
- INSTANCE_NAME: インスタンス名。
- NETWORK_ARCHITECTURE_TYPE: ネットワーク アーキテクチャ タイプは次のように定義されます。
OLD_NETWORK_ARCHITECTURE
: インスタンスは以前のネットワーク アーキテクチャを使用します。NEW_NETWORK_ARCHITECTURE
: インスタンスは新しいネットワーク アーキテクチャを使用します。
HTTP メソッドと URL:
GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME
リクエストの本文(JSON):
{ "sqlNetworkArchitecture": "NETWORK_ARCHITECTURE_TYPE" }
リクエストを送信するには、次のいずれかのオプションを開きます。
次のような JSON レスポンスが返されます。
{ "kind": sql#instance "name": INSTANCE_NAME "project": PROJECT_ID "sqlNetworkArchitecture": enum (SqlNetworkArchitecture) ... }
REST v1beta4
インスタンスのネットワーク アーキテクチャを確認するには、Cloud SQL Admin API の instances.get
メソッドを使用します。
リクエストのデータを使用する前に、次のように置き換えます。
- PROJECT_ID: プロジェクト ID。
- INSTANCE_NAME: インスタンス名。
- NETWORK_ARCHITECTURE_TYPE: ネットワーク アーキテクチャ タイプは次のように定義されます。
OLD_NETWORK_ARCHITECTURE
: インスタンスは以前のネットワーク アーキテクチャを使用します。NEW_NETWORK_ARCHITECTURE
: インスタンスは新しいネットワーク アーキテクチャを使用します。
HTTP メソッドと URL:
GET https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME
リクエストの本文(JSON):
{ "sqlNetworkArchitecture": "NETWORK_ARCHITECTURE_TYPE" }
リクエストを送信するには、次のいずれかのオプションを開きます。
次のような JSON レスポンスが返されます。
{ "kind": sql#instance "name": INSTANCE_NAME "project": PROJECT_ID "sqlNetworkArchitecture": enum (SqlNetworkArchitecture) ... }
複数の Cloud SQL インスタンスのネットワーク アーキテクチャを確認する
1 つのプロジェクトに存在する複数のインスタンスのネットワーク アーキテクチャを確認するには、gcloud sql instances list
コマンドまたは instance.list
メソッドを使用します。
gcloud
1 つのプロジェクトに存在する複数のインスタンスのネットワーク アーキテクチャを確認するには、次のコマンドを実行します。
gcloud sql instances list --show-sql-network-architecture
出力は次のようになります。
NAME DATABASE_VERSION LOCATION ... SQL_NETWORK_ARCHITECTURE instance_1 POSTGRES_13 asia-northeast1-b OLD_NETWORK_ARCHITECTURE instance_2 MYSQL_5_7 europe-west1-d NEW_NETWORK_ARCHITECTURE ...
REST v1
1 つのプロジェクトに存在する複数のインスタンスのネットワーク アーキテクチャを確認するには、instance.list
メソッドを使用します。
リクエストのデータを使用する前に、次のように置き換えます。
- PROJECT_ID: プロジェクト ID。
- NETWORK_ARCHITECTURE_TYPE: 次のネットワーク アーキテクチャ タイプ。
OLD_NETWORK_ARCHITECTURE
: インスタンスは以前のネットワーク アーキテクチャを使用します。NEW_NETWORK_ARCHITECTURE
: インスタンスは新しいネットワーク アーキテクチャを使用します。
HTTP メソッドと URL:
LIST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances
リクエストの本文(JSON):
{ "sqlNetworkArchitecture": "NETWORK_ARCHITECTURE_TYPE" }
リクエストを送信するには、次のいずれかのオプションを開きます。
次のような JSON レスポンスが返されます。
{ "kind": sql#instance "name": INSTANCE_NAME "project": PROJECT_ID "sqlNetworkArchitecture": enum (SqlNetworkArchitecture) ... }
REST v1beta4
1 つのプロジェクトに存在する複数のインスタンスのネットワーク アーキテクチャを確認するには、instance.list
メソッドを使用します。
リクエストのデータを使用する前に、次のように置き換えます。
- PROJECT_ID: プロジェクト ID。
- NETWORK_ARCHITECTURE_TYPE: ネットワーク アーキテクチャ タイプは次のように定義されます。
OLD_NETWORK_ARCHITECTURE
: インスタンスは以前のネットワーク アーキテクチャを使用します。NEW_NETWORK_ARCHITECTURE
: インスタンスは新しいネットワーク アーキテクチャを使用します。
HTTP メソッドと URL:
LIST https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances
リクエストの本文(JSON):
{ "sqlNetworkArchitecture": "NETWORK_ARCHITECTURE_TYPE" }
リクエストを送信するには、次のいずれかのオプションを開きます。
次のような JSON レスポンスが返されます。
{ "kind": sql#instance "name": INSTANCE_NAME "project": PROJECT_ID "sqlNetworkArchitecture": enum (SqlNetworkArchitecture) ... }
1 つの Cloud SQL インスタンスのネットワーク アーキテクチャをアップグレードする
1 つのインスタンスのネットワーク アーキテクチャをアップグレードするには、gcloud sql instances patch
コマンド、instance.update
メソッド、または instance.patch
メソッドを使用します。
gcloud
インスタンスのネットワーク アーキテクチャをアップグレードするには、次のコマンドを実行します。
gcloud sql instances patch INSTANCE_NAME --upgrade-sql-network-architecture
アップグレードには数分かかります。
アップグレードの際には、長時間実行オペレーションが開始され、オペレーション トークンが返されます。
operation_id
REST v1
インスタンスのネットワーク アーキテクチャをアップグレードするには、Cloud SQL Admin API の instance.update
または instance.patch
メソッドを使用します。
Cloud SQL ネットワーク アーキテクチャをアップグレードする場合、インスタンスに対する別の更新をリクエストに含めることはできません。リクエストの本文には、sqlNetworkArchitecture
を NEW_NETWORK_ARCHITECTURE
に設定した DatabaseInstance
オブジェクトのインスタンスを含めます。
アップグレードの際には、長時間実行オペレーションが開始され、オペレーション トークンが返されます。
operation_id
リクエストのデータを使用する前に、次のように置き換えます。
- PROJECT_ID: プロジェクト ID。
- INSTANCE_NAME: インスタンス名。
- NETWORK_ARCHITECTURE_TYPE: ネットワーク アーキテクチャ タイプは次のように定義されます。
OLD_NETWORK_ARCHITECTURE
: インスタンスは以前のネットワーク アーキテクチャを使用します。NEW_NETWORK_ARCHITECTURE
: インスタンスは新しいネットワーク アーキテクチャを使用します。
HTTP メソッドと URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME
リクエストの本文(JSON):
{ "sqlNetworkArchitecture": "NETWORK_ARCHITECTURE_TYPE" }
リクエストを送信するには、次のいずれかのオプションを開きます。
次のような JSON レスポンスが返されます。
{ "kind": sql#instance, "targetLink": string, "status": enum (SqlOperationStatus), "name": string, "insertTime": string, "startTime": string, "endTime": string ... }
インスタンスのアップグレードが失敗した場合は、アップグレード オペレーションを再試行してください。
REST v1beta4
インスタンスのネットワーク アーキテクチャをアップグレードするには、Cloud SQL Admin API の instance.update method
または instance.patch method
を使用します。
Cloud SQL ネットワーク アーキテクチャをアップグレードする場合、インスタンスに対する別の更新をリクエストに含めることはできません。リクエストの本文には、sqlNetworkArchitecture
を NEW_NETWORK_ARCHITECTURE
に設定した DatabaseInstance
オブジェクトのインスタンスを含めます。
アップグレードの際には、長時間実行オペレーションが開始され、次のオペレーション トークンが返されます。
operation_id
リクエストのデータを使用する前に、次のように置き換えます。
- PROJECT_ID: プロジェクト ID。
- INSTANCE_NAME: インスタンス名。
- NETWORK_ARCHITECTURE_TYPE: ネットワーク アーキテクチャ タイプは次のように定義されます。
OLD_NETWORK_ARCHITECTURE
: インスタンスは以前のネットワーク アーキテクチャを使用します。NEW_NETWORK_ARCHITECTURE
: インスタンスは新しいネットワーク アーキテクチャを使用します。
HTTP メソッドと URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME
リクエストの本文(JSON):
{ "sqlNetworkArchitecture": "NETWORK_ARCHITECTURE_TYPE" }
リクエストを送信するには、次のいずれかのオプションを開きます。
次のような JSON レスポンスが返されます。
{ "kind": sql#instance, "targetLink": string, "status": enum (SqlOperationStatus), "name": string, "insertTime": string, "startTime": string, "endTime": string ... }
なんらかの理由でインスタンスのアップグレードが失敗した場合は、アップグレード オペレーションを再試行できます。
よくある質問
このセクションでは、Cloud SQL ネットワーク アーキテクチャのアップグレードに関するよくある質問に対する回答を記載します。
- アップグレードは Cloud SQL インスタンスにどのような影響を与えますか?
- アップグレード後、すべての機能は同じように動作しますか?
- どのインスタンスが以前のネットワーク アーキテクチャを使用していますか?
- 新しい Cloud SQL インスタンスはすべて新しいネットワーク アーキテクチャ上に作成されますか?
- 1 つのコマンドでプロジェクトに含まれるすべてのインスタンスを更新できますか?
- プライマリをアップグレードすると、レプリカも自動的にアップグレードされますか?
- Cloud SQL インスタンスのネットワーク アーキテクチャがアップグレードされるという通知を受け取りました。どうすればよいですか?
- ゾーン インスタンスのネットワーク アーキテクチャをアップグレードできないのはなぜですか?
アップグレードは Cloud SQL インスタンスにどのような影響を与えますか?
ネットワーク アーキテクチャをアップグレードすると、Cloud SQL インスタンスは MAINTENANCE 状態になります。この状態のインスタンスでは、平均で最大 4 分間のダウンタイムが発生します。アップグレードが完了するまで、インスタンスに対する追加の変更は許可されません。プロジェクトまたはネットワーク内の他のインスタンスはアップグレードの影響を受けません。
アップグレード後、すべての機能は同じように動作しますか?
新しいアーキテクチャでは、Cloud SQL インスタンスのすべての機能が古いアーキテクチャと同じように動作します。新しいネットワーク アーキテクチャを使用するようにインスタンスをアップグレードした後、そのインスタンスのネットワークを切り替える場合は、宛先ネットワーク内のすべてのインスタンスも新しいネットワーク アーキテクチャにアップグレードされていることを確認してください。
どのインスタンスが以前のネットワーク アーキテクチャを使用していますか?
2021 年 8 月以降に作成された新しいプロジェクトでは、新しいネットワーク アーキテクチャが自動的に使用されます。既存のプロジェクトでは、2 年以上経過した Cloud SQL インスタンスで以前のネットワーク アーキテクチャを使用している場合があります。したがって、そのプロジェクトの新しいインスタンスで新しいネットワーク アーキテクチャを使い始めるには、そのプロジェクト内のすべてのインスタンスをアップグレードする必要があります。
新しい Cloud SQL インスタンスはすべて新しいネットワーク アーキテクチャ上に作成されますか?
デフォルトでは、2021 年 8 月以降に作成されたプロジェクトで作成された新しい Cloud SQL インスタンスは、新しいネットワーク アーキテクチャを使用します。2021 年 8 月より前に作成されたプロジェクトでインスタンスを作成して新しいネットワーク アーキテクチャを使用する場合は、次のことを行う必要があります。
そのプロジェクトにある既存のインスタンスをすべて新しいネットワーク アーキテクチャに更新します。
Google Cloud サポート契約を結んでいる場合は、サポート リクエストを作成して、プロジェクトのデフォルト ネットワーク アーキテクチャを新しいアーキテクチャに変更します。
サポート契約を結んでいない場合は、インスタンスを作成して新しいネットワーク アーキテクチャにアップグレードします。
プロジェクトのデフォルトが変更されてから、そのプロジェクトで新しいネットワーク アーキテクチャを使用してインスタンスを作成できます。
プロジェクトのデフォルトのネットワーク アーキテクチャを変更しない場合、そのプロジェクト内の新しいインスタンスは、すべて以前のネットワーク アーキテクチャを使用します。その場合、これらのインスタンスを個別に新しいネットワーク アーキテクチャにアップグレードする必要があります。
1 つのコマンドでプロジェクトに含まれるすべてのインスタンスを更新できますか?
いいえ。新しいネットワーク アーキテクチャへのアップグレードは、各インスタンスに基づいて行われます。
プライマリをアップグレードすると、レプリカも自動的にアップグレードされますか?
いいえ。新しいネットワーク アーキテクチャへのアップグレードは、個々のインスタンスに基づいて行われます。各レプリカは個別のインスタンスとして扱われ、個別にアップグレードする必要があります。つまり、プライマリがアップグレードされ、レプリカが以前のネットワーク アーキテクチャを使用している場合、レプリカは影響を受けません。その逆も同様です。レプリカをアップグレードしても、プライマリは影響を受けません。
Cloud SQL インスタンスのネットワーク アーキテクチャがアップグレードされるという通知を受け取りました。どうすればよいですか?
お客様による対応は必要ありません。
インスタンスによっては、プライベート ネットワークで自動アップグレードが実行されるときに、リクエストが一時的に拒否されるものがあります。回避策として、1 つの Cloud SQL インスタンスのネットワーク アーキテクチャをアップグレードするの手順に沿って、インスタンスのネットワーク アーキテクチャを自分でアップグレードしてください。
ゾーン インスタンスのネットワーク アーキテクチャをアップグレードできないのはなぜですか?
インスタンス構成でゾーンの可用性が有効になっており、最後の定期メンテナンス イベントがスキップされている場合は、新しいネットワーク アーキテクチャへのアップグレードがインスタンスでサポートされていない可能性があります。この問題を回避するには、インスタンスで高可用性を有効にして、ネットワーク アーキテクチャをアップグレードします。アップグレードが完了したら、インスタンス構成をゾーンの可用性に戻してください。
次のステップ
- Private Service Connect の詳細を確認する
- Assured Workloads の詳細を確認する
- Cloud SQL 用にプライベート サービス アクセスを構成するの詳細を確認する
- AlloyDB for PostgreSQL へのデータベース移行サービスの詳細を確認する