【barman 紹介】PostgreSQL のバックアップを取ってみよう ~その②~

こんにちは。サイオステクノロジーの橋本です。
前回紹介した pgBackRest に続いて今回は PostgreSQL のバックアップ管理ツール barman を紹介します。

コミュニティページ : barman
https://pgbarman.org/

ちなみに barman はバーテンダーのイギリス英語だそうです。
バーテンダーはアメリカ英語なんですね。
film と movie、Autumn と Fall と同じ関係性で barman と Bartender という単語があるわけです。

お酒の barman とは全く関係なく、
PostgreSQL の barman は Backup and Recovery Manager の略称です。

 〇バックアップツールの比較〇

まず、前回ご紹介した pgBackRest と比較してみましょう。

pgBackRest のメリット、デメリット
・メリット
 非常に高機能で細かい制御が可能
 完全バックアップはもとより、増分や差分バックアップの取得も可能
・デメリット
 機能に比例して設定が複雑になりがち

Barman のメリットデメリット
・メリット
 ロジカルレプリケーションを利用したリアルタイム WAL ファイルバックアップ
 バックアップはpg_basebackup や rsync を利用したものであるため、直感的に理解しやすい
・デメリット
 基本的に完全バックアップしか取得できない

言う増分バックアップは
Postgres サーバに対し、完全バックアップを取得、
バックアップファイルがすでに取得済みのバックアップコンテンツで同様のものがある場合、
ハードリンクを作成することで DISK 容量を節約するものです

一般的にいう増分バックアップとは違う点に注意が必要です。

barman の最大の特徴としてストリーミングレプリケーションを用いて、
WAL ファイルをリアルタイムバックアップすることが可能です。
barman を用いることで RPO (Recovery Point Objective) を極めて短くすることが できます。
※EnterpriseDB 社は RPO を 0 にすることができると言っています。

〇用語説明〇

今回、Barman でしか用いない用語はないですが、
人によってブレが出る用語なので、一応説明します。

・アーカイブ WAL
 barman の用語ではないですが、本記事では archive_command で退避された WAL ファイルを
 全てアーカイブ WAL と呼んでいます。

〇できること、機能紹介〇

さて、できることは以下となります。

– できるバックアップ種別
 ・完全バックアップ

– 取得できるバックアップ
 ・リモートバックアップ ☆
 ・ローカルバックアップ
 ・レプリケーションを利用した WAL ファイルバックアップ☆

– 機能
 複数の PostgreSQL サーババックアップ ☆
 WAL圧縮
 世代管理

コミュニティマニュアルでは「増分バックアップ」とありますが上記で説明したように、
一般的な「増分バックアップ」と異なるためできることとしては扱っていません。

Barman の最大の特徴はレプリケーションを利用した WAL ファイルバックアップです。
この機能を使えば RTO(Recovery Time Objective) を極めて短くすることができます。
※ Barman の開発元である EnterpriseDB 社は RTO = 0 もできるとドキュメントで説明しています。
 実際、それくらい短い時間で復旧が可能です。

〇環境〇

前提として今回は以下の環境で検証しました。
OS , kernel や Python および barman のバージョンは全サーバ共通です。

PostgerSQL サーバは以下の2つバージョンのサーバを用意しました。

 

また、前提として 1秒に 1レコード、現在時刻を挿入するスクリプトを実装しています。
これを PostgreSQL のリストア時に、いつの時点にリカバリができたか判断に利用します。

〇バックアップイメージ図〇

Barman は pg_basebackup あるいは rsync を用いてベースとなるバックアップを取得します。

今回バージョンが異なる 2 サーバを用意しました。
せっかくなのでそれぞれ別の方法でバックアップを取得してみましょう。

Postgres 10

Postgres 10 サーバは pg_basebackup でバックアップを取得し、
ストリーミングレプリケーションを用いて WAL を受け取ります。

Postgres 14

Postgres 10 サーバは rsync でバックアップを取得しましょう。
また、アーカイブ WAL はPostgreSQL の設定 archive_command で受け取るように設定します。
※この場合 RTO はストリーミングレプリケーションを用いて WAL を受け取るより長くなります。

 

〇インストール〇

インストールは yum でインストール可能です。

・barman サーバ

 yum -y install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
 yum -y install barman postgresql14

 

Barman はレプリケーション等を行うため postgresql パッケージが必要です。
しかし、postgresql パッケージ内に含まれる pg_receivewal や pg_basebackup を利用するだけであり、
Barman サーバ内部では Postgresプロセスの稼働はなくDBの構築も不要という点に特徴があります

