Amazon Aurora のアップグレード
概要
Aurora 1.14 強制アップグレード通知が来たので、AWSドキュメントの隙間をAWSサポートに聞いたことをまとめる。
Amazon Aurora は定期的に更新をリリースします
更新の案内
https://forums.aws.amazon.com/forum.jspa?forumID=60
過去の更新履歴
http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Aurora.DatabaseEngineUpdates.html
更新(アップグレード)必須のものもあれば、利用者の判断に任せる場合もある。
最近だと、
- Aurora バージョン 1.13 ・・・必須ではありません。
- Aurora バージョン 1.14 ・・・既存の Aurora DB クラスターの必須アップグレードです。
アップグレードします(しなさい)アナウンスは、事前にAWSからメール通知がくる。
利用者の準備や検証期間を考慮しているので期間的にかなり余裕(猶予)がある。
Auroraのバージョン確認方法
select AURORA_VERSION();
アップグレード情報の確認
AWSマネジメントコンソール の RDS で Recommendations を開く
アップグレード開始方法
方法1
利用者が任意のタイミングで手動でアップグレードを開始する
方法2
「次のメンテナンスウィンドウ」内でアップグレードを実施する設定をする
(メンテナンスウィンドウの時間はUTCなので注意)
ZDP (zero-downtime-patching) とは
▼Aurora バージョン 1.10 から追加された機能
http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Aurora.DatabaseEngineUpdates.20161214.html
▼通常のアップグレードはインスタンスの再起動が発生するが、ZDPは再起動せずにアップグレードが完了する。
- 通常のアップグレード・・・対象インスタンスを再起動するため対象のAuroraインスタンスが20〜30秒ダウンする。
- ZDPのアップグレード・・・対象インスタンスを再起動しない。スループットが一時的に (5 秒ほど) 低下しますが、アプリケーションセッションは保持されます。
▼ZDPは Writer インスタンスのみ利用できる。ReaderインスタンスはZDP適用外
単一ノード DB クラスター、または、複数ノード DB クラスターの書き込みインスタンスへのパッチに適用されます。
ZDP は クラスターのプライマリ DB インスタンスにのみ適用されます。ZDP は Aurora レプリカには適用できません。
単一ノード DB クラスター・・・"プライマリインスタンスのみ(Writer+Reader)のAuroraクラスター"のこと
複数ノード DB クラスターの書き込みインスタンス・・・"複数ノード構成のAuroraクラスターの Writer インスタンス"のこと
▼ZDP は、Writerノードのインスタンスが以下の状態では正常に実行されない
http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Aurora.DatabaseEngineUpdates.20170515.html
実行時間が長いクエリが進行中である
実行時間が長いトランザクションが開いている
バイナリログ記録が有効になっている
バイナリログのレプリケーションが実行中である
パラメータの変更が保留中である
一時テーブルが使用中である
テーブルロックが使用中である
オープン SSL 接続がある
バイナリログ記録が有効になっている・・・
Auroraは、Writeノードに限りバイナリログを出すことができる。
Auroraのクラスターパラメータグループに「binlog_format MIXED」というような設定が入っている状態のこと
▼ZDPが発動するか事前に確認するコマンドや表示項目はないし、AWSサポートに聞いてもわからない。利用者がZDP発動条件に当てはまるのかどうかを確認しないとならず、実際にアップグレードを実施してみないとZDPアップグレードなのか、通常の再起動アップグレードなのかわからない。
▼ZDP は発動条件を満たしていれば必ずZDPアップグレードが実施される。逆に言うと、ZDP発動条件を満たしていれば、ZDPを無効にして意図的に通常の再起動アップグレードを実施させることはできない。
Aurora アップグレード動作
Aurora バージョン 1.13 から「クラスターパッチ適用モデル」機能が追加された。このモデルでは Aurora DB クラスター内のすべてのノードに同時にパッチが適用されます。このモデルでアップグレードされるのかどうかは、更新の内容次第。
最近だと、
・Aurora バージョン 1.13 ・・・Aurora のバージョン 1.13 では、クラスターパッチ適用モデルを使用しており、
・Aurora バージョン 1.14 ・・・Aurora のバージョン 1.14 では、クラスターパッチ適用モデルが使用されており、
クラスターパッチ適用モデル
アップグレードを処理を開始すると、対象クラスター内の全ノードのアップグレードが開始される。特定のノードだけをアップグレードさせることはできない。
アップグレードが開始されると、最初に Writer からアップグレードされ、その後に Reader がアップデートされる。Readerが複数ある場合、全Readerは同じタイミングでアップグレードが開始される。
ZDP発動条件を満たしている Writer と複数 Reader という Auroraクラスター構成の場合
(1) Writer インスタンスは ZDP アップグレード
・対象の Writer インスタンスのダウンタイムなし。スループットが一時的に (5 秒ほど) 低下するだけ。
(2) 全Reader インスタンスが同時に再起動アップグレード
・全 Reader インスタンスは20〜30秒のダウンタイムが発生する。
・全 Reader ノードが同じタイミングでアップグレード開始するので、Readerのノード数に関係なく、
ダウンタイムはは20〜30秒ほど。
※クラスター全体のダウンタイムは Reader のアップグレード時間(バッファーを考慮して数分くらい?)
※更新系は助かるけど、参照系は助からない。
ZDP発動条件を満たしていない Writer と複数 Reader という Auroraクラスター構成の場合
(1) Writer インスタンスは再起動アップグレード
・20〜30秒のダウンタイムが発生する。
(2) 全 Reader インスタンスが同時に再起動アップグレード
・全 Reader インスタンスは20〜30秒のダウンタイムが発生する。
・全 Reader ノードが同じタイミングでアップグレード開始するので、Readerのノード数に関係なく、
ダウンタイムはは20〜30秒ほど。
※クラスター全体のダウンタイムは Writer のアップグレード時間+Reader のアップグレード時間
(バッファーを考慮して数分くらい?)
※更新系も、参照系も助からない。
アップグレードの際に発生する再起動では、フェイルオーバーは発生しない。当然、ZDPアップグレードでも、
フェイルオーバーは発生しない。
上記のアップグレードの動作は、手動でアップグレードを実施した場合も、メンテナンスウィンドウ内で
アップグレードが実施される場合も同じ
その他気になること
- Writerノードがバイナリログを出している場合、アップグレードによりバイナリログがフラッシュされる。でも、レプリケーション接続設定周りで特に何もしなければ、スレーブ側にも反映され、レプリケーション状態には問題は出ない。
追記
- 2021/05/07
- Auroraのバージョン確認方法
- アップグレード情報の確認
- 2021/05/07
- Auroraのバージョン確認方法
- アップグレード情報の確認
Author And Source
この問題について(Amazon Aurora のアップグレード), 我々は、より多くの情報をここで見つけました https://qiita.com/tonishy/items/542f7dd10cc43fd299ab著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .