目的別ガイド：運用管理編

PostgreSQLの運用管理として必要な作業には何があるのでしょうか？運用要件によって必要な作業は変わってきますが、およそ以下の事項が挙げられます。

メンテナンス

DBは、日々の運用により内部状態が変化していきます。常に一定のパフォーマンスを発揮するには、良い状態を保つためのメンテナンスが必要です。主に VACUUM や ANALYZE が該当します。

監視

異常を事前に察知する、もしくは発生後に原因を調査するために、DBやOSの状態を監視しておきます。適切なトラブルシューティングのためには、システムリソースやPostgreSQLの稼動統計情報の取得が必要です。

バックアップ/リストア

停電程度ならばトランザクション結果はクラッシュ・リカバリできますが、ディスクの故障や誤操作によるデータ消失に対処するにはバックアップの取得が必要です。リカバリ要件やバックアップ/リストアにかかる時間を検討して、バックアップ方式を選びましょう。

アップグレード / アップデート

PostgreSQL の新版のリリースには大きく2つあります。バージョン名 (x.y.z) の x または y が変化するメジャーリリース (8.3 → 8.4) と、z が変化するマイナーリリース (8.3.6 → 8.3.7) です。マイナーリリースでは、互換性が完全に保たれたまま、バグやセキュリティ問題の修正が行われます。マイナーリリースには柔軟に追随できるようにしておきましょう。

上記をどんなタイミングで行えば良いのかを、それぞれ「運用前の設定」「日単位」「月単位～」「不定期」というカテゴリで整理しています。

運用前に行うこと

ログ関連の設定

サーバログは何か問題があった場合に、まず確認すべき重要な情報です。必ずどこかにログを残すよう、PostgreSQLの設定をしておきましょう。(→ ログ関連の設定)

稼動統計情報関連の設定

PostgreSQLは、自身でDB内部の活動状態をモニタリングしており、それをテーブル情報として蓄積しています(この情報を稼動統計情報と言います)。これはとても有用なので、是非取得するように設定しておきましょう。(→ 稼動統計情報を活用しよう)

autovacuum

autovacuum機能は、テーブルの状態を監視して、然るべきタイミングに自動でVACUUMをする機能です。8.3でデフォルトonになっています。autovacuumを遅延させながら行ったり、規定時間以上かかった場合にログに出力するなどの設定も可能です。

日単位で行うこと

VACUUM, ANALYZE は autovacuum に任せられますが、その他の定期的にジョブを実行するには、別途ジョブ実行ツールが必要です。 UNIX/Linux では cron (crontab)、Windows ではタスク・スケジューラが一般的ですが、マルチプラットフォームで PostgreSQL 専用の pgAgent も利用できます。

VACUUM

PostgreSQLは追記型のアーキテクチャのため、更新や削除処理によりDB内部にガベージが発生します。ガベージは、DBの肥大化やキャッシュ利用効率の低下を招きます。このガベージを回収するメンテナンスがVACUUMです。autovacuumに任せてしまうこともできます。VACUUMを手動で行う場合は、VERBOSEオプションを付与しておくと、所要時間や回収したガベージ量が確認できるため有用です。

ANALYZE

DBMSがDB内のデータを検索する際は、データの並び順や物理的な配置などの統計情報を利用して、最も効率の良い方法でデータを検索します。ANALYZEは、この統計情報を最新のデータ状態を基にリフレッシュするコマンドです。autovacuum機能により自動で実施することもできます。

システムリソースの取得

DBMSやOSなどのソフトウェアが消費しているHWリソースを指してシステムリソースとしています。典型的には、CPU使用率やデバイス使用率、各プロセスの活動状態などの情報になります。これらを記録しておくことで、問題発生の事前把握や、問題発生時の原因の絞込みが可能です。特に、アーカイブログの蓄積やDB肥大化により引き起こされがちなディスクフルには十分注意しましょう。

バックアップ

バックアップには、DBの内容を論理的な形式(SQL)で取得する方法と、ファイルシステムのファイルとして取得する方法の大きく2種類があります。いずれもPostgreSQLの稼働中に行えますが、以下の違いがあります。(→ バックアップの概要と方式一覧)

論理バックアップ (pg_dump)

pg_dump を使ってDBのデータをダンプします。一部のテーブルやDBのスキーマ、データ内容だけを取得するといった選択が可能です。SQLの形でデータの取得を行い、主に小規模のDBやメジャーバージョン間での移行、他のDBMSへの移行の際に使用します。

オンライン・バックアップ

オンライン・バックアップでは、DBクラスタをrsyncやcpコマンドを使い、ファイルとして取得します。DBやテーブル単位の指定はできず、DBクラスタ全体のバックアップとなります。アーカイブログを取得しておくことが必須です。アーカイブログと組み合わせて、ダウン直前までのリカバリが可能なPITRが必要な際に使用します。

月単位～で行うこと

月次メンテナンス

日々のメンテナンスに加え、以下のコマンドを実施することで、定期的にDBの状態を最適化しておくと良いです。下記のコマンドの実施中はテーブルやインデックスへのアクセスができなくなるので、システムを停止できるような定期メンテナンス枠を確保し、そこで実施すると良いでしょう。

REINDEX

インデックスの再構築をします。

CLUSTER

インデックス順に、テーブルデータを物理的に再編成します。テーブルの物理的な圧縮+再編成+REINDEXの効果があります。CLUSTERをオンラインで実施可能なpg_reorgというプロダクトもあります。

VACUUM FULL

テーブルを物理的に圧縮します。DBが肥大化してディスクフル直前の状態に実施します。

アップグレード / アップデート

アップグレード

PostgreSQLではメジャーバージョン間のDBクラスタの互換性がありません。そのため、メジャーバージョンの異なるPostgreSQLに移行する際は、pg_upgrade による変換するか、pg_dump でデータを抽出し、それを新しい (あるいは古い) メジャーバージョンの PostgreSQL へ流し込む作業が必要です。加えて、メジャーバージョン間では PostgreSQL の振る舞いが変わることがあるため、APのチェックやパラメータの再設計などが必要になります。

アップデート

PostgreSQL のマイナーバージョン間では、DBクラスタに互換性があるため、基本的にはバイナリの差し替えのみで済みます。バグ修正は行われますが、AP から見える PostgreSQL の振る舞いは原則的には変わりません。 セキュリティやデータ破損に関する不具合が修正されていることもあるので、アップデートにはなるべく積極的に追随するようにしましょう。

不定期に行うこと

何らかの原因により、DBサーバが重くなったりPostgreSQLが反応しなくなった場合には、応急処置が必要となります。システムダウンの時間をなるべく短くするため、万が一の際の対処手段は用意しておきます。

システム/PostgreSQLの再起動

OSがハングしてしまったり、PostgreSQLのプロセスがOOM-Killerなどでいなくなってしまった場合などは、OSのリブートやPostgreSQLの再起動を行いましょう。

フェイルオーバ

一般的には、何らかのレプリケーションツールやHeartbeatなどの死活監視ツールを用いて、現用系(アクト)と待機系(スタンバイ)の2台のサーバを用意しておき、現用系に問題が起こった際には、速やかに待機系に切り替える処理を行います。フェイルオーバが発生した際は、現用系のサーバに記録されたログ等から原因の究明を行い、すぐに新規の待機系として使用できるようにしましょう。