前回記事のデプロイメント編に引き続き、巨大な PostgreSQLドキュメントの読むべきポイントを紹介していきます。今回は「PostgreSQLドキュメントの歩き方 – 運用管理編」と題しまして、主として構築済みの PostgreSQL の運用管理を担当する人を対象とします。
PostgreSQLドキュメントの在り処や基本的な見方については前回記事を参照ください。
ロールや権限の調整
PostgreSQLのロール（ユーザ）に関する変更や、一部のオブジェクト（例えば「データベース」や「スキーマ」）に対する権限調整は、アプリケーション保守担当ではなくて、データベース運用管理者の管轄になっていることがあります。
ロールについては概念の説明から具体的なコマンドまで［第21章 データベースロール］で解説されています。現在のロールの一覧と属性の一覧を見る方法については ［psql］コマンドの du オプションを確認しましょう。
オブジェクトの権限設定については残念なことに体系的な説明が書かれたページがありません。しかしながら、［GRANT］、［REVOKE］、［ALTER DEFAULT PRIVILEGES］など権限調整を行うSQLコマンドのページにある解説が参考になります。
- ［III. サーバの管理］⇒［第21章 データベースロール］
- ［VI. リファレンス］⇒［PostgreSQLクライアントアプリケーション – psql］
- ［VI. リファレンス］⇒［SQLコマンド – GRANT］
- ［VI. リファレンス］⇒［SQLコマンド – REVOKE］
- ［VI. リファレンス］⇒［SQLコマンド – ALTER DEFAULT PRIVILEGES］
バックアップとリストア
定常的なバックアップとリストア方式を整備することは運用管理者の大事な仕事です。
バックアップとリストアについては［25章 バックアップとリストア］に体系的な記載があります。この章と文書内のリンク先に必要な情報は揃っています。なお、この章で書かれている３つのバックアップ方式の用語は、他には次のような呼び方がされます。
| ドキュメント上の記載 | その他の言い方 |
| SQLによるダンプ | ダンプ、 論理バックアップ、ホットバックアップ |
| ファイルシステムレベルのバックアップ | コールドバックアップ |
| 継続的アーカイブ | オンラインバックアップ、 オンライン物理バックアップ、 ベースバックアップとWALアーカイビング（アーカイブロギング）、 PITR |
なお、［25.3. 継続的アーカイブとポイントインタイムリカバリ（PITR）］節は文書量が多いです。ひとまず継続的アーカイブとポイントインタイムリカバリ（PITR）を実現するには、［25.3.1. WALアーカイブの設定］、［25.3.2. ベースバックアップの作成］、［25.3.4. 継続的アーカイブによるバックアップを使用した復旧］から読めばよいでしょう。
定期バックアップとローテーション
PostgreSQLにはバックアップの定期取得を制御する機能がありません。それはcronやタスクスケジューラなどのOS機能やジョブスケジューラアプリケーションを使って運用管理者が用意する必要があります。これについてはドキュメントにも記載がありません。
また、定期的にバックアップを採取する場合にはバックアップのローテーション、すなわち古いバックアップや古いWALアーカイブを削除する仕事も必要です。こちらも PostgreSQL機能としてサポートされておらず、ドキュメントにも記載がありません。ただし、古いWALアーカイブを削除するコマンド［pg_archivecleanup］は付属しています。
定期バックアップとローテーションを行うには、ドキュメントに記載されたバックアップ手順を参考に自身でスクリプトを記述する必要があります。この辺りが面倒であれば、pg_rmanなどのサードパーティの各種PostgreSQL用バックアップユーティリティを使う方法も検討してください。
レプリケーションを構成する
バージョン10 から PostgreSQL は二つのレプリケーションをサポートするようになりました。
旧来（バージョン9）からある物理レプリケーション（単にストリーミングレプリケーションとも呼ばれる）については、［26.2. ログシッピングスタンバイサーバ］と［26.5. ホットスタンバイ］に記載があります。また、［27章 リカバリの設定］にある recovery.conf 設定の説明も参照する必要があるでしょう。
また、バージョン10から登場した論理（ロジカル）レプリケーションについては、［31章 論理レプリケーション］に記載されています。
- ［III. サーバの管理］⇒［26.2. ログシッピングスタンバイサーバ］
- ［III. サーバの管理］⇒［26.5. ホットスタンバイ］
- ［III. サーバの管理］⇒［27章 リカバリの設定］
- ［III. サーバの管理］⇒［31章 論理レプリケーション］
性能チューニング
場合によってはデータベースの性能チューニングも運用管理者の担当となっているかもしれません。
性能チューニングにあたって、まずは、現在のPostgreSQL稼働状況が健全かを調べることが必要です。そのための情報収集について［28章 データベース活動状況の監視］に記載があります。また、ログ出力を通して稼動状態を調べる方法も良く行われます。［19.8.3. 何をログに］節の一連の「log_*」設定パラメータについて目を通しておくとよいでしょう。また、実行されているSQLと所要時間の傾向を調べるのに拡張［pg_stat_statements］の使用を検討しても良いかもしれません。
また、個別のSQLについて実行プランを調べる必要があるかもしれません。そのための［EXPLAIN］文の説明を確認しておきましょう。拡張［auto_explain］で本番稼動中にログに実行プランを記録する方法もあります。
実行プランやプランナの統計情報についての基本的な解説は、［14章 性能に関するヒント］に記載されています。データ投入時の性能については、この章に具体的な改善手段がいくつか書かれています。残念ながら、それ以外の SQL実行を改善する手段については記載は多くありません。
- ［III. サーバの管理］⇒［14章 性能に関するヒント］
- ［III. サーバの管理］⇒［19章 サーバの設定］［19.8.3. 何をログに］
- ［III. サーバの管理］⇒［28章 データベース活動状況の監視］
- ［VI. リファレンス］⇒［SQLコマンド – EXPLAIN］
- ［付録F 追加で提供されるモジュール］⇒［F.4. auto_explain］
- ［付録F 追加で提供されるモジュール］⇒［F.30. pg_stat_statements］
運用管理編まとめ
以上で運用管理編は終わりです。前回のデプロイメント編には運用マターともいえる内容も含まれていますので、前回記事も合わせて参照いただけましたらと思います。最後にアプリケーション開発編も追加する予定です。