PostgreSQLのトラブルシューティング＠第5回中国地方DB勉強会

PostgreSQL
　　のトラブルシューティング
第五回　中国地方DB勉強会
株式会社メトロシステムズ
花田　茂

• 花田茂
• @s87
• shigeru.hanada@gmail.com
• 普段の業務
• PostgreSQLの本体開発、関連ツール開発
• OSS導入コンサル・サポート
• OSSトレーニング講師
• 日本PostgreSQLユーザ会（JPUG）で活動
• 勉強会やイベントでの講演
• ドキュメント翻訳
Copyright © Metro Systems Co.,Ltd. All rights reserved.
自己紹介
東京・池袋の
この辺で仕事してます
2

トラブルシューティングの基本
• トラブルを起こさない
• トラブルが起こりにくい設計
• トラブルが起こりにくい環境
• トラブルを把握する
• 定常的に監視
• 通知の仕組みと受け取る体制
• トラブルに対処する
• 原因と対処方法の特定
• 確実な作業
3

トラブルシューティングの基本
• トラブルを起こさない
• トラブルが起こりにくい設計
• トラブルが起こりにくい環境
• トラブルを把握する
• 定常的に監視
• 通知の仕組みと受け取る体制
• トラブルに対処する
• 原因と対処方法の特定
• 確実な作業アーキテクチャの
理解が必要
3

アーキテクチャというと…
• PostgreSQLが動く仕組み
• プロセス・ファイル・メモリの構成
• 追記ベースのMVCC
• WALとPITR
• B-Treeをはじめとするインデックス
• ロック機構
• クエリプランナー
• Etc.
4

アーキテクチャというと…
• PostgreSQLが動く仕組み
• プロセス・ファイル・メモリの構成
• 追記ベースのMVCC
• WALとPITR
• B-Treeをはじめとするインデックス
• ロック機構
• クエリプランナー
• Etc.
4
これだけで数日
かかるので…

アーキテクチャに関するポインタ
• Webサイト
• PostgreSQLドキュメント
• http://www.postgresql.jp/document/9.3/html/internals.html
• PostgreSQL Internals（永安氏）
• http://www.postgresqlinternals.org/
• PostgreSQL Internals（HP社）
• http://h50146.www5.hp.com/services/ci/opensource/pdfs/
PostgreSQL_Internals.pdf
5

• 勉強会・イベント
• JPUG勉強会
• 東京開催ですが、たいていUSTREAM中継・録画があります
• 開催情報（JPUGしくみ分科会 Webサイト）
• http://www.postgresql.jp/wg/shikumi/
• USTREAMチャンネル（jpug_study）
• http://www.ustream.tv/channel/jpug-shikumi
• OSS-DB 技術解説セミナー
• LPIC試験と同じLPI-Japanが開催する技術セミナー
• 運用管理に関しては上位試験のGoldまで
6

• 書籍
• PostgreSQL全機能バイブル
• 技術評論社
• 鈴木啓修　著
• http://gihyo.jp/book/2012/978-4-7741-5392-6
• 内部構造から学ぶPostgreSQL 設計・運用計画の鉄則
• 技術評論社
• 勝俣智成，佐伯昌樹，原田登志　著
• https://gihyo.jp/book/2014/978-4-7741-6709-1
7

• きちんとバックアップ
• バックアップ方式の選び方
• きちんとログ記録
• トラブルに備えるサーバログ設定とログの読み方
• きちんと監視
• PostgreSQLの監視機能
• 監視に便利な外部ツール
• きちんと対処
• トラブルの切り分けの基本的な流れ
• よくあるトラブルと対処方法
今日の内容
9

きちんと
バックアップ
10

バックアップ方式の選び方
• なぜバックアップが重要なのか？
• HDDをはじめとするハードウェア故障
• 誤削除などのヒューマンエラー
• ソフトウェアのバグでデータ損失
• 災害などによる電源喪失
• Etc.
11

• なぜバックアップが重要なのか？
• HDDをはじめとするハードウェア故障
• 誤削除などのヒューマンエラー
• ソフトウェアのバグでデータ損失
• 災害などによる電源喪失
• Etc.
11
復旧できなければ
システムの最期

