RDS インスタンスのメジャーバージョンのアップグレード

メジャーバージョンとマイナーバージョンのアップグレード

メジャーバージョン	マイナーバージョン
手動	手動、自動
既存アプリケーションとの下位互換性のない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 は変更になるため、この点は注意が必要であり、事前にブルー/グリーンデプロイの考慮事項を確認した方が良さそうです。