ブルー/グリーンデプロイを使用してシングルAZ構成のRDS for MariaDBをアップグレードする
2025.01.31こんにちは、なおにしです。
MariaDB 10.4 のサポート終了(2025年2月28日)に伴い、標題について検討する機会がありましたのでご紹介します。
はじめに
RDSを利用する場合はマルチAZ構成にすることが可用性等の観点から推奨されますが、主にコスト抑制のためにシングルAZ構成で稼働している環境も少なくないかと思います。そんな中、元々はスモールスタートの想定で停止も柔軟に実施できるはずだったものが、気付けば中々停止を許されないような状況になることもあるかもしれません。
突発的な障害に伴う停止はやむおえないですが、計画的に停止する必要がある対応の一つがDBのバージョンアップ対応だと思います。
オンプレかつクローズドな環境であれば、稼働しているDBバージョンのサポートが切れてもそのまま継続利用ということも可能ですが、AWSのマネージドサービスであるRDSを使用している場合はそういうわけにもいかず、バージョンアップに追随する必要があります。
例えば、今回対象とするAmazon RDS for MariaDB 10.4 は、2025年2月28日に標準サポートが終了となります。
実際に当該バージョンのMariaDBを利用されている環境では、メールやAWS Health Dashboardで通知が来ているかと思います。
文面をそのまま転載することは避けますが、2025年2月28日以降に当該バージョンのRDS for MariaDBがどうなるのかというと、2025年3月28日までの定期メンテナンスウィンドウ中に、MariaDB 10.11.8 以降に自動的にアップグレードされるようです。
また、それでもアップグレードを先送りにしていた場合は、2025年3月28日以降に定期メンテナンスウィンドウに関係なくバージョン 10.11.8 以降にアップグレードされるということで、バージョン 10.4を継続利用することはできません。
このため、特に何もせずにいた場合は、意図せず(もちろんAWSとしては告知済みですが)DBの再起動が発生してしまうので、それまでに計画的にバージョンアップを適用する方が良いかと思います。
そこでダウンタイムを最小限に抑えるために推奨されている方法が標題のとおりブルー/グリーンデプロイになりますので、実際にシングルAZ構成のRDS for MariaDBで検証してみました。
やってみた
対象バージョンについて
今回アップグレードを試したRDS for MariaDBのバージョンは「10.4.32」です。バージョンアップを計画する際はよくアップデートパスをまずは確認するかと思いますが、確認方法はドキュメントに記載されています。
実際にAWS CLIで確認した結果は以下のとおりです。
$ aws rds describe-db-engine-versions \
--engine mariadb \
--engine-version 10.4.32 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text | grep 10.11
10.11.4
10.11.5
10.11.6
10.11.7
10.11.8
10.11.9
10.11.10
今回はHealth Dashboardに記載されていたバージョン「10.11.10」をターゲットにしますので、問題なさそうです。
ちなみに、「10.4.32」から「10.11.10」へのアップグレードはメジャーバージョンアップになります。こちらの定義もドキュメントに記載されているとおりです。
メジャーバージョン番号は、10.11 など、バージョン番号の整数部分と 1 つ目の小数部分の両方です。
続いてどのマイナーバージョンを選択すべきかですが、期待する機能が含まれているどうかだけではなく、先ほどのドキュメントに記載されているとおりサポート期間も判断材料になります。例えば執筆時点ではバージョン「10.11」については以下のとおりです。
| MariaDB engine version | Community release date | RDS release date | RDS end of standard support date |
|---|---|---|---|
| 10.11.10 | 1 November 2024 | 20 December 2024 | March 2026 |
| 10.11.9 | 8 August 2024 | 4 September 2024 | March 2026 |
| 10.11.8 | 16 May 2024 | 14 June 2024 | September 2025 |
| 10.11.7 | 7 February 2024 | 26 February 2024 | March 2025 |
| 10.11.6 | 13 November 2023 | 12 December 2023 | March 2025 |
| 10.11.5 | 14 August 2023 | 7 September 2023 | March 2025 |
| 10.11.4 | 7 June 2023 | 21 August 2023 | March 2025 |
上記のとおりサポート期間が最も長く、新しいバージョンであるため、今回は「10.11.10」をターゲットにしています。なお、メジャーバージョンとマイナーバージョンでそれぞれサポート期間が記載されていますので併せてご確認ください。
パラメータグループについて
RDSに紐づくパラメータグループはDBバージョンごとに異なるため、個別に各パラメータをチューニングしていた場合は、アップグレード後も対象のパラメータが使用できるか、存在しているかなどを事前に確認する必要があります。ドキュメントには以下のように記載されています。
カスタムパラメータグループを使用しており、メジャーバージョンアップグレードを実行する場合には、新しい DB エンジンバージョンのデフォルトのパラメータグループを指定するか、新しい DB エンジンバージョンの独自のカスタムパラメータグループを作成する必要があります。新しいパラメータグループを DB インスタンスと関連付けるには、アップグレードの完了後に、顧客主導型のデータベースの再起動が必要となります。
例えば、今回では以下のように名前が変わっているパラメータがありました。
-
long_query_time
-
https://mariadb.com/kb/en/server-system-variables/#long_query_time
-
From MariaDB 10.11.0, this is an alias for log_slow_query_time.
-
log_slow_query_timeに名称変更
-
-
slow_query_log
-
https://mariadb.com/kb/en/server-system-variables/#slow_query_log
-
From MariaDB 10.11.0, an alias for log_slow_query.
-
log_slow_queryに名称変更
-
グリーン(移行先)環境の作成
以下のドキュメントに基づいて検証します。RDSのブルー/グリーンデプロイ自体の概要についてはこちらもご参照ください。
目的のバージョンを指定してグリーン環境を作成しようとすると早速エラーが発生しました。
ドキュメントによると以下のとおりなので、まずはバージョン「10.4.34(10.4での最後のマイナーバージョン)」でグリーン環境を作成することにします。
RDS Blue/Green デプロイメントは、メジャー バージョン アップグレードのデフォルト オプション グループのみをサポートします。ブルー/グリーン展開を作成するときは、メジャー バージョンのアップグレードを指定しないでください。ブルー/グリーン展開を作成した後、グリーン環境でデータベースをアップグレードできます。
グリーン環境の作成中は以下のように表示されます。ブルー(移行元)環境も変更中ステータスになって若干不安になりましたが、もちろん読み書き可能な状態でした。
今回の検証ではおおよそ「30分」で作成完了となりました。小さくて見づらいかもしれませんがイベント履歴は以下のとおりです。環境の作成前後で自動スナップショットが作成されています。
作成が完了した状態は以下のとおりです。
ブルー環境とグリーン環境を比較するような表示で見やすく、以下のような注意表示もあってありがたいです。
一部のグリーン環境設定は、ブルー環境設定とは異なります。
Blue インスタンスエンジンバージョン は 10.4.32 で、Green インスタンスエンジンバージョン は 10.4.34 です。
エンドポイント名はそれぞれ以下のとおりでした。サーバ内で指定する際も「green」という文字が入っている方がグリーン環境だという感じで分かりやすいです。
- ブルー：naonishi-dev-rds-mariadb.cxqwk26gardn.ap-northeast-1.rds.amazonaws.com
- グリーン：naonishi-dev-rds-mariadb-green-qyhnos.cxqwk26gardn.ap-northeast-1.rds.amazonaws.com
今回は非常に簡易的ですが以下のようなクエリを使用しながらデータの同期状況を確認しました。
CREATE DATABASE IF NOT EXISTS test_db;
USE test_db
CREATE TABLE IF NOT EXISTS users (
id INT AUTO_INCREMENT PRIMARY KEY,
username VARCHAR(50) NOT NULL UNIQUE,
email VARCHAR(100) NOT NULL UNIQUE,
password_hash VARCHAR(255) NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE IF NOT EXISTS posts (
id INT AUTO_INCREMENT PRIMARY KEY,
user_id INT NOT NULL,
title VARCHAR(255) NOT NULL,
content TEXT NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
);
INSERT INTO users (username, email, password_hash) VALUES ('naonishi', '[email protected]', 'hashedpassword1');
INSERT INTO posts (user_id, title, content) VALUES (1, 'naonishiの投稿', 'テスト');
SELECT * FROM posts;
スキーマとテーブル作成は出力結果は割愛しますが、グリーン環境の作成中にブルー環境で以下のようにインサート操作を行いました。
[root@ip-172-30-30-101 ~]# mysql -u admin -p -h naonishi-dev-rds-mariadb.cxqwk26gardn.ap-northeast-1.rds.amazonaws.com
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 14
Server version: 10.4.32-MariaDB-log Source distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
（略）
MariaDB [test_db]> INSERT INTO posts (user_id, title, content) VALUES (1, 'naonishiの投稿', 'B/G環境作成中。');
Query OK, 1 row affected (0.007 sec)
MariaDB [test_db]> select * from posts;
+----+---------+----------------------------+----------------------------------------------------+---------------------+
| id | user_id | title | content | created_at |
+----+---------+----------------------------+----------------------------------------------------+---------------------+
| 1 | 1 | naonishiの投稿 | B/G環境作成中。 | 2025-01-14 11:06:55 |
+----+---------+----------------------------+----------------------------------------------------+---------------------+
1 rows in set (0.000 sec)
MariaDB [test_db]> INSERT INTO posts (user_id, title, content) VALUES (1, 'naonishiの投稿', 'B/G環境作成中。');
Query OK, 1 row affected (0.006 sec)
MariaDB [test_db]> select * from posts;
+----+---------+----------------------------+----------------------------------------------------+---------------------+
| id | user_id | title | content | created_at |
+----+---------+----------------------------+----------------------------------------------------+---------------------+
| 1 | 1 | naonishiの投稿 | B/G環境作成中。 | 2025-01-14 11:06:55 |
| 2 | 1 | naonishiの投稿 | B/G環境作成中。 | 2025-01-14 11:19:26 |
+----+---------+----------------------------+----------------------------------------------------+---------------------+
2 rows in set (0.001 sec)
MariaDB [test_db]> INSERT INTO posts (user_id, title, content) VALUES (1, 'naonishiの投稿', 'B/G環境作成中。');
Query OK, 1 row affected (0.007 sec)
MariaDB [test_db]> select * from posts;
+----+---------+----------------------------+----------------------------------------------------+---------------------+
| id | user_id | title | content | created_at |
+----+---------+----------------------------+----------------------------------------------------+---------------------+
| 1 | 1 | naonishiの投稿 | B/G環境作成中。 | 2025-01-14 11:06:55 |
| 2 | 1 | naonishiの投稿 | B/G環境作成中。 | 2025-01-14 11:19:26 |
| 3 | 1 | naonishiの投稿 | B/G環境作成中。 | 2025-01-14 11:28:19 |
+----+---------+----------------------------+----------------------------------------------------+---------------------+
3 rows in set (0.000 sec)
MariaDB [test_db]> INSERT INTO posts (user_id, title, content) VALUES (1, 'naonishiの投稿', 'B/G環境作成完了。');
Query OK, 1 row affected (0.007 sec)
MariaDB [test_db]> select * from posts;
+----+---------+----------------------------+----------------------------------------------------+---------------------+
| id | user_id | title | content | created_at |
+----+---------+----------------------------+----------------------------------------------------+---------------------+
| 1 | 1 | naonishiの投稿 | B/G環境作成中。 | 2025-01-14 11:06:55 |
| 2 | 1 | naonishiの投稿 | B/G環境作成中。 | 2025-01-14 11:19:26 |
| 3 | 1 | naonishiの投稿 | B/G環境作成中。 | 2025-01-14 11:28:19 |
| 4 | 1 | naonishiの投稿 | B/G環境作成完了。 | 2025-01-14 11:44:24 |
+----+---------+----------------------------+----------------------------------------------------+---------------------+
4 rows in set (0.000 sec)
MariaDB [test_db]>
ブルー/グリーンデプロイの目的からすれば当然といえば当然ではあるのですが、実際にグリーン環境で同期されたデータが表示されるのを見ると、こんなに簡単に同期された環境ができてしまうのかと感動します。
[root@ip-172-30-30-101 ~]# mysql -u admin -p -h naonishi-dev-rds-mariadb-green-qyhnos.cxqwk26gardn.ap-northeast-1.rds.amazonaws.com
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 72
Server version: 10.4.34-MariaDB-log Source distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> use test_db;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
MariaDB [test_db]> select * from posts;
+----+---------+----------------------------+----------------------------------------------------+---------------------+
| id | user_id | title | content | created_at |
+----+---------+----------------------------+----------------------------------------------------+---------------------+
| 1 | 1 | naonishiの投稿 | B/G環境作成中。 | 2025-01-14 11:06:55 |
| 2 | 1 | naonishiの投稿 | B/G環境作成中。 | 2025-01-14 11:19:26 |
| 3 | 1 | naonishiの投稿 | B/G環境作成中。 | 2025-01-14 11:28:19 |
| 4 | 1 | naonishiの投稿 | B/G環境作成完了。 | 2025-01-14 11:44:24 |
+----+---------+----------------------------+----------------------------------------------------+---------------------+
4 rows in set (0.000 sec)
MariaDB [test_db]>
もちろん実際の本番ワークロードではより複雑なクエリが実行されていたり個別の設定があったりするかと思いますので、ドキュメントに記載の考慮事項やベストプラクティスをよくご確認ください。
グリーン環境のアップグレード
それではグリーン環境を選択して目的のDBエンジンバージョンを指定します。
新しいDBエンジンバージョンを指定すると、以下のようにDBパラメータグループ・オプショングループが自動的にdefaultに変更されます。このため、事前にカスタムパラメータグループと必要に応じてカスタムオプショングループを作成しておく必要があります。
グリーン環境なので「すぐに適用」を選択します。
以下のようにすぐにアップグレードが開始されます。
今回の検証ではおおよそ「10分」ほどでアップグレードが完了しました。イベント履歴は以下のとおりです。途中で再起動されたり、アップグレード前後でスナップショットが作成されています。
アップグレード途中・完了後のそれぞれのタイミングで先ほどと同様にブルー環境でクエリを実行していましたが、グリーン環境で問題なく同期されていました。
ブルー/グリーンの切り替え
切り替え時の注意点やベストプラクティスは以下にまとめられています。
- 両方の環境でプライマリ DB インスタンス での新しい書き込みオペレーションを停止します。
- 両方の環境で DB インスタンスへの接続を切断し、新しい接続を許可しません。
切り替え中は、両方の環境でデータベースからの書き込みが遮断されます。本稼働環境でトラフィックが最も少ない時間を特定します。アクティブな DDL など、トランザクションの実行時間が長い場合、切り替え時間が長くなり、本稼働環境のワークロードのダウンタイムが長くなる可能性があります。
上記のとおり、短時間とはいえブルー環境も利用できなくなります。また、切り替え後のブルー環境は以下のとおりRead Only になります。
RDS は、現在のリソース名に
-oldnを付加することによって、ブルー環境の DB インスタンスの名前を変更します。ここで、nは数字です。DB インスタンスは、read_onlyパラメータを0に設定しない限り、読み取り専用です。RDS は、グリーン環境の DB インスタンスを-newnと名付けます。
それでは実際に切り替えてみます。
切り替え時にはタイムアウトを設定可能です。
切り替えのタイムアウト期間は、30 秒から 3,600 秒 (1 時間) まで指定できます。切り替えに指定された期間より長くかかる場合、変更はすべてロールバックされ、どちらの環境にも変更は加えられません。デフォルトのタイムアウト期間は 300 秒 (5 分) です。
切り替わりました。今回の検証で切り替えに要した時間はおおよそ「3分」でした。
イベント履歴は以下のとおりです。なお、上記の「3分」という数字はイベント履歴上の話ですので、実際にクライアントから新しいブルー環境に接続できるようになるまではもっと短い時間となります。ブルー/グリーンデプロイの概要ドキュメントにも、以下のように明記されています。
環境をスイッチオーバーして、グリーン環境を新しい本番稼働環境に移行できます。切り替えには通常 1 分もかからず、データが失われることはなく、アプリケーションを変更する必要もありません。
エンドポイント名も変更されています。グリーン環境は新しいブルー環境となり、元々のブルー環境は古いブルー環境となります。元々のブルー環境に割り当てられていたエンドポイント名が新しいブルー環境に割り当てられるため、サーバ側ではエンドポイントの変更を行う必要がありません。
- 古いブルー：naonishi-dev-rds-mariadb-old1.cxqwk26gardn.ap-northeast-1.rds.amazonaws.com
- 新しいブルー：naonishi-dev-rds-mariadb.cxqwk26gardn.ap-northeast-1.rds.amazonaws.com
試しに古いブルー環境に接続すると前述のとおりRead Onlyになっていることが確認できました。
[root@ip-172-30-30-101 ~]# mysql -u admin -p -h naonishi-dev-rds-mariadb-old1.cxqwk26gardn.ap-northeast-1.rds.amazonaws.com
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 451
Server version: 10.4.32-MariaDB-log Source distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> SHOW VARIABLES LIKE 'read_only';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| read_only | ON |
+---------------+-------+
1 row in set (0.001 sec)
MariaDB [(none)]>
ブルー/グリーン環境の削除
微妙に怖い操作ですが、ドキュメントにも以下のとおりきちんと明記されています。
ブルー/グリーンデプロイを削除しても、ブルー環境に影響はありません。
ブルー/グリーンデプロイのロールを選択してアクションから[削除]します。なお、「切り替え」はグレーアウトされているので新しいブルー環境をまたグリーン環境に戻すというようなことはできません。
削除中の表示は以下のとおりです。
イベント履歴としては以下が出力されるだけでした。
古いブルー環境のインスタンスは残ったままです。このためもし切り戻す際は、古いブルー環境のRead Onlyを解除した上でエンドポイントを変更する必要があります。
古いブルー環境のインスタンスが不要と判断できれば、必要に応じて手動スナップショットを取得した上で削除します。
まとめ
以前から機能としては知っていましたが、実際の操作イメージをつかめていなかったためまとめてみました。ブルー/グリーンデプロイを使用すれば、計画した日時に短いダウンタイムでDBをアップグレード可能です。MariaDB 10.4についてはサポート期限までは残り少ないため、今から突貫でアップグレードを計画するのは難しいかもしれませんが、今後も短いダウンタイムでのアップグレード等の操作が必要になった際には活用したい機能でした。
本記事がどなたかのお役に立てれば幸いです。
![[アップデート] Amazon RDSに専用ログボリューム機能が追加されました](https://devio2023-media.developers.io/wp-content/uploads/2023/08/amazon-rds.png)