• どんな種類がある？
論理物理
12
オフライン
オンライン
なしコールドバックアップ
cp/rsync/tar
エクスポート
pg_dump/
pg_dumpall
ホットバックアップ
pg_basebackup
+アーカイブログ
大規模な場合はストレージの
スナップショット機能も有効

• どんな違いがある？
コールドバックアップエクスポートホットバックアップ
13
戻せる
範囲
バージョン
移行
バックアップ
単位
設定ファイル
バックアップ
取得時点
バックアップ
取得開始時点
ベースバックアップ
以降でWALのある
任意の時点
不可可不可
DBクラスタ全体
テーブルセット、
データベース、
全データベース
DBクラスタ全体
含む含まない含む

• かならず事前にリハーサル
• 「バックアップを取っていたがリストアできない」とい
うケースがままあります！
• かならずリストア手順を整理してリハーサルしましょう
• トラブル発生時の１秒は血の１秒
• 所要時間も見積っておき、システム復旧までのスケジュールを明確に
14

ちょこっとアーキテクチャ
• テーブルスペースはシンボリックリンク
15
＜LOCATION指定＞
＜PostgreSQLバージョン＞
＜DB OID＞
＜TABLE OID＞
$PGDATA
pg_tblspc
＜TABLESPACE OID＞
＜LOCATION指定＞
＜PostgreSQLバージョン＞
＜DB OID＞
＜TABLE OID＞
物理構造
論理構造

より詳しく知りたい方は
• 「バックアップことはじめ」
• JPUG主催の勉強会での講演
• USTREAM録画
• http://www.ustream.tv/recorded/48237629
• 講演スライド
• http://www.slideshare.net/satock/29shikumi-backup
16

きちんと
ログ記録
17

サーバログ記録の設定
• サーバログとは
• PostgreSQLサーバの動作を記録するDBA向けのログ
• syslogまたはログファイルに出力可能
• DBクラスタ全体で一つの出力先
• 大量のログ出力はロック競合でパフォーマンス低下の原因にも
• デフォルト設定では実運用に向かない
• 標準エラー出力にしか出ない
• エラー内容のみの出力で、タイムスタンプなどが出ない
• 致命的なエラーしか出力されない
18

• 出力先の設定
• 必ずsyslogまたはログファイルのいずれかには出力
• ログファイル出力
• log_destination = ‘stderr’
• logging_collector = on
• log_filename = ‘postgresql-%Y-%m-%d.log’（日付別ファイル）
• log_rotation_age = 1d（設定は出力量に応じて）
• ローテートしたログは定期的にバックアップしましょう
• syslog出力
• log_destination = ‘syslog’
• ファイル出力より重くなることがあるので注意
19

• ログ行に出す情報の設定
• 各行の先頭に解析に役立つ情報を出力
• 設定例：タイムスタンプ・ユーザ名・データベース名
• log_line_prefix = ‘%t %u@%d ‘
• 最後の空白を忘れずに！
• 他にも…
• %u：ユーザ名
• %h：リモートホスト（接続元の判別）
• %a：アプリケーション名（バッチとWeb系アクセスの判別）
• %c：セッションID（複数のログ行のひもづけに）
• %p：プロセスID
20

• 記録する処理の設定
• 何が起こっているか？を知るための情報を出力
• 接続・切断
• log_connections = on
• log_disconnections = on
• チェックポイント
• log_checkpoint = on
• 自動VACUUM
• log_autovacuum_min_duration = 0（全ての自動VACUUMを記録）
• 一時ファイルの使用状況
• log_temp_files = 1MB（0で全ての一時ファイル生成を記録）
21

サーバログの読み方
接続のないログでは
ユーザ名やホスト名は出ない
...
2014-09-18 15:17:11 JST @[541a78e7.7cb1:1] LOG: database system was shut down at 2014-09-18 15:17:04 JST
2014-09-18 15:17:11 JST @[541a78e7.7cac:5] LOG: database system is ready to accept connections
2014-09-18 15:17:11 JST @[541a78e7.7cb5:1] LOG: autovacuum launcher started
2014-09-18 15:17:34 JST [unknown]@[unknown][541a78fe.7cc7:1] LOG: connection received: host=[local]
2014-09-18 15:17:34 JST postgres@postgres[541a78fe.7cc7:2] LOG: connection authorized: user=postgres
database=postgres
2014-09-18 15:19:28 JST postgres@postgres[541a78fe.7cc7:3] LOG: temporary file: path "base/pgsql_tmp/
pgsql_tmp31943.0", size 53559296
2014-09-18 15:19:28 JST postgres@postgres[541a78fe.7cc7:4] STATEMENT: explain analyze select * from
pgbench_accounts order by abalance;
...
• ログファイルの例
• 起動～接続
22
接続要求時は
ユーザ・ホストともに不明
「LOG:」部分はメッセージの
重要性に応じて「ERROR:」や
「PANIC:」などに変わる

