1. 目的
- Aurora PostgreSQLのアップデート通知が来て、「期日までに手動でアップデート適用しない場合はメンテナンスウィンドウ内にて自動適用されるよ」とのこと。フェイルオーバーが必要なため、接続断時間があるのは確実だが、実際どれくらいになるのかを検証環境にて実機確認する。
2. Aurora PostgreSQLの環境／適用するアップデート
-
今回アップデートを適用するAurora PostgreSQLの環境は以下の通り。
- エンジンバージョン: 11.9 (= Aurora PostgreSQLのバージョン 3.4)
- ノード数: 2
- サイズ： db.r5.xlarge
-
適用するアップデートは以下の2つ。
- 「Upgrade to Aurora PostgreSQL 3.4.7」 (DBエンジンのパッチ)
- 「New Operating System upgrade is available」 (OSのパッチ)
-
補足
- DBエンジンのアップデートに関しては、AWS公式サイト「Aurora PostgreSQL の PostgreSQL DB エンジンのアップグレード」に説明あり。
- DBエンジンのアップデートの種類として、メジャーバージョンアップと、マイナーバージョンアップ/パッチ適用の大きく2種類ある。今回の「Upgrade to Aurora PostgreSQL 3.4.7」はパッチ適用に相当する。(PostgreSQL 11.9 = Aurora PostgreSQL 3.4であり、そのマイナーバージョン内でのパッチ適用)
- OSのアップデートに関しては、AWS公式サイト「Amazon Aurora DB クラスターのメンテナンス」に説明があり、必要に応じて不定期に実施される様子。
- 今回、「New Operating System upgrade is available」(OSのパッチ)が「期限内に適用しないと自動適用されるよ」の通知対象。ただし、「Upgrade to Aurora PostgreSQL 3.4.7」(DBエンジンのパッチ)を先に適用しないと、「New Operating System upgrade is available」のアップデート適用を行う画面が出てこないため、前者を先に適用する。
3. 接続断時間確認の方法
- Aurora PostgreSQLと同一VPC内に、PostgreSQLのクライアント(psql)をインストールしたインスタンスを用意する。
- アップデート作業中、Aurora PostgreSQLの2つのエンドポイント(ライターインスタンス、リーダーインスタンス)に対し、psqlコマンドを用いて接続し、1秒間隔で2つのselect文を実行するスクリプトを実行する。(スクリプトのソースは複雑なため省略)
- 実行するselect文は以下の2つ。select文の出力結果をスクリプトで整えてログ出力する。
select文.sql
select count(*) from pg_stat_activity; # PostgreSQLの内部プロセス数の取得
select AURORA_VERSION(); # Aurora エンジンバージョンの取得 (3.4.2 ⇒ 3.4.7 へアップグレード)
- 平常時のスクリプト実行ログは以下のようになる。アップデート適用中に接続断が発生した場合、psqlコマンドがエラー/応答待ちになり、1秒間隔での実行ができなくなる。スクリプトの出力する時刻の値が1秒以上に開くことで接続断時間を検出できる。
スクリプトの出力結果.txt
2023/04/27 17:32:53 connections:8 version:3.4.2
2023/04/27 17:32:54 connections:8 version:3.4.2
2023/04/27 17:32:55 connections:8 version:3.4.2
2023/04/27 17:32:56 connections:8 version:3.4.2
2023/04/27 17:32:57 connections:8 version:3.4.2
- PostgreSQLクライアント(psql)と、Aurora PostgreSQLの構成は以下となる。
4. アップデート動作と接続断時間の確認
4.1 アップデート動作(概要)
- アップデート動作は、DBエンジンパッチとOSパッチで以下のように異なる。
- DBエンジンパッチはAuroraのクラスターへの適用となり、マネコンで「今すぐ適用」すると、全てのノードに適用される。
- 一方、OSパッチはAuroraの構成ノード毎に適用する必要がある。今回は2ノード構成のため、①リーダーインスタンスへのパッチ適用⇒②手動フェイルオーバー⇒③切り替わり後のリーダーインスタンスへのパッチ適用、の順で実施する。
4.2 接続断時間
- 各作業プロセスにおける各エンドポイントへの接続断時間は以下のようになった。
| パッチ種別 | 手順 | 所要時間 | 接続断（ライター） | 接続断（リーダー） | |
|---|---|---|---|---|---|
| 1 | DBエンジン | 該当のクラスターに対し、パッチ「Upgrade to Aurora PostgreSQL 3.4.7」を適用 | 16分 | 有(6秒) | 有(37秒) |
| 2 | OS | リーダーインスタンスに対し、パッチ「New Operating System upgrade is available」を適用 | 7分 | 無 | 有(8秒) |
| 3 | OS | フェイルオーバーを実施し、リーダーインスタンスだったノードをライターインスタンスに変更 | 1分 | 有(9秒) | 有(15秒) |
| 4 | OS | 切り替わり後のリーダーインスタンスに対し、パッチ「New Operating System upgrade is available」を適用 | 7分 | 無 | 無 |
- 接続断の発生タイミング、及びクラスタ・構成ノードのイベントログを時系列にまとめた。
| ライターエンドポイント接続断 | リーダーエンドポイント接続断 | クラスターイベントログ | ノード01イベントログ | ノード02イベントログ | |
|---|---|---|---|---|---|
| DBエンジンパッチの適用(17:33:59～17:49:17) | 17:44:11～17:44:16 (6秒) | 17:44:17～17:44:53 (37秒) | 17:33:59 Database cluster engine version upgrade started. 17:49:17 Database cluster engine version has been upgraded. |
17:44:08 DB instance shutdown 17:44:14 DB instance restarted |
17:46:14 Read replica has been disconnected from master. Restarting postgres. 17:46:25 DB instance restarted |
| ノード02へのOSパッチ適用 (17:56:12～18:02:24) | 18:02:19～18:02:26(8秒) | 17:56:12 Applying off-line patches to DB instance 17:57:17 DB instance shutdown 18:01:06 DB instance restarted 18:02:05 Finished applying off-line patches to DB instance 18:02:17 DB instance shutdown 18:02:24 DB instance restarted |
|||
| フェイルオーバー(18:08:49～18:09:22) | 18:08:58～18:09:07 (9秒) | 18:08:51～18:09:06(15秒) | 18:08:49 Started cross AZ failover to DB instance: node02 18:09:22 Completed failover to DB instance: node02 |
18:08:56 A new writer was promoted. Restarting database as a reader. 18:09:00 Read replica has fallen behind the master too much. Restarting postgres. 18:09:05 DB instance restarted |
18:09:04 DB instance restarted |
| ノード01へのOSパッチ適用(18:14:07～18:20:41) | 18:14:07 Applying off-line patches to DB instance 18:15:12 DB instance shutdown 18:20:22 Finished applying off-line patches to DB instance 18:20:34 DB instance shutdown 18:20:41 DB instance restarted |
- 通常、アプリケーションからはライターエンドポイントのみを接続先として使用しているため、特にライターエンドポイントの接続断時間に着目する。DBエンジンパッチの適用時、及びフェイルオーバー時に秒レベルの断が発生しており、概ね想定通りの結果となった。
- リーダーエンドポイントにも接続断が発生しているが、今回2ノード構成のため接続断が発生しやすい可能性もあり、仮にリーダーインスタンスが複数あれば動作が異なるかもしれない。
- DBエンジンのパッチ適用について、エンジンバージョンが新しい場合はダウンタイムなしのパッチ適用 (ZDP) に改善されている可能性があり、機会があれば対象のバージョンでの動作検証を行いたい。
4.3 アップデート動作(詳細)
-
アップデート実施時、動作の流れの把握のため随時画面キャプチャを行った。
-
今回作業対象となるクラスターはこちら。クラスターに2台ノードがあり、ノード01がライター、ノード02がリーダーの状態。
-
このクラスターに適用可能なアップデートの一覧が表示される。今回はDBエンジンパッチ、OSパッチの2つが対象だが、まずは表示されている「Upgrade to Aurora PostgreSQL 3.4.7」(DBエンジンパッチ)を選択し、「今すぐ適用」を実行する。
- クラスターのステータスが「アップグレード」に、パッチのステータスが「進行中」に変化する。パッチ適用が完了すると、クラスターのステータスが「利用可能」に戻る。(画面は省略)
- DBエンジンパッチの適用完了後、リーダーインスタンスに対して適用可能なアップデートとして「New Operating System update is available」(OSパッチ)が表示される。選択して「今すぐ適用」を実行する。
- ノードのステータスが「メンテナンス」に、パッチのステータスが「進行中」に変化する。パッチ適用が完了すると、ノードのステータスが「利用可能」に戻る。（画面は省略）
- リーダーインスタンスの表示画面から、「アクション」->「フェイルオーバー」を選択し、フェイルオーバーを実行する。
- フェイルオーバー完了後、ノード02がライターインスタンス、ノード01がリーダーインスタンスにロールが切り替わる。
- ノード02と同様の手順にて、ノード01(この時点でのリーダーインスタンス)にOSパッチを適用し作業終了(画面は省略)。
5. 所感
- 今回はメジャーバージョンアップではないので、本来軽微な作業であるはずだが、それでも「これ何のパッチ？」「クラスターに適用？それともノードに適用？」「どのタイミングで接続断時間が発生？」など、仕様の確認や実機検証にかなり手間取ってしまった。アップデート期限までに余裕を持ってクイックに対応できるようノウハウを整備していきたい。