このチュートリアルでは、高可用性 MySQL データベース クラスタ デプロイメント(プライマリ データベースとレプリカ データベース)の垂直スケーリング(スケールアップとスケールダウン)について説明します。このプロセスには、Compute Engine インスタンスのスケールアップとスケールダウンのほかに、ディスクのスケールアップも含まれます。
一般に、ディスク容量のスケールアップは、管理対象のデータの増加に対応するために行われます。
MySQL を実行する Compute Engine インスタンスを垂直方向にスケーリングする理由はいくつかあります。スケールアップする理由の一部(および、スケールダウンする場合は反対の理由)を次に示します。
- システムが、書き込み / 読み取りスループット パフォーマンスの上限に達している。CPU とメモリの数を増やすと、ハードウェア容量が増えます。
- 時間の経過に伴ってクエリの数が増えるか、クエリ数の急増が予測される(ブラック フライデーやサイバー マンデー中など)。CPU とメモリの数を増やすと、予約が行われます。
- システムにさらにクライアントが追加されたことなどにより、クエリの同時実行数が増える。CPU とメモリの数を増やすと、より高いレベルの同時実行がサポートされます。
- Google Cloud で、Compute Engine インスタンスのリストに「パフォーマンス向上」の推奨事項が表示される場合がある。この推奨は、Compute Engine インスタンスをスケールアップするかどうかを再検討する場合に重要です。
このチュートリアルは、次の役割の方に役立ちます。
- スケーラビリティを得るために MySQL クラスタのデプロイを計画しているクラウドアーキテクト
- MySQL クラスタを使用してアプリケーションを実装するクラウド エンジニア
- MySQL クラスタを管理しているクラウド運用チーム
- MySQL クラスタでデータベースを管理し、垂直スケーリング プロセスを実行(または時間の経過に伴って複数のプロセスを実行)する必要がある IT 管理者とデータベース管理者
アーキテクチャ
次の図は、可用性の高い MySQL クラスタの全体的なアーキテクチャを示しています。このチュートリアルでは、このアーキテクチャをベースにして、垂直スケーリング プロセスを説明します。
このチュートリアルは、次の内容を理解していることを前提としています。
- Deployment Manager と、Cloud Shell や
mysql
などの各種コマンドライン ツールを使用した MySQL クラスタの設定と実行。 - Compute Engine インスタンスの管理オペレーション。
- Compute Engine のディスク管理オペレーション。
目標
- プライマリ データベースとレプリカ データベースを使用して MySQL クラスタを設定します。
- マシンタイプを変更して、MySQL クラスタのすべての Compute Engine インスタンス(メモリと CPU)を垂直方向にスケールアップします。
- マシンタイプを変更して、MySQL クラスタのすべての Compute Engine インスタンス(メモリと CPU)を垂直方向にスケールダウンします。
- Compute Engine インスタンスのディスクサイズを増やします。
費用
このドキュメントでは、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 プロジェクトを選択または作成します。
-
Compute Engine and Cloud Storage API を有効にします。
- Google Cloud CLI をインストールします。
-
gcloud CLI を初期化するには:
gcloud init
-
Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。
-
Compute Engine and Cloud Storage API を有効にします。
- Google Cloud CLI をインストールします。
-
gcloud CLI を初期化するには:
gcloud init
MySQL クラスタの設定
最初のステップは、動作する MySQL クラスタを作成することです。このクラスタには、説明と検証に使用するデータを入力します。データの検証については、MySQL プライマリ データベースとレプリカ データベースにクエリを実行する手順がチュートリアルで説明されています。
MySQL クラスタを設定するための以下の手順は、関連チュートリアルである HAProxy を使用して MySQL クラスタを Compute Engine に移行するから引用したものです(便宜上、細かな変更が加えられています)。
Google Cloud コンソールで 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 インスタンスも作成されます。
クライアント インスタンスからプライマリ インスタンスへのリモート ルートアクセスを有効にします。
Google Cloud コンソールで [**VM インスタンス] ページに移動します。
source-mysql-primary
インスタンスの行で、[SSH] をクリックしてセキュアシェルに接続します。セキュアシェルが使用可能になったら、次のコマンドを実行します。
mysql -u root -psolution-admin
mysql
にログインしたら、次のステートメントを発行します。GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'solution-admin';
データベースがクライアントからアクセス可能であることを確認します。Google Cloud コンソールで ssh を使用して
mysql-client
Compute Engine インスタンスに接続します。セキュアシェルが使用可能になったら、次のようにします。[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
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
インスタンスの行で、more_vert(その他の操作)をクリックし、次に [停止] をクリックします。Compute Engine インスタンスが停止したら、
source-mysql-replica
をクリックし、edit [編集] をクリックします。[マシンタイプ] で、スケールアップ先のマシンタイプ
n1-standard-1
(1 vCPU、3.75 GB メモリ)を選択します。[保存] をクリックします。
保存が完了したら、play_arrow [開始 / 再開] をクリックします。
前述の検証用の mysql
コマンドを使用して、スケーリング オペレーションの後に MySQL レプリカが再稼働しているかどうかをテストできます。
MySQL プライマリをスケールアップする
まず、MySQL プライマリを実行している Compute Engine インスタンスを停止します。
Google Cloud コンソールで [VM インスタンス] ページに移動し、Compute Engine インスタンスのリストを表示します。
source-mysql-primary
インスタンスの行で、more_vert(その他の操作)をクリックし、次に [停止] をクリックします。Compute Engine インスタンスが停止したら、
source-mysql-primary
をクリックし、edit [編集] をクリックします。[マシンタイプ] で、スケールアップ先のマシンタイプ
n1-standard-1
(1 vCPU、3.75 GB メモリ)を選択します。このマシンタイプが MySQL レプリカ用に選択されているものと同じであることを確認します。[保存] をクリックします。
保存が完了したら、play_arrow [開始 / 再開] をクリックします。
前述の検証用の 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
インスタンスの行で、more_vert(その他の操作)をクリックし、次に [停止] をクリックします。Compute Engine インスタンスが停止したら、
source-mysql-replica
をクリックし、edit [編集] をクリックします。[マシンタイプ] で、スケールダウン先のマシンタイプ
f1-micro
(1 vCPU、0.6 GB メモリ)を選択します。[保存] をクリックします。
保存が完了したら、play_arrow [開始 / 再開] をクリックします。
前述の検証用の mysql
コマンドを使用して、スケーリング オペレーションの後に MySQL レプリカが再稼働しているかどうかをテストできます。
MySQL プライマリをスケールダウンする
まず、MySQL プライマリを実行している Compute Engine インスタンスを停止します。
Google Cloud コンソールで [VM インスタンス] ページに移動し、Compute Engine インスタンスのリストを表示します。
source-mysql-primary
インスタンスの行で、more_vert(その他の操作)をクリックし、次に [停止] をクリックします。Compute Engine インスタンスが停止したら、
source-mysql-primary
をクリックし、edit [編集] をクリックします。[マシンタイプ] で、スケールダウン先のマシンタイプ
f1-micro
(1 vCPU、0.6 GB メモリ)を選択します。このマシンタイプが MySQL レプリカ用に選択したものと同じであることを確認してください。[保存] をクリックします。
保存が完了したら、play_arrow [開始 / 再開] をクリックします。
前述の検証用の 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 インスタンス] ページに移動します。
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 インスタンス] ページに移動します。
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
インスタンスの行で、more_vert(その他の操作)をクリックし、次に [停止] をクリックします。Compute Engine インスタンスのディスクをリストします。
[
source-mysql-replica
] を選択します。edit [編集] をクリックします。
[サイズ] で、サイズを 20 GB に増やします。
[保存] をクリックし、保存操作が完了するまで待ちます。
Compute Engine インスタンスをリストします。
source-mysql-replica
インスタンスの行で、more_vert(その他の操作)をクリックし、次に [開始] をクリックします。
前述の検証用の mysql
コマンドを使用して、ディスクサイズの増加後に MySQL プライマリが期待どおりに稼働しているかをテストできます。
MySQL プライマリのディスクサイズを増やす(シャットダウンあり)
MySQL プライマリをホストしている Compute Engine のディスクのサイズを増やします。
Google Cloud コンソールで [VM インスタンス] ページに移動し、Compute Engine インスタンスのリストを表示します。
source-mysql-primary
インスタンスの行で、more_vert(その他の操作)をクリックし、次に [停止] をクリックします。Compute Engine インスタンスのディスクをリストします。
[
source-mysql-primary
] を選択します。edit [編集] をクリックします。
[サイズ] で、サイズを 20 GB に増やします。
[保存] をクリックし、保存操作が完了するまで待ちます。
Compute Engine インスタンスをリストします。
source-mysql-primary
インスタンスの行で、more_vert(その他の操作)をクリックし、次に [開始] をクリックします。
前述の検証用の 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 つのコマンドで増加を確認できます。
クリーンアップ
チュートリアルが終了したら、作成したリソースをクリーンアップして、割り当ての使用を停止し、課金されないようにできます。次のセクションで、リソースを削除または無効にする方法を説明します。
プロジェクトの削除
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
次のステップ
このチュートリアルで学んだことを本番環境の MySQL クラスタに適用して、スケーリングが必要な場合のプロセスとルーチンを確立できます。コンテンツを最初に実行するには、本番環境の MySQL クラスタのクローンを作成し、ドライランを実行します。本番環境での後続の垂直方向スケーリングの変更に影響を及ぼす可能性がある重要な手順をメモしておきます。
このチュートリアルに示されているステップを実行するスクリプトを開発することを検討してください。これにより、本番環境で手動でスケーリングする代わりに、自動的にスケーリングできます。
詳細については、これらの MySQL チュートリアルをご覧ください。
Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。