パッケージに互換性があるため、postgresql14 パッケージを入れておけば、
PostgreSQL 10 サーバのバックアップも取得可能です。
逆はできないので Barman にインストールする PostgreSQL パッケージは最新がおすすめです。
※ PostgreSQL10 のパッケージでは PostgreSQL 14 サーバのバックアップは取得できない。

・PostgreSQL サーバ

yum -y install barman-cli

DBをリストアする際やアーカイブ WALを処理する際に、
barman 系コマンドが必要となるのでbarman コマンドをインストールします。

〇設定〇

・Barman 設定
barman は /etc/barman/barman.conf で全体(グローバル)の設定を
/etc/barman/conf.d/任意ファイル名 で個別サーバ設定を行います。

一つの設定ファイルで全サーバの設定を行うことも可能ですが、
わかりやすく 1 ファイル 1 サーバで設定しましょう

サーバ : Barman サーバ
設定ファイル : /etc/barman.d/postgresql10.conf

[postgresql10] # server_name といい任意の名前を設定します。
conninfo = host=172.31.23.90 user=pg-user dbname=postgres port=5432 # Postgres サーバへの接続情報
backup_method = postgres # バックアップ手法を指定 postgres は pg_basebackup でのバックアップとなる
streaming_backup_name = barman_streaming_BACKUP # pg_basebackup 時の application_name を指定
streaming_archiver = on # ロジカルレプリケーションで WAL ファイルを受け取る設定を有効化する
create_slot = auto # レプリケーションスロットを自動で作る設定
slot_name = slot_for_backup # レプリケーションスロット名を指定
path_prefix = /usr/pgsql-14/bin # barman サーバ内の pg_receivewal などが格納されている場所を指定
archiver = off # archive_command によるバックアップを無効化

設定ファイルはBarman 側の設定は上記です。
注意としてはロジカルレプリケーションでWAL を受け取っているので、archiver を明示的にoff にしています。
archiver の設定は archive_command を用いて Barman サーバへ WAL をバックアップする際に利用します。

rsync でバックアップを行う場合は以下のような設定になります。
サーバ : Barman サーバ
設定ファイル : /etc/barman.d/postgresql14.conf

[postgresql14]
ssh_command = ssh -i /var/lib/barman/.ssh/id_rsa pg-user@172.31.20.196
conninfo = host=172.31.20.196 user=pg-user dbname=postgres port=5432
backup_method = rsync
backup_options = exclusive_backup
archiver = on

PostgreSQL 側の設定は pg_hba.conf によるアクセス権限の付与が必要です。

・PostgreSQL 設定

・postgresql10

サーバ : postgresql10 サーバ
設定ファイル : pg_hba.conf

host replication pg-user 172.31.16.19/32 trust
host postgres pg-user 172.31.16.19/32 trust

 

Barman は PostgreSQL に接続して、
Checkpioint コマンドの実行や pg_start_backup (pg_stop_backup) を実行します。
加えて、PostgreSQL 10 サーバではレプリケーションでWAL ファイルを受け取るため、
レプリケーション用の設定も必要です。

サーバ : postgresql14 サーバ
設定ファイル : pg_hba.conf

host postgres pg-user 172.31.16.19/32 trust

 

PostgreSQL 14 では archive_command で WAL ファイルを受け取るため、
レプリケーション用の設定は不要です。

Postgresql 14 サーバではarchive_command を用いて WAL ファイルを Barman サーバに渡す必要があるため、
以下のように設定します。

サーバ : postgresql14 サーバ
設定ファイル : postgresql.conf

archive_command = 'barman-wal-archive 172.31.16.19 postgresql14 %p'

 

なお、postgresql10 サーバのアーカイブ wal はストリーミングレプリケーションで受け取っているため
archive_command の設定は不要です。

 

〇レプリケーション設定〇

さて、次はストリーミングレプリケーションで WAL を受け取る設定です。
シンプルにコマンドだけで言うと「barman receive-wal <server_name>」で可能です。
今回の場合は「barman receive-wal postgresql10」で可能です。

ポイントとしては2つあります。
1つはPostgres プロセスがレプリケーションを受け取るのではなく、
Barman が pg_receivewal を利用してレプリケーションを行う点です。
*つまり、Postgres プロセスは立ち上がらない

2つ目はフォアグラウンドプロセスで稼働するという点です。

