AWS Aurora MySQL v5.6 から v5.7 へのアップグレードをちょっとだけ考えてみた
Aurora MySQL v5.6 のサポート期限がいつかわからない
現在、Auroraでは、MySQL v5.6 (Engine 1.x) とv5.7互換 (Engine 2.x) のデータベースが利用できます。
Oracleが開発しているオリジナルのMySQL v5.6(以降 Vanilla MySQLと記載) は、2021/02 にサポートが切れます。 Aurora MySQL は Amazonが独自に開発している互換DBです。Vanilla MySQLのサポート期限はAuroraには関係ないのですが、互換DBであることを踏まえると、 「同じようなタイミングでサポート切れになる可能性もあるのでは・・・」と心配になってしまいます。
例えば、RHEL6互換のAmazon LinuxはRHEL6のサポート期限(2020/11末)と近しいタイミングでサポートが終了になっているようです。
一方で、Aurora のMySQLの最新バージョン(8.0) へのキャッチアップは、まだされていません(RDS MySQLはMySQL v8.0利用可)。MySQL v8.0は2年以上前（2018/04）にリリースされています。
Amazon が Aurora を常に最新のMySQLにキャッチアップさせ続ける気があるのかどうか、よくわからないです。 v8.0へはキャッチアップせず、v5.6/v5.7 互換のバージョンをずっと継続していくのかもしれません。
ようするに、Aurora v5.6がいつまでサポートされるのか、いつかはサポートが切れるのか、よくわかりませんでした。
補足しておくと、Aurora には LTS(長期サポート)リリースのバージョンがあり、LTSに指定されたバージョンのリリースから最低でも１年はサポートが継続されると明記されています。 ある日突然サポートが打ち切られるということはないでしょう。 docs.aws.amazon.com
メリットが限られているアップグレード
MySQL v5.7 の新機能のうち、いくつかは Aurora の制限により使えないとされています。 これらは、「使えない」というよりは、Aurora 独自に解決策がすでにあるため、「使う必要がない」と言えるものが多くあります。 例えば、「起動時の InnoDB バッファープールのロード」は同じ役割をはたす機能が Aurora v5.6の時点 で既に実装されています。
- グループのレプリケーションプラグイン
- ページサイズの増加
- 起動時の InnoDB バッファープールのロード
- InnoDB フルテキストパーサープラグイン
- マルチソースレプリケーション
- オンラインバッファープールのサイズ変更
Auroraのアーキテクチャや制限を踏まえると、v5.7にアップグレードして得られるメリットは主に以下でしょうか。 オンプレでのアップグレード体験と比較すると、ちょっと物足りなさを感じますね。。。(それだけ、Auroraが既に十分、賢いとも言える)
アップグレード方法
とはいえ、いつアップグレードすることになっても良いよう、方法を検討してみました。
インプレース
DBを停止し、現在利用しているサーバをそのままアップグレードする方法です。現時点ではAuroraではサポートされていないようです。
サポートされました！
ダンプ・インポート
mysqldumpでデータを抜いて、v5.7へインポートする。
シンプルでわかりやすいやり方ですが、データ量が多いとすごく時間がかかります。
スナップショット復元
Aurora MySQL v5.6 のスナップショットから v5.7 の新規DBインスタンスを作成することができます。 DBへの書き込みを停止し→スナップショットの取得→新規DBインスタンスの作成→アプリからの接続先変更 という流れになります。
移行先を事前に作成しておけないので、当日、間接的な部分も含めて完了させないといけない点がデメリットでしょうか。例えば、監視設定とかセキュリティまわりなど。
v5.7のスナップショットからv5.6を作成すること(ダウングレード)はできないようです。 万が一の切り戻し時には他の手段を取る必要があります。
レプリケーション
v5.6/v5.7 のAuroraクラスタ間でレプリケーションをしておく。データを事前に連携しておくので、停止時間が短く済みます。 事前にv5.7側に参照を向けておいて実績を作れるというメリットもありますが、v5.6→v5.7間で普段発生しないレプリケーション遅延が発生する可能性があります。
