MySQL 環境を柔軟にスケーリング

このチュートリアルでは、高可用性 MySQL データベースクラスタデプロイメント（プライマリデータベースとレプリカデータベース）の垂直スケーリング（スケールアップとスケールダウン）について説明します。このプロセスには、Compute Engine インスタンスのスケールアップとスケールダウンのほかに、ディスクのスケールアップも含まれます。

一般に、ディスク容量のスケールアップは、管理対象のデータの増加に対応するために行われます。

MySQL を実行する Compute Engine インスタンスを垂直方向にスケーリングする理由はいくつかあります。スケールアップする理由の一部（および、スケールダウンする場合は反対の理由）を次に示します。

システムが、書き込み / 読み取りスループットパフォーマンスの上限に達している。CPU とメモリの数を増やすと、ハードウェア容量が増えます。
時間の経過に伴ってクエリの数が増えるか、クエリ数の急増が予測される（ブラックフライデーやサイバーマンデー中など）。CPU とメモリの数を増やすと、予約が行われます。
システムにさらにクライアントが追加されたことなどにより、クエリの同時実行数が増える。CPU とメモリの数を増やすと、より高いレベルの同時実行がサポートされます。
Google Cloud で、Compute Engine インスタンスのリストに「パフォーマンス向上」の推奨事項が表示される場合がある。この推奨は、Compute Engine インスタンスをスケールアップするかどうかを再検討する場合に重要です。

このチュートリアルは、次の役割の方に役立ちます。

スケーラビリティを得るために MySQL クラスタのデプロイを計画しているクラウドアーキテクト
MySQL クラスタを使用してアプリケーションを実装するクラウドエンジニア
MySQL クラスタを管理しているクラウド運用チーム
MySQL クラスタでデータベースを管理し、垂直スケーリングプロセスを実行（または時間の経過に伴って複数のプロセスを実行）する必要がある IT 管理者とデータベース管理者

アーキテクチャ

次の図は、可用性の高い MySQL クラスタの全体的なアーキテクチャを示しています。このチュートリアルでは、このアーキテクチャをベースにして、垂直スケーリングプロセスを説明します。

プライマリデータベースとレプリカデータベースにデプロイされた MySQL クライアントインスタンスを示す垂直スケーリングプロセスのアーキテクチャ。

このチュートリアルは、次の内容を理解していることを前提としています。

Deployment Manager と、Cloud Shell や mysql などの各種コマンドラインツールを使用した MySQL クラスタの設定と実行。
Compute Engine インスタンスの管理オペレーション。
Compute Engine のディスク管理オペレーション。

目標

プライマリデータベースとレプリカデータベースを使用して MySQL クラスタを設定します。
マシンタイプを変更して、MySQL クラスタのすべての Compute Engine インスタンス（メモリと CPU）を垂直方向にスケールアップします。
マシンタイプを変更して、MySQL クラスタのすべての Compute Engine インスタンス（メモリと CPU）を垂直方向にスケールダウンします。
Compute Engine インスタンスのディスクサイズを増やします。

費用

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

始める前に

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

Google Cloud Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

プロジェクトセレクタに移動

Google Cloud プロジェクトで課金が有効になっていることを確認します。

Compute Engine and Cloud Storage API を有効にします。

API を有効にする

Google Cloud CLI をインストールします。

gcloud CLI を初期化するには:

gcloud init

Google Cloud Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

プロジェクトセレクタに移動

Google Cloud プロジェクトで課金が有効になっていることを確認します。

Compute Engine and Cloud Storage API を有効にします。

API を有効にする

Google Cloud CLI をインストールします。

gcloud CLI を初期化するには:

gcloud init

MySQL クラスタの設定

最初のステップは、動作する MySQL クラスタを作成することです。このクラスタには、説明と検証に使用するデータを入力します。データの検証については、MySQL プライマリデータベースとレプリカデータベースにクエリを実行する手順がチュートリアルで説明されています。

MySQL クラスタを設定するための以下の手順は、関連チュートリアルである HAProxy を使用して MySQL クラスタを Compute Engine に移行するから引用したものです（便宜上、細かな変更が加えられています）。

Google Cloud コンソールで Cloud Shell を開きます。