つまり & を付けてバックグラウンドで実行しなければ
コマンドプロンプトがかえって来なくなります。

「barman receive-wal 10 &」を投入してバックグラウンドで実行するでも問題ないが、
この場合 Barman サーバで予期せぬ再起動が発生し、
いつの間にかロジカルレプリケーションが止まっていたという事象があり得ます。

そのため、今回は systemd を使ってデーモンとしてプロセスを稼働させてみましょう

サーバ : Barman サーバ
設定ファイル : /usr/lib/systemd/system/barman-streaming-postgresql10.service

[Unit]
Description=Barman streaming

[Service]
Type=simple

User=barman
Group=barman

ExecStart=/bin/barman receive-wal postgresql10
ExecStop=/bin/barman receive-wal postgresql10 --stop

[Install]
WantedBy=multi-user.target

 

サービスファイルを作ったの自動起動設定を有効化しつつ、
サービスを立ち上げてみましょう

systemctl enable barman-streaming-postgresql10 --now

・起動状況

# systemctl status barman-streaming-postgresql10.service
● barman-streaming-postgresql10.service - Barman streaming
Loaded: loaded (/usr/lib/systemd/system/barman-streaming-postgresql10.service; enabled; vendor preset: disabled)
Active: active (running) since 火 2022-09-26 15:50:17 JST; 7min ago
Process: 21756 ExecStop=/bin/barman receive-wal postgresql10 --stop (code=exited, status=0/SUCCESS)
Main PID: 21767 (barman)
CGroup: /system.slice/barman-streaming-postgresql10.service
tq21767 /usr/bin/python2 /bin/barman receive-wal postgresql10
mq21769 /usr/pgsql-14/bin/pg_receivewal --dbname=dbname=replication host=172.31.23.90 options=-cdatestyle=iso port=5432 replication=true user=pg-user application_name=barman_receive_wal --verbose --no-loop --no-password --directory=/var...

9月 26 15:50:17 ip-172-31-16-19.ap-northeast-1.compute.internal systemd[1]: Started Barman streaming.
9月 26 15:50:17 ip-172-31-16-19.ap-northeast-1.compute.internal barman[21767]: Starting receive-wal for server postgresql10
9月 26 15:50:17 ip-172-31-16-19.ap-northeast-1.compute.internal barman[21767]: postgresql10: pg_receivewal: 0/3000000 (タイムライン 1)からログのストリーミングを開始
#

 

プロセスを見ると以下のようになります。

# ps -ef | grep [r]eceive
barman 21767 1 0 15:50 ? 00:00:00 /usr/bin/python2 /bin/barman receive-wal postgresql10
barman 21769 21767 0 15:50 ? 00:00:00 /usr/pgsql-14/bin/pg_receivewal --dbname=dbname=replication host=172.31.23.90 options=-cdatestyle=iso port=5432 replication=true user=pg-user application_name=barman_receive_wal --verbose --no-loop --no-password --directory=/var/lib/barman/postgresql10/streaming --slot=slot_for_backup
#

 

これで Postgresql10 サーバもアーカイブ WAL を受け取れるようになりました。

詳細なレプリケーションステータスは「barman replication-status <server_name>」で確認可能です。

# barman replication-status postgresql10
Status of streaming clients for server 'postgresql10':
Current LSN on master: 0/305E248
Number of streaming clients: 1

1. Async WAL streamer
Application name: barman_receive_wal
Sync stage : 2/3 WAL Sent (min)
Communication : TCP/IP
IP Address : 172.31.16.19 / Port: 44768 / Host: -
User name : pg-user
Current state : streaming (async)
Replication slot: slot_for_backup
WAL sender PID : 13464
Started at : 2022-09-26 15:50:17.389410+09:00
Sent LSN : 0/305E248 (diff: 0 B)
Write LSN : 0/305E168 (diff: -224 B)
Flush LSN : 0/3000000 (diff: -376.6 KiB)
#

 

〇WAL アーカイブ設定確認〇

次に WALアーカイブ構成が正しくできているか確認します。
barman switch-xlog –force –archive <server_name> を実行することで確認できます。

「確認」とコミュニティマニュアルでも記載されていますが、PostgreSQL サーバでは実際に Checkpioint が発行されます。

# barman switch-xlog --force --archive postgresql10
The WAL file 000000010000000000000004 has been closed on server 'postgresql10'
Waiting for the WAL file 000000010000000000000004 from server 'postgresql10' (max: 30 seconds)
Processing xlog segments from streaming for postgresql10
000000010000000000000004
#

