もりはやメモφ(・ω・ )

ITとか読書感想文とか

RDS PostgreSQLのメンテやVUP時にpsqlを回してDBのダウンタイムをログに残す

やりたいこと

PostgreSQLのダウンタイムを雑に計測します。

背景

RDS PostgreSQLを運用していると以下のようなケースでメンテナンスが必要になります。

  • Hardware Maintenance
  • DB engine version の Update

メンテナンスを実施すると一定時間のDBへ接続できない時間が発生します。 同様の作業は他のDBでも必要になることが多いため、接続できない時間の目安を計測しました。

前提

この手順を行うための前提です。

  • メンテナンス対象のDBへ接続できる
  • psql コマンド利用できる
  • bash が利用できる

手順

pgpassファイルの作成

.pgpass ファイルは psql のためのパスワードファイルです。このファイルを作成しておくとpsqlに都度パスワードを入力する必要がなくなるため、シェルからpsqlを実行するのが簡単に行えます。 参考: PostgreSQL 13.1文書 - 33.15. パスワードファイル

$ vim ~/.pgpass

---
hostname:port:database:username:password
---

$ chmod 0600 ~/.pgpass

sql実行シェルを作成

軽いSQLを実行するシェルを作成します。 SQLはすぐにリターンされるものであればなんでも良いです。

ここではファイル名を checkpg としています。こちらも名前は任意です。

$ vim checkpg
#!/bin/bash

echo -n "$(date '+%Y%m%d-%T'): "
psql -t -h morihaya-test-dummy.ap-northeast-1.rds.amazonaws.com -U username -d database -c ' select count(*) from pg_user;'

一度手打ちでちゃんと実行可能か確認します。問題なければ以下のような結果が返ります。

# ./checkpg
20220418-23:51:31:      2

シェルの実行とログ取得開始

単発で実行可能なことを確認できれば後は連続実行をします。 ここではシンプルに以下のような実行をしました。終える時は fg でバックグラウンドから戻して Ctrl + c です。

while(true)
do
  ./checkpg
  sleep 10
done >> checkpg.log &

結果

ログ取得を開始した後は、DBのメンテナンス作業を行います。 作業を終えたらログを確認します。結果として以下のようなものが記録されます。

20220418-23:06:17:      2

20220418-23:06:27:      2

20220418-23:06:37:      2

20220418-23:06:47: 20220418-23:06:57: 20220418-23:07:07: 20220418-23:07:17: 20220418-23:07:27: 20220418-23:07:37: 20220418-23:07:47: 20220418-23:07:57: 20220418-23:08:07: 20220418-23:08:17: 20220418-23:08:27: 20220418-23:08:37: 20220418-23:08:47: 20220418-23:08:57: 20220418-23:09:07: 20220418-23:09:17: 20220418-23:09:27: 20220418-23:11:47:      2

20220418-23:11:57:      2

20220418-23:12:07:      2

20220418-23:12:17:      2

20220418-23:12:27: 20220418-23:12:37:      2

20220418-23:12:47:      2

正直言ってみづらいですが、日時が横に連続して記録されているところがダウンタイムが発生した時間帯になります。 この例では 20220418-23:06:47 - 20220418-23:09:27 の約3分弱ほどのダウンタイムと 20220418-23:12:27: - 20220418-23:12:37 の10秒程度のダウンタイムが発生したようです。


以上、RDS PostgreSQL のメンテによるダウンタイムを雑に計測したメモでした。

ちなみに例ではMulti-AZが無効なシングルDBの結果であるためMulti-AZの構成と比べて3分と長めの時間がかかりました。Multi-AZであればF/Oによって1分程度で切り替わることを期待しています。