変更要約: 初版(主題S2・S2.1〜S2.5)
2.2標準付属ツール
PostgreSQLに標準付属するコマンド群を学びます。サーバーの起動・停止・再読込を担うpg_ctl、ロール作成・削除のcreateuser・dropuser、データベース作成・削除のcreatedb・dropdb、対話ターミナルのpsql、ビルド情報を返すpg_config、クラスタの制御情報を表示するpg_controldata、サーバーの生死を確認するpg_isready、WALをリセットするpg_resetwal、そしてpsqlのメタコマンド(\d \l \dt \du \c \? \h \timing)を押さえます。
PostgreSQLには、サーバーの起動から日々の対話操作、状態確認までを担う標準付属のコマンド群が揃っています。これらは覚える数こそ多いものの、それぞれ役割がはっきり分かれているため、「何をしたい時にどのコマンドか」を対応づけて押さえれば得点源になります。
2.2.1pg_ctl とユーザー/データベース管理コマンド
- pg_ctl=PostgreSQLサーバープロセスを制御する中心コマンド。サブコマンド
start(起動)・stop(停止。-mで停止モード指定)・reload(設定ファイルの再読込のみ、接続は維持)・restart(停止して起動し直す)・status(稼働状態を確認)を持ちます。 - createuser/dropuser=データベースロール(ユーザー)を作成・削除するコマンドラインツール。内部的にはSQLの
CREATE ROLE/DROP ROLEを実行するラッパーで、-s(スーパーユーザー権限付与)等のオプションが用意されています。 - createdb/dropdb=データベースを作成・削除するコマンドラインツール。内部的にはSQLの
CREATE DATABASE/DROP DATABASEのラッパーです。既定ではtemplate1をコピーしてデータベースを作成します。
2.2.2psql と診断系コマンド
- psql=PostgreSQLの標準対話ターミナル。SQL文の実行に加え、
\で始まるメタコマンドが使えます:\l(データベース一覧)・\c(データベース切替)・\dt(テーブル一覧)・\d(テーブル等の構造表示。\d テーブル名で詳細)・\du(ロール一覧)・\timing(各クエリの実行時間表示をトグル)・\?(メタコマンドのヘルプ)・\h(SQLコマンドのヘルプ)。 - pg_config=インストールされたPostgreSQLのビルド時設定・バージョン・各種ディレクトリパス(インクルードディレクトリ等)を表示します。pg_controldata=データディレクトリの制御ファイル情報(データベースクラスタの状態、最終チェックポイント位置、WALのタイムラインID等)を表示する読み取り専用ツールです。
- pg_isready=サーバーが接続を受け付けられる状態かどうかを簡易チェックするツール(監視スクリプトからの死活確認に使う。終了コードで判定可能)。pg_resetwal=破損したWAL(先行書き込みログ)をリセットし、起動不能になったクラスタを強制的に起動可能な状態に戻す最終手段のツール(データ不整合のリスクを伴うため他に手段が無い場合のみ使用)。
「pg_ctl reloadは接続を維持したまま設定ファイルのみ再読込・restartは接続を切って再起動」「createuser/createdbはCREATE ROLE/CREATE DATABASEのラッパー」「\lはDB一覧・\dtはテーブル一覧・\duはロール一覧・\dは構造表示」「pg_isready=死活確認・pg_resetwal=WAL強制リセット(最終手段)」が最頻出です。メタコマンドの文字と意味の対応(\lと\dtの混同等)も繰り返し狙われます。
運用の一日を思い浮かべると、これらのコマンドの使い分けが見えてきます。朝、設定変更の依頼が来てpostgresql.confのmax_connectionsを変えたいとします。この変更は再起動が必要なパラメータなので、pg_ctl restart -D $PGDATAで安全に停止・起動し直します。一方、ログ出力先だけを変えるような再起動不要なパラメータであれば、接続を切らずに済むpg_ctl reload(あるいはSQLのSELECT pg_reload_conf()相当)で反映させ、業務影響を最小化します。次に新しいアプリ用のロールとデータベースを用意する依頼が来れば、createuser app_user→createdb -O app_user app_dbという順で作成し、実際にpsql -U app_user -d app_dbで接続確認します。psql内では\lで作成したデータベースが一覧に出ているか、\duでapp_userロールが意図した権限で存在するかを目視確認するのが定番の手順です。監視の文脈では、ロードバランサーやオーケストレーションツールが定期的にpg_isready -h dbhostを実行し、終了コード0(受付可能)以外を検知したら切り離す、という自動化に組み込まれます。最後に、万一停電などでクラスタが破損し起動すらできないという深刻な事態に陥った場合、他の復旧手段が尽きた最終手段としてpg_resetwalを検討しますが、これはトランザクションの整合性を犠牲にしてでも起動を優先する強制措置であるという性質を理解しておく必要があります。
| コマンド | 役割 | 備考 |
|---|---|---|
| pg_ctl reload | 設定ファイルのみ再読込 | 接続を維持 |
| pg_ctl restart | 停止して起動し直す | 接続は切れる |
| pg_isready | 接続受付可否の簡易チェック | 監視の死活確認に利用 |
| pg_resetwal | WALを強制リセット | データ不整合リスクの最終手段 |
ひっかけ: 「設定ファイルを変更した内容は、どんな変更でもpg_ctl reloadだけで即座に反映される」は誤りです。max_connectionsのように再起動(restart)が必要なパラメータも存在し、reloadだけでは反映されません。また「\dtはデータベース一覧を表示する」も誤り=\dtはテーブル一覧・\lがデータベース一覧です。さらに「pg_resetwalは日常的なメンテナンスで使う安全なコマンド」という前提も誤り=これはデータ不整合のリスクを伴う最終手段であり、通常運用では使いません。
2.2.3この節のまとめ
- pg_ctl=start/stop/reload/restart/status。reloadは接続維持で設定再読込のみ・restartは接続を切って再起動
- createuser/dropuser・createdb/dropdbはCREATE/DROP ROLE・DATABASEのラッパー。psqlのメタコマンド(
\l\dt\du\d\c\?\h\timing)を区別 - pg_config=ビルド情報・pg_controldata=制御ファイル情報・pg_isready=死活確認・pg_resetwal=WAL強制リセット(最終手段)
進捗の記録にはログインが必要です。
理解度チェック
(軽い確認用)Q1. postgresql.conf のログ出力先だけを変更した。稼働中の接続を切断せずに、この変更をサーバーへ反映させる最も適切な方法は?
Q2. psql に接続した状態で、サーバー上に存在するデータベースの一覧を確認したい。使うべきメタコマンドは?
Q3. 停電の影響でPostgreSQLサーバーが破損し、通常の起動手順では一切起動できなくなった。他の復旧手段がすべて尽きている場合の最終手段として検討されるコマンドは?