Cloud Shell を開く
Cloud Storage バケット名を表す環境変数を設定します。
```
GCS_BUCKET_NAME=${USER}-mysql-$(date +%s)
echo $GCS_BUCKET_NAME
```
Cloud Storage バケットを作成します（デフォルトではマルチリージョン）。
```
gsutil mb gs://${GCS_BUCKET_NAME}/
```
バケットには、MySQL プライマリとレプリカ作成の両方に使用される作成スクリプトと起動スクリプトが格納されます。
GitHub リポジトリのクローンを作成し、環境の設定に使用するスクリプトを取得します。
```
git clone https://github.com/GoogleCloudPlatform/solutions-compute-mysql-migration-haproxy.git mysql-migration
```
mysql-migration フォルダから初期化スクリプトを実行して、プライマリとレプリカの Compute Engine インスタンスの MySQL クラスタを作成します。
```
cd mysql-migration
./run.sh ${DEVSHELL_PROJECT_ID} ${GCS_BUCKET_NAME}
```
このスクリプトでは、MySQL クライアントの Compute Engine インスタンスも作成されます。
クライアントインスタンスからプライマリインスタンスへのリモートルートアクセスを有効にします。
1. Google Cloud コンソールで [**VM インスタンス] ページに移動します。
  
  [VM インスタンス] に移動
2. source-mysql-primary インスタンスの行で、[SSH] をクリックしてセキュアシェルに接続します。
3. セキュアシェルが使用可能になったら、次のコマンドを実行します。
```
mysql -u root -psolution-admin
```
4. mysql にログインしたら、次のステートメントを発行します。
```
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'solution-admin';
```
データベースがクライアントからアクセス可能であることを確認します。Google Cloud コンソールで ssh を使用して mysql-client Compute Engine インスタンスに接続します。セキュアシェルが使用可能になったら、次のようにします。
1. [Compute Engine] > [VM インスタンス] を選択し、source-mysql-primary という名前のインスタンスが含まれた行を探して、その内部 IP アドレスをメモします。
  
  IP_ADDRESS_OF_SOURCE_MYSQL_PRIMARY は、source-mysql-primary の内部 IP に置き換えます。
```
mysql -u root -psolution-admin -h IP_ADDRESS_OF_SOURCE_MYSQL_PRIMARY
```
2. mysql シェルが使用可能になったら、次のコマンドを実行します。
```
SHOW databases; # source_db must be present
USE source_db;
SHOW tables; # source_table must be present
SELECT COUNT(*) FROM source_table; # must return 5000
```
  同じコマンドセットを使用して、レプリカに同じデータセットが含まれていることを確認できます。代わりに source-mysql-replica の内部 IP アドレスを使用します。

この時点で、3 つの Compute Engine インスタンスが実行されています。

クライアント（mysql-client）。
MySQL プライマリ（source-mysql-primary）。
MySQL レプリカ（source-mysql-replica）。MySQL プライマリは MySQL レプリカにレプリケーションされます。

各 Compute Engine インスタンスのマシンタイプは f1-micro（1 vCPU、0.6 GB メモリ）であり、スケールアップはマシンタイプ n1-standard-1（1 vCPU、3.75 GB メモリ）まで行われます。ディスクのサイズは 10 GB であり、2 倍の 20 GB になります。これらの選択は一例にすぎず、デプロイメントの特定のニーズに応じて変更できます。

Compute Engine インスタンスを垂直方向にスケールアップする（フェイルオーバーなし）

このセクションでは、MySQL プライマリとレプリカを実行する Compute Engine インスタンスをスケールアップする方法について説明します。Compute Engine インスタンスのマシンタイプを変更して、CPU とメモリを同時にスケールアップします。マシンタイプを変更するには、Compute Engine インスタンスを停止し、変更後に再起動する必要があります。

同じ処理能力を確実に得るために、両方の Compute Engine インスタンスで同じマシンタイプを使用することをおすすめします。

MySQL レプリカが最初にスケールアップされます。問題が見つかっても、MySQL プライマリの実行が中断されることはありません。問題が発生した場合は、プライマリ側のダウンタイムなしで解決できます。さらに、プライマリデータベースをスケールアップする前に、問題が一時的または疑似であるか、一般的な問題かを判断できます。

別の方法（その場合でも、Compute Engine インスタンスの再起動が必要）では、ダウンタイムを最小限に抑えるためにプライマリからセカンダリにフェイルオーバーします。この方法については、以降のセクションで説明します。