...
2014-09-18 15:17:11 JST @[541a78e7.7cb1:1] LOG: database system was shut down at 2014-09-18 15:17:04 JST
2014-09-18 15:17:11 JST @[541a78e7.7cac:5] LOG: database system is ready to accept connections
2014-09-18 15:17:11 JST @[541a78e7.7cb5:1] LOG: autovacuum launcher started
2014-09-18 15:17:34 JST [unknown]@[unknown][541a78fe.7cc7:1] LOG: connection received: host=[local]
2014-09-18 15:17:34 JST postgres@postgres[541a78fe.7cc7:2] LOG: connection authorized: user=postgres
database=postgres
2014-09-18 15:19:28 JST postgres@postgres[541a78fe.7cc7:3] LOG: temporary file: path "base/pgsql_tmp/
pgsql_tmp31943.0", size 53559296
2014-09-18 15:19:28 JST postgres@postgres[541a78fe.7cc7:4] STATEMENT: explain analyze select * from
pgbench_accounts order by abalance;
...
• 検索（一時ファイル生成）
一時ファイルのサイズ
（バイト単位）
セッションIDとセッション
内行番号でひもづけが可能
23
「STATEMENT:」行にはメイ
ンのログの発生元クエリが出力
される

...
2014-09-18 15:55:48 JST @[541a7fa5.d886:15] LOG: checkpoints are occurring too frequently (15 seconds apart)
2014-09-18 15:55:48 JST @[541a7fa5.d886:16] HINT: Consider increasing the configuration parameter
"checkpoint_segments".
2014-09-18 15:55:48 JST @[541a7fa5.d886:17] LOG: checkpoint starting: xlog
2014-09-18 15:55:51 JST @[541a7fa5.d886:18] LOG: checkpoint complete: wrote 29296 buffers (22.4%); 0
transaction log file(s) added, 0 removed, 10 recycled; write=2.988 s, sync=0.681 s, total=3.676 s; sync files=3,
longest=0.601 s, average=0.227 s
...
• チェックポイント
24
チェックポイントが頻発
しているという警告
チェックポイントで発生し
たI/Oなどの詳細情報
checkpoint_segmentsに
基づいて開始された

さらに進んだログ記録
• ログ収集
• CSV出力
• log_destination = ‘csvlog‘とするとCSV形式のログを出力
• 通常形式との同時出力も可能
• CSVならばデータベースへの取り込みも容易でSQLでの集計・分析も可能
• contribモジュールのfile_fdwを使うとファイルを直接テーブル形式で参照
可能
• Fluentd連携
• データ収集機構であるFluentdを使ってログデータをストリーミング収集
• 参考
• http://chopl.in/blog/2013/06/07/
postgresql_csv_log_with_fluentd.html
• http://tech-sketch.jp/2014/07/postgresqlfluentd.html
25

PostgreSQLでの監視ポイント
• 監視すべきポイント
• 死活（プロセス、サービス）
• 性能（スループット、レスポンス）
• リソース（CPU、メモリ、ディスク、N/W）
• 処理状況（チェックポイント、自動VACUUM）
• エラー発生（障害、攻撃など）
• Etc.
27

PostgreSQLでの監視ポイント
• 監視すべきポイント
• 死活（プロセス、サービス）
• 性能（スループット、レスポンス）
• リソース（CPU、メモリ、ディスク、N/W）
• 処理状況（チェックポイント、自動VACUUM）
• エラー発生（障害、攻撃など）
• Etc.
27
システム特性に
応じて

28

OSレベルの監視
• 死活監視
• プロセス
• PostgreSQLのプロセスの有無
• サービス
• 新規接続で簡単なSELECT文を発行してサービス死活を監視• 性能監視
• アプリケーションのスループットやレスポンス
• アプリケーションログやWebアクセスログから集計
29

