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

第五回　中国地方DB勉強会株式会社メトロシステムズ

花田　茂

PostgreSQL　　のトラブルシューティング

Copyright © Metro Systems Co.,Ltd. All rights reserved.

• 花田茂• @s87

• [email protected]

• 普段の業務• PostgreSQLの本体開発、関連ツール開発

• OSS導入コンサル・サポート

• OSSトレーニング講師

• 日本PostgreSQLユーザ会（JPUG）で活動• 勉強会やイベントでの講演

• ドキュメント翻訳

自己紹介

東京・池袋のこの辺で仕事してます

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

http://h50146.www5.hp.com/services/ci/opensource/pdfs/PostgreSQL_Internals.pdf





• 勉強会・イベント• 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

http://www.ustream.tv/channel/jpug-shikumi

http://www.ustream.tv/channel/jpug-shikumi


• 書籍• PostgreSQL全機能バイブル• 技術評論社

• 鈴木啓修　著

• http://gihyo.jp/book/2012/978-4-7741-5392-6

• 内部構造から学ぶPostgreSQL 設計・運用計画の鉄則• 技術評論社

• 勝俣智成，佐伯昌樹，原田登志　著

• https://gihyo.jp/book/2014/978-4-7741-6709-1


7

http://gihyo.jp/book/2012/978-4-7741-5392-6

http://gihyo.jp/book/2012/978-4-7741-5392-6

というわけで

8


• きちんとバックアップ• バックアップ方式の選び方

• きちんとログ記録• トラブルに備えるサーバログ設定とログの読み方

• きちんと監視• 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

http://www.ustream.tv/recorded/48237629

http://www.ustream.tv/recorded/48237629

http://www.slideshare.net/satock/29shikumi-backup

http://www.slideshare.net/satock/29shikumi-backup

きちんとログ記録

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


サーバログの読み方• ログファイルの例• 起動～接続

22

...2014-09-18 15:17:11 JST @[541a78e7.7cb1:1] LOG: database system was shut down at 2014-09-18 15:17:04 JST2014-09-18 15:17:11 JST @[541a78e7.7cac:5] LOG: database system is ready to accept connections2014-09-18 15:17:11 JST @[541a78e7.7cb5:1] LOG: autovacuum launcher started2014-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=postgres2014-09-18 15:19:28 JST postgres@postgres[541a78fe.7cc7:3] LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31943.0", size 535592962014-09-18 15:19:28 JST postgres@postgres[541a78fe.7cc7:4] STATEMENT: explain analyze select * from pgbench_accounts order by abalance;...

接続のないログではユーザ名やホスト名は出ない

接続要求時はユーザ・ホストともに不明

「LOG:」部分はメッセージの重要性に応じて「ERROR:」や「PANIC:」などに変わる


サーバログの読み方• ログファイルの例• 検索（一時ファイル生成）

23

...2014-09-18 15:17:11 JST @[541a78e7.7cb1:1] LOG: database system was shut down at 2014-09-18 15:17:04 JST2014-09-18 15:17:11 JST @[541a78e7.7cac:5] LOG: database system is ready to accept connections2014-09-18 15:17:11 JST @[541a78e7.7cb5:1] LOG: autovacuum launcher started2014-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=postgres2014-09-18 15:19:28 JST postgres@postgres[541a78fe.7cc7:3] LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31943.0", size 535592962014-09-18 15:19:28 JST postgres@postgres[541a78fe.7cc7:4] STATEMENT: explain analyze select * from pgbench_accounts order by abalance;...

一時ファイルのサイズ（バイト単位）

セッションIDとセッション内行番号でひもづけが可能

「STATEMENT:」行にはメインのログの発生元クエリが出力

される


サーバログの読み方• ログファイルの例• チェックポイント

24

...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: xlog2014-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...

チェックポイントが頻発しているという警告

チェックポイントで発生した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

http://tech-sketch.jp/2014/07/postgresqlfluentd.html

http://tech-sketch.jp/2014/07/postgresqlfluentd.html

きちんと監視

26


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


PostgreSQLでの監視• その他の監視• テーブルの状態• pg_statio_all_tablesビュー（キャッシュヒット率、不要領域率など）

• pg_stat_all_tablesビュー（CRUD処理数、VACUUM実行時刻など）

• インデックスの状態• pg_statio_all_indexesビュー（キャッシュヒット率）

• pg_statindex()関数（インデックス段数や空き領域率など）

• contribモジュールのpgstattupleが必要

• レプリケーション状況• pg_stat_replicationビュー（スタンバイ数、遅延状況など）

32


PostgreSQLでの監視• リソース監視• 接続数• pg_stat_activityビュー

• 共有バッファ• pg_buffercacheビュー（ダーティバッファ率など）

• 一時ファイル• log_temp_files 設定でサーバログに出力

• データベースサイズ• pg_database_size()

• テーブルサイズ・インデックスサイズ• pg_relation_size()、pg_table_size()

33

contribモジュールのpg_buffercache


PostgreSQLでの監視• サーバログの監視• ログレベルでのチェック• ログレベルの意味は…

• PANIC：DBクラスタ全体の問題、全セッション切断

• FATAL：セッションレベルの問題、当該セッションのみ切断

• ERROR：トランザクションレベルの問題、トランザクションアボート

• WARNING：それほど重要でない事象