このコマンドが失敗する場合は、archive_command やレプリケーション設定に誤りがある可能性が高いです。

〇Barman 設定確認〇

これで一通りの設定が完了したはずです。
barman は設定に不備がないか「barman check <server_name>」で確認可能です。
実際に見てみましょう。

# barman check postgresql10
Server postgresql10:
PostgreSQL: OK
superuser or standard user with backup privileges: OK
PostgreSQL streaming: OK
wal_level: OK
replication slot: OK
directories: OK
retention policy settings: OK
backup maximum age: OK (no last_backup_maximum_age provided)
backup minimum size: OK (0 B)
wal maximum age: OK (no last_wal_maximum_age provided)
wal size: OK (0 B)
compression settings: OK
failed backups: OK (there are 0 failed backups)
minimum redundancy requirements: OK (have 0 backups, expected at least 0)
pg_basebackup: OK
pg_basebackup compatible: OK
pg_basebackup supports tablespaces mapping: OK
systemid coherence: OK (no system Id stored on disk)
pg_receivexlog: OK
pg_receivexlog compatible: OK
receive-wal running: OK
archiver errors: OK
#

 

# barman check postgresql14
Server postgresql14:
PostgreSQL: OK
superuser or standard user with backup privileges: OK
wal_level: OK
directories: OK
retention policy settings: OK
backup maximum age: OK (no last_backup_maximum_age provided)
backup minimum size: OK (0 B)
wal maximum age: OK (no last_wal_maximum_age provided)
wal size: OK (0 B)
compression settings: OK
failed backups: OK (there are 0 failed backups)
minimum redundancy requirements: OK (have 0 backups, expected at least 0)
ssh: OK (PostgreSQL server)
not in recovery: OK
systemid coherence: OK (no system Id stored on disk)
archive_mode: OK
archive_command: OK
continuous archiving: OK
archiver errors: OK
#

全て OK と出ているので問題がなさそうです。
エラーが出ている場合はエラーの内容と Barman のログ (/var/log/barman/barman.log)から
エラーの原因を特定、修正する必要があります。
*ミスしがちなポイントやよくあるエラーはブログ末尾でいくつか取り上げます。

〇バックアップ取得〇

バックアップの取得は 「barman backup –wait <server_name>」で可能です。

$ barman backup --wait postgresql10
Starting backup using postgres method for server postgresql10 in /var/lib/barman/postgresql10/base/20220926T160151
Backup start at LSN: 0/40137A0 (000000010000000000000004, 000137A0)
Starting backup copy via pg_basebackup for 20220926T160151
Copy done (time: 2 seconds)
Finalising the backup.
This is the first backup for server postgresql10
WAL segments preceding the current backup have been found:
000000010000000000000003 from server postgresql10 has been removed
Backup size: 31.5 MiB
Backup end at LSN: 0/6000000 (000000010000000000000005, 00000000)
Backup completed (start time: 2022-09-26 16:01:52.008113, elapsed time: 2 seconds)
Waiting for the WAL file 000000010000000000000005 from server 'postgresql10'
Processing xlog segments from streaming for postgresql10
000000010000000000000004
000000010000000000000005
$
$ barman backup --wait postgresql14
Starting backup using rsync-exclusive method for server postgresql14 in /var/lib/barman/postgresql14/base/20220926T160216
Backup start at LSN: 0/8000028 (000000010000000000000008, 00000028)
This is the first backup for server postgresql14
WAL segments preceding the current backup have been found:
000000010000000000000003 from server postgresql14 has been removed
000000010000000000000004 from server postgresql14 has been removed
000000010000000000000005 from server postgresql14 has been removed
000000010000000000000006 from server postgresql14 has been removed
Starting backup copy via rsync/SSH for 20220926T160216
Copy done (time: 1 second)
This is the first backup for server postgresql14
Asking PostgreSQL server to finalize the backup.
Backup size: 34.8 MiB
Backup end at LSN: 0/8001CE8 (000000010000000000000008, 00001CE8)
Backup completed (start time: 2022-09-26 16:02:17.128906, elapsed time: 3 seconds)
Waiting for the WAL file 000000010000000000000008 from server 'postgresql14'
Processing xlog segments from file archival for postgresql14
000000010000000000000007
000000010000000000000008
000000010000000000000008.00000028.backup
$

 

