はじめに

Windows 11環境で「pgAdmin 4が起動しない」不具合について、その現象の具体例と、原因・対策を紹介します。

動作環境

• Windows 11 Pro 24H2
• PostgreSQL 17.6
• pgAdmin 4 ：Ver. 9.6　Python Ver. 3.13.6

第1位　「The pgAdmin 4 server could not be contacted」エラー

pgAdmin 4 起動時の現象

起動時にブラウザが開くが、上記エラー「The pgAdmin 4 server could not be contacted」が表示されて操作不能となる

原因

セッションファイルの破損、または前回の異常終了

対策

以下のようにRoamingフォルダ内の「pgAdmin」フォルダを削除する

Remove-Item "$env:APPDATA\pgAdmin" -Recurse -Force

又は、手動で削除

C:\Users\ユーザー名\AppData\Roaming\pgAdmin

再起動後、正常に起動するかどうかを確認する。

amzn.to

Bigme B6、カラー電子書籍リーダー、4GB+64GB 6インチ電子ペーパータ 、Android 14...

レビュー：ストレージ容量が増やせないKindleが不便で購入しました。SDも使えて、持っている本を全部ダウンロードしてオフラインでもいつでも読めるのは便利ですね。PlayBooksでも何冊か買っているので1つの端末で完結するのも便利です。

第2位　PostgreSQLサービスが停止している

pgAdmin 4 起動時の現象

pgAdminは起動するが、データベースに接続できない

原因

PostgreSQLサービスに異常があるため、pgAdminがサービスに接続できない。

対策

PostgreSQLサービスの存在とその状態（起動中か停止中）を確認する

確認方法（例）

# PostgreSQLサービスの存在と状態を確認
Get-Service | Where-Object { $_.Name -like "postgresql*" }

出力例

• サービスは存在しているが、起動していない場合

Status   Name               DisplayName
------   ----               -----------
Stopped  postgresql-x64-17  PostgreSQL 17

サービスが存在しない場合は、何も表示されません。

サービスが起動していない場合

サービスを起動する。
起動例：サービス名はPostgreSQLのバージョンによって異なるので注意

Start-Service -Name "postgresql-x64-17"

PostgreSQLが未インストールの場合

下記のコマンドでインストールするか、公式ダウンロードサイトからインストーラーをダウンロードしてインストールする。

New-Service -Name "postgresql-x64-17" -BinaryPathName "C:\Program Files\PostgreSQL\17\bin\pg_ctl.exe runservice" -DisplayName "PostgreSQL 17" -StartupType Automatic

サービス登録が失敗している場合

以下のようにサービスを登録する（パスは環境に応じて調整）

New-Service -Name "postgresql-x64-17" -BinaryPathName "C:\Program Files\PostgreSQL\17\bin\pg_ctl.exe runservice" -DisplayName "PostgreSQL 17" -StartupType Automatic

amzn.to

Amazon Kindle - 目に優しい、かさばらない、大きな画面で読みやすい

レビュー：初めてのKindleタブレット。サイズ選びに迷いましたが、軽くて持ち運びやすく、寝転んで読むのにも快適です。読書がますます楽しくなりこちらを選んで正解でした。

第3位　プロキシ設定がlocalost通信を妨害している

pgAdmin 4 起動時の現象

• ブラウザは開くが「The pgAdmin 4 server could not be contacted」と表示される
• 真っ白な画面のまま何も表示されない

原因

Windowsのプロキシ設定がlocalhost通信を外部に転送しようとして失敗する。

pgAdmin 4は、起動時にローカルHTTPサーバー（通常 http://127.0.0.1:5050）を立ち上げてUIを表示します。
しかし、Windowsのプロキシ設定が有効になっていると、localhostへの通信がプロキシ経由になり、pgAdminのローカルサーバーに接続できなくなることがあります。

• この問題が起こり易い環境
  • VPN接続中
  • 企業ネットワークでグローバルプロキシが強制されている
  • Windowsの「自動プロキシ検出」が有効になっている

対策

localhost通信をプロキシから除外する

• 環境変数 NO_PROXY を設定する（推奨）
  pgAdminの起動時にこの環境変数が設定されていれば、localhost通信がプロキシを経由せず直接処理されます。

PowerShellで設定（ユーザー環境変数：pgAdmin 4 再起動必要）

[System.Environment]::SetEnvironmentVariable("NO_PROXY", "127.0.0.1,localhost", "User")

コマンドプロンプトで設定（永続化：：pgAdmin 4 再起動必要）

setx NO_PROXY "127.0.0.1,localhost"

amzn.to

【Kindle (2024年発売・2022年発売) 用】Amazon純正 ファブリックカバー (マッチャ)

レビュー：純正の製品かそうでないものを購入するか迷いましたが、結論これで大満足でした。触り心地が良く、ピンクの発色もとても良いです。カバーの開閉で画面がオンオフされるなど機能性も全く問題ありません。女性にプレゼントしましたが、ケースに起因する重量感は特段感じなかったとのこと。ケースに迷っている方はマストバイの商品かと思います。

第4位　管理者権限で起動していない

pgAdmin 4 起動時の現象

起動はするが、設定変更や接続が反映されない。

原因

pgAdminは一部の操作に管理者権限が必要。

対策

ショートカットを右クリック → 「管理者として実行」。

• 常に管理者として実行する方法
  • ショートカットの「プロパティ」
  • 「互換性」タブ
  • 「管理者としてこのプログラムを実行」にチェック

amzn.to

【Android16 タブレット 11インチ 世界初登場】

価格が安いのでさほど期待はしていませんでしたが、画質は悪くないYouTube動画も問題なくみれます。ゲームはやらないので、普段使いなら十分な性能だと思います。また付属品が充実している点も購入ポイントでした。

第5位　pgAdminのバージョンが古い

pgAdmin 4 起動時の現象

Windows 11で起動しない、またはUIが崩れる。

原因

古いバージョンでは互換性に問題がある。

対策

最新版のpgAdmin 4をインストールする。

winget install --id=pgAdmin.pgAdmin4

コマンドの実行で「入力条件に一致するパッケージが見つかりませんでした」が表示される場合

• 原因１
  リポジトリが不足している

リポジトリの確認とリセット。Powershellで以下のコマンドを実行

winget source list

winget と msstore の両方が表示されない場合は、以下のコマンドでリセットし、再度「winget source list」コマンドで確認。

winget source reset --force

筆者の場合は、「winget と msstore 」の両方が入ってました。

• 原因２
  IDが誤っているか登録されていない。pgAdmin.pgAdmin4というIDが現在のwingetリポジトリに存在しない可能性があるので、正しいIDを以下のコマンドで検索します。

winget search pgAdmin

筆者の環境では、正しいIDは「PostgreSQL.pgAdmin」でした。

正しいIDが分かったので、以下のコマンドでインストールします。

winget install --id=PostgreSQL.pgAdmin

インストール中は、下記のプログレスバーが表示されます。

まとめ

pgAdmin 4の起動トラブルは「環境ファイル」「サービス」「権限」「プロキシ設定」等、多岐にわたります。特にプロキシがlocalhost通信を妨害するケースでは、環境変数 NO_PROXY の設定やWindowsのプロキシ除外設定が有効です。ログファイルやポート状態を確認しながら、再現性のある手順で対処することで、初心者でも安定した起動環境を構築できます。

WALの遅延と肥大化とは？

PostgreSQLの非同期レプリケーションで最も多く発生するトラブルが、WALの遅延と肥大化です。

WALの遅延と肥大化とは、プライマリの変更情報がスタンバイ側に反映されるのが遅れ、その結果、反映されないWALが溜まってディスク容量を圧迫する事をいいます。

WALが遅延・肥大化するとどうなる？

スタンバイの同期不能

未だスタンバイに反映されていないWALが削除され、スタンバイの再構築が必要になります。

フェルオーバーが不可能になる

スタンバイが遅延してもプライマリは動作を続ける為、プライマリの状態に追いつけなくなります。よって、プライマリが故障した場合、スタンバイがプライマリとして動作できなくなります。

ディスク容量不足によるPostgreSQLの停止

WALファイルは プライマリ側のpg_wal ディレクトリに蓄積されますが、最終的に書き込み不能となり、PostgeSQLが停止します。

バックアップが失敗する

WALアーカイブが遅延すると、PITR（ポイントインリカバリ）が不可能になります。

• PITR（ポイントインリカバリ）
  ベースバックアップ（物理バックアップ）とWALアーカイブを使用してバックアップ取得時点から任意の時刻までWALを「再生」する機能。障害直前や指定時刻の状態に復元できる。

