请确认在执行Amazon Aurora PostgreSQL的更新时连接中断的时间(停机时间)

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 count(*) from pg_stat_activity;  # PostgreSQLの内部プロセス数の取得
select AURORA_VERSION();  # Aurora エンジンバージョンの取得 (3.4.2  3.4.7 へアップグレード)
    平常時のスクリプト実行ログは以下のようになる。アップデート適用中に接続断が発生した場合、psqlコマンドがエラー/応答待ちになり、1秒間隔での実行ができなくなる。スクリプトの出力する時刻の値が1秒以上に開くことで接続断時間を検出できる。
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
auroraposgre.png

4. 确认更新操作和连接断开时间。

4.1 更新操作(概述)

    • アップデート動作は、DBエンジンパッチとOSパッチで以下のように異なる。

DBエンジンパッチはAuroraのクラスターへの適用となり、マネコンで「今すぐ適用」すると、全てのノードに適用される。
一方、OSパッチはAuroraの構成ノード毎に適用する必要がある。今回は2ノード構成のため、①リーダーインスタンスへのパッチ適用⇒②手動フェイルオーバー⇒③切り替わり後のリーダーインスタンスへのパッチ適用、の順で実施する。

4.2 连接中断时间

    各作業プロセスにおける各エンドポイントへの接続断時間は以下のようになった。
パッチ種別手順所要時間接続断(ライター)接続断(リーダー)1DBエンジン該当のクラスターに対し、パッチ「Upgrade to Aurora PostgreSQL 3.4.7」を適用16分有(6秒)有(37秒)2OSリーダーインスタンスに対し、パッチ「New Operating System upgrade is available」を適用7分無有(8秒)3OSフェイルオーバーを実施し、リーダーインスタンスだったノードをライターインスタンスに変更1分有(9秒)有(15秒)4OS切り替わり後のリーダーインスタンスに対し、パッチ「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 restarted17: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: node0218: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 restarted18: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 更新操作(详细说明)

posgre01a.png
postgre02a.png
    クラスターのステータスが「アップグレード」に、パッチのステータスが「進行中」に変化する。パッチ適用が完了すると、クラスターのステータスが「利用可能」に戻る。(画面は省略)
postgre03a.png
    DBエンジンパッチの適用完了後、リーダーインスタンスに対して適用可能なアップデートとして「New Operating System update is available」(OSパッチ)が表示される。選択して「今すぐ適用」を実行する。
postgre04a.png
    ノードのステータスが「メンテナンス」に、パッチのステータスが「進行中」に変化する。パッチ適用が完了すると、ノードのステータスが「利用可能」に戻る。(画面は省略)
postgre05.png
    リーダーインスタンスの表示画面から、「アクション」->「フェイルオーバー」を選択し、フェイルオーバーを実行する。
postgre06a.png
    フェイルオーバー完了後、ノード02がライターインスタンス、ノード01がリーダーインスタンスにロールが切り替わる。
postgre07a.png
    ノード02と同様の手順にて、ノード01(この時点でのリーダーインスタンス)にOSパッチを適用し作業終了(画面は省略)。

5. 所感 –

    今回はメジャーバージョンアップではないので、本来軽微な作業であるはずだが、それでも「これ何のパッチ?」「クラスターに適用?それともノードに適用?」「どのタイミングで接続断時間が発生?」など、仕様の確認や実機検証にかなり手間取ってしまった。アップデート期限までに余裕を持ってクイックに対応できるようノウハウを整備していきたい。
广告
将在 10 秒后关闭
bannerAds