Edited at

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からメール通知がくる。

利用者の準備や検証期間を考慮しているので期間的にかなり余裕(猶予)がある。


アップグレード開始方法

方法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ノードがバイナリログを出している場合、アップグレードによりバイナリログがフラッシュされる。でも、レプリケーション接続設定周りで特に何もしなければ、スレーブ側にも反映され、レプリケーション状態には問題は出ない。