メジャーバージョンとマイナーバージョンのアップグレード
| メジャーバージョン | マイナーバージョン |
|---|---|
| 手動 | 手動、自動 |
| 既存アプリケーションとの下位互換性のないDBの変更が含まれる場合有。 | 既存のアプリケーションとの下位互換性がある変更のみ。 |
メジャーバージョンのアップグレード
- 商用環境への適用前に、いずれのアップグレードも徹底的にテストすること。
- メジャーバージョンアップグレード中、必要に応じて RDS によって MySQL バイナリ
mysql_upgradeが実行され、テーブルがアップグレードされます。 - メジャーバージョンアップグレード中、RDS によって
slow_logおよびgeneral_logテーブルが空にされます。これらのログ情報を保持するには、メジャーバージョンアップグレードの前にログファイルの内容を保存する。 - 通常は約 10 分で完了するが、インスタンスタイプによる。
MySQL 5.7 から 8.0 へのアップグレードの事前チェック
- MySQL 8.0 には 5.7 との非互換性がいくつかある。
- MySQL 5.7 から 8.0 へのアップグレードをスタートすると、RDS では、これらの非互換性を検出するために自動的に事前チェック（必須）が実行されます。非互換性がある場合、RDS でアップグレードすることはできません。事前チェックで非互換性が見つかった場合、DB インスタンスが停止する前に、RDS により自動的にアップグレードがキャンセルされるため、実行時にダウンタイムが発生することはありません。
MySQL 5.7 から 8.0 へのアップグレードに失敗した後のロールバック
- アップグレードに失敗した場合、DB は新しい MySQL 8.0 で正常に起動できなく、DB は再起動され、MySQL 5.7 にロールバックします。
アップグレードをテストする
1.ドキュメントで互換性の問題を確認する。
2.カスタムDBパラメータグループを利用している場合、新しいメジャーバージョンと互換性のある既存の設定で新しいDBパラメータグループを作成し、手順5でテストインスタンスをアップグレードするときに新しいDBパラメータグループを指定する。
3.アップグレードする DB の スナップショットを作成する。
4.スナップショットから復元して、新しいテスト DB を作成する。
5.新しいテスト DB を新しいバージョンにアップグレードする。
6.アップグレードした DB によって使用されるストレージを評価し、アップグレードに追加のストレージが必要かどうかも判断する。
7.新しいバージョンの DB とアプリケーションが正しく動作することを確認する。
アップグレード方法
従来のアップグレード方法
- マルチ AZ 配置にある場合、プライマリとスタンバイの両方がアップグレードされます。アップグレードが完了するまで、DBインスタンスは利用できなくなります。
[データベース]を選択し、アップグレードする DB インスタンスを選択し、[変更]をクリック。
DB エンジンバージョンには、8.0 の新しいバージョンを指定し、[続行]。
[DB インスタンスを変更]をクリック。
結果を確認します。
イベントから、次の通り再起動がされるため、ダウンタイムが発生することがわかります。
リードレプリカを使用してダウンタイムを短縮してアップグレードする方法
MySQL 5.7 DB のリードレプリカを作成します。[アクション] で [リードレプリカを作成] を選択して作成します。※なお、リードレプリカを作成するには、「自動バックアップ」機能が有効になっている必要があります。これは、バックアップから復元してリードレプリカが作成されるからです。
リードレプリカが作成されたら MySQL 8.0 にアップグレードします。
※これは、「従来のアップグレード方法」と同様の手順です。
リードレプリカの MySQL 8.0 へのアップグレードが完了したら、リードレプリカがソース MySQL 5.7 の DBインスタンスと最新であることを確認します。
mysql> SHOW REPLICA STATUS\G
*************************** 1. row ***************************
Seconds_Behind_Source: 0
MySQL 8.0 にアップグレードしたばかりのリードレプリカを選択し、[アクション] で、[昇格] させます。
これで、MySQL データベースのアップグレードバージョンが作成されたため、アプリケーションを新しい MySQL 8.0 DB インスタンスへ向き先を変更するだけです。
ブルーグリーン
ブルー/グリーンデプロイの作成
DB インスタンス（database-1）を選択し、「アクション」 で 「ブルー/グリーンデプロイの作成」 を選択します。
「ブルーグリーン識別子」を入力し、今回はエンジンバージョンが、ブルー環境は「5.7.41」→ グリーン環境は「8.0.32」にしたいので、以下の通り設定します。
ブルー/グリーンデプロイの表示
database-1（Blue）と database-1-green(Green)が作成されました。
エンドポイントにおいても、それぞれ、Blue と Green のものが作成されているため、切り替え前に、Green に対してテストを行うことができます。
ここで注目しておいてほしいのは「リソースID」です、後程切り替え後の状態も確認します。
ブルー/グリーンデプロイの切り替え
切り替えるブルー/グリーンデプロイを選択し、「アクション」から「切り替え」を選択します。
切り替えの内容を確認し、タイムアウトはデフォルトの 5 minutes のまま「切り替え」します。
切り替え後の状態を確認してみます。
Green
Blue
- エンドポイント
Green のエンドポイントは、Blue のエンドポイントとなり、
Blue のエンドポイントは、old*が付与されたエンドポイントになったことがわかります。 - DB インスタンス ID
Green の DB インスタンス ID は、Blue の DB インスタンス ID となり、
Blue の DB インスタンス ID は、old*が付与された DB インスタンス ID になったことがわかります。 - リソース ID
Green のリソース ID は、Green、
Blue のリソース ID は、Blue のままです。
即ち、DB インスタンス ID は変更になりませんが、リソース ID は変更になるため、この点は注意が必要であり、事前にブルー/グリーンデプロイの考慮事項を確認した方が良さそうです。
ブルーグリーンのついでに...
2024/11/20 追記
既存の RDS データベースインスタンスのストレージボリュームを縮小することはできません。
そのため、以前はボリュームサイズの小さい新しいデータベースインスタンスを手動で作成し、現在のデータベースから新しく作成したデータベースインスタンスにデータを手動で移行するなどの必要がありました。
下記のアップデートにより、ブルーグリーンで RDS データベースインスタンスのストレージボリュームを縮小して移行できるようになったので、ブルーグリーンで RDS インスタンスのメジャーバージョンのアップグレードをする場合はついでに検討してみてはいかがでしょうか。