OSレベルの監視
• リソース監視
• CPU、メモリ、ディスクI/O、N/W
• sar、vmstat、iostat、netstatなど
• ディスク使用量
• データベース、テーブルのサイズ
• WAL（オンライン、アーカイブ）
• サーバログ
• du、lsなど
30

PostgreSQLでの監視
• 性能監視
• スロークエリ分析
• log_min_durationで一定時間以上かかったクエリをサーバログに出力
• 0にすると全てのクエリを出力→負荷が高いので注意
• セッション内で変更可能→バッチプログラムでは値を大きく設定
• contribモジュールのauto_explainでは実行計画も取得可能
• 出力が大量になりがちなので注意
• contribモジュールのpg_stat_statementsではクエリの詳細分析が可能
• クエリごとに実行時間や実行回数、キャッシュヒット率などを集計
• 9.2以降は条件値の部分がリテラルのクエリも正規化して集計
• pg_stat_statementsビューでSQLから利用可能→集計などが容易
31

• その他の監視
• テーブルの状態
• pg_statio_all_tablesビュー（キャッシュヒット率、不要領域率など）
• pg_stat_all_tablesビュー（CRUD処理数、VACUUM実行時刻など）
• インデックスの状態
• pg_statio_all_indexesビュー（キャッシュヒット率）
• pg_statindex()関数（インデックス段数や空き領域率など）
• contribモジュールのpgstattupleが必要
• レプリケーション状況
• pg_stat_replicationビュー（スタンバイ数、遅延状況など）
32

• リソース監視
• 接続数
• pg_stat_activityビュー
• 共有バッファ
• pg_buffercacheビュー（ダーティバッファ率など）
• 一時ファイル
• log_temp_files 設定でサーバログに出力
• データベースサイズ
• pg_database_size()
• テーブルサイズ・インデックスサイズ
• pg_relation_size()、pg_table_size()
33
contribモジュールの
pg_buffercache

• サーバログの監視
• ログレベルでのチェック
• ログレベルの意味は…
• PANIC：DBクラスタ全体の問題、全セッション切断
• FATAL：セッションレベルの問題、当該セッションのみ切断
• ERROR：トランザクションレベルの問題、トランザクションアボート
• WARNING：それほど重要でない事象
• FATAL・PANICのログが出ていたら、即確認・対応を
• ERRORはSQLシンタックスエラーでも出るが、基本的には対応を
34

• サーバログの監視
• ログイベントでのチェック
• チェックポイントの頻発
• 自動VACUUMの大量実行
• 接続失敗
• スロークエリの発見
• Etc.
35

pg_statsinfoでの監視
• pg_statsinfoとは
• NTTが開発したPostgreSQL専用の性能監視ツール
• 一次配布元：http://pgstatsinfo.projects.pgfoundry.org
• PostgreSQL 8.3～9.3に対応
• 専用ツールなので、きめ細かい監視が可能
• 性能監視に特化しているので、運用管理ツールが別途必要
• 定期的に「スナップショット」と呼ばれる統計情報を取
得し、それを後から分析するという使い方
• スナップショット保存にPostgreSQLデータベースが必要
• Webレポートを生成するpg_stats_reporterと組み合わ
せて利用
• サンプルレポート：http://pgstatsinfo.projects.pgfoundry.org/files/
report_sample.html
36

• スロークエリのサンプル
37
実行回数、合計実行時間、
一回あたりの実行時間で
ソート可能

• CPU使用率のサンプル
38
CPU使用率の推移と
チェックポイント期間を照合

Zabbixでの監視
• Zabbixとは
• Zabbix SIAのパフォーマンス監視ソリューション
• 複数のサーバを統合的に監視可能
• 「テンプレート」と呼ばれる監視定義を組み込むことで
様々な対象を監視可能
• SMS、Eメールなどでの障害通知が可能
• PostgreSQLについてはpg_monzテンプレートが便利
39

Zabbixでの監視
• pg_monzとは
• TIS株式会社とSRA OSS, Inc. Japanが共同開発した
PostgreSQL用テンプレート
• 一次配布元：http://pg-monz.github.io/pg_monz/
• PostgreSQL 9.2以上に対応
• 定期的に性能値を監視し一部をグラフ化
• 状態別のバックエンドプロセス数
• キャッシュヒット率
• サーバログへのERROR以上の出力数
• 特定イベントでのアラートも実現
• PostgreSQLサーバダウン（プロセス数が0個）
• データベース容量超過
40

