ForgeVision Engineer Blog

フォージビジョン エンジニア ブログ

Aurora クラスターのメジャーバージョンアップ時にカスタムパラメータを適用せよ！

AWS Amazon RDS

はじめに

こんにちは、クラウドインテグレーション事業部の遅れてきたルーキー八木です。
最近、業務でAuroraクラスターのメジャーバージョンアップを繰り返し行う機会がありました。その時にカスタムしたインスタンスパラメータグループやクラスターパラメータグループを適用する際の手順が少しややこしかったので、手順や挙動についてまとめてみました。
parameter_group_change

Auroraメジャーバージョンアップ時にカスタムパラメータを適用する！

本ブログでわかること

  • メジャーバージョンアップ時カスタムクラスターパラメータグループを適用する手順
  • メジャーバージョンアップ時カスタムインスタンスパラメータグループを適用する手順

注意点

  • 検証したのは、MySQL5.7系(Aurora MySQLバージョン2)からMySQL8.0系(Aurora MySQLバージョン3)へのバージョンアップです。
  • DBエンジンのメジャーバージョンアップグレードそのものについては深堀りしません。

前提知識

本題に入る前に、インスタンスパラメータグループとクラスターパラメータグループについて整理しておきましょう。 詳しくはこちらに記載がありますが、カスタムパラメータを適用する際の特徴として以下のようなものがあります。

インスタンスパラメータグループ

  1. インスタンス固有で適用されるパラメータを定義する
  2. DBエンジンの種類、バージョンによってパラメータグループファミリーが異なる
  3. DB パラメータグループを指定せずに DB インスタンスを作成すると、デフォルトの DB パラメータグループが適用される
  4. デフォルトのパラメータグループのパラメータ設定は変更できない
  5. カスタムパラメータを設定するには、既存のものを複製または新たに作成したインスタンスパラメータグループの設定値を変更する

クラスターパラメータグループ

  1. クラスター内のすべての DB インスタンスに適用されるパラメータを定義する
  2. DB クラスターパラメータグループを指定せずにマルチ AZ DB クラスターを作成すると、デフォルトの DB クラスターパラメータグループが適用される
  3. デフォルトのクラスターパラメータグループのパラメータ設定は変更できない
  4. カスタムパラメータを設定するには、既存のものを複製または新たに作成したクラスタパラメータグループの設定値を変更する

最初の項目以外は基本的に同じなのですが、DBエンジンメジャーバージョンアップ時に特に注意すべきは、「DBエンジンのバージョンによってパラメータグループファミリーが異なる」という点です。 これは、バージョンアップ前にカスタム値を設定していたパラメータグループは、そのままバージョンアップ後に引き継ぐことができないということを意味しています。バージョンアップ後も同じようにカスタムパラメータを適用したい場合は、以下のような手順を踏む必要があります。

  1. バージョンアップ後のパラメータグループファミリーに合わせたインスタンスパラメータグループを作成する
  2. バージョンアップ後のパラメータグループファミリーに合わせたクラスターパラメータグループを作成する
  3. メジャーバージョンアップを実施すると同時に1,、2で作成したカスタムインスタンスパラメータグループ、カスタムクラスターパラメータグループを指定する

動的パラメータと静的パラメータ

ご存じの方も多いかと思いますが、ここでおさらいしておくと、パラメータには静的なパラメータと動的なパラメータがあり、前者はパラメータの設定後にDBインスタンスの再起動が必要なもの、後者はパラメータの設定後に再起動が不要なものとされています。仮にバージョンアップ時に適用するカスタムパラメータグループのパラメータが動的なものだけであれば、そのまま適用されると考えがられそうですが、そうはなりません。
これには以下のような理由があり、バージョンアップ後に適用するのはパラメータグループファミリーが異なる新しいDBパラメータグループになるので、静的、動的にかかわらずDBインスタンスの再起動が必要になります。

新しい DB パラメータグループを DB インスタンスに関連付ける場合、RDS は、DB インスタンスが再起動された後にのみ、変更された静的および動的パラメータを適用します。ただし、DB インスタンスに関連付けた後に DB パラメータグループの動的パラメータを変更すると、これらの変更は再起動せずに直ちに適用されます。

よって、上記の3ステップの後にDBインスタンスの再起動を実施するところまでが、メジャーバージョンアップ後にカスタムしたインスタンスパラメータグループ、クラスターパラメータグループを適用する手順となります。

  1. バージョンアップ後のパラメータグループファミリーに合わせたインスタンスパラメータグループを作成する
  2. バージョンアップ後のパラメータグループファミリーに合わせたクラスターパラメータグループを作成する
  3. メジャーバージョンアップを実施、同時に1、2で作成したカスタムインスタンスパラメータグループ、カスタムクラスターパラメータグループを指定する
  4. バージョンアップ後にカスタムしたパラメータグループを適用するためDBインスタンスを再起動する

コラム~Aurora　MySQLのオプショングループ~

さて少し話がそれますが、パラメータグループの他にオプショングループというものがあります。これはデータベースの管理やセキュリティに関する機能を設定するもので、パラメータグループと同じようにカスタム値を設定するには、カスタムのオプショングループを作成してそれをDBインスタンスに適用する必要があります。

今回、Auroraバージョンアップに伴い、オプショングループってどうなってるの？といったことを調べていたところ、衝撃の事実が！

Aurora MySQLはオプショングループ機能がない！

正確に言うと、Auroraのオプショングループはオプションとして提供する機能がないということで、AWS CLIを使えばオプショングループの作成やDBインスタンスへの関連付けもできるのですが、「オプションの追加」がマネコンからもCLIからもできないという状態になります。マネジメントコンソールからはそもそもAuroraのオプショングループが作成できない仕様になっていますが、こんな理由があったのですね

