Database Support Blog

  • EDB
  • PostgreSQL
2025.11.19

今さら聞けない!?WALアーカイブのベストプラクティス

当記事は EnterpriseDB 社のナレッジベース記事の翻訳の紹介です。

基本的に引用元の原文そのままで和訳していますが、文中のマニュアルへのリンクは、日本語版が公開されている場合、日本語版マニュアルへのリンクに置き換えています。

はじめに

この記事は以下を前提としています。

  • データベース保全の要となる災害対策(DR)やポイント・イン・タイム・リカバリ(PITR)の方針は、物理ベースバックアップとWALアーカイブを組み合わせることです。
  • 本記事では潜在的なDRやPITRに備えて様々な対策をどう講じるかについて取り上げます。
  • 包括的な物理バックアップを取得するために補助的なツールを用いることを強くお勧めします。信頼性や機能性からBarmanやpgBackRestが推奨されます。
  • BarmanとpgBackRestのどちらもベースバックアップとWALアーカイブ機能を有し、根幹の要件は満たしますが、追加の機能面で違いがあります。これらは後の項目で説明します。

WALアーカイブの選択肢

  • (*1)「ソリューション」列は、WALアーカイブに利用できる手法の一覧です。
  • (*2)「WALアーカイブの耐久性」は、WALアーカイブがどの程度堅牢か、あるいは転送方法が安全かを示します。本記事では、この項目に影響する要素として、WALファイルがディスクにfsyncされるかどうかや、ネットワークの問題を含めます。
  • (*3)「難易度」は手法の設定や本番環境での運用がどの程度難しいかを示します。いくら手法が理論上は安全でも、ユーザーにとって複雑すぎたり、オペミスを誘発するようなものであれば、実際には安全な手法として評価できません。
  • (*4)「取得方法」はWALログがどのようにアーカイブされるかの一般的な分類を示します。
  • (*5)「プッシュ型」は、WALファイルが作成された後データベースがそれらをアーカイブ先へ送ることを意味します。
  • (*6)「プル型」はデータベースからのWALデータの受け取りにレプリケーションが利用され、アーカイブ先に書きこまれることを示します。

注意事項:WindowsやLinuxのディストリビューションによっては、そのまま同じコマンドが使えない場合があります。実際の環境で必ずテストした上で稼働環境に適用してください。


以下の各段落ではそれぞれの手法について詳しく解説します。

1) Barman

Barmanについての基礎知識

Barmanは推奨される物理バックアップ・ツールの一つです。barman cron機能は特にバックアップ・プロセスの運用に有効です。また、以下のような多彩な機能を含みます。

Barmanの利用方法はこちらのウェブページにまとまっています。


archive_commandおよびbarman-wal-archive
  • Barmanはbarman-wal-archiveコマンドによってarchive_commandパラメータの機能を強化します。
  • この機能を使うと、WALファイルはfsync()システムコールによってディスクに書き出され、rsync、cp、scpよりも確実にデータを保持できます。
  • また、barman-wal-archiveを利用すると、具体的な格納先パスの代わりに、格納先サーバー・ホスト名を指定するため、誤った場所にWALファイルがコピーされるリスクを減らせます。

設定例:

archive_command = 'barman-wal-archive barmanserver db01 %p'

  • 「barmanserver」にBarmanサーバー・ホスト名を指定します。
  • 「db01」にはBarman構成ファイル(/etc/barman.d/db01.confなど)内で[db01]のように記述した構成名を指定します。
  • 「%p」はデータベースが作成する各WALファイル名を表します。WALファイルが生成されると、データベースは新しいファイル名でarchive_commandに設定されたコマンドを実行します。

複数サーバーへのアーカイブ
  • 複数の拠点へのアーカイブが必要になる場面では、Barman georedundancyが有用です。
  • この機能を使うことによって、複数のBarmanサーバーを利用できるだけでなく、他のBarmanサーバーにあるバックアップを一次バックアップとして扱うこともできます。
  • rsync、cp、scpをbarman-wal-archiveと組み合わせるのはやめましょう!実際にお客様が以下のようなarchive_commandを設定して、問題が生じた事例があります。