Hinemosでの監視
• Hinemosとは
• NTTデータが開発したオープンソースの統合運用監視ソ
フトウェア
• 一次配布元：http://www.hinemos.info/hinemos?banner_id=g01hp002
• オンプレミスとクラウド環境を一括管理
• 状態監視、ジョブ管理、パフォーマンス監視など
• GUIでのオペレーション
41
OSC 2014 Hiroshimaで
NTTデータの石田さんが講演！

切り分け
• まずは事象を把握
• サービス停止？パフォーマンス低下？エラー発生？
• アプリケーションログを確認
• どこで問題が起きている？←エラーハンドリング重要！
• サーバログを確認
• いつ、どのデータベースでどんな異常が発生？
• OSログを確認
• 同時期に関連するメッセージが出ていないか？
• 必要に応じてバックアップ
• 最悪でもトラブル対処前の状態に戻せるように
43

トラブルへの対処
• 起動トラブル
• サーバログに「FATAL: configuration file "＜ファイル
パス＞" contains errors」と出て起動できない
• パラメータ記述間違いなので、設定ファイルを修正する
• サーバログに「FATAL: could not create shared
memory segment: Invalid argument」と出て起動で
きない
• 共有メモリ不足なのでSHMMAXなどのカーネルパラメータを調整する
• サーバログに「FATAL: data directory "＜$PGDATA
パス＞" has group or world access」と出て起動でき
ない
• DBクラスタディレクトリの権限不正なので、chmodで$PGDATAのパーミ
ッションを「0700」に設定する（バックアップ展開時等にありがち）
44

• 接続トラブル
• サーバログに「FATAL: connection limit exceeded for
non-superusers」と出て接続できない
• 一般ユーザの接続数が多すぎるので、不要な接続を
pg_terminate_backend()関数で切断するか、max_connections設定を増
やして再起動する
• サーバログに「FATAL: sorry, too many clients
already」と出て接続できない
• スーパーユーザも含めた接続数が多すぎるので、不要な接続を
pg_terminate_backend()関数で切断するか、max_connections設定を増
やして再起動するか、superuser_reserved_connectionsを増やして再起
動する
• postgresユーザのパスワードを忘れて接続できない
• pg_hba.confの先頭に「postgresユーザでのローカル接続はtrust」の設定
を足して設定をリロードする（接続後はpg_hba.confの設定を戻して再度
リロード推奨）
45

搭載メモリ
を増やす
• ディスクI/Oしたら負け
• いかにディスクI/Oを減らすか？がモダンなDBのアーキテクチャの根本
• 共有バッファに割り当てなくてもOSキャッシュで高速化
• オンラインWALはコミット時にsyncするので効果低
• 性能トラブル
• 検索が遅い
46

速いストレージ
に換える
• SSDなどの高速ストレージの費用対効果は高い
• DBサイズが大きい場合は、ボトルネックになっている箇所だけでも
• オンラインWAL
• 頻繁にアクセスされるキャッシュヒット率の低いテーブル
• 検索が遅い
• テーブルスペース分けましょう
47

48
CPUコア
CPUキャッシュ
共有バッファ
OSキャッシュ
ストレージキャッシュ
プラッタ
高速
低速

• 検索が遅い
• キャッシュヒット率が低い場合は、shared_buffersが足りないので、
shared_buffersを増やして再起動する
• ただし、PostgreSQLが使用できる物理メモリの40%程度が上限
• それでも足りなければ物理メモリの増設を検討
• 検索対象データをWHERE条件で絞り込める場合は、検索条件列をキーと
してパーティション化する
• インデックスオンリースキャン（a.k.a カバーリングインデックス）の効果
が低い（EXPLAIN ANALYZEで表示されるHeap Fetchesが多い）場合
は、VACUUM後に更新されたデータが多いので、対象テーブルを
VACUUMする
• インデックスキーでソートするテーブルのpg_stats.correlationが０に近い
場合は、ヒープデータの並びとキー値の相関が低いので、CLUSTERコマン
ドでヒープデータをキー順にソートする
49