PostgreSQL徹底入門 第4版 インストールから機能・仕組み、アプリ作り、管理・運用まで | 近藤 雄太, 正野 裕大, 坂井 潔, 鳥越 淳, 笠原 辰仁, 石井 達夫 |本 | 通販 | Amazon

Amazonで近藤 雄太, 正野 裕大, 坂井 潔, 鳥越 淳, 笠原 辰仁, 石井 達夫のPostgreSQL徹底入門 第4版 インストールから機能・仕組み、アプリ作り、管理・運用まで。アマゾンならポイント還元本が多数。近藤 雄太, 正野...

amzn.to

WAL遅延の原因

スタンバイ側のI/O性能不足

HDDや低IOPSのクラウドストレージでは、WALの書き込み・適用が追いつかず replay_lag が発生しやすくなります。特に読み取りクエリと競合する場合、顕著になります。

• IOPS（アイオプス）
  1秒間に何回の「読み込み（Read）」や「書き込み（Write）」操作ができるかの指標
• replay_lag
  スタンバイサーバがプライマリサーバにどれだけ遅れているかを示す指標
  例）00:00:03.456 → 約3.4秒の遅延

ネットワーク帯域の不足・不安定な接続

プライマリ→スタンバイ間のWAL転送が詰まり、write_lag や flush_lag が発生します。VPNやクラウド間通信で多発し易い遅延です。

• write_lag
  プライマリがWALを送信してから、スタンバイがそれを受信してメモリに書き込むまでにかかった時間
• flush_lag
  スタンバイがWALをディスクに書き込むまでにかかった時間

スタンバイのWAL適用処理の遅延

スタンバイでのクエリ実行やバックグラウンドプロセスがWALの適用を妨げたり、CPU競合やメモリ不足により発生する遅延です。

プライマリ側の送信プロセス不足（max_wal_senders）

複数のスタンバイがある場合、送信プロセスが足りずにWAL送信が滞り発生します。

• max_wal_senders
  PostgreSQL の設定パラメータ。WALをスタンバイやバックアップツールに送信するプロセスの最大数を指定する。

wal_keep_size の不足によるWAL早期削除

スタンバイが遅延しているのに、プライマリが未反映のWALを削除してしまいます。

• wal_keep_size
  PostgreSQL の設定パラメータ。プライマリサーバが保持しておくWALファイルのサイズを指定する。

アーカイブ処理の詰まり（archive_command）

アーカイブ先の容量不足やスクリプトエラーによってWALが溜まり、遅延や肥大化が発生します。

• archive_command
  WALを外部に保存（アーカイブ）するためのコマンド。特に PITR（Point-In-Time Recovery）や長期バックアップ、スタンバイ再同期において重要な役割を果たします。

遅延状況の確認方法 と LSN（Log Sequence Number）

• LSN（Log Sequence Number）
  WALファイルの中で「どの位置までWALが処理されたか」を示す表記方法。WALの位置を上下32ビットで、X/Y の様に表記します。
  • X：0 ⇀ WALセグメントの先頭（最初のファイル）
  • Y：16B6C60 ⇀ そのセグメント内のオフセット位置（バイト単位）
    

LSNの進み方（イメージ）

0/00000000 → 0/00001000 → 0/00002000 → ... → 0/16B6C60 → ...

WALが書き込まれるたびに、LSNは進みます。スタンバイが replay_lsn を報告することで、プライマリは「どこまで追いついているか」を把握できます。

• 遅延状況の確認

SELECT
  application_name,
  write_lag,
  flush_lag,
  replay_lag,
  write_lsn,
  flush_lsn,
  replay_lsn
FROM pg_stat_replication;

• write_lag
  プライマリがWALを送信してからスタンバイが受信してメモリに書き込むまでにかかった時間
• flush_lag
  スタンバイがWALをディスクに書き込むまでにかかった時間
• replay_lag
  スタンバイサーバがプライマリサーバにどれだけ遅れているかの時間
• write_lsn
  スタンバイが WALをメモリ上に書き込んだLSN
• flush_lsn
  スタンバイがWALをディスクにフラッシュ（書き込み）LSN
• replay_lsn
  スタンバイがWALを適用し、データベース状態に反映したLSN

［改訂3版］内部構造から学ぶPostgreSQL―設計・運用計画の鉄則 (Software Design plus) | 上原 一樹, 勝俣 智成, 佐伯 昌樹, 原田 登志 |本 | 通販 | Amazon

Amazonで上原 一樹, 勝俣 智成, 佐伯 昌樹, 原田 登志の［改訂3版］内部構造から学ぶPostgreSQL―設計・運用計画の鉄則 (Software Design plus)。アマゾンならポイント還元本が多数。上原 一樹, 勝俣 ...

amzn.to

WAL遅延と肥大化を防ぐ対処法

スタンバイ側 I/O性能の向上

• スタンバイ側のSSDへの移行
  HDDでは flush_lag や replay_lag が顕著に出るため、SSD化は最優先の対処法となります。
• IOPS保証付きインスタンス選定
  クラウド環境では IOPS制限が遅延要因になります。
• スタンバイでのクエリ制限
  読み取り専用用途に限定し、WAL適用を妨げないようにします。
  

ネットワーク帯域の不足・不安定な接続の解消

• 同一AZ配置
  クラウドではプライマリ・スタンバイを同一地域の独立したセンター郡に配置します。
• VPNやファイアウォールの最適化
  パケットロスや遅延の原因を排除します。

スタンバイ WAL適用処理の遅延対策

• スタンバイのhot_standby_feedbackの設定
  設定を on にし、VACUUMとの衝突を防いでWAL適用をスムーズに実行できるようにします。
  • VACUUM
    不要になったデータ（デッドタプル）を物理的に除去し、テーブルのサイズやパフォーマンスを最適化するメンテナンス処理

プライマリ側の送信プロセス不足対策

• プライマリ側の送信プロセス数を増やす
  例）max_wal_senders = 10

wal_keep_size の不足によるWAL早期削除 対策

• プライマリ側でWALを保持できるファイルサイズを増やす
  例）wal_keep_size = ‘512MB’ 　# スタンバイの遅延に応じて調整

アーカイブ処理の詰まり 対策

• アーカイブ先の容量を十分に確保すると共に、容量を監視する
• 強制アーカイブの実施
  WALセグメントが満たされていなくても、定期的にWALファイルをアーカイブ先へ排出します。その結果、pg_wal内のWALを早めに削除でき、肥大化やスタンバイの遅延を抑制できます。

archive_timeout = 60  # 60秒ごとにWALを強制アーカイブ

まとめ

WAL遅延と肥大化は上述したように、適切な監視と対応を実施すれば防ぐ事が可能です。使用していて異常が感じられないからといって、そのままにしておくと、ある日 突然 異常が発生し、業務が停止するばかりでなく、原因の究明と復旧に時間と労力を費やす事となります。又、場合によっては大きな損失を被る事になりまねません。

そうならないためにも、適切な監視を実施して異常を早めに発見し、対策する事が重要です。

はじめに

PostgreSQLのストリーミングレプリケーションは、データの可用性と冗長性を高める強力な仕組みです。しかし、構築しただけでは安心できません。運用フェーズでは、レプリケーションの状態監視、障害対応、遅延対策など、複数の観点から注意を払う必要があります。

本ブログでは、Windows環境でPostgreSQLのストリーミングレプリケーションを構築済みの方を対象に、運用時の状態監視方法を紹介します。

ストリーミングレプリケーションの構築方法は下記ブログを参照ください。

ストリーミングレプリケーション構築方法

レプリケーションの動作状況の確認

まずは、レプリケーションが正常に動作しているかを定期的に確認することが重要です。

プライマリ動作の確認

以下のSQLで、スタンバイとの接続状況や遅延を確認します。

SELECT pid, client_addr, state, sync_state, write_lag, flush_lag, replay_lag
FROM pg_stat_replication;

• state
  ストリーミングレプリケーションなので、streaming なら正常

• sync_state
  同期レプリケーションなので、sync なら正常

• write_lag
  WALをスタンバイに送信した後、スタンバイがそのWALを書き込むまでにかかった時間。
  正常値は、0～数百ミリ秒。５秒以上ならば、スタンバイのI/O性能低下、ネットワーク障害、WAL送信設定不備などが疑われる。

• flush_lag
  プライマリサーバがWALを送信してから、スタンバイサーバがそのWALを「ディスクにフラッシュ（書き込み確定）」するまでにかかった時間を示す指標。
  正常値は、0～数百ミリ秒。５秒以上は異常と考えられる。

• replay_lag
  スタンバイサーバがプライマリから受信したWALを「実際に適用（replay）」するまでにかかった時間を示す指標。
  正常値は、0～数百ミリ秒。５秒以上は異常と考えられる。