MySQL レプリカをスケールアップする

まず、MySQL レプリカを実行している Compute Engine インスタンスを停止します。

Google Cloud コンソールで [VM インスタンス] ページに移動し、Compute Engine インスタンスのリストを表示します。

コンピューティングインスタンスをリストする
source-mysql-replica インスタンスの行で、（その他の操作）をクリックし、次に [停止] をクリックします。
Compute Engine インスタンスが停止したら、source-mysql-replica をクリックし、 [編集] をクリックします。
[マシンタイプ] で、スケールアップ先のマシンタイプ n1-standard-1（1 vCPU、3.75 GB メモリ）を選択します。
[保存] をクリックします。
保存が完了したら、 [開始 / 再開] をクリックします。

前述の検証用の mysql コマンドを使用して、スケーリングオペレーションの後に MySQL レプリカが再稼働しているかどうかをテストできます。

MySQL プライマリをスケールアップする

まず、MySQL プライマリを実行している Compute Engine インスタンスを停止します。

Google Cloud コンソールで [VM インスタンス] ページに移動し、Compute Engine インスタンスのリストを表示します。

コンピューティングインスタンスをリストする
source-mysql-primary インスタンスの行で、（その他の操作）をクリックし、次に [停止] をクリックします。
Compute Engine インスタンスが停止したら、source-mysql-primary をクリックし、 [編集] をクリックします。
[マシンタイプ] で、スケールアップ先のマシンタイプ n1-standard-1（1 vCPU、3.75 GB メモリ）を選択します。このマシンタイプが MySQL レプリカ用に選択されているものと同じであることを確認します。
[保存] をクリックします。
保存が完了したら、 [開始 / 再開] をクリックします。

前述の検証用の mysql コマンドを使用して、スケーリングオペレーションの後に MySQL プライマリが再稼働しているかどうかをテストできます。

Compute Engine インスタンスを垂直方向にスケールダウンする（フェイルオーバーなし）

このセクションでは、MySQL プライマリとレプリカを実行する Compute Engine インスタンスをスケールダウンする方法について説明します。Compute Engine インスタンスのマシンタイプを変更して、CPU とメモリを同時にスケールダウンします。マシンタイプを変更するには、Compute Engine インスタンスを停止し、変更後に再起動する必要があります。

同じ処理能力を確実に得るために、両方の Compute Engine インスタンスで同じマシンタイプを使用することをおすすめします。この手順は、スケールアップの手順と似ています。ただし、完全を期すために、次のセクションで明確に説明します。

MySQL レプリカをスケールダウンする

まず、MySQL レプリカを実行している Compute Engine インスタンスを停止します。

Google Cloud コンソールで [VM インスタンス] ページに移動し、Compute Engine インスタンスのリストを表示します。

コンピューティングインスタンスをリストする
source-mysql-replica インスタンスの行で、（その他の操作）をクリックし、次に [停止] をクリックします。
Compute Engine インスタンスが停止したら、source-mysql-replica をクリックし、 [編集] をクリックします。
[マシンタイプ] で、スケールダウン先のマシンタイプ f1-micro（1 vCPU、0.6 GB メモリ）を選択します。
[保存] をクリックします。
保存が完了したら、 [開始 / 再開] をクリックします。

前述の検証用の mysql コマンドを使用して、スケーリングオペレーションの後に MySQL レプリカが再稼働しているかどうかをテストできます。

MySQL プライマリをスケールダウンする

まず、MySQL プライマリを実行している Compute Engine インスタンスを停止します。

Google Cloud コンソールで [VM インスタンス] ページに移動し、Compute Engine インスタンスのリストを表示します。

コンピューティングインスタンスをリストする
source-mysql-primary インスタンスの行で、（その他の操作）をクリックし、次に [停止] をクリックします。
Compute Engine インスタンスが停止したら、source-mysql-primary をクリックし、 [編集] をクリックします。
[マシンタイプ] で、スケールダウン先のマシンタイプ f1-micro（1 vCPU、0.6 GB メモリ）を選択します。このマシンタイプが MySQL レプリカ用に選択したものと同じであることを確認してください。
[保存] をクリックします。
保存が完了したら、 [開始 / 再開] をクリックします。