誤った設定例:
archive_command = test ! -f /archive_location/%f && cp %p /archive_location/%f && barman-wal-archive barmanserver db01 %p

rsync、cp、scpと併用すると、barman-wal-archiveによる耐久性が損なわれます。この例では、cpの失敗によってbarman-wal-archiveも実行されません。

「&&」を「;」に置き換えたとしても、有効になるアーカイブはcpで作成されたアーカイブのみになってしまい、Barmanのカスケード・アーカイブを利用したほうが安心です。


Barman pg_receivewal

Barmanでは内部的なpg_receivewal実行によるWALストリーミングをサポートしています。
これは目標復旧時点(以下、RPO)をできるだけ直近にすることに役立ちます。pg_receivewal自体については後続の 4) で詳しく述べます。


2) pgBackRest

pgBackRestについての基礎知識

pgBackRestもまた推奨される物理バックアップ・ツールの一つです。Barmanと同じく、ファイルやディレクトリ単位のfsyncによって確実にデータを保持します。
また、以下のような多彩な機能を含みます。

詳細な使用方法は開発元ウェブページか、EDBドキュメントをご参照ください。


archive_commandおよびpgBackRest

アーカイブを行うためには、archive_commandパラメータにarchive-pushを設定します。


設定例:

archive_command = 'pgbackrest --stanza=demo archive-push %p'

この手順はクイック・スタートのページで示されています。

3) archive_library & basic_archive(15以降)

  • データベース・バージョンが15以降で、BarmanやpgBackRestがご利用になれない場合、データベース機能のarchive_libraryとbasic_archiveを使うことが推奨されます。
  • これを使うことでWALファイルをfsyncすることができ、アーカイブのデータを確実に保持します。
  • 加えて、アーカイブが成功するまでデータベースはWALファイルの削除や循環を行いません。
  • 注意: サーバーがクラッシュした場合は、データベースの起動前にarchtempの一時ファイルを削除するようにしてください。詳細はドキュメントの注釈もご確認ください。

設定手順例(EDBの手順ですがPostgreSQLにも利用できます):

edb=# show shared_preload_libraries;
             shared_preload_libraries
$libdir/dbms_pipe,$libdir/edb_gen,$libdir/dbms_aq,$libdir/basic_archive
edb=# alter system set shared_preload_libraries='$libdir/dbms_pipe','$libdir/edb_gen','$libdir/dbms_aq','$libdir/basic_archive';
$ /usr/local/enterprisedb/bin/pg_ctl -D /var/lib/edb/as15 -l /var/lib/edb/as15/log/logfile restart
edb=# show archive_library;
edb=# show basic_archive.archive_directory
edb=# alter system set archive_library = 'basic_archive';
edb=# alter system set basic_archive.archive_directory = '/var/lib/edb/archive_test';
edb=# SELECT pg_reload_conf();
edb=# show archive_library;
basic_archive
edb=# show basic_archive.archive_directory
/var/lib/edb/archive_test
edb=# create table test( i int);
edb=# insert into test generate_series(1,1000);
edb=# select pg_switch_wal();
edb=# insert into test generate_series(1,1000);
edb=# select pg_switch_wal();
edb=# select * from pg_stat_archiver;
archived_count|last_archived_wal|last_archived_time| failed_count|last_failed_wal|last_failed_time|stats_reset
23|000000010000000000000019|09-FEB-23 17:26:38.722981 +00:00|0 ||| 07-FEB-23 16:28:15.290586 +00:00
$ ls -l /var/lib/edb/archive_test
-rw_______ 1 enterprisedb enterprisedb 16777216 Feb 9 17:26 000000010000000000000018
-rw_______ 1 enterprisedb enterprisedb 16777216 Feb 9 17:26 000000010000000000000019
$ ps waux | grep archive
postgres: archiver last was 000000010000000000000019

4) pg_receivewal、レプリケーション・スロットおよびsystemdスケジューラー