• コマンドの実行例

※write_lag、flush_log、replay_log がNULLなのは、現在新しいWALが生成されていない為。

スタンバイ側動作の確認

スタンバイ側では、WAL受信状況を以下で確認できます。

SELECT status, receive_start_lsn, receive_start_tli, written_lsn, flushed_lsn, latest_end_lsn, latest_end_time FROM pg_stat_wal_receiver;

• status
  ストリーミングレプリケーションなので、streaming なら正常

• receive_start_lsn
  WAL受信開始位置。
  通常運用では頻繁に変化しないため、急な変更があれば再構築や障害の兆候有り。

• receive_start_tli
  受信開始時のタイムラインID。
  フェイルオーバー後にタイムラインが変わるため、プライマリとの整合性確認に使用する。タイムラインが一致していない場合、スタンバイが古い状態である可能性がある。

• written_lsn
  スタンバイがWALを書き込んだ最新位置。
  latest_end_lsn との差が大きいと、WAL受信はしているが書き込みが遅れている可能性あり。

• flushed_lsn
  スタンバイがWALをフラッシュ（ディスクに確定書き込み）した最新位置。
  written_lsn より遅れている場合、フラッシュ処理が滞っている。

• latest_end_lsn
  プライマリが送信した最新のWALの位置。
  written_lsn や flushed_lsn と比較して遅延を把握する。位置。

• latest_end_time
  latest_end_lsn に対応するWALのタイムスタンプ。
  スタンバイが最新WALをどれだけ遅れて受信しているかの目安になる。
  

• コマンドの実行例

また、現在のWAL適用位置は以下で確認できます。

SELECT pg_last_wal_replay_lsn();

PowerShellでの監視例

Windows環境では、PowerShellを使って定期監視スクリプトを作成できます。タスクスケジューラで定期実行すれば、ログ監視や通知にも応用可能です。

• スクリプト例（replication_monitor.ps1）

#スクリプトの実行制限（ポリシー）の確認と変更
Get-ExecutionPolicy
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

# PostgreSQL接続情報
$PGUSER = "postgres"
$PGDATABASE = "postgres"
$PGHOST = "localhost"
$PGPORT = "5432"

# psqlコマンドのパス（環境に応じて変更）
$PSQL = "C:\Program Files\PostgreSQL\17\bin\psql.exe"

# ログファイル出力先
$LOGFILE = "C:\pg_backup\pg_shell_log\replication_monitor.log"

# 日時取得
$timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

# pg_stat_replicationの取得（プライマリ側のレプリケーション状態の取得）
$replication = & $PSQL -U $PGUSER -d $PGDATABASE -h $PGHOST -p $PGPORT -c "SELECT state, sync_state, write_lag, flush_lag, replay_lag FROM pg_stat_replication;" 2>&1

# pg_stat_wal_receiverの取得（スタンバイ側のWAL受信状態取得）
$receiver = & $PSQL -U $PGUSER -d $PGDATABASE -h $PGHOST -p $PGPORT -c "SELECT status, written_lsn, flushed_lsn, latest_end_lsn FROM pg_stat_wal_receiver;" 2>&1

# ログ出力
Add-Content -Path $LOGFILE -Value "[$timestamp] Replication Status:"
Add-Content -Path $LOGFILE -Value $replication
Add-Content -Path $LOGFILE -Value "[$timestamp] WAL Receiver Status:"
Add-Content -Path $LOGFILE -Value $receiver
Add-Content -Path $LOGFILE -Value "----------------------------------------"

• 実行結果

レプリケーション監視の重要性

レプリケーション監視は、PostgreSQLの高可用性とデータ整合性を維持するために不可欠です。

プライマリとスタンバイ間の遅延（write_lag、flush_lag、replay_lag）や接続状態（state、sync_state）を定期的に確認することで、障害の予兆を早期に検知できます。

遅延が蓄積すれば、スタンバイの昇格時にデータ不整合が生じるリスクがあり、業務停止や復旧困難につながります。監視を自動化し、可視化することで、安定運用と迅速な障害対応が可能になります。

はじめに

本ブログでは、初心者〜中級者向けにPostgreSQLのレプリケーション構築手順を紹介します。レプリケーションは大きく分けると、

• データベースクラスタを一括して複製する「ストリーミングレプリケーション（物理レプリケーション）」
• テーブル単位やデータベース単位に複製する「ロジカルレプリケーション（論理レプリケーション）」

があります。ここでは「ストリーミングレプリケーション」の構築を中心に紹介します。

PostgreSQLレプリケーションとは？ なぜ必要？

レプリケーションとは、1つのデータベース（プライマリ）から別のデータベース（スタンバイ）へリアルタイムでデータを複製する仕組みです。

複製を作成するメリットは、

• 障害時の迅速な復旧（フェイルオーバー）
  プライマリが故障した場合、複製のスタンバイを使用する
• 読み取り負荷の分散（参照系クエリの負荷分散）
  ユーザーからの多くのクエリ（参照系）スタンバイに分散させる事で、全体として処理能力を高める
• 災害対策（DR）
  スタンバイを遠くの地域に置く事で、災害からのデータ損失のリスクを減少させる

等です。

レプリケーションのアーキテクチャ

ストリーミングでもロジカルでも、基本的な仕組みは「ＷＡＬ」を使用している事です。

「ＷＡＬ」（Write Ahead Log）とは、データベースへの変更内容が全て記録されているログの事で、この「ＷＡＬ」を別のPostgreSQLに転送・リカバリして複製を作成し、レプリケーションを実現しています。

• ①クエリにより「WAL」が生成され、テーブルが更新される。
• ②スタンバイに転送されてきた「WAL」をそのまま「WAL」ファイルに書き込み、「WAL」の内容で、テーブルを更新する。

※プライマリから送られてきた「WAL」をそのまま適用する為、以下の条件が必要となります。

• PostgreSQLのメジャーバージョンが同じであること
  • マスタとスタンバイは同じWALフォーマット・バージョンである必要あり
• ハードウェアやOSのアーキテクチャが同じである事

ストリーミングレプリケーションの特徴

ストリーミングレプリケーションは、WAL（Write-Ahead Logging）ファイルをリアルタイムでスタンバイサーバに転送することで、プライマリとスタンバイ間のデータ同期を実現します。

• 特徴
  • プライマリで生成されたWALファイルを、TCP接続を通じてスタンバイに送信
  • ファイルコピーではなく、ストリーム転送なので即時性が高い
  • スタンバイ側はSELECTのみ可能（書き込み不可）

使用環境

• Windows 11 Pro 24H2
• PostgreSQL 17.6
• プライマリサーバのＩＰ　：192.168.0.80
• スタンバイサーバーのＩＰ：192.168.0.60

ストリーミングレプリケーションの設定

プライマリサーバの設定

postgresql.confの設定

postgresql.confはメイン設定ファイルであり、データベースの動作に関するさまざまなパラメータを定義する重要な役割を担っています

先ずは、postgresql.confをプライマリサーバ用に設定します。

• 基本接続

listen_addresses = '*'　　　　　　　#外部からの全ての接続を許可
port = 5432　　　　　　　　　　　　 #デフォルトの待ち受けポート

• WAL（Write-Ahead Logging）関連設定

wal_level = replica　　　　　　　　#レプリケーション用にreplicaを指定
　　　　　　　　　　　　　　　　　 #ロジカルなら logical を指定
max_wal_senders = 5　　　　　　　　#スタンバイ接続数の上限（必要に応じて設定）
wal_keep_size = '256MB'　　　　　　#WALファイルの保持サイズ。遅延対策に有効。

• 同期レプリケーション設定

synchronous_commit = on                        #同期レプリケーションを明示的に指定
　　　　　　　　　　　　　　　　　　　　　　　 #標準は、on
synchronous_standby_names = 'standby01'　　　　#同期レプリケーションを使用する場合の
　　　　　　　　　　　　　　　　　　　　　　　 #スタンバイ側の名称を指定

• ログ出力設定（トラブルシューティング）

logging_collector = on
log_directory = 'log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_connections = on
log_disconnections = on

• メモリ・パフォーマンス関連（環境に応じて調整）

shared_buffers = '512MB'　　　　#PostgreSQLが使用するメモリ領域。物理メモリの
                                #25〜40%が目安。
effective_cache_size = '1GB'　　#OS側のキャッシュ見積もり。クエリプランに影響。
work_mem = '4MB'　　　　　　　　#ソートやハッシュ処理に使うメモリ。
                                #複雑なクエリが多い場合は増やす。
maintenance_work_mem = '64MB'   #PostgreSQLが「メンテナンス系の処理」を
                                #行うときに使うメモリの上限

上記の値は必要に応じて設定してください。

