AWSのRDSをブルーグリーンデプロイ(blue-green)で5.7から8.0にアップグレード

MySQL5.7 で運用していた AWS の RDS。

サポートが切れ、2024 年 3 月からは強制的にアップグレードはされないものの、有償サポート期間に突入ということで、それだけは避けたいところ。

ということで、MySQL8.0 にアップグレードします。

少し前に、Aurora で MySQL5.7 から MySQL8.0 へブルーグリーンデプロイを行ったばかりだったので、その経験を活かしてブルーグリーンデプロイでやってみます。

ブルーグリーンデプロイ

AWS で 2022 年頃に登場した新しい機能。

今回のケースで言うと、MySQL8.0 の RDS を新しく作成して、MySQL5.7 の RDS からレプリケーションを行います。
(この時点で RDS は 2 台になる)

そして切り替え作業を行うとブルーとグリーンが入れ替わり、RDS のエンドポイントもそのまま新しくブルーになった RDS へ向けられます。

よって RDS に接続しているアプリは、短時間の通信断でアップグレードした MySQL が使えるというわけです。

過去に、MySQL5.6 から 5.7 へサービス無停止に近い状態で移行したことがありますが、これと同じことが簡単な操作でできるのは便利です。

Aurora クラスタ構成の場合は、少し面倒な手順が残っているものの、シンプルなパラメータグループしか使ってない RDS の場合は簡単に移行できちゃいます。

ブルーグリーンデプロイで切り替え

上記で書いた通り、ブルーグリーンで切り替えを行うと、ブルーとグリーンが入れ替わります。

ブルーだった MySQL5.7 の RDS は「古いブルー」になるのですが、「green」と書いてくれた方が入れ替わった感があるのですよね。

って、以前は「古いブルー」という表現はなかった気がするのですが、どこかで AWS 側が UI 変えたのかなって思ってます。

ブルーグリーンデプロイの削除

新しくブルーとなった MySQL8.0 へ接続も切り替わっているので、アプリの動作に問題がなかったら、ブルーグリーンを削除します。

どちらにしても、このブルーグリーンは 2024 年 2 月現在、ロールバックの機能を備えていないので、古いブルーを戻したりはできないのですよね。

なので、商用のサービスでは事前の検証が必須です。

では、ブルーグリーンを削除します。

削除を開始すると一時的に、「Blue」と「Green」の表記が出てきますが、これはこれで逆な気も・・・。

削除が完了すれば、完全に切り離されます。

古いRDSインスタンスの削除

では、不要となった MySQL5.7 のインスタンスは削除しちゃいましょう。

このままだと料金が 2 倍発生したままになりますからね。

削除保護が有効にっている場合はインスタンスの変更からチェックを外して保存し、インスタンスの削除を実行します。

PHP5.6からutf8mb4の文字コードでMySQL8.0

ブルーグリーンデプロイから話は逸れますが、実はこの RDS に接続していたアプリの中にレガシーな PHP5.6 ベースのアプリがありました。
(しかも、Codeigniter2 のフレームワーク)

そのアプリからの DB 接続では以下のエラーが発生。

どうやら文字コードで怒られていますね。

これまで、RDS もアプリも「utf8mb4」で利用しており、MySQL8.0 の RDS でも変わりないのですけどね。

mysqli などのドライバの問題なのでしょうか。

って、PHP5.6 なんてとっくの昔にサポート外ですからね。

MySQLサーバの文字コード設定

RDS のパラメータグループではデフォルトの「utf8mb4」で、当然 MySQL の文字コード設定を見ても同じ。

character_set_system だけ「utf8mb3」なのは気になります。

って、「utf8」の表示って「utf8mb3」になったのでしょうか。

バイト数の表現が明確になっていいかもしれませんが、いきなりだな・・・。

 mysql> show variables like 'character_set\_%';
+--------------------------+---------+
| Variable_name            | Value   |
+--------------------------+---------+
| character_set_client     | utf8mb4 |
| character_set_connection | utf8mb4 |
| character_set_database   | utf8mb4 |
| character_set_filesystem | binary  |
| character_set_results    | utf8mb4 |
| character_set_server     | utf8mb4 |
| character_set_system     | utf8mb3 |
+--------------------------+---------+

設定を調整してみましたが解決しなかったので、一旦は絵文字などの使用を諦めて、アプリ側も「utf8mb3」で統一することにしました。

パラメータグループで「utf8」に統一した割に、変更が入ったのは「character_set_server」のところのみか・・・。

 mysql> show variables like 'character_set\_%';
+--------------------------+---------+
| Variable_name            | Value   |
+--------------------------+---------+
| character_set_client     | utf8mb4 |
| character_set_connection | utf8mb4 |
| character_set_database   | utf8mb4 |
| character_set_filesystem | binary  |
| character_set_results    | utf8mb4 |
| character_set_server     | utf8mb3 |
| character_set_system     | utf8mb3 |
+--------------------------+---------+

パラメータグループはこんな感じ。

utf8mb3は非推奨(deprecated)

MySQL の公式ドキュメントを見ると、以下の記載があります。

将来的には utf8 が utf8mb4 のエイリアスになるのか。

ってことで、そろそろ PHP5.6 の古いアプリも誤魔化しきれなくなってきますね。

utf8mb3 文字セットは非推奨であり、将来の MySQL リリースで削除される予定です。 かわりに utf8mb4 を使用してください。 utf8 は現在 utf8mb3 のエイリアスですが、ある時点では utf8 が utf8mb4 への参照になることが予想されます。 utf8 の意味があいまいにならないように、utf8 ではなく文字セット参照に utf8mb4 を明示的に指定することを検討してください。

utf8mb3 文字セット (3 バイトの UTF-8 Unicode エンコーディング)

saratoga

フリーランスエンジニア

XYouTube

仕事にも趣味にも IT を駆使するフリーランスエンジニア。技術的な TIPS や日々の生活の中で深堀りしてみたくなったことを備忘録として残していきます。