前述の検証用の mysql コマンドを使用して、スケーリングオペレーションの後に MySQL プライマリが再稼働しているかどうかをテストできます。

Compute Engine インスタンスを垂直方向にスケールアップする（フェイルオーバーあり）

MySQL データベースのシャットダウン、スケールアップ、再起動に要する時間は、本番環境にとって長すぎる場合があります。処理の高速化はフェイルオーバーに基づいて行われます。まず、レプリカをスケールアップし、再起動した直後に既存のプライマリを停止すると、そのレプリカが（新しい）プライマリになります。全体としてのダウンタイムは、MySQL データベースをスケールアップレプリカにフェイルオーバーするのに必要な時間です。

大まかな手順は次のとおりです。

レプリカをスケールアップします。レプリカを停止し、マシンタイプを変更してから再起動します。
レプリカのスケールアップ中にプライマリで行われた変更がレプリカで反映されるまで待ちます。
プライマリを停止します。
レプリカがレプリケーションログをドレインするのを待ちます。
レプリカを新しいプライマリにします。
プライマリ（新しいレプリカ）を停止します。
新しいレプリカをスケールアップします。
それを新しいプライマリの新しいレプリカにします。

この処理が完了すると、両方の MySQL システムがスケールアップされ、プライマリとレプリカの関係になります。元のプライマリは新しいレプリカになり、以前のレプリカは新しいプライマリになります。コマンドについては、以降のセクションで詳しく説明します。

プライマリとレプリカの両方が同じマシンタイプであり、ディスクのタイプとディスク容量も同じであるため、通常、フォールバックは必ずしも必要ありません。フォールバックを行うと、フォールバック中に短時間の停止が生じます。ただし、フォールバックが必要な場合は、フェイルオーバー手順をもう一度実行する必要があります。

既存の MySQL レプリカをスケールアップする

MySQL レプリカをスケールアップするで概説されているように、レプリカをスケールアップします。この期間中、プライマリは中断されずに使用できます。

プライマリからスケールアップしたレプリカへのフェイルオーバー

次のコマンドは、プライマリからレプリカへのフェイルオーバーを実行します。

Cloud Shell でプライマリを停止し、それ以上の更新が受信されないようにします。
```
gcloud compute instances stop source-mysql-primary --zone=us-east1-b;
```
次の手順に進むために、プライマリが停止するまで待つ必要はありません。
Google Cloud コンソールで、[VM インスタンス] ページに移動します。

[VM インスタンス] に移動
source-mysql-replica インスタンスの行で [SSH] をクリックしてインスタンスに接続します。
セキュアシェルが使用可能になったら、mysql シェルを起動します。
```
mysql -u root -psolution-admin
```
レプリカでバイナリログが有効になっているかどうかを確認します（ON である必要があります）。
```
SHOW VARIABLES LIKE 'log_bin';
```
ログレプリカの更新が無効になっているかどうかを確認します（OFF である必要があります）。
```
SHOW VARIABLES LIKE 'log_slave%';
```
リレーログをドレインします。
```
STOP SLAVE IO_THREAD;
```
すべての処理が行われたことを確認します。
```
SHOW PROCESSLIST;
```
このコマンドの出力で、Slave has read all relay log が表示されている必要があります。その結果が表示されるまでコマンドを実行し続けます。
レプリカを停止します。
```
STOP SLAVE;
```

レプリカの役割をプライマリに変更します。

RESET MASTER;
GRANT REPLICATION SLAVE ON *.* TO 'sourcereplicator'@'%' IDENTIFIED BY 'solution-admin';

これで、新しいプライマリが設定されました。

新しい MySQL レプリカをスケールアップする

この時点で以前のレプリカはプライマリになり、クライアントはそれにアクセスして読み取りと書き込みの操作を行えます。

前述の手順に従ってレプリカ（以前のプライマリ）をスケールアップしてから、レプリカを起動します。

レプリカをプライマリに接続してレプリケーションする

Google Cloud コンソールで、[VM インスタンス] ページに移動します。

[VM インスタンス] に移動
source-mysql-primary インスタンスの行で、[SSH] をクリックしてセキュアシェルに接続します。
セキュアシェルが使用可能になったら、mysql シェルを起動します。
```
mysql -u root -psolution-admin
```