• FATAL・PANICのログが出ていたら、即確認・対応を

• ERRORはSQLシンタックスエラーでも出るが、基本的には対応を

34


PostgreSQLでの監視• サーバログの監視• ログイベントでのチェック• チェックポイントの頻発

• 自動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

http://pgstatsinfo.projects.pgfoundry.org

http://pgstatsinfo.projects.pgfoundry.org

http://pgstatsinfo.projects.pgfoundry.org/files/report_sample.html





pg_statsinfoでの監視• スロークエリのサンプル

37

実行回数、合計実行時間、一回あたりの実行時間で

ソート可能


pg_statsinfoでの監視• 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

http://pg-monz.github.io/pg_monz/

http://pg-monz.github.io/pg_monz/


Hinemosでの監視• Hinemosとは• NTTデータが開発したオープンソースの統合運用監視ソ

フトウェア• 一次配布元：http://www.hinemos.info/hinemos?banner_id=g01hp002

• オンプレミスとクラウド環境を一括管理

• 状態監視、ジョブ管理、パフォーマンス監視など

• GUIでのオペレーション

41

OSC 2014 HiroshimaでNTTデータの石田さんが講演！

きちんと対処

42


切り分け• まずは事象を把握• サービス停止？パフォーマンス低下？エラー発生？

• アプリケーションログを確認• どこで問題が起きている？←エラーハンドリング重要！

• サーバログを確認• いつ、どのデータベースでどんな異常が発生？

• 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


トラブルへの対処• 性能トラブル• 検索が遅い

46

搭載メモリを増やす

• ディスクI/Oしたら負け

• いかにディスクI/Oを減らすか？がモダンなDBのアーキテクチャの根本

• 共有バッファに割り当てなくてもOSキャッシュで高速化

• オンラインWALはコミット時にsyncするので効果低


トラブルへの対処• 性能トラブル• 検索が遅い

47

速いストレージに換える

• SSDなどの高速ストレージの費用対効果は高い

• DBサイズが大きい場合は、ボトルネックになっている箇所だけでも

• オンラインWAL

• 頻繁にアクセスされるキャッシュヒット率の低いテーブル

• テーブルスペース分けましょう


ちょこっとアーキテクチャ

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

http://pgbulkload.projects.pgfoundry.org/index_ja.html





トラブルへの対処• クエリ関連トラブル• 検索結果が文字化けする• クライアントエンコーディングがうまく設定されていないので…

• 環境変数$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

http://www.slideshare.net/iakio/jpug-ezo20110809

http://www.slideshare.net/iakio/jpug-ezo20110809


ちょっとアーキテクチャ• XID周回とMVCC• 各トランザクションは単純増加のXIDを持つ• 自分より小さいXIDのトランザクションがコミットされていれば、そのトラ

ンザクションによる変更は可視（READ COMMITTED分離レベル）

• 0～2は特別なXIDで、通常のXIDよりも常に古いとみなす

• XIDは32bitなので、約42億個のうち「3～UINT_MAX」を循環的に使う

57

0～2は常に「古い」＝可視

現在より先の半分は「新しい」＝「不可

現在

現在より前の半分は「古い」＝「可視」

0約42億

約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フラッシュ→変更適用

59

postgres=# SELECTpid, 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_delayFROM pg_stat_replication;-[ RECORD 1 ]-+------------------------------pid | 4976client_addr |backend_start | 2014-09-21 09:44:26.081209+09state | streamingsent_delay | 0write_delay | 360flush_delay | 360replay_delay | 832


トラブルへの対処• レプリケーショントラブル• スレーブが追従できなくなった…• 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 | 4774usesysid | 10usename | postgresapplication_name | walreceiverclient_addr |client_hostname |client_port | -1backend_start | 2014-09-21 09:29:39.097147+09state | streamingsent_location | 1/E305A068write_location | 1/E305A068flush_location | 1/E305A068replay_location | 1/E305A068sync_priority | 0sync_state | async

[pgdata]$ ls /home/postgres/pgdata/pg_xlog/0000000100000001000000BD.00000028.backup0000000100000001000000DC0000000100000001000000DD0000000100000001000000DE0000000100000001000000DF0000000100000001000000E00000000100000001000000E10000000100000001000000E20000000100000001000000E3 ! 00000001 00000001 000000E30000000100000001000000E40000000100000001000000E50000000100000001000000E60000000100000001000000E7... タイムライン番号

セグメント番号


トラブルへの対処• レプリケーショントラブル• スレーブサーバが故障した• 停止したスレーブサーバを復旧して再起動

• マスター側の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

http://www.postgresql.jp/document/9.3/html/index.html

http://www.postgresql.jp/document/9.3/html/index.html


解決しない場合は…• 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

http://ml.postgresql.jp/mailman/listinfo/pgsql-jp

http://ml.postgresql.jp/mailman/listinfo/pgsql-jp

http://www.postgresql.org/list/

http://www.postgresql.org/list/


解決しない場合は…• 商用サポートを利用• SRA OSS, Inc. Japan、SIOS、野村総研（NRI）、ア

シスト、Etc.• サービスレベルはさまざま

• ドキュメント調査から独自パッチ作成まで

• 過去事例の参照

• ２４時間３６５日対応

67

ご清聴ありがとうございました

Q&A

68

?

Technology

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