• インデックスが使われない
• EXPLAINの結果が「Seq Scan」の場合はインデックスが使われていない
• 絞り込みやソートに使う列にインデックスを作成する
• インデックスショットガンにならないように！
• EXPLAIN ANALYZEで表示される見積もり件数と実際の件数が乖離してい
る場合は、プランナが使用する統計情報が古いので、ANALYZEコマンド
で統計情報を更新する
• 運用中にこのような状態になる場合は自動VACUUMだけでは不足して
いるので、ワーカー数を増やすか手動ANALYZEをスケジュールする
• ストレージが十分に速い場合は、インデックスを使うプランのコストが過
大見積もりされているので、random_page_costを２～３に下げる
• 共有バッファ以外のメモリがOSキャッシュとして活用されている場合は、
OSキャッシュの効果を過小評価しているので、effective_cache_sizeを増
やす
50

• インデックススキャンの速度が落ちてきた
• pgstatindex(‘＜インデックス名＞’)の結果のleaf_fragmentationが大きい
場合はインデックス断片化しているので、REINDEXコマンドでインデック
スを再構築する
• contribモジュールのpgstattupleが必要
• B-Treeのツリー段数も分かります
• REINDEXはそのインデックスを使うSELECTをブロックするので、同
一定義のインデックスを作って交換（CREATE INDEX
CONCURRENTLY＋DROP INDEX＋RENAME）がお勧め
• 主キーの場合はREINDEX CONCURRENTLYが使えないので、同一定
義のインデックスを作って制約再作成（CREATE INDEX
CONCURRENTLY＋DROP CONSTRAINT＋ADD CONSTRAINT
USING ＜インデックス＞）を使う
51

• 更新処理が遅い
• WAL書き込みがボトルネックになるケースでは…
• WALが$PGDATA内にある場合は、I/O競合で遅くなっている可能性が
あるので、サーバを停止してからpg_xlogを別のボリュームに移動して
元の位置にそれを指すシンボリックリンクを作成する
• 更新セッション数が多く1トランザクションあたりの更新量が多い場合
は、オンラインWALファイルへの書き込みがコミット以外のタイミン
グで発生しているので、まとめて書き込めるように１トランザクショ
ンの更新が収まる程度にwal_buffersを増やして再起動する
• オンラインWALの配置されたストレージのキャッシュをライトバック
に設定する（バッテリバックアップのあるストレージの場合限定）
• サーバクラッシュ時に喪失してよいデータの場合は、UNLOGGEDテー
ブルに変更する
52

• 更新処理が遅い
• 更新処理でのキャッシュヒット率が低い場合は、HOT更新が効くように
FILLFACTORを60～90%程度に設定する
• トレードオフでテーブルサイズは大きくなる
• PostgreSQLはUPDATE時に新しいデータを追加するための空き領域
を必要とする
• 同一ページに空き領域がないと、空き領域マップ（FSM）を参照して
別ページを共有バッファにのせてそこに書き込む→キャッシュ効率低下
• HOT更新とは、非インデックス列の更新において更新元データと同じ
ページに新データを書き込むことでインデックス側の更新を避ける機構
53

• データのロードが遅い
• INSERTを使っている場合は、COPYコマンドに置き換える
• インデックスやトリガーがある状態でロードしている場合は、インデック
スやトリガーを削除・無効化してからロードする
• 空のテーブルへの初期データロードの場合は、同一トランザクション内で
TRUNCATE＋COPYしてWAL出力を抑制する
• wal_level=minimalやarchive_mode=offの設定が必要
• WAL出力がボトルネックになっている場合は、pg_bulkloadでロードする
• 一次配布元：http://pgbulkload.projects.pgfoundry.org/
index_ja.html
54

• クエリ関連トラブル
• 検索結果が文字化けする
• クライアントエンコーディングがうまく設定されていないので…
• 環境変数$PGCLIENTENCODINGで指定する
• 接続パラメータ「client_encoding」で指定する
• ドライバ関数（PHPのpg_set_client_encoding()など）で指定する
• 接続後に「SET client_encoding = ‘SJIS’;」と実行する
• postgresql.confのclient_encodingパラメータでデフォルトを指定する
• 日本語のソート順がおかしい(コード順でなく辞書順)
• Cでないロケールが設定されているので、新しいデータベースをCロケール
で作成してからエクスポート・インポートでデータを移行するか、9.1以降
であれば列単位のCOLLATE指定で回避する
55