取得したバックアップは barman list-backups <server_name> で確認可能です。

$ barman list-backups postgresql10
postgresql10 20220926T160151 - Mon Sep 26 16:01:54 2022 - Size: 47.5 MiB - WAL Size: 16.0 MiB
$ barman list-backups postgresql14
postgresql14 20220926T160216 - Mon Sep 26 16:02:18 2022 - Size: 50.8 MiB - WAL Size: 0 B
$

〇リストア〇

・疑似障害
リストアに当たり事前に以下のコマンドで障害を発生させます。

$ date ; kill -9 $(head -1 ${PGDATA}/postmaster.pid) ; date
2022年 9月 26日 月曜日 16:20:03 JST
2022年 9月 26日 月曜日 16:20:03 JST
$

 

バックアップを取得したのは 16:01 と 16:02 なので、
バックアップ取得時刻~16:20 のデータがリストアできていれば PITR の成功と判断できます。

・リストア
リストアは以下のコマンドで可能です。

barman recover <server_name> <backup_id> <復元先ディレクトリ> –remote-ssh-command ‘ssh <user 名>@<IP アドレス>’ –get-wal

backup_id は barman list-backups <server_name> で確認可能です。

postgresql10 の backup_id は 20220926T160151、
postgresql14 の backup_id は 20220926T160216 となっています。
複数のバックアップを取得した環境で、一世代前のバックアップからリストアしたい事情などがある場合に
backup_id を指定します。

今回の場合、持っている最新のバックアップからリストアをしたいので「latest」を指定します。

ポイントとしては 3 つあります。
1: リストア先サーバの指定
–remote-ssh-command を指定しないとコマンドを実行したサーバ (つまり barman サーバ)にリストアがされます。

2: リストアに WAL ファイルを含める
–get-wal を指定することで WAL ファイルを含めたリストアが可能となります。

3: リストア後の archive_command の設定
リストア直後の archive_command 設定は「archive_command = false」となっています。
この状態ではバックアップの取得ができないなどの不都合がありますので、
元の設定に戻しましょう。

具体的なリストアコマンドは以下となります。
barman recover postgresql10 latest /pgdb/data_bk –remote-ssh-command ‘ssh pg-user@172.31.23.90’ –get-wal

このコマンドはシンプルにあるだけ最新の状態にリストアするコマンドです。
特定の時間に戻したい場合は上記に加えて –target-time を付与します。
疑似障害のおよそ 1 分前を指定してリストアしてみましょう。

サンプル

$ barman recover postgresql10 latest /pgdb/data_bk --remote-ssh-command 'ssh pg-user@172.31.31.5' --get-wal --target-time '2022-09-26 16:19:00'
Starting remote restore for server postgresql10 using backup 20220926T160151
Destination directory: /pgdb/data_bk
Remote command: ssh pg-user@172.31.23.90
Copying the base backup.
Generating recovery configuration
Identify dangerous settings in destination directory.

IMPORTANT
These settings have been modified to prevent data losses

postgresql.conf line 218: archive_command = false

WARNING: 'get-wal' is in the specified 'recovery_options'.
Before you start up the PostgreSQL server, please review the recovery.conf file
inside the target directory. Make sure that 'restore_command' can be executed by the PostgreSQL user.

Recovery completed (start time: 2022-09-26 16:04:12.701154, elapsed time: 6 seconds)

Your PostgreSQL server has been successfully prepared for recovery!
$

 

PostgreSQL のデータディレクトリ (PGDATA) は /pgdb/data ですが、
直接上書きリストアするのは怖いので一旦 /pgdb/data_bk に退避します。

そのうえで
mv /pgdb/data /pgdb/data_org
mv /pgdb/data_bk /pgdb/data
を行い、元のデータを残しつつ、バックアップデータを復元します。

PostgreSQL を起動する前に archive_command をもとに戻します。
*今回の場合ローカルに WAL アーカイブを退避していました。

sed -i -e "s/archive_command \= false/archive_command = 'cp %p \/opt\/backups\/postgres\/archived_wals\/%f \;'/" /pgdb/data/postgresql.conf

 

1秒に 1レコード、現在時刻を挿入するスクリプトを動かしていたので、
正常にリストアができているか確認してみましょう