pg_receivewalについての基礎知識

  • データベース・バージョンが14以前で、BarmanやpgBackRestの利用にあたり制限がある場合、pg_receivewalを使って、WALを所定の格納先へストリーミングすることができます。
  • pg_receivewalはarchive_commandにrsyncやcp、scpを設定するよりも耐久性があります。
  • pg_walへWALを書きこむ際や、レプリケーション経由で転送するとき、fsyncは更新をディスクに書きこむことを保証します。
  • このことから、pg_receivewalはファイル全体の書き込み完了を待つことなく、リアルタイムでWALをストリーミングできるため、RPOを最新時点に近づけるのにも有用です。
  • –synchronousオプションとsynchronous_standby_names、synchronous_commitを組み合わせることで、同期アーカイブ機能も利用でき、トランザクションごとのアーカイブが次の更新前に完了することを保証しますが、これはパフォーマンスとトレードオフです。ドキュメント記載の通り、synchronous_commit=remote_applyとしている場合はこの設定をすべきではありません。

pg_receivewal利用の複雑さ(スタンドアロン、Barman無しの場合)

  • 外部のスケジュール管理システムによる管理が必要なため、この方法はBarmanを利用するより複雑で、この手法がご自身のユースケースに最適かを評価するにはより専門的な支援や、多くのテストが必要です。この機能はbarman cronが提供する機能の一部を置き換えることが可能です。
  • 運用例には、プログラムがオフラインの場合に再起動する手順も含まれます。例えばデータベースが再起動されると、pg_receivewalは強制終了され、アーカイブ・サーバー・ホストが再起動されます。そのため、systemdプロセスのようなカスタムプロセスを活用しなければなりません。
  • pg_receivewalを唯一のアーカイブ手段として利用する場合、物理レプリケーション・スロットと併用することが強く推奨されます。レプリケーションスロットを使うことで、障害(*1)によってpg_receivewalプロセスが停止してしまっても、レプリケーションスロットの働きによってデータベースは、プロセスが再開(*2)するまでWALを循環させません。
     (*1) ネットワーク障害、プログラム・エラー、OS停止が想定されます。
     (*2) max_slot_wal_keep_size=1と仮定します。
  • レプリケーション・スロットを使う欠点として、ディスク容量が100%になり、データベースの停止を引き起こすことが考えられます。長期間の障害に備え、以下のどちらを採用するか、予め決めておきましょう。
  • アーカイブを重視してディスクフルのリスクを取る
  • データベース持続性を重視してアーカイブ損失のリスクを取る
  • アーカイブの監視は以下の方法で実現可能です。
  • データベースのレプリケーション状況の監視
  •   SQL例:select * from pg_stat_replication, select * from pg_replication_slots;
  • サービス状態の監視(定期実行)
  •   コマンド例:systemctl status systemd_name

5) rsyncを用いたアーカイブ

バックアップ・ツールを採用することが難しい場合、archive_commandにrsyncを記載するのも方法の一つです。rsyncを用いた手法には以下の特徴があります。

  • rsyncはまずファイルのコピーを一時ファイルとして作成し、コマンドが成功した場合のみ、一時ファイルの名前を正しいものに修正します。
  • 将来rsyncバージョンが3.2.4以上で普及した場合は、rsync–fsyncによる実装もご検討いただけます。

設定例:

archive_command = 'test ! -f enter_backup_location/%f && rsync -a %p enter_backup_location/%f'

  • 設定例で用いたrsyncのオプション、引数等は以下の通りです。
  • -a:アーカイブモードで実行することで、再帰的かつハードリンクで保存します。
  • %p:データベースが生成する各WALファイルの名前($PGDATA/pg_wal/WALファイル名)を表します。%pと記載することで、WALファイルが生成されるごとに、データベースは新しいWALファイル名でこのコマンドを実行します。
  • %f:WALセグメント名を表します。
  • test ! -f enter_backup_location location/%fを指定することで、書き込み前にファイルが存在するかをチェックします。存在すれば、WALファイルはコピーされず、コマンドはエラーになります。これは潜在的なデータ損失を防ぐのに有効です。
  • 同名のアーカイブがすでに存在するとき、そのアーカイブにも必要な情報が含まれている可能性があり、ユーザーは手動で問題のアーカイブを退避する必要性に迫られます。test ! -f が設定されていれば、データベースはこのアーカイブを保持できますが、設定がない場合、古いファイルは間違って上書きされてしまう可能性があります。
  • 同名のアーカイブがすでに存在した場合、データベースがアーカイブをスキップしてしまいますが、返り値は0(成功)になるため、rsyncの ?ignore-existingオプションは使用しないでください。このオプションは潜在的なデータ損失につながります。