• メンテナンス関連トラブル
• 「WARNING: database "＜DB名＞" must be
vacuumed within 177009986 transactions」という
ログが出る（数字部分は可変）
• トランザクションID（XID）の周回が近いので、VACUUMを実行する
• XID周回とは、32bitのXIDがオーバーフローして「3」に戻ること
• 「フリーズ」されていない古いデータが参照できなくなる
• 詳しくは以下のマニュアル・スライド・動画を
• https://www.postgresql.jp/document/9.3/html/routine-vacuuming.
html#VACUUM-FOR-WRAPAROUND
• http://www.slideshare.net/iakio/jpug-ezo20110809
• http://www.ustream.tv/recorded/23501365
• 8.1以降は周回前に警告（上のログ）が出てデータ消失は発生しない
• 運用設計時に自動VACUUMや定期VACUUMを必ず検討すること
56

ちょっとアーキテクチャ
• XID周回とMVCC
• 各トランザクションは単純増加のXIDを持つ
• 自分より小さいXIDのトランザクションがコミットされていれば、そのトラ
ンザクションによる変更は可視（READ COMMITTED分離レベル）
• 0～2は特別なXIDで、通常のXIDよりも常に古いとみなす
• XIDは32bitなので、約42億個のうち「3～UINT_MAX」を循環的に使う
57
0～2は常に「古い」＝可視
現在より先の半分は
「新しい」＝「不可
現在
現在より前の半分は
「古い」＝「可視」
約42億0
約21億

• メンテナンス関連トラブル
• サーバログに「LOG: checkpoints are occurring too
frequently」と出る
• チェックポイントが頻発しているので、checkpoint_segmentsや
checkpoint_timeoutの設定を増やしてチェックポイント発生間隔を広げる
か、 checkpoint_completion_targetを小さくしてチェックポイント所要
時間を短縮します
• チェックポイント間隔を広げると、以下の影響が出ます
• $PGDATA/pg_xlogに溜まるWALファイルが
「checkpoint_segmentsの増分×２」個程度増えます
• クラッシュ時のリカバリ時間が長くなります
• チェックポイント所要時間を短縮すると、チェックポイント中のディス
クI/O量が増え負荷が上がります
58

• レプリケーショントラブル
• pg_stat_replicationでレプリケーション状態を把握
• どこで遅れている？
• リモートに転送→WAL書き込み→WALフラッシュ→変更適用
postgres=# SELECT
pid, client_addr, backend_start, state,
pg_xlog_location_diff(pg_current_xlog_location(), sent_location) sent_delay,
pg_xlog_location_diff(pg_current_xlog_location(), write_location) write_delay,
pg_xlog_location_diff(pg_current_xlog_location(), flush_location) flush_delay,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location) replay_delay
FROM pg_stat_replication;
-[ RECORD 1 ]-+------------------------------
pid | 4976
client_addr |
backend_start | 2014-09-21 09:44:26.081209+09
state | streaming
sent_delay | 0
write_delay | 360
flush_delay | 360
replay_delay | 832
59

• スレーブが追従できなくなった…
• WALの転送が追いつかない場合は、マスタ側のwal_keep_segmentsを増
やすか、スレーブから参照できる位置にアーカイブログを配置する
• スレーブが必要とするWALセグメントがなくなってしまった場合、その
スレーブは廃棄して新たにベースバックアップからスレーブを構築する
• 間もなく出る9.4では、「レプリケーションスロット」という仕組みで
マスタ側でのWALセグメント管理が自動化される
• スレーブ側のロングトランザクションが参照するオブジェクトにマスタ側で
DDLを実行したりすると、スレーブ側への変更が停止する
• WALは送信してあるので、スレーブ側のトランザクションを終了させれ
ば更新が適用されてマスタに追いつく
60
ロングトランザクションの監視、重要！