$ psql -d INFDB -c "select * from test ORDER BY id DESC FETCH FIRST 5 ROWS ONLY;"
id | date | hostname
-----+---------------------+-------------------------------------------------
287 | 2022-09-26 16:18:58 | ip-172-31-23-90.ap-northeast-1.compute.internal
286 | 2022-09-26 16:18:57 | ip-172-31-23-90.ap-northeast-1.compute.internal
285 | 2022-09-26 16:18:56 | ip-172-31-23-90.ap-northeast-1.compute.internal
284 | 2022-09-26 16:18:55 | ip-172-31-23-90.ap-northeast-1.compute.internal
283 | 2022-09-26 16:18:54 | ip-172-31-23-90.ap-northeast-1.compute.internal
(5 行)

$

 

16:18:58 にリストアができました。
*スクリプトも厳密に 1,000 msec で動いているわけではないので 1 秒は誤差と判断します。

・PostgreSQL14 のリストア
PostgreSQL14 は archive_command で WAL ファイルを受け取っています。
そのため、最新の状態にリストアすることはできません。

リストアできるのは最後に archive_command で WAL ファイルを受け取った時刻までです。

 

〇よくあるトラブル〇

本ブログを執筆するにあたり直面したトラブルについて備忘を含め記録します。

・確認ポイント
 barman check <server_name>
 Barman サーバのログファイル (/var/log/barman/barman.log)
 PostgreSQL ログファイル

pg_hba.conf の設定が不足している

$ barman check postgresql10
Server postgresql10:
PostgreSQL: FAILED
directories: OK
retention policy settings: OK
backup maximum age: OK (no last_backup_maximum_age provided)
backup minimum size: OK (64.7 MiB)
wal maximum age: OK (no last_wal_maximum_age provided)
wal size: OK (0 B)
compression settings: OK
failed backups: OK (there are 0 failed backups)
minimum redundancy requirements: OK (have 1 backups, expected at least 0)
pg_basebackup: OK
pg_basebackup compatible: FAILED (PostgreSQL version: None, pg_basebackup version: 14.3)
systemid coherence: OK (no system Id available)
pg_receivexlog: OK
pg_receivexlog compatible: FAILED (PostgreSQL version: None, pg_receivexlog version: 14.3)
receive-wal running: FAILED (See the Barman log file for more details)
archiver errors: OK
$

 

pg_hba.conf が不足しているため「PostgreSQL: FAILED」となっています。
そして、PostgreSQL に接続ができないため、バックアップ先サーバの情報がまったくわからない状況です。
そのため pg_basebackup compatible: と pg_receivexlog compatible も FAILED となっています。

焦らず Barman サーバのログファイルを確認すれば、
わかりやすく原因が記載されています。

/var/log/barman/barman.log

2022-09-26 15:26:54,793 [3830] barman.postgres WARNING: Error retrieving PostgreSQL status: connection to server at "172.31.31.5", port 5432 failed: FATAL: no pg_hba.conf entry for host "172.31.19.92", user "pg-user", database "postgres", SSL off
2022-09-26 15:26:54,797 [3830] barman.postgres WARNING: Error retrieving PostgreSQL status: connection to server at "172.31.31.5", port 5432 failed: FATAL: no pg_hba.conf entry for replication connection from host "172.31.19.92", user "pg-user", SSL off

 

 

・WAL アーカイブ設定確認がうまくできない

コマンド「barman switch-xlog –force –archive <server_name>」が失敗する場合、
PostgreSQL サーバの設定などが不足している可能性があります。

・「streaming_archiver = on」の場合
そもそもレプリケーションが正常に受けられているか確認しましょう。
barman replication-status postgresql10

streaming_archiver = on はをストリーミングレプリケーションを通して
WAL アーカイブを受け取ります。
そのため原因としてはレプリケーションが受けられていないことほぼほぼです。

archiver = on の場合
この場合、Barman サーバ PostgreSQL サーバの archive_mode に従って WAL アーカイブを取得します。
つまり、PostgreSQL サーバ側に問題がある可能性が高いです。
以下の点で問題がないか確認してください。

・PostgreSQL サーバから PostgreSQL プロセス所有ユーザで Barman サーバに対して ssh ができる
・PostgreSQL サーバに barman-cli パッケージがインストールされている

この 2 点が不足していることが原因である可能性が高いです。
そのうえで PostgreSQL ログファイルを確認して原因を確認しましょう。

 

〇まとめ〇

Barman は比較的シンプルな設定ながら RTO を極めて短くできる OSS です。
リストアも比較的簡単にできるのでぜひ触ってみて下さい!

ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

0人がこの投稿は役に立ったと言っています。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です