pg_hba.confファイルの設定

pg_hba.confは接続認証の制御ファイルで、誰が・どこから・どの方法で接続できるかを定義します。

インストールされたファイルはUNIX用なので、以下の様にWndows用に書き換えます。

# TYPE  DATABASE        USER            ADDRESS                 METHOD
# IPv4 local connections:
host    all             all             127.0.0.1/32         scram-sha-256


# IPv6 local connections:
host    all             all             ::1/128                 scram-sha-256

# Allow replication connections from localhost, by a user with the replication privilege.
host    replication     replicator      192.168.0.60/24         scram-sha-256

• host all all 127.0.0.1/24 scram-sha-256
  すべてのデータベースに対して、全てのユーザーから接続を許可しています。
• host replication replicator 192.168.0.60/24 scram-sha-256
  レプリケーション専用接続で、ID：replicatorで（192.168.0.1～254：スタンバイサーバー）からプライマリサーバ（192.168.0.80）にアクセスを許可しています。

レプリケーション権限を持つユーザーの作成

• 下記コマンドで作成します。

CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'reppass';

PostgreSQLサービス再起動（PowerShell）

• PostgreSQLが正常に再起動するか確認します。

Restart-Service -Name postgresql-x64-17

スタンバイサーバーの設定

初期同期の実行

pg_basebackupでプライマリからデータを取得し、初期同期を実行します。

• C:\pgsql　フォルダを作成

mkdir C:\pgsql

• 下記コマンドで初期同期を実行

cd "C:\Program Files\PostgreSQL\17\bin"
.\pg_basebackup.exe -h 192.168.0.80 -D "C:\pgsql\standby_data" -U replicator -P -R -W

これから以後のファイル設定は、”C:\pgsql\standby_data”　内のファイルに対して行います。

postgresql.auto.conf の内容追加

postgresql.auto.conf に下記の内容を追加します。application_name はプライマリ側の synchronous_standby_names に一致させると同期レプリケーションが可能となります。

primary_conninfo = 'host=192.168.0.80 port=5432 user=replicator password=reppass application_name=standby01'

standby.signal ファイルの作成（自動作成されていない場合）

内容は無くてもよいが、このファイルが存在することで、PostgreSQLはスタンバイモードで起動します。作成方法は下記コマンドを実行。

New-Item -Path "C:\pgsql\standby_data\standby.signal" -ItemType File

postgresql.conf の調整

postgresql.conf ファイルの内容が、下記のようになるよう調整します。

# 接続関連
listen_addresses = '*'                 # 外部からの接続を許可
port = 5432                            # 通常のPostgreSQLポート

# WAL受信と適用
wal_level = replica                    # WALを受信する最低レベル
hot_standby = on                       # スタンバイでもSELECTなどの読み取りを許可
wal_receiver_status_interval = 1s     # プライマリへの受信状況報告間隔
wal_retrieve_retry_interval = 3s      # WAL取得失敗時の再試行間隔

# ログ出力（トラブル時の診断に必須）
logging_collector = on
log_directory = 'log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_min_messages = info
log_connections = on
log_disconnections = on

hot_standby = on により、スタンバイでも読み取りクエリが可能になります。

サービスの登録と起動（初回のみ）

• サービスの登録
  スタンバイ側で下記のコマンドを実行して「pgsql-standby」サービスを登録します。 C:\Program Files\PostgreSQL\17\bin にパスを通すか、ディレクトリに移動して実行。

cd "C:\Program Files\PostgreSQL\17\bin"
./pg_ctl register -N "pgsql-standby" -D "C:\pgsql\standby_data"

• サービスの起動
  下記コマンドを実行

Start-Service -Name pgsql-standby

• 動作確認
  下記SELECT文で、trueが返ればスタンバイとして動作中です。

SELECT pg_is_in_recovery();

レプリケーション動作の確認

プライマリ側のテーブルに１件のレコードを追加した場合、スタンバイ側にも同様に追加されるか確認してみます。

• プライマリ側の操作
  articlesテーブルに1件のレコードを追加

• スタンドバイ側の状態
  プライマリ側に追加されたレコードが、スタンドバイ側にも追加され、同期している事が確認できます。

ストリーミングレプリケーションのまとめ

ストリーミングレプリケーションは、基本的にデータベース全体を複製します。レプリケーションの元となるサーバーは１台だけ設定できますが、スタンバイは複数台設定できます。又、スタンバイサーバーで実行できるのは参照系のクエリのみです。

冒頭でも述べましたが、ストリーミングレプリケーションは、PostgreSQLの高可用性を実現する重要な機能です。設定はシンプルですが、細部の確認が成功の鍵。この記事を参考に、安全で再現性の高い構成を作成して下さい。

PostgreSQLで全文検索を使う理由

Webアプリや業務システムで「検索機能」は欠かせません。PostgreSQLは、標準SQLだけでなく強力な全文検索機能を備えており、特にpg_trgm拡張を使うことで、LIKE検索より高速かつ柔軟な検索が可能になります。

使用環境

• Windows 11 Pro 24H2
• PostgreSQL 17.6
• pgAdmin4 9.6
• Chrome 134.0.6998.205

LIKE検索とpg_trgmの違い

LIKE検索

• SQL標準の部分一致検索にしか過ぎない
  • 例：WHERE content LIKE ‘%検索%’
  • %は任意の文字列を表すワイルドカード
• 問題点
  • インデックスが効きにくい（特に先頭に%がある場合）
  • 大量データになると検索が遅くなる

pg_trgm

• 全文検索をする為の拡張機能
  • 文字列を「3文字ずつの断片（トライグラム）」に分解して類似度を計算
  • 例：WHERE content % '検索'（%はpg_trgm演算子）

• 利点
  • 類似検索が可能（完全一致でなくてもヒット）
  • インデックス（GINインデックス）と組み合わせると高速

GINインデックス

• Generalized Inverted Index（汎用反転インデックス¹）
  • pg_trgmと組み合わせることで、トライグラム単位²で高速検索可能

LIKE検索・pg_trgm　どちらを使用すべきか？

• 小規模・簡易検索
  • LIKEで十分
• 大量データ・類似検索・高速化
  • pg_trgm＋GINインデックスが圧倒的に有利

LIKE検索・pg_trgm 比較準備

サンプルテーブルの作成とデータ登録

• 下記サンプルプログラムを作成します。サンプルプログラムの目的は、
  • LIKE検索とpg_trgm検索の違いを体感する
  • GINインデックスの有無による速度差を確認する
  • 類似語や誤字でもヒットするかを試す(下記プログラムの、WHEN i % 3 = 1 THEN ‘PosgrelSQLは高速な検索が可能です。’　では、PostgreSQL を PosgrelSQL にしています。)

-- サンプルプログラム

CREATE TABLE articles (
  id SERIAL PRIMARY KEY,
  title TEXT,
  content TEXT
);

-- 10000件のサンプルデータを生成（実験用）
INSERT INTO articles (title, content)
SELECT
  '記事' || i,
  CASE
    WHEN i % 3 = 0 THEN 'PostgreSQLの全文検索は便利です。'
    WHEN i % 3 = 1 THEN 'PosgrelSQLは高速な検索が可能です。'
    ELSE 'PostgreSQLはオープンソースのRDBMSです。'
  END
FROM generate_series(1, 10000) AS s(i);

SQLでの拡張機能「pg_trgm」の有効化

• psql で以下のSQLを実行

CREATE EXTENSION IF NOT EXISTS pg_trgm;

LIKE検索・pg_trgm検索結果の比較

pgAdmin4 による検索結果の比較

ここでは、初心者向けでもある為、pgAdmin4の「クエリツール」で確認します。

pgAdmin4 のクエリ完了時間 とは

pgAdmin 4がクエリをPostgreSQLに送信し、サーバーが処理して結果を返し、pgAdminがそれを受け取って表示するまでの一連の流れにかかった時間です。（以下の表の合計時間）

サーバー側の実行処理のみの時間や、実行前の準備の時間を知りたい場合

以下のコマンドを使用します。

• LIKE検索

EXPLAIN ANALYZE SELECT * FROM articles WHERE content LIKE '%PostgreSQL%';

• pg_trgm検索

EXPLAIN ANALYZE SELECT * FROM articles WHERE content % 'PostgreSQL';

pgAdmin4 による検索結果

• LIKEの実行確認用SQL

-- 部分一致検索（検索語：PostgreSQL）
SELECT * FROM articles WHERE content LIKE '%PostgreSQL%';

• 実行結果と実行時間
  • 検索件数：6,666件
  • 検索時間：0.170ms

• pg_trgmの実行確認用SQL

-- pg_trgm検索（類似度）
SELECT * FROM articles WHERE content % 'PostgreSQL';