• pg_stat_replication.sent_location以降のWALファイル
が必要
61
postgres=# SELECT * FROM pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid | 4774
usesysid | 10
usename | postgres
application_name | walreceiver
client_addr |
client_hostname |
client_port | -1
backend_start | 2014-09-21 09:29:39.097147+09
state | streaming
sent_location | 1/E305A068
write_location | 1/E305A068
flush_location | 1/E305A068
replay_location | 1/E305A068
sync_priority | 0
sync_state | async
[pgdata]$ ls /home/postgres/pgdata/pg_xlog/
0000000100000001000000BD.00000028.backup
0000000100000001000000DC
0000000100000001000000DD
0000000100000001000000DE
0000000100000001000000DF
0000000100000001000000E0
0000000100000001000000E1
0000000100000001000000E2
0000000100000001000000E3 ! 00000001 00000001 000000E3
0000000100000001000000E4
0000000100000001000000E5
0000000100000001000000E6
0000000100000001000000E7
... タイムライン番号
セグメント番号

• スレーブサーバが故障した
• 停止したスレーブサーバを復旧して再起動
• マスター側のWALまたはアーカイブWALが残っていれば、自動でレプ
リケーション再開
• 復旧できなかった場合は、ベースバックアップを取得して再構築
• 故障したスレーブが同期レプリケーション先だった場合は、マスタの
postgresql.confのsynnchronous_standby_namesから名前を削除して設
定をリロードする
62

• シングル構成のマスタサーバが故障した
• スレーブのうち一台をマスタに昇格する
• 同期レプリケーション先があればそれを
• 非同期しかない場合はその中で最も進んだスレーブを
• 他のスレーブはそのノードからレプリケーションを継続
• 新マスタのIPアドレスを旧マスタのものに設定すれば、新マスタ起動後
に各スレーブは新マスタに再接続してレプリケーションを再開
• スレーブが一台少なくなるので、マスタに昇格したスレーブの設定を引き継
ぐサーバを構築
63

• HA構成のマスタサーバ（稼働系）が故障した
• マスタサーバ（待機系）にフェイルオーバーした後、そこからベースバック
アップを取得して待機系として再セットアップする
• 旧稼働系が無事に残っていても、いったんフェイルオーバーした場合は捨て
る必要がある
• 旧稼働系の方がデータファイルの内容が新しく、フェイルバックできな
い可能性があるため
• HA構成のマスタサーバ（待機系）が故障した
• マスタサーバ（待機系）からベースバックアップを取得して待機系として再
セットアップする
64

• HA構成のマスタサーバ（稼働系）が故障した
• マスタサーバ（待機系）にフェイルオーバーした後、そこからベースバック
アップを取得して待機系として再セットアップする
• 旧稼働系が無事に残っていても、いったんフェイルオーバーした場合は捨て
る必要がある
• 旧稼働系の方がデータファイルの内容が新しく、フェイルバックできな
い可能性があるため
• HA構成のマスタサーバ（待機系）が故障した
• マスタサーバ（待機系）からベースバックアップを取得して待機系として再
セットアップする
64
稼働系切り替えも
リハーサルを！

解決しない場合は…
• Webで調査
• エラーメッセージなどで検索
• メッセージ全体を引用符で囲んで！→部分文字列でヒットしないように
• テーブル名やデータ部分等は除いて検索しましょう
• バージョンの違いに注意！ • マニュアルで調査
• 日本語マニュアルで調査
• http://www.postgresql.jp/document/9.3/html/index.html
65

• MLに相談
• pgsql-jp（日本語ML）
• http://ml.postgresql.jp/mailman/listinfo/pgsql-jp
• pgsql-generals（英語ML）
• http://www.postgresql.org/list/
• MLに出すときのコツ
• OSやPostgreSQLのバージョン、プラットフォームを明記
• 否定形を避けて「発生した事象」や「試したこと」を記述
• 「～できない」ではなく「～と想定して～したが～になる」など
• できれば再現可能なテストケース
• 手順、テストデータとSQL文、Etc.
• 焦らない（ボランティアベースなので回答がくるとは限りません）
66

• 商用サポートを利用
• SRA OSS, Inc. Japan、SIOS、野村総研（NRI）、ア
シスト、Etc.
• サービスレベルはさまざま
• ドキュメント調査から独自パッチ作成まで
• 過去事例の参照
• ２４時間３６５日対応
67

ご清聴ありがとうございましたQ&A
?
68

PostgreSQLのトラブルシューティング＠第5回中国地方DB勉強会

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to PostgreSQLのトラブルシューティング＠第5回中国地方DB勉強会 (20)

More from Shigeru Hanada (6)

PostgreSQLのトラブルシューティング＠第5回中国地方DB勉強会