6) cpを用いたアーカイブ

  • cpコマンドはネットワークの問題を引き起こしやすいです。
  • また、cpは「ディスクの容量が十分ではない」問題に安全に対応できません。
  • cpによるディスク容量不足になって、メインプロセスが停止した後でも、cpプロセスはハングしたままであり、手動削除する必要がある部分的なファイルを残します。rsyncでこの問題は回避できます。
  • cpよりもrsyncの方がネットワーク問題への耐性が高い上、「ディスクの容量が十分ではない」問題を回避できるため、アーカイブ上の問題に遭遇する確率が低いです。
  • archive_commandでcpをすでにご利用の場合は、rsyncへの置き換えが簡単で、利点も多いためお勧めです。

7) scpを用いたアーカイブ

scpを用いたアーカイブもまた、barman-wal-archiveやrsyncに劣るだけでなく、廃止される見込みのため推奨されません。

  • もしarchive_commandでscpをすでにご利用の場合は、rsyncへの置き換えが簡単で、多くのメリットがあります。

(以上、EDB社ブログ記事より翻訳)


終わりに

いかがでしたでしょうか?初めてPostgreSQLに触れるお客様や、データベースのバージョンアップに際して、バックアップを見直すお客様にとって、RPOに直結するアーカイブの考え方は設計において重要な一要素です。

この記事を通して、アーカイブ手法や考え方の一助になれば幸いです。



\ PostgreSQLとEDBの違いについて知りたい方はこちらへ! /

\ EDBとは?について知りたい方はこちらへ! /



執筆者情報

てい ゆき プロフィール画像

2018年に中途入社。Oracle Database、EDB Postgres/PostgreSQLの支援経験を積み、2024年からEDB/PostgreSQLサポートを担当。趣味は競馬・麻雀。...show more


■本記事の内容について
 本記事に記載されている製品およびサービス、定義及び条件は、特段の記載のない限り本記事執筆時点のものであり、予告なく変更になる可能性があります。あらかじめご了承ください。

■商標に関して
 ・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
 ・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
  文中の社名、商品名等は各社の商標または登録商標である場合があります。

関連している記事

  • EDB
  • PostgreSQL
2025.04.16

PostgreSQLの拡張機能「system_stats」のご紹介

EDB社が提供するPostgreSQLの拡張機能「system_stats」はPostgreSQL ユーザーがパフォーマンス問題に取り組む際の非常に強力なツールになります。SQLクエリでOS情報を取得できるため、DBエンジニアにとってはパフォーマンスの監視が格段に簡単になります。テストした結果をご紹介します。

  • EDB
  • PostgreSQL
2025.03.10

意外な落とし穴!アプリケーション⇒DBデータ型によるパフォーマンス影響

PostgreSQLのオプティマイザがインデックスを適切に使用できない理由は様々ですが、本記事ではJDBC⇔PostgreSQL間でデータ型の不一致がインデックスの使用にどういった悪影響を及ぼすかを見ていきます

  • EDB
  • PostgreSQL
2024.09.12

新ツール Postgres Workload Report によるパフォーマンス診断~データベース管理の未来を共に創る!~

EDB Postgres Workload Reportsは、Postgresデータベースのパフォーマンス診断とトラブルシューティングを強化する新しいツールです。OracleのAWRに似た詳細なレポートを提供し、データベースの問題を迅速に特定・解決できるようサポートします。本記事では概要と利用手順をご紹介します。

ページの先頭へ戻る