creating_option_group
オプショングループの作成画面

やってみる

バージョンアップ後のパラメータグループファミリーに合わせたインスタンスパラメータグループを作成する

ここから先ほど整理した手順に沿って実際にメジャーバージョンアップとカスタムパラメータグループの適用をやっていこうと思います。
今回は mysql5.7からmysql 8.0 への更新なので、パラメータグループファミリーを更新後のaurora mysql8.0 とし、タイプをDBパラメータグループ(=インスタンスパラメータグループ)として、雛形を作成します。

create-db-parameter-group
インスタンスパラメータグループの生成

以前のパラメータを引き継ぐ

同じDBエンジンでもバージョンが異なると設定できるパラメータが微妙に異なりますので、直接MySQL5.7のパラメータ設定を引き継ぐのは難しそうです。自分は新たに作成したMySQL8.0用のパラメータグループと元々適用されていたMySQL5.7用パラメータグループをメニューの「パラメータの比較」で引き継げるパラメータと引き継げないパラメータの洗い出しを行いました。

parameter_group_comarison
パラメータグループの比較
parameter_group_comarison
異なるパラメータグループファミリーも比較できる

バージョンアップ後のパラメータグループファミリーに合わせたクラスターパラメータグループを作成する

手順はインスタンスパラメータグループの作成手順と一緒なので詳細は省略します。パラメータグループ作成時のタイプでDB Cluster Parameter Groupを選択し、パラメータグループの編集によってカスタム値を設定します。

カスタムパラメータグループを指定してメジャーバージョンアップを実施

これでパラメータグループの準備ができました。ただ、マネジメントコンソールからバージョンアップする場合は明示的に指定できるのはクラスターパラメータグループのみ(下記添付画像)なので、インスタンスパラメータグループについてはバージョンアップ後にデフォルトのものが適用されてしまいます。

modify_on_console
マネジメントコンソールでの変更

AWS CLI であればサブコマンドでインスタンスパラメータグループを明示的に指定することが可能なので、こちらで実行してみます。ただ、この場合でもインスタンスごとに別々のインスタンスパラメータグループを適用することまではできず、クラスター内の全てのインスタンスに対して同じインスタンスパラメータグループが適用されます。

参考： modify-db-cluster — AWS CLI 2.1.30 Command Reference 
$ aws rds modify-db-cluster \
--db-cluster-identifier aurora-cluster\
--apply-immediately \
--db-cluster-parameter-group-name　custom-cluster-pg-aurora80 \
--db-instance-parameter-group-name custom-pg-aurora-mysql80 \
--allow-major-version-upgrade \
--engine-version 8.0.mysql_aurora.3.02.2 \
--region ap-southeast-1

ステータスの変化

modify-db-cluster でバージョンアップを実行すると、まずDBクラスターのステータスがupgrading (日本語表記だと"のアップグレード")になり、その後1分程度でDBインスタンスのステータスもそれぞれupgrading になります。

db_status_change
DBクラスターのステータス変化

この時点ではまだ指定したカスタムパラメータグループは適用になっていません。パラメータグループはバージョンアップ前のままです。

parameter_group_applystatus1
バージョンアップ直後のパラメータグループのステータス

しばらくするとステータスが再起動を保留中に変わります。

parameter_group_change
パラメータグループのステータス変化2

さらに数分後に、新しいパラメータグループに表示が変わりました。

parameter_group_change3
パラメータグループのステータス変化3

このあとDBクラスターとDBインスタンスのステータスがアップグレードから利用可能になりましたが、この時のパラメータグループたちのステータスはというと....

DBインスタンスのステータス変化

まだ適用中と再起動を保留中のままです。

parameter_group_change4
パラメータグループのステータス変化4

さらに待つこと数分、両方のパラメータグループのステータスが再起動を保留中になりました。

parameter_group_change5
パラメータグループのステータス変化5

新しく適用されたパラメータグループのカスタムパラメータを適用するには、ライターインスタンスとリーダーインスタンスをそれぞれ再起動させる必要があります。プライマリインスタンスを再起動する場合はフェイルオーバーがかかるので注意してください。また、MySQLのバージョンによっても挙動が異なるので詳しくは[こちら](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_RebootCluster.html)をご覧ください。

standbyinstance_failover
リーダーインスタンス再起動＆フェイルオーバー
リーダーインスタンスをフェイルオーバーすると、そのインスタンスのパラメータグループのみが同期中になりました。

parameter_group_status
旧リーダーインスタンスのパラメータグループのステータス

再起動してない側のインスタンスのパラメータグループは以前として再起動を保留中のままです

parameter_group_status
旧ライター(新リーダー)のパラメータグループ

ここでさらにもう一度新リーダーインスタンスを再起動＆フェイルオーバーすると、ライターインスタンスが元のAZに戻り、両方のインスタンスでパラメータグループが同期中となります。

まとめ

ということで、メジャーバージョンアップした際のカスタムインスタンスパラメータグループとカスタムクラスターパラメータグループの適用の流れを見てきました。結構、手間がかかると感じたのはわたしだけではないはず。。さらに言うとこの状態だとクラスター内のインスタンスには全てに同じインスタンスパラメータグループが適用されているので、ライターとリーダーで別々のインスタンスパラメータグループを適用したい、といった場合は、個別にインスタンスパラメータグループを変更してそのインスタンスを再起動をする必要があります。いやー結構大変ですが、この記事が、みなさまがAuroraバージョンアップする際のお役に立てば幸いです。