• 実行結果と実行時間
  • 検索件数：10,000件
  • 検索時間：0.197ms
  • 類似文字（ここでは、PosgrelSQL）も検索されている為多少時間がかかっていると思われる。

インデックスの作成とパフォーマンス比較

GINインデックス作成

• 下記のSQLを実行してGINインデックス作成を作成します

CREATE INDEX articles_idx ON articles USING GIN (content gin_trgm_ops);

• インデックスが作成されているか？

• pg_trgm＋GINインデックスの実行結果

PostgreSQL 「フルテキスト検索入門」 まとめ

PostgreSQLでの文字列検索は、LIKE '%文字列%' が基本ですが、インデックスが効かず遅くなりがちです。そこで登場するのが pg_trgm 拡張。曖昧検索を高速化する強力な武器です。

• LIKE検索の課題
  • % で始まる検索はインデックスが使えない
  • 全件走査（Seq Scan）になり、件数が多いと遅い
  • 日本語や長文では特に非効率

• pg_trgmとは？
  • 「トライグラム（3文字単位）」で文字列を分割し、類似度を計算
  • % 演算子で曖昧検索が可能（content % '検索語'）
  • GINインデックスと組み合わせることで爆速化

脚　注

1. GINインデックス（汎用反転インデックス）
   通常のインデックス（BTREEなど）は「行単位」でインデックスを作りますが、反転インデックスは「値 → 行」の逆方向でインデックスを作ります。
   例）
   通常：id → content
   反転：単語 → 含まれる行ID
   つまり、検索語に対応する行を高速に引き出すための構造です。
   ↩︎
2. トライグラム単位
   ・「Tri（3）」＋「gram（文字列単位）」＝3文字の連続部分列
   ・文字列を3文字ずつの断片に分割して、検索語との共通部分の数で類似度を計算
   ↩︎

はじめに

PostgreSQLを使った業務システム開発において、ストアドプロシジャ（PROCEDURE）とストアドファンクション（FUNCTION）は、処理の再利用性や保守性を高める重要な要素です。

本ブログでは、「psql」と「pgAdmin4」を使って、簡単な「本の在庫管理システム」を題材に、両者の違いや使い方を紹介します。

使用環境

• Windows 11 Pro 24H2
• PostgreSQL 17.6
• pgAdmin4 9.6
• Chrome 134.0.6998.205

ストアドファンクション（Stored Function）とは？

ストアドファンクションは、値を返す処理を定義するSQLの関数です。たとえば「在庫数を取得する」「売上を計算する」といった処理を関数として定義し、SELECT文などから呼び出すことができます。

• 特徴
  • RETURNS で戻り値を定義
  • SELECT や PERFORM で呼び出し
  • 単一の値や集計結果を返す用途に最適
• 基本構文

CREATE [OR REPLACE] FUNCTION 関数名(引数 型, ...)
RETURNS 戻り値の型
LANGUAGE plpgsql
AS $$
DECLARE
  -- 変数宣言（任意）
BEGIN
  -- 処理内容
  RETURN 戻り値;
END;
$$;

ストアドプロシジャ（Stored Procedure）とは？

ストアドプロシジャは、複数ステップの処理や副作用を伴う業務ロジックをまとめた手続き型の処理です。たとえば「在庫を更新し、ログを記録する」といった一連の処理を1つのプロシジャにまとめることができます。

• 特徴
  • 戻り値はなし（ただしOUTパラメータは使える）
  • CALL で呼び出し
  • BEGIN, COMMIT, ROLLBACK によるトランザクション制御が可能
  • 複雑な業務処理に適している
• 基本構文

CREATE [OR REPLACE] PROCEDURE プロシジャ名(引数 型, ...)
LANGUAGE plpgsql
AS $$
DECLARE
  -- 変数宣言（任意）
BEGIN
  -- 処理内容（複数ステップ可）
  -- トランザクション制御も可能
END;
$$;

ストアドファンクション・ストアドプロシジャの作成と実行

テーブルの作成

先ず 以下のテーブルを作成します。

• booksテーブル
  在庫数テーブル。在庫数を入力しておき、ストアドファンクションから参照されます。

CREATE TABLE books (
  book_id SERIAL PRIMARY KEY,
  title TEXT NOT NULL,
  stock INT DEFAULT 0
);

• stock_logs
  在庫数の変化を記録するログテーブルです。ストアドプロシジャによって更新されます。

