Closed4
Aurora MySQL 2.10 からのアップグレードを考える
batchi背景
- Aurora MySQL 2.10 (MySQL 5.7 互換) が廃止される
- 2.11.1か3.x.xへのアップグレードを検討している
前提知識
バージョンの考え方は「メジャー・マイナー・パッチ」
なので、
- 2.10.x→2.11.1へのアップグレードはマイナーバージョンアップグレード
- 2.10.x→3.x.xへのアップグレードはメジャーバージョンアップグレード
手法の選択肢
- インプレースアップグレード
- スナップショットからの復元
- Amazon RDS Blue/Green デプロイメント
他にはダンプ＆リストア、レプリケーションがありそう。以下は5.6（v1）から8.0（v3）への移行の例。
インプレースアップグレード
▼マイナーバージョンの場合
▼メジャーバージョンの場合
- エンドポイントの置き換えなし
- ダウンタイム：相対的に長そう
- 切り戻し：スナップショットからの復元
パッチバージョンの場合のみ？「ゼロダウンタイムパッチ適用」がある。条件を満たせば自動で適用される？
コンソールでエンジンバージョンの変更を試みると「B/Gデプロイ」を検討して、というメッセージが表示される。
ダウンタイムの目安は？
マイナーバージョンの場合は数十秒程度？
更新は、DB クラスター内のすべてのインスタンスに同時に適用されます。更新では、DB クラスター内のすべてのインスタンスでデータベースを再起動する必要があるため、20 ～ 30 秒のダウンタイムが発生します。その後、DB クラスターの使用を再開できます。
メジャーバージョンの場合は数十分単位で見ておけばよいか？
正確に測ったわけではないですが、今回の検証では以下の時間ダウンタイムが発生しました。
- バージョン 1→ バージョン 2:15 分~20 分（インアップグレードの待ち時間）
Blue / Green デプロイメント
ダウンタイムは通常1分未満。マイナーバージョンアップグレードのためにB/Gデプロイ使った方がいいことってあるのか？
エンドポイントをアプリ側で切り替える必要はない。
いくつか注意事項がありそう。
- パラメータグループにおけるバイナリログ出力の有効化が必要（binlog_format ⇒ MIXED）
- パラメータグループ変更時の適用（リブート）漏れがあるとGreen環境を作成できない
- クラスタに紐づけているサブネットグループにおいて3az以上の指定が必要
- Green環境作成前のBlue環境に対する何らかの書き込み操作が必要
5.7と8.0の差異
パラメータグループの差とか考えておいた方が良さそう。
参考
batchi- インプレースで所要時間を短くしたいならマイナーアップグレードに留めておく
- メジャーアップグレードの場合はv2とv3の差異を考慮する必要がある
- Blue / Greenデプロイはダウンタイムを短くするのに有効だが少し大掛かりになる、周辺の考慮事項にも注意
batchi正確性の担保のないマトリクス
| 移行方法 | ダウンタイム（予測） | 手順 | 切り戻し | DBエンドポイント | 備考 |
|---|---|---|---|---|---|
| インプレース（マイナー） | 数十秒〜数分 | シンプル | スナップショット | 同じ | 自動アップグレード可 |
| インプレース（メジャー） | 数十分 | シンプル | スナップショット | 同じ | |
| ダンプ&リストア | 数分？ | 普通 | 旧環境に切り戻す | 変わる | |
| スナップショット&リストア | 数分？ | 普通 | 旧環境に切り戻す | 変わる | |
| レプリケーション | 数十秒？ | 複雑 | 旧環境に切り戻す | 変わる | |
| Blue / Green デプロイ | 1分未満 | 少し複雑 | 旧環境に切り戻す | 同じ | いくつか前提条件あり |
batchi5.7から8.0へのインプレースアップグレード
このスクラップは2023/03/11にクローズされました