32/135 © 2014 PostgreSQL Enterprise Consortium
図 4.6: ストレージローカルコピー Storage
Server
OS DBMS ( PostgreSQL )
Local Copy Application
表 4.1: 主なバックアップ／リカバリ方式 論理
バックアップ
オフライン バックアップ
オンラインバックアップ（物理） レプリケーション
OS レベルの ファイルコピー
ストレージ
ローカルコピー 非同期 同期
a バックアップ 概要
pg_dumpコマンド 等を使用
データベースを 停止し、
cp,rsyncなどを 用いたファイルコ ピー
pg_start_backupと cp,rsyncなどの組み 合わせ、または pg_basebackupを使 用
I/Oの静止点で ストレージの機能 を用いてデータを 複製
ストリーミングレプリ ケーション構成のスタン バイをバックアップとみ なす。
b 業務への 影響度
バックアップ中は ストレージ負荷が高 まる
バックアップ中は 業務停止
バックアップ中は ストレージ負荷が高ま る
大きな影響なし 大きな影響
なし
性能面で の影響大
c 必要構成 ― ― アーカイブログ運用
左記に加えスト レージローカルコ ピー機能を備えた ストレージが必要
スタンバイ サーバが 必要
スタンバイ サーバが 必要
（※1）
d バックアップ
最小単位 テーブル データベース
クラスタ
データベース クラスタ
データベース クラスタ
データベース クラスタ
e バックアップ 取得時間
ファイルコピーと比 較して長時間
（検証では約2倍）
ファイルコピー時 間と同等
ほぼファイルコピー時 間と同等（※2）
短時間
（数秒～数分） ―
f
リストア・
リカバリ時間
（RTO）
ファイルコピーと比 較して長時間
（検証では約5～10 倍）
ファイルコピー時 間と同等
ファイルコピー時間＋
WAL のロールフォワー ド時間
短時間
（数秒～数分） ―
g
障害時にどの時 点までデータを 復旧できるか
（RPO）
バックアップ取得時 点
バックアップ取得
時点（※3） 障害発生時点 障害発生時点 障害発生
時点（※4）
障害発生 時点
h
オペレーションミ スによるデータ 障害への対応
基本的に不可
（※6）
基本的に不可
（※5） PITRにより可 PITRにより可 不可
i
リストア・リカバ リに必要な データ
ダンプファイル
バックアップ データファイル
（※7）
・ バックアップ データファイル
・ WALファイル
・アーカイブされた WALファイル
・ バックアップ データファイル
・ WALファイル
・ アーカイブされた WALファイル
―
j まとめ・注意点
・ 比較的小さなデー タベースのバック アップに使用する
・ テーブル単位、
データベース単位 にバックアップする ことが可能
・ 物理バックアップ より処理時間が 長い
・ データベース を停止できる場 合に使用する
・ ストレージロー カルコピーを用 いてバックアッ プすることも可
・可用性（特に継続性）
要件のレベルの高い システムで推奨する 方式
・不要となったアーカイ ブされた WAL を定期 的に削除する必要あ り
・バックアップ／リ カバリを短時間 で実行する要件 がある場合に使 用する
・I/Oの静止点で バックアップを実 施する
・アーカイブされた WAL については 左記と同様
・他の方式ではRTO 要件を満たせない場 合に使用する
・非同期レプリケーショ ンでは、マスタ障害時 にコミット済データが 欠損する可能性があ る
・他のバックアップ方式 と併用することを推奨
※1 同期レプリケーション構成の場合、スタンバイサーバに障害が発生するとマスタサーバでトランザクションの実 行ができなくなるため、可用性の観点からはスタンバイサーバを複数用意するなどの対応が必要である。
※2 pg_basebackupを使用した場合、検証ではデータベースサーバ上のファイルコピー（cpなど）よりは処理時
本節では PostgreSQL が単体で動作するシステムを前提にし、データベースおよびデータベースを稼働させるサーバ に対してどのような監視を行うかについて説明します。なお、監視に際してはOS のコマンドを利用することがあります。本 書では、基本的に Linuxのコマンドを前提に記載します。
4.4.1. 監視するために収集する情報
PostgreSQL および稼動サーバに対する監視は「死活」と「性能」の２つの観点から行われます。
4.4.1.1. 死活監視するために収集する情報
データベースシステムが利用可能（オンライン)な状態となっているか、監視します。
主な監視対象としては、サーバの応答、ネットワークの異常、PostgreSQL プロセスの停止、SQL の実行可否な どがあげられます。通常、監視システムを用いてこれらを数秒程度のリアルタイム間隔にて監視を行い、異常発生 時に運用オペレータに通知するよう措置します。
以下の表にサーバ、PostgreSQL それぞれの死活監視で収集すべき主な監視対象をまとめます。
表 4.2: サーバ情報による死活監視
項目 頻度 対象 手段 確認内容
ネットワークの疎通
数秒間隔
ネットワーク疎通の有無 ping コマンド 一定の時間内で応答があること
サーバOS の応答 サーバOS の応答 ping コマンド 一定の時間内で応答があること
エラーメッセージ サーバ上の問題 /var/log/message
ファイル
エラーを示すメッセージが無いこと
表 4.3: PostgreSQL 情報による死活監視
項目 頻度 対象 手段 確認内容
PostgreSQL プロセ ス
数秒間隔
PostgreSQL プロセスの有 無
ps コマンド pg_stat_activity ビュー
規定の PostgreSQL プロセスが存在す ること
SQL 実行 SQL 実行可否 psqlコマンド
(SELECT 1 の発行 など)
一定時間内に応答があること
エラーメッセージ PostgreSQL 上の問題 /var/log/message ファイル,
pg_log/*のファイル
エラーを示すメッセージが無いこと
34/135 © 2014 PostgreSQL Enterprise Consortium
4.4.1.2. 性能監視を行うために収集する情報
性能監視では、データベースが提供するサービスレベルが劣化していないか監視します。
データベースを稼働させるOS リソースの不足やネットワークの遅延など、主に基盤リソースの不足によりサー ビスレベルは悪化します。また長期の稼働期間中に発生したデータの追加／削除等によるストレージのフラグメ ント、データの配置パターンとマッチしない非効率なインデックスなど、経年的に性能が劣化する要因があります。
これらの要因により、データベースの性能が劣化していないか監視します。
以下の表にサーバ、PostgreSQL それぞれの性能監視で収集すべき主な監視対象をまとめます。
表 4.4: サーバ情報による性能監視
項目 頻度 対象 手段 確認内容
CPU
数分間隔
CPU使用率 sar コマンド CPU使用率が規定の範囲内である
こと
スワップ スワップ回数 vmstat コマンド スワップ回数が規定の範囲内であるこ
と
I/O利用状況 I/Oビジー率 sar コマンド,
iostat コマンド
I/Oビジー率が規定の範囲内である こと
I/O待ち状況 I/O待ち個数 sar コマンド,
iostat コマンド
I/O待ち個数が規定の範囲内である こと
NW利用状況 NW帯域使用率 sar コマンド NW帯域の使用量が規定の範囲内
であること
ディスクスペース ディスク使用率 dfコマンド,
duコマンド
ディスク使用率が規定の範囲内であ ること
表 4.5: PostgreSQL 情報による性能監視
項目 頻度 対象 手段 確認内容
応答性能 数分間隔
スロークエリ (遅いクエリの有無)
log_min_duration _statement(ログ を確認), pg_stat_stateme nts ビュー
log_min_duration_statement の設 定値を超えた際に出力されるログ, total_time/calls で実行時間を確認
接続[ロングトランザク ション]
(長時間放置されている トランザクション有無)
pg_stat_activity ビュー
state が「idle in transaction」のまま で、xact_start が古い(長時間 COMMITしていない)トランザクショ ンの有無
ロック
(ロック待ち時間の長い クエリ有無)
pg_locks ビュー, pg_stat_activity ビュー,
pg_class カタログ
grantedがfalse で、xact_start 長い 問い合わせがないかを確認 (補足)
pg_locks のpidとpg_stat_activity のpid、pg_locks の relation と pg_class のOID を結合するとよい キャッシュヒット率 pg_stat_databas
e ビュー, pg_statio_all_tab les ビュー,
blks_hit, blks_read,
heap_blks_hit, heap_blks_read, idx_blks_hit, idx_blks_readの値か ら算出した値
項目 頻度 対象 手段 確認内容
pg_statio_all_ind exes ビュー
(補足)
「blks_hit*100/
(blks_hit+blks_read)」で対象のデー タベースのキャッシュヒット率が求まる
キャパシティ 同時接続数 pg_stat_activiry
ビュー pg_stat_activityビューの行数 スループットとエ
ラー commit/rollback回数 pg_stat_databas
e ビュー xact_commit, xact_rollbackの回数
DB 性能保全
インデックスのばらつき
(ディスクの利用状況) pg_stats ビュー correlation（統計的相関）が-1 また
は +1 に近いこと
インデックス利用率 pg_stat_all_table s ビュー
seq_scan, idx_scan の値から算出す る値
(補足) idx_scan*100/
(seq_scan+idx_scan)で対象テーブ ルのインデックス利用率が求まる
オブジェクトサイズ
pg_database_siz e関数,
pg_total_relation _size関数, pg_relation_size 関数
左記関数の結果の増分
不要領域 pg_stat_all_table s ビュー
n_live_tup、n_dead_tupで分かる有 効な行数、無効な行数
4.4.2. 収集した情報の分析／対処
常時稼働を求められることが多いデータベースにとって、障害を早期検出する死活監視は重要な位置を占めます。
特に冗長化が行われていないシングルサーバ構成においては、早期に障害原因を切り分け、障害原因を取り除くこ とが求められます。本節では、監視システムが PostgreSQL の障害を検出した際に、どのように障害原因を切り分 け、対応を行うべきかについて説明します。
4.4.2.1. データベース異常時の分析/対処
4.4.1 の項で前述したように、PostgreSQL の死活監視は主に以下の観点で行われます。実際には、原因の切 り分けを容易にするためにより細かい単位で監視を行うこともありますが、その場合も障害時に確認すべき点は 同様です。
• 対象サーバへのネットワーク経路に異常が無いか (ping による疎通確認等)
• 対象サーバ上で稼働する PostgreSQL に対する SQL 要求に対して応答が返ってくるか
• PostgreSQL から応答が返ってくる場合、正常応答が得られるか
上記の監視結果が正常値でないというアラートが検出された場合、上記の観点から対象サーバの状態を順番 に確認して速やかに原因を特定し、復旧作業を行う必要があります。それぞれの観点における障害原因の切り 分け手順を以下に示します。
1. 対象サーバへのネットワークに異常が発生した場合
36/135 © 2014 PostgreSQL Enterprise Consortium