CREATE TABLE stock_logs (
  log_id SERIAL PRIMARY KEY,
  book_id INT REFERENCES books(book_id),
  change INT,
  log_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

ストアドファンクションの作成

在庫数を取得するストアドファンクションを作成します。

記号：$$は、「ドルクオート（dollar-quoting）」と呼ばれる構文で、関数やプロシジャの本体（つまりPL/pgSQLコード）を囲むための区切り記号です。

-- 関数を作成または置き換える（既存の関数があれば上書き）
CREATE OR REPLACE FUNCTION get_stock(book_title TEXT)
-- 戻り値の型を指定（在庫数：整数）
RETURNS INT AS $$
-- 変数宣言部：在庫数を一時的に保持する変数
DECLARE
  current_stock INT;
BEGIN
  -- booksテーブルから、指定されたタイトルの在庫数を取得し、変数に格納
  SELECT stock INTO current_stock
  FROM books
  WHERE title = book_title;
  -- 取得した在庫数を関数の戻り値として返す
  RETURN current_stock;
END;
-- PL/pgSQL言語で記述された関数であることを指定
$$ LANGUAGE plpgsql;

psqlでの作成

psqlに「CREATE FUNCTION…」文を入力して作成。

pgadmin4 での作成

• 「関数」右クリック⇀「作成」⇀「関数」

• 「一般」タブにストアドファンクションの名称を入力

• 「定義」タブで、「返り値の型」「言語」「引数」を以下の様に設定

• 「コード」タブには、「DECLARE」文から「END;」までを作成して入力

• 「オプション」タグの動作属性に、「STABLE」を指定

• 「パラメータ」タグには下記の値を指定
  • client_min_messages
    • クライアント向けにどのレベルのログ情報出力を指定するかのパラメタ
  • debug1
    • 一般的なデバッグ情報（ユーザー向け）

• 「保存」ボタンをクリック
  内容は、上記の指定でpgadmin4 が作成した「get_stock」ストアドファンクション

• 「ストアドファンクション」の詳細については、以下の公式サイトを参照ください。

CREATE FUNCTION（公式ドキュメント）

ストアドプロシジャの作成

在庫数の変化を「stock_logs」テーブルに記録するストアドプロシジャを作成します。

psqlでの作成

psqlに「CREATE PROCEDURE…」文を入力して作成。

pgadmin4 での作成

• 「プロシージャ」右クリック⇀「作成」⇀「プロシージャ」

• 「一般」タブにストアドプロシジャの名称を入力

• 「定義」タブで、「言語」「引数」を以下の様に設定

• 「コード」タブには、「DECLARE」文から「END;」までを作成して入力

• 「パラメータ」タブは「ストアドファンクション」と同様に設定。

• 「SQL」タグで内容を確認し、「保存」ボタンをクリック
  • 内容は、上記の指定でpgadmin4 が作成した「update_stock_and_log」ストアドプロシジャ

• 「ストアドプロシジャ」の詳細については、以下の公式サイトを参照ください。

CREATE PROCEDURE（公式ドキュメント）

ストアドファンクション・ストアドプロシジャの実行

手動実行（psql）して、「ストアドファンクション」及び「ストアドプロシジャ」が正常動作する事を確認します。

【結果】：psql でもadmin4 でも正常動作を確認できました。（当たり前です）

• ストアドファンクション

psql SELECT 関数名(……)

pgadmin4 SELECT 関数名(……)

• ストアドプロシジャ

psql CALL プロシジャ名(…..)

pgAdmin4 CALL プロシジャ名(…..)

有効活用できる場面

ストアドファンクション

• 集計や計算ロジックを共通化したいとき
• SELECT文の中で使用したいとき
• トリガーで呼びたいとき
• トリガーで呼び出したいとき
  • レコードを追加した後での自動処理等

ストアドプロシジャ

• 複数の更新・挿入処理をまとめたいとき
  • 在庫更新＋ログ記録等
• トランザクション制御を含めたいとき
  • BEGIN ... COMMIT を明示的に扱える
• 外部から明示的に呼び出す業務処理
  • バッチ処理やAPI連携のエントリポイントとして

まとめ

本ブログでは以下の事項を紹介しました。

• ストアドファンクションとストアドプロシジャの違い
• ストアドファンクションとストアドプロシジャの主な用途
• psql と、pgadmin4（GUI）による作成方法
• ストアドファンクションとストアドプロシジャの実行方法
• 有効活用できる場面

ストアドファンクションやストアドプロシジャは、データベースの中で処理を共通化できる事、及びトリガーに応じて起動できる点で有効性が高いと考えられます。但し、ストアドプロシジャは、トリガー関数等を使用する必要が有りますが…。

今回、pgadmin4 でも作成しましたが、初心者にとっては最初の理解に役立つと思うが、一度覚えてしまったら手数の多さが気になって使用しなくなるのではないかと思いました。実際、処理の部分は自分で作成するわけで、ＧＵＩのメリットが十分生かされていないと感じた。但し、デバッグできるのは魅力。

はじめに

Ubuntu Server Pro環境で、PostgreSQLとpgAdmin4を使ってGUIベースでデータベース管理を始めたい方向けに、インストールから接続までの手順をわかりやすく解説します。

尚、本ブログではVMware Workstation Pro 環境下にUbuntu Server Proをインストールして作業を進めます。

Windows 11 への「VMware Workstation Pro」インストールは下記ブログを参考にして下さい。
参考：Windows 11 への「VMware Workstation Pro」インストール

Ubuntu Server Pro について

Ubuntu Server Pro は、通常のUbuntu Serverに「セキュリティ強化」と「長期サポート」を追加したプロ向けの拡張サービスです。

• 主な特徴
  • 最大10年間のセキュリティ更新（通常は5年）
  • Livepatch機能：再起動なしでカーネルの脆弱性を修正
  • ESM（Extended Security Maintenance）：古いパッケージも安全に使える
  • FIPS準拠：政府・金融機関向けのセキュリティ基準に対応
  • 無料使用：個人なら最大5台まで無料で使用可能
• 主な使用者
  • サーバーを長期間安定運用したい人
  • セキュリティを重視する企業・開発者

PostgreSQLとPgadmin4 について

PostgreSQLは無料で使える高機能なデータベース管理システム（RDBMS）

• 主な特徴
  • オープンソースで信頼性が高く、世界中の企業や開発者に利用されています
  • 複雑なデータ処理やトランザクション管理に強く、商用DBに匹敵する性能を持ちます

pgAdmin4は、PostgreSQLをGUIで操作できる管理ツール

• 主な特徴
  • Webブラウザやデスクトップアプリで動作し、初心者でも直感的に使えます
  • データベースの作成・編集・クエリ実行・バックアップなどが可能

このブログで習得できること

1. Ubuntu Server Proの初期設定とパッケージ更新
2. PostgreSQLのインストールと基本設定
3. PostgreSQLとpgAdmin4の接続方法
4. よくあるトラブルとその対処法

Ubutu Server Pro の更新と準備

まずはサーバー環境を最新に保ちます。これにより、依存関係の不具合を防げます。

sudo apt update && sudo apt upgrade -y

• apt update：パッケージ情報を最新に更新
• apt upgrade -y：インストール済みのパッケージを一括アップグレード

PostgreSQLのインストール

Ubuntuでは公式リポジトリから簡単にPostgreSQLを導入できます。

sudo apt install postgresql postgresql-contrib -y

• postgresql：メインのデータベースサーバー
• postgresql-contrib：便利な追加モジュール（例：uuid生成など）

インストール直後のPostgreSQLサービス状態

以下のコマンドで状態を確認します。

sudo systemctl status postgresql

コマンドの実行結果。

• Loaded（ユニットファイル読み込み状態）の 確認
  • preset: enabled となっているので、「自動起動が許可されている」状態。

• Active（サービス稼働状態）の確認
  • active（exited）となっているのは、「サービスは起動したがすぐに終了した」状態を示しています。これは、正常な動作です。

PostgreSQLの初期設定（ユーザーとDBの作成）

新規ユーザーの作成

• PostgreSQLでは、postgresが管理者なので、先ず管理者ユーザーに切り替えます。

sudo -i -u postgres

• 新規スーパーユーザーの作成は下記コマンド作成します。

createuser --interactive --pwprompt --superuser

• 新規ユーザーの名称を入力
• パスワードの入力

Enter name of role to add: myuser 
Enter password for role:*****
Enter it again:*****

• myuser がスーパーユーザーとして登録されたかの確認
  • psql でPostgreSQLのシェルに入り
  • \du で確認

新規データベースの作成

• PostgreSQLのシェルで、新規スーパーユーザー接続用のデータベースを作成する
  • １番目のmyuser：作成するデータベースの所有者
  • ２番目のmyuser：作成するデータベース名称

\q                                #一旦、PostgreSQLのシェルから抜ける
createdb -U postgres -O myuser myuser

• 新規スーパーユーザーでPostgreSQLにログインする

psql -U myuser -W -h 127.0.0.1

PgAdmin4（Web版）のインストール

pgAdmin4はPostgreSQLをGUIで管理できる強力なツールです。下記コマンドで必要パッケージのインストールを行います。

• 必要なパッケージの準備

sudo apt update
sudo apt install curl gnupg lsb-release ca-certificates

• pgAdminのGPG鍵の追加

curl https://www.pgadmin.org/static/packages_pgadmin_org.pub | sudo gpg --dearmor -o /usr/share/keyrings/pgadmin-keyring.gpg

• APTリポジトリの追加

echo "deb [signed-by=/usr/share/keyrings/pgadmin-keyring.gpg] https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/$(lsb_release -cs) pgadmin4 main" | sudo tee /etc/apt/sources.list.d/pgadmin4.list

• パッケージ情報を更新

sudo apt update

• pgAdmin Web版のインストール

sudo apt install pgadmin4-web

• 下記のエラーが出る場合
  N: Ignoring file ‘pgadmin4.’ in directory ‘/etc/apt/sources.list.d/’ as it has an invalid filename ecxtendion
  E: unable to locate package pgadmin4-web
  • これはリポジトリ設定ファイルのファイル名の拡張子ミスが原因で、APT がそのファイルを無視しているために pgadmin4-web パッケージが見つからないというエラーです。
  • APT は /etc/apt/sources.list.d/ にあるファイルのうち、.list 拡張子が付いていないファイルを無視します。
  • つまり、pgadmin4. というファイル名は .list が付いていないため、APT にとって無効です。
• エラーの対策
  • 下記コマンドでファイル名を修正。これで .list 拡張子が付いた正しいファイル名になります。

sudo mv /etc/apt/sources.list.d/pgadmin4. /etc/apt/sources.list.d/pgadmin4.list

• APTキャッシュの更新
  • これで、pgadminのリポジトリが読み込まれ、パッケージ情報が取得されます。

sudo apt update

• pgAdmin Web版のインストール

sudo apt install pgadmin4-web

• Webモードの初期設定

sudo /usr/pgadmin4/bin/setup-web.sh

このスクリプトを実行すると、以下のような対話が始まります：

• 初期ユーザーのメールアドレスとパスワードを入力
• Apache の設定を自動で行うか確認（y を選択）
• Apache を再起動して設定を反映

pgAdmin4にアクセスしてPostgreSQLを管理

• VMware上のUbuntu Server Pro のIPアドレスを確認

ip a

• ホストPCのブラウザで以下にアクセス

http://<サーバーのIPアドレス>/pgadmin4

• pgAdmin ログイン画面

ログイン後、「新しいサーバーを追加」からPostgreSQLを追加します。

• Name: 任意（例：MyPostgres）
• Host: localhostまたはサーバーのIP
• Username: 作成したユーザー（例：myuser）
• Password: そのユーザーのパスワード

良くあるトラブルと対処法

【PostgreSQL】スキーマを活用しよう！

PostgreSQLでは、スキーマを活用することでデータベースの管理や運用を柔軟に行うことができます。本ブログでは、スキーマの概念、基本的な操作方法、実用的な活用例について紹介します。

スキーマとは？

スキーマとは、データベース内でテーブルやビュー、関数、シーケンスなどのオブジェクトをグループ化するための名前空間です。スキーマを適切に活用することで、以下のようなメリットがあります。

• データの整理
  テーブルをカテゴリ別に整理できます
  
  
• アクセス制御
  スキーマごとに権限の設定が可能となります
  
  
• 名前衝突の回避
  同じ名前のテーブルを異なるスキーマに作成可能となります
  
  
• マルチテナント環境の実現
  アプリケーションごとにスキーマを分けることで管理が容易になります
  ※マルチテナント環境については後述します。
  
  

下図はcustomer_db内に地域毎のスキーマを作成した結果です。

スキーマの基本操作

スキーマの作成

スキーマは CREATE SCHEMA コマンドで作成します。

CREATE SCHEMA sales;

特定のユーザーが所有するスキーマを作成する場合は、以下のように指定します。

CREATE SCHEMA marketing AUTHORIZATION user_name;

スキーマ内のオブジェクト作成

スキーマを作成した後、そのスキーマ内にテーブルを作成するには、スキーマ名を明示的に指定します。

CREATE TABLE sales.orders (
    order_id SERIAL PRIMARY KEY,
    customer_name TEXT,
    total_amount NUMERIC(10,2)
);

スキーマの一覧表示

作成したスキーマの一覧を確認するには、pg_namespace システムカタログを参照します。

SELECT nspname FROM pg_namespace;

または、psqlの \dn コマンドでも一覧を表示できます。

\dn

スキーマの削除

スキーマを削除するには、DROP SCHEMA を使用します。

DROP SCHEMA sales;

スキーマ内にオブジェクトがある場合は、CASCADE オプションを指定しないと削除できません。

DROP SCHEMA sales CASCADE;

スキーマの活用方法

アクセス制御

スキーマ単位で権限を設定することで、ユーザーのアクセスを制限できます。

例: sales スキーマへのアクセス権を sales_user に付与する

GRANT USAGE ON SCHEMA sales TO sales_user;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA sales TO sales_user;

スキーマ検索パスの設定

スキーマの検索パスを設定することで、スキーマ名を省略してオブジェクトを操作できます。

SET search_path TO sales, public;

これにより、sales スキーマ内のテーブルを sales.orders ではなく orders として参照できるようになります。

マルチテナント環境の実現

マルチテナントアプリケーションでは、各クライアントごとにスキーマを分けることでデータを分離できます。

CREATE SCHEMA tenant1;
CREATE SCHEMA tenant2;

そして、クライアントごとに適切な検索パスを設定します。

SET search_path TO tenant1;

public スキーマ

public スキーマとは標準で作成されるスキーマです。デフォルトで全てのユーザーがpublicスキーマに対して以下の権限を持っています。

• アクセス権限
  public スキーマ内のオブジェクトにアクセスできる権限（USAGE）

GRANT USAGE ON SCHEMA public TO PUBLIC;

• 作成権限
  public スキーマ内にテーブルやビューなどのオブジェクトを作成する権限

GRANT CREATE ON SCHEMA public TO PUBLIC;

public スキーマのリスク管理

public スキーマは、デフォルトで すべてのユーザーがオブジェクトを作成できる 設定になっているため、適切なリスク管理をしないとセキュリティ上の問題が発生する可能性があります。

その為、リスクを最小限にする為には以下のような管理方法を取っても良いでしょう。

CREATE 権限を削除する

一般ユーザーが public スキーマにオブジェクトを作成できないようにする。

REVOKE CREATE ON SCHEMA public FROM PUBLIC;

USAGE 権限は必要に応じて設定する

完全に public スキーマを使わない場合は、USAGE も削除する。ただし、これを行うと public スキーマ内のオブジェクトにアクセスできなくなるため、注意が必要です。

REVOKE USAGE ON SCHEMA public FROM PUBLIC;

search_path を適切に設定する

デフォルトで public スキーマが検索パスの先頭にあるため、不要ならば外す。

ALTER ROLE my_user SET search_path TO my_schema;

スキーマを分離して管理する

public スキーマを使用せず、テナントごとや用途ごとにスキーマを分ける。

CREATE SCHEMA my_schema AUTHORIZATION my_user;

まとめ

本ブログでは、PostgreSQLのスキーマの基本操作から応用的な活用方法までを紹介しました。

ポイントまとめ

• スキーマを使うとデータを整理しやすくなる
• CREATE SCHEMA でスキーマを作成し、テーブルやビューを管理できる
• アクセス制御や検索パスを活用すると、より柔軟な運用が可能になる
• マルチテナント環境ではスキーマを分けることでデータの分離が容易になる

スキーマを適切に活用し、より効率的なPostgreSQLの運用を目指しましょう！

【PostgreSQL】メンテナンス　ー　VACUUM（基礎）

PostgreSQLはデータベースのパフォーマンスを維持するために定期的なメンテナンスが必要です。その中でも特に重要なのがVACUUMコマンドによる不要データの回収です。

本ブログではWindows環境におけるVACUUMの基本から運用方法までを紹介します。

VACUUMとは？

PostgreSQLはMVCC（Multi-Version Concurrency Control）を採用しており、更新や削除されたデータはすぐには物理的に消えず不要な領域（デッドタプル）として蓄積されていきます。

データベース操作で不要になったデータ（デッドタプル）を再利用可能領域としてマークを付加し、ストレージの効率を最適化する機能がVACUUMコマンドです。

VACUUMを実行することでデッドタプルを整理し、ディスク使用量の増加やパフォーマンスの低下を防ぐ事が可能となります。

• 図で示すと以下のようになります
  • ID 002レコードの更新（テーブルA 変更後）
    • トランザクションコード106(XMAX)の処理でデータは更新されますが、レコード領域は残り、新たに ID 002のレコードが追加されます。
  • ID 004レコードの削除（テーブルA 変更後）
    • ID 004のレコードは、トランザクション107(XMAX)で削除されますがレコード領域は残ります。
• VACUUMを実行すると、更新/削除された領域は削除されませんが再利用可能となります。

• ＶACUUMコマンド実行後
  ＶACUUMを実行すると、FSMに空き領域として登録され再利用されます。

【PostgreSQL】VACUUMの種類と実行方法

基本的なVACUUM

VACUUMコマンドを実行する事によってデッドタプルを再利用できるようにします。ただし、ディスク領域自体の解放は行いません。

• データベース内の全てのテーブルを対象とする場合

postgres-# VACUUM
postgres-#

• 特定のテーブルを対象とする場合

postgres=# VACUUM customers;
VACUUM
postgres=#

ANALYZEを含めたVACUUM

ANALYZEはPostgreSQLの統計情報を更新するコマンドです。SQLクエリが最適な実行計画を選択できるようテーブルのデータ分布を分析します。

postgres=# VACUUM ANALYZE;
VACUUM
postgres=#

完全なVACUUM（VACUUM FULL）

VACUUM FULLを実行すると未使用領域を解放し、テーブルのサイズを縮小できます。ただし、VACUUM FULL はデッドタプルを削除するだけでなく、新しい物理テーブルを作成しデータを再配置 します。

そのため、テーブル全体が一時的にロック され、他のトランザクションがそのテーブルを読み書きできなくなり、処理負荷が大きくなるため頻繁な使用は避けましょう。

postgres=# VACUUM FULL;
VACUUM
postgres=#

Windows環境でのVACUUM実行方法

Windows環境で手動でVACUUMを実行するには以下の方法があります。

• pgAdmin 4
  • 「Query Tool」を開き、上記のVACUUMコマンドを実行します。
• psqlコマンドライン
  • psqlを開き、データベースに接続後、VACUUMコマンドを実行します。

• pgAgentを使用したスケジューリング実行（後述）

Autovacuumの設定とカスタマイズ

PostgreSQLでは、自動的にVACUUMを実行する「Autovacuum」がデフォルトで有効になっています。

自動VACUUMは不要領域の割合が高くなったテーブルや、最後にANALYZEを実行してからの累計変更行数が多くなったテーブルに対して自動的に実行されます。

postgresql.confのパラメータを調整する事で自動実行時間を調整できますが、自動実行の間隔によってはパフォーマンスに影響する為注意が必要です。

# Autovacuumの間隔を短くする
autovacuum_vacuum_threshold = 50
autovacuum_analyze_threshold = 50

# Autovacuumプロセスの最大並列実行数
autovacuum_max_workers = 3

pgAgentを使ったVACUUMのスケジューリング実行

Windows環境では、pgAgentを使用してVACUUMをスケジュール実行できます。

pgAgentのインストールとスケジュールの設定

pgAgentは、pgAdmin4のスタックビルダからインストールします。具体的なインストール方法とジョブのスケジューリングは以下のブログを参照下さい。

参考ブログ：https://www.kemmy-it.com/2024/08/19/pgadmin_3/

• VACUUM ANALYZE コマンドを実行するバッチファイルの例。

@echo off
"C:\Program Files\PostgreSQL\16\bin\psql.exe" -U postgres -d test_db -c "VACUUM ANALYZE;"

まとめ

Windows環境でPostgreSQLを運用する際、VACUUMを適切に管理することは重要です。

• 基本的なVACUUM
  手動で実行する方法
• Autovacuumの設定
  自動メンテナンスの最適化
• pgAgentによるスケジュール実行
  運用の効率化
• バッチファイルとタスクスケジューラを活用

これらを適切に組み合わせることで、データベースのパフォーマンスを維持し、効率的な運用が可能になります。

【PostgreSQL】バックアップの種類と比較

PostgreSQLには主に以下の3種類のバックアップ方法があり、それぞれに特徴とメリット・デメリットがあります。

バックアップを実施するには目的に合った方法を理解し適切にバックアップを行う事が重要です。

論理バックアップ

論理バックアップとはデータベースの内容をSQLスクリプトや圧縮ファイルとしてエクスポートするバックアップ方法です

特　徴

• pg_dump や pg_dumpall を使用
• SQLスクリプトとしてエクスポート
• テーブル単位、データベース単位での復元が容易

メリット

• 柔軟な復元（テーブル単位、スキーマ単位など）
• 異なるバージョンのPostgreSQLへの移行が容易

デメリット

• 大規模データベースでは時間がかかる
• 一貫性のあるスナップショットを取得するには注意が必要

論理バックアップ「pg_dump/pg_restore」については下記のブログを参考下さい。
参考ブログ：【PostgreSQL】バックアップ・リストア 「pg_dump/pg_dumpall/pg_restore/psql」

オフライン物理バックアップ

PostgreSQLを停止しデータディレクトリ全体を手動でコピーするバックアップ方法です。データの一貫性が確保されるシンプルで確実な手法ですが、バックアップ中はデータベースを使用できないという制約があります。

特　徴

• PostgreSQLを停止し、データディレクトリ全体をコピー

メリット

• シンプルで確実な方法
• すべてのデータが一貫性のある状態でバックアップされる

デメリット

• バックアップ中はデータベースを使用できない
• 柔軟性が低い（部分的な復元が困難）

オンライン物理バックアップ (pg_start_backup())

PostgreSQLを停止せずにデータディレクトリを手動でコピーするバックアップ方法です。

WAL (Write-Ahead Logging) を活用し、一貫性のあるスナップショットを取得できるため、PITR (ポイントインタイムリカバリ) にも対応可能です。

• WAL（Write-Ahead Logging）とは？
  データの整合性を保つための技術で、データが変更される前にその変更内容をログに記録することで、システムがクラッシュしても、ログを使って変更を復元できるようにしています。
  
  
• PITR (ポイントインタイムリカバリ) とは？
  データベースの復旧方法の一つで、特定の時点にデータベースを戻すプロセスです。これにより、データベースがクラッシュしたり、誤ってデータを削除した場合でも、指定した時点まで正確に復旧することができます。
  
  

特　徴

• pg_start_backup() を使用し、PostgreSQLを停止せずにデータディレクトリを手動でコピー
• Write-Ahead Logging (WAL) を利用

メリット

• サーバーを停止せずにバックアップ可能
• 一貫性のあるスナップショットを取得可能
• PITR（Point-in-Time Recovery）に対応

デメリット

• 手動操作が必要で手順が複雑
• WALファイルの管理が必要

【PostgreSQL】pg_start_backup() を使用したオンライン物理バックアップの手順

前提条件

wal_level が replica 以上に設定されている（WALログを適切に取得するために必要）

wal_level は、PostgreSQLのWAL (Write-Ahead Logging) の詳細度を決定する設定パラメータで、以下の3つのレベルがあります。

• minimal
  もっとも低いレベルで、クラッシュリカバリのみをサポート。レプリケーションや PITR (ポイントインタイムリカバリ) には対応しない。
• replica (推奨)
  ストリーミングレプリケーションやアーカイブをサポートする標準設定。
• logical
  論理デコーディングをサポートし、データ変更を詳細に記録。
  

オンライン物理バックアップを行う場合は、wal_level = replica 以上に設定する必要があります。設定を変更するには、postgresql.conf を編集し、PostgreSQLを再起動してください。

wal_level = replica

バックアップの取得手順

バックアップモードの開始（psql で実行）

pg_backup_start（）はスーパーユーザーで実行します。又、下記の「backup label」にはバックアップが特定できる一意の文字を入力します。

• PostgreSQL 14以前
  pg_start_backup('backup_label');
• PostgreSQL 15以降
  pg_backup_start('backup_label', true);
  

C:\>psql -U postgres
psql (16.4)
"help"でヘルプを表示します。

postgres=# SELECT pg_backup_start('backup_label', true);
 pg_backup_start
-----------------
 0/2000028
(1 行)

データディレクトリをコピー（コマンドプロンプトで実行）

C:\>xcopy /E /I /EXCLUDE: "C:\Program Files\PostgreSQL\16\data" C:\backup_directory\data
C:\Program Files\PostgreSQL\16\data\backup_label.old
C:\Program Files\PostgreSQL\16\data\backup_manifest
                         ・
                         ・
                         ・
C:\Program Files\PostgreSQL\16\data\pg_wal\archive_status\000000010000000000000002.done
C:\Program Files\PostgreSQL\16\data\pg_xact\0000
2006 個のファイルをコピーしました

C:\>

バックアップモードの終了（psql で実行）

• PostgreSQL 14以前
  pg_stop_backup();
• PostgreSQL 15以降
  pg backup_stop();

postgres=# SELECT pg_backup_stop();
NOTICE:  WAL archiving is not enabled; you must ensure that all required WAL segments are copied through other means to complete the backup
                              pg_backup_stop
---------------------------------------------------------------------------
 (0/3000060,"START WAL LOCATION: 0/2000028 (file 000000010000000000000002)+
 CHECKPOINT LOCATION: 0/2000060                                           +
 BACKUP METHOD: streamed                                                  +
 BACKUP FROM: standby                                                     +
 START TIME: 2025-02-10 06:08:54 JST                                      +
 LABEL: backup_label                                                      +
 START TIMELINE: 1                                                        +
 ","")
(1 行)

postgres=#

WALログを保存（コマンドプロンプトで実行）

C:\>xcopy /E /I "C:\Program Files\PostgreSQL\16\data\pg_wal" C:\backup_directory\pg_wal
C:\Program Files\PostgreSQL\16\data\pg_wal\000000010000000000000002
C:\Program Files\PostgreSQL\16\data\pg_wal\000000010000000000000003
C:\Program Files\PostgreSQL\16\data\pg_wal\archive_status\000000010000000000000002.done
3 個のファイルをコピーしました

オンライン物理バックアップ（pg_basebackup）との違い

データベースを停止しないオンライン物理バックアップには（pg_basebackup）コマンドを使用する方法もあります。pg_basebackupは主に以下の場合に使用されます。

• データディレクトリ全体のスナップショットを取得し、復旧のために必要な全てのデータを取得する場合
• レプリケーションのスタンバイサーバをセットアップする場合
• Point-In-Time Recovery (PITR) を行うための基盤となるバックアップを作成する場合
• 別のサーバーにPostgreSQLデータベースを移行する場合
• 定期的なバックアップを自動化する場合

「pg_basebackup」を使用したオンライン物理バックアップについては下記のブログを参考下さい。
参考ブログ：【PostgreSQL】pg_basebackup によるオンライン物理バックアップ

【PostgreSQL】バックアップの復元

バックアップの復元手順

既存のデータディレクトリを削除（または別の場所に移動）

C:\>net stop postgresql-x64-16
postgresql-x64-16 - PostgreSQL Server 16 サービスを停止中です.
postgresql-x64-16 - PostgreSQL Server 16 サービスは正常に停止されました。

C:\>ren "C:\Program Files\PostgreSQL\16\data" "data_old"

バックアップをリストア

c:\>xcopy /E /I C:\backup_directory\data "C:\Program Files\PostgreSQL\16\data"
C:\backup_directory\data\000000010000000000000002
C:\backup_directory\data\000000010000000000000003
C:\backup_directory\data\backup_label.old
C:\backup_directory\data\backup_manifest
                         ・
                         ・
                         ・
C:\backup_directory\data\pg_wal\000000010000000000000003
C:\backup_directory\data\pg_wal\archive_status\000000010000000000000002.done
C:\backup_directory\data\pg_xact\0000
2009 個のファイルをコピーしました

C:\>

WALログを適用

C:\>xcopy /E /I C:\backup_directory\pg_wal "C:\Program Files\PostgreSQL\16\data\pg_wal"
C:\backup_directory\pg_wal\000000010000000000000002
C:\backup_directory\pg_wal\000000010000000000000003
C:\backup_directory\pg_wal\archive_status\000000010000000000000002.done
3 個のファイルをコピーしました

C:\>

PostgreSQLを起動

C:\>net start postgresql-x64-16
postgresql-x64-16 - PostgreSQL Server 16 サービスを開始します.
postgresql-x64-16 - PostgreSQL Server 16 サービスは正常に開始されました。

C:\>

まとめ

pg_start_backup() を使用すると、柔軟で細かい管理が可能になりますが、pg_basebackup の方が簡単にフルバックアップを取得できます。運用環境に応じて適切な方法を選択して下さい。