レプリケーションを開始します。

CHANGE MASTER TO MASTER_HOST='source-mysql-replica', master_user='sourcereplicator',master_password='solution-admin';
RESET SLAVE;
START SLAVE;

プライマリ MySQL インスタンスがレプリカに複製されます。

プライマリからレプリカへのレプリケーションをテストする

次のテストでは、プライマリ MySQL インスタンス source-mysql-replica のテーブル source_table に行を追加します。レプリカの MySQL インスタンス source-mysql-primary で追加を確認できます。

source-mysql-replica インスタンスで、新しいプライマリに行を追加します。以前に行が追加されていない場合は、カウントに 5001 が表示されます。
```
USE source_db;
INSERT INTO source_table (event_data) VALUES (ROUND(RAND()*15000,2));
SELECT count(*) FROM source_table;
```
レプリカでレプリケーションを監視します。カウントには 5001 が表示されている必要があります。
```
USE source_db;
SELECT count(*) FROM source_table;
```

これで、フェイルオーバープロセスに必要な手順は終了です。スケールダウンする場合もフェイルオーバーと同じ手順を使用します。

Compute Engine インスタンスのディスクサイズを増やす

このセクションでは、MySQL プライマリをホストする Compute Engine インスタンスと MySQL レプリカをホストする Compute Engine インスタンスの両方の Compute Engine インスタンスディスクのサイズを増やす方法について説明します。ディスクのサイズを大きくすることはできますが、小さくすることはできません。

ディスクをスケールアップするには、次の 2 つの方法があります。両方の方法について、以降のセクションで概説します。ディスクを動的にサイズ変更する機能では、Compute Engine インスタンスを再作成する必要はありません。詳しくは、こちらのブログ投稿をご覧ください。1 つの方法として、Compute Engine インスタンスを停止し、ディスクサイズを増やしてから、再起動する方法があります。インスタンスを再起動すると、MySQL データファイルを格納するルートパーティションのサイズが自動的に変更されます。

もう一つの方法では、Compute Engine インスタンスを停止して再起動する必要はありません。代わりに、Cloud Shell とインスタンスのセキュアシェルでコマンドラインステートメントを実行する必要があります。

確認のために、ディスクサイズを増やす前後にコマンド df -h --total を使用して、前後のサイズを確認できます。

ディスクのサイズを変更する前に、各ディスクのスナップショットを作成することをおすすめします。これにより、サイズ変更前の状態に基づいて、各ディスクの状態を復活させることができます。

MySQL レプリカのディスクサイズを増やす（シャットダウンあり）

まず、MySQL レプリカをホストしている Compute Engine インスタンスのディスクのサイズを増やします。

Google Cloud コンソールで [VM インスタンス] ページに移動し、Compute Engine インスタンスのリストを表示します。

コンピューティングインスタンスをリストする
source-mysql-replica インスタンスの行で、（その他の操作）をクリックし、次に [停止] をクリックします。
Compute Engine インスタンスのディスクをリストします。

インスタンスのディスクをリストする
[source-mysql-replica] を選択します。
[編集] をクリックします。
[サイズ] で、サイズを 20 GB に増やします。
[保存] をクリックし、保存操作が完了するまで待ちます。
Compute Engine インスタンスをリストします。

コンピューティングインスタンスをリストする
source-mysql-replica インスタンスの行で、（その他の操作）をクリックし、次に [開始] をクリックします。

前述の検証用の mysql コマンドを使用して、ディスクサイズの増加後に MySQL プライマリが期待どおりに稼働しているかをテストできます。

MySQL プライマリのディスクサイズを増やす（シャットダウンあり）

MySQL プライマリをホストしている Compute Engine のディスクのサイズを増やします。

Google Cloud コンソールで [VM インスタンス] ページに移動し、Compute Engine インスタンスのリストを表示します。

コンピューティングインスタンスをリストする
source-mysql-primary インスタンスの行で、（その他の操作）をクリックし、次に [停止] をクリックします。
Compute Engine インスタンスのディスクをリストします。

インスタンスのディスクをリストする
[source-mysql-primary] を選択します。
[編集] をクリックします。
[サイズ] で、サイズを 20 GB に増やします。
[保存] をクリックし、保存操作が完了するまで待ちます。
Compute Engine インスタンスをリストします。

コンピューティングインスタンスをリストする
source-mysql-primary インスタンスの行で、（その他の操作）をクリックし、次に [開始] をクリックします。

前述の検証用の mysql コマンドを使用して、ディスクサイズの増加後に MySQL プライマリが期待どおりに稼働しているかをテストできます。

MySQL レプリカのディスクサイズを増やす（シャットダウンなしで動的）

次の手順は、ファイルシステム ext4 の動的ディスクサイズの増加と、単一のパーティションでのボリュームを示しています。他のファイルシステムタイプやパーティション構成では、増加に対応するために別の手順が必要になります。

前述のように、まず、レプリカをホストしている Compute Engine インスタンスのディスクサイズを増やしてから、プライマリをホストしている Compute Engine インスタンスのディスクサイズを増やします。

Google Cloud コンソールで [VM インスタンス] ページに移動し、Compute Engine インスタンスのリストを表示します。

コンピューティングインスタンスをリストする
[SSH] をクリックして source-mysql-replica インスタンスに接続します。
セキュアシェルでディスクとそのパーティショニングを確認し、ディスク sda に 1 つのパーティション sda1 があることを確認します。
```
lsblk
```
Cloud Shell で次のコマンドを実行して、ディスクサイズを増やします。プロンプトが表示されたら、y で応答します。
```
gcloud compute disks resize source-mysql-replica --size=20G --zone=us-east1-c
```
セキュアシェルで、ディスクサイズが増加したことを確認します。
```
lsblk
```
なお、パーティションのサイズはまだ 10 GB です。
セキュアシェルで、次のコマンドを実行して、ファイルシステムと、それらのタイプおよびサイズを確認します。
```
df -Th
```
セキュアシェルでパーティションを拡張します。
```
sudo growpart /dev/sda 1
sudo resize2fs /dev/sda1
lsblk
df -Th
```
最後の 2 つのコマンドで増加を確認できます。

MySQL プライマリのディスクサイズを増やす（シャットダウンなしで動的）

プライマリのディスクサイズを動的に増やす方法は、レプリカの場合と同じです。

Google Cloud コンソールで [VM インスタンス] ページに移動し、Compute Engine インスタンスのリストを表示します。

コンピューティングインスタンスをリストする
[SSH] をクリックして source-mysql-primary インスタンスに接続します。
セキュアシェルでディスクとそのパーティショニングを確認し、ディスク sda に 1 つのパーティション sda1 があることを確認します。
```
lsblk
```
Cloud Shell で次のコマンドを実行して、ディスクサイズを増やします。プロンプトが表示されたら、y で応答します。
```
gcloud compute disks resize source-mysql-primary --size=20G --zone=us-east1-b
```
セキュアシェルで、ディスクサイズが増加したことを確認します。
```
lsblk
```
なお、パーティションのサイズはまだ 10 GB です。
セキュアシェルで、次のコマンドを実行して、ファイルシステムと、それらのタイプおよびサイズを確認します。
```
df -Th
```
セキュアシェルでパーティションを拡張します。
```
sudo growpart /dev/sda 1
sudo resize2fs /dev/sda1
lsblk
df -Th
```
最後の 2 つのコマンドで増加を確認できます。

クリーンアップ

チュートリアルが終了したら、作成したリソースをクリーンアップして、割り当ての使用を停止し、課金されないようにできます。次のセクションで、リソースを削除または無効にする方法を説明します。

プロジェクトの削除

Google Cloud コンソールで、[リソースの管理] ページに移動します。
[リソースの管理] に移動
プロジェクトリストで、削除するプロジェクトを選択し、[削除] をクリックします。
ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ

このチュートリアルで学んだことを本番環境の MySQL クラスタに適用して、スケーリングが必要な場合のプロセスとルーチンを確立できます。コンテンツを最初に実行するには、本番環境の MySQL クラスタのクローンを作成し、ドライランを実行します。本番環境での後続の垂直方向スケーリングの変更に影響を及ぼす可能性がある重要な手順をメモしておきます。

このチュートリアルに示されているステップを実行するスクリプトを開発することを検討してください。これにより、本番環境で手動でスケーリングする代わりに、自動的にスケーリングできます。

詳細については、これらの MySQL チュートリアルをご覧ください。

Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud アーキテクチャセンターをご覧ください。