構成リファレンス

Barmanは、構成より慣例のアプローチに従います。これにより、一部のオプションをグローバルに定義し、サーバーレベルでオーバーライドできることにより構成が簡素化されます。これは、サーバーのデフォルトの動作を設定し、必要に応じて特定のサーバーをカスタマイズできることを意味します。このデザインにより、柔軟性を維持しながら、過剰な構成の必要性が削減されます。

使用法

効果的な操作には、適切な構成が重要です。 Barmanは、さまざまな種類の構成ファイルを使用して、グローバル設定、サーバー固有の設定、および3つのスコープで構成されるモデル固有の設定を管理します。

1. Global Configuration: It comprises one file with a set of configurations for the barman system, such as the main directory, system user, log file, and other general options. Default location is /etc/barman.conf and it can be overridden on a per-user level by ~/.barman.conf or by specifying a .conf file using the -c / --config with the barman command directly in the CLI.

Barmanは、事前に定義された順序で構成ファイルを検索し、最初に見つけたものを使用します。検索順序は次のとおりです。

• ~/.barman.conf - ユーザーごとの構成ファイル。

• /etc/barman.conf - メインのグローバル構成ファイル。

• /etc/barman/barman.conf - 代替グローバル構成ファイル。

2. Server Configuration: It comprises one or more files with a set of configurations for a Postgres server that you want to keep track and interact for backup, recovery and/or replication. Default location is /etc/barman.d and must use the .conf suffix. You may have one or multiple files for servers. You can override the default location by setting the configuration_files_directory option in the global configuration file and placing the files in that particular location.

3. Model Configuration: It comprises one or more files with a set of configurations overrides that can be applied to Barman servers within the same cluster as the model. These overrides can be implemented using the barman config-switch command. Default location is /etc/barman.d and must use the .conf suffix. The same configuration_files_directory override option from the server configuration applies for models. You may have one or multiple files for models.

注釈

歴史的には、グローバル、サーバー、およびモデルオプションを含む単一の構成ファイルを使用できますが、メンテナンス上の理由から、このアプローチは非推奨です。

構成ファイルは INI フォーマットに従い、角かっこ内のヘッダーで示されるセクションで構成されています。各セクションにはさまざまなオプションを含めることができます。

モデルとサーバーには一意の識別子が必要で、予約語は名前として使用できません。

Reserved Words

次の予約語は、サーバー名またはモデル名として使用できません。

• barman グローバルセクションを識別します。

• all すべての管理対象サーバーでコマンドを実行するための特別なショートカット。

Parameter Types

構成オプションには次のタイプがあります。

• String テキストデータファイルパス、名前など。

• Enum 列挙値、多くの場合事前定義された選択に制限されます。

• Integer 数値。

• Boolean on 、 true 、 1 true または off 、 false 、 0 false です。

  注釈

  一部の列挙型では、 off は許可されますが、 false は許可されません。

オプション

構成ファイルのオプションには、特定のスコープまたは共有スコープを持つことができます。次の構成オプションは、 Barmanがバックアップとリカバリーを実行する方法を構成するだけでなく、 Barmanが構成済みのPostgresサーバーと相互作用して、バックアップとリカバリー、および高可用性戦略を適用できる方法のさまざまな側面を構成するために使用されます。

一般

これらは一般的な構成オプションです。

active

このオプションが true デフォルトに設定されている場合、サーバーは完全に動作します。 false に設定されている場合、サーバーは診断使用のみに制限されます。つまり、バックアップ実行やWALアーカイブなどの操作コマンドが一時的に無効になります。新しいサーバーをBarmanに組み込む場合、最初に active = false を設定することをお勧めします。サーバーをアクティブにする前に、バーマンチェックで問題が示されないことを確認します。このアプローチは、初期セットアップ中にBarmanでの過度のエラーログを防ぐのに役立ちます。

スコープサーバー/モデル。

archiver

このオプションは、サーバーのPostgresの archive_command を介したログファイルの配布を有効にします。 true に設定すると、 Barmanは継続的アーカイブが構成されることを想定し、Postgresが受信ディレクトリ incoming_wals_directory に保存するWALファイルを、チェック、処理、圧縮を含めて管理します。 false デフォルトに設定されている場合、継続的なアーカイブは無効になります。

注釈

archiver も streaming_archiver も構成されていない場合、 Barmanはこのオプションを true に自動的に設定して、デフォルトでアーカイブが有効になっていた以前のデフォルト動作との互換性を維持します。

スコープグローバル/サーバー/モデル。

archiver_batch_size

このオプションは、 0 より大きい値に設定することにより、アーカイバープロセスのWALファイルのバッチ処理を有効にします。設定されていない場合、アーカイバーはWALキューに無制限のデフォルトの処理モードを使用します。バッチ処理が有効になると、アーカイバープロセスは実行ごとに最大 archiver_batch_size WALセグメントを処理します。この値は整数である必要があります。

スコープグローバル/サーバー/モデル。

bandwidth_limit

バックアップおよびリカバリー操作の最大転送速度を1秒あたりのキロバイト単位で指定します。 0 の値は、制限なしデフォルトを示します。

注釈

backup_method = postgres | rsync の場合にのみ適用されます。

スコープグローバル/サーバー/モデル。

barman_home

Barmanのメインデータディレクトリを指定します。デフォルトの /var/lib/barman 。

範囲 グローバル。

barman_lock_directory

ロックファイルのディレクトリを指定します。デフォルトは barman_home です。

注釈

barman_lock_directory は、非ネットワークローカルファイルシステム上にある必要があります。 NFSまたはその他のネットワークファイルシステムを使用してバックアップとWALファイルを保存する場合、lockディレクトリがローカルファイルシステムにあることを確認してください。

範囲 グローバル。

check_timeout

サーバーごとにBarman checkコマンドの最大実行時間を秒単位で設定します。タイムアウトを無効にするには、 0 に設定します。デフォルトは 30 秒です。負でない整数である必要があります。

スコープグローバル/サーバー/モデル。

cluster

サーバーまたはモデルを、関連するクラスター名にタグ付けします。 Barmanは、この関連付けを使用して、このクラスター内のすべてのサーバー/モデルの構成をオーバーライドします。サーバーで省略した場合、デフォルトのサーバーの名前が使用されます。

注釈

該当するサーバーをグループ化するには、構成モデルに指定する必要があります。

スコープサーバー/モデル。

config_changes_queue

barman config-update コマンドを介して要求された構成の変更を処理するBarmanのキューのファイルシステムの場所を指定します。このキューは、構成変更要求のシリアル化と再試行を管理します。デフォルトでは、 Barmanは barman_home の下の cfg_changes.queue という名前のファイルに書き込みます。

範囲 グローバル。

configuration_files_directory

サーバー/モデル構成ファイルがBarmanによって読み取られるディレクトリを指定します。デフォルトの /etc/barman.d/ 。

範囲 グローバル。

conninfo

BarmanがPostgresサーバーに接続するために使用する接続文字列を指定します。これはlibpq接続文字列です。一般的に使用されるキーには、 host 、 hostaddr 、 port 、 dbname 、 user および password が含まれます。詳細については、 host PostgreSQLドキュメントを参照してください。

スコープサーバー/モデル。

create_slot

ストリーミングWALファイルにレプリケーションスロットがまだ存在しない場合、 Barmanがレプリケーションスロットを自動的に作成するかどうかを決定します。 auto に設定され、 slot_name が定義されている場合、 Barmanはスロットを自動的に作成しようとします。 manual デフォルトに設定している場合、レプリケーションスロットを手動で作成する必要があります。

スコープグローバル/サーバー/モデル。

description

人間が読めるサーバーの説明を提供します。

スコープサーバー/モデル。

errors_directory

Barmanによるアーカイブ中にエラーが発生したWALファイルが保存されるディレクトリ。これには、重複したWALファイルたとえば、既にストリーミングされたが、異なるハッシュを持つアーカイブされたWALファイル、およびWALアーカイブディレクトリで見つかった予期しないファイルが含まれます。

このディレクトリにファイルを配置する目的は、誰かが後でアーカイブされなかった理由を確認し、適切なアクションを実行できるようにすることです。破棄、どこか別の場所に保存、以前にアーカイブされた重複ファイルを置き換えるなど

スコープサーバー。

encryption

バックアップとWALファイルの暗号化に使用される暗号化方法を指定します。サポートされている値は次のとおりです。

• none デフォルト 暗号化は適用されません。

• gpg 暗号化に`GPG`を使用します。システムに`GPG`をインストールし、適切に構成する必要があります。

スコープグローバル/サーバー/モデル。

encryption_key_id

バックアップとWALファイルの暗号化に使用される暗号化キーIDを指定します。このオプションは encryption = gpg の場合に必要で、システムで使用可能な有効な:term:`GPG`キーIDに対応する必要があります。

スコープグローバル/サーバー/モデル。

encryption_passphrase_command

バックアップとWALファイルを復号するための暗号化パスフレーズを取得するために使用されるコマンドを指定します。コマンドはパスフレーズを標準出力に書き込む必要があります。

スコープグローバル/サーバー/モデル。

forward_config_path

cron または sync-info コマンド中に、パッシブノードが構成ファイルパスをプライマリノードに転送するかどうかを決定します。 Barmanが -c / --config オプションで呼び出され、構成パスがパッシブとプライマリBarmanサーバーの両方で同じである場合、 true に設定します。デフォルトの false 。

スコープグローバル/サーバー/モデル。

immediate_checkpoint

Postgresがバックアップの開始時にチェックポイントを処理する方法を制御します。 false デフォルトに設定して、 checkpoint_completion_target に従ってチェックポイントを完了できます。即時チェックポイントの場合は true に設定します。Postgresはできるだけ早くチェックポイントを完了します。

スコープグローバル/サーバー/モデル。

keepalive_interval

ハートビートクエリーを送信する間隔を秒単位で設定して、rsyncバックアップ中にlibpq接続をアクティブに保ちます。デフォルトは 60 秒です。これを 0 に設定すると、ハートビートが無効になります。

スコープグローバル/サーバー/モデル。

lock_directory_cleanup

barman_lock_directory の未使用のロックファイルの自動クリーンアップを有効にします。

範囲 グローバル。

log_file

Barmanのログファイルの場所を指定します。デフォルトの /var/log/barman/barman.log 。

範囲 グローバル。

log_level

ロギングのレベルを設定します。オプションには次のものが含まれます DEBUG 、 INFO 、 WARNING 、 ERROR 、および CRITICAL 。

範囲 グローバル。

minimum_redundancy

保持するバックアップの最小数を指定します。デフォルトは 0 です。

スコープグローバル/サーバー/モデル。

model

true に設定すると、サーバーセクションを構成ファイルからクラスターのモデルに変更します。この場合、 false オプションはありません。 false オプションをシミュレートする場合は、構成内のオプションをコメントアウトする #model=true または削除します。サーバー名のデフォルト。

スコープ モデル。

network_compression

ネットワーク転送のデータ圧縮を有効または無効にします。圧縮を無効にするには false デフォルトに設定し、有効にしてネットワーク使用量を削減するには true に設定します。

スコープグローバル/サーバー/モデル。

parallel_jobs

バックアップまたはリカバリー中にファイルのコピーに使用されるパラレルワーカーの数を制御します。正の整数である必要があります。デフォルトは 1 です。

注釈

backup_method = rsync の場合にのみ適用されます。

スコープグローバル/サーバー/モデル。

parallel_jobs_start_batch_period

並列ジョブの単一バッチが開始される時間間隔を秒単位で指定します。デフォルトは 1 秒です。これは、 parallel_jobs_start_batch_size が 10 であり、 parallel_jobs_start_batch_period が 1 である場合、 1 秒以内に開始できる 10 ジョブの最大数があるため、1秒あたりの 10 ジョブの有効レート制限が得られることを意味します。

注釈

backup_method = rsync の場合にのみ適用されます。

スコープグローバル/サーバー/モデル。

parallel_jobs_start_batch_size

単一のバッチで開始する並列ジョブの最大数を定義します。デフォルトは 10 ジョブです。これは、 parallel_jobs_start_batch_size が 10 であり、 parallel_jobs_start_batch_period が 2 である場合、これは、 2 秒以内に開始できる最大 10 ジョブを生成することを意味します。

注釈

backup_method = rsync の場合にのみ適用されます。

スコープグローバル/サーバー/モデル。

path_prefix

コロンで区切られた1つ以上の絶対パスをリストします。Barmanは、PostgreSQLバイナリ PG_MAJOR_VERSION の適切な bin ディレクトリから rsync 、暗号化、圧縮ツールなどの実行可能ファイルを検索します。これらのパスは PATH 環境変数の先頭に追加され、他のパスより前にチェックされます。

スコープグローバル/サーバー/モデル。

primary_checkpoint_timeout

プライマリサーバーにチェックポイントを強制する前に、新しいWALファイルを待機する時間。デフォルトの 0 。

スコープサーバー/モデル。

primary_conninfo

スタンバイバックアップ中にBarmanがプライマリPostgresサーバーに接続するための接続文字列。

スコープサーバー/モデル。

primary_ssh_command

Barmanがパッシブの場合、プライマリBarmanサーバーに接続するためのSSHコマンド。

スコープグローバル/サーバー/モデル。

slot_name

streaming_archiver が有効になっている場合の receive-wal コマンドのレプリケーションスロット名。

スコープグローバル/サーバー/モデル。

ssh_command

BarmanがrsyncバックアップのためにPostgresサーバーに接続するために使用するSSHコマンド。

スコープサーバー/モデル。

streaming_archiver

WALファイルのPostgresのストリーミングプロトコルを有効にします。デフォルトの false 。

注釈

archiver も streaming_archiver も構成されていない場合、 Barmanは archiver オプションを true に自動的に設定して、デフォルトでアーカイブが有効になっていた以前のデフォルト動作との互換性を維持します。

スコープグローバル/サーバー/モデル。

streaming_archiver_batch_size

ストリーミングアーカイバーでWALファイルを処理するためのバッチサイズ。デフォルトの 0 。

スコープグローバル/サーバー/モデル。

streaming_archiver_name

receive-wal コマンドのアプリケーション名。デフォルト barman_receive_wal 。

スコープグローバル/サーバー/モデル。

streaming_backup_name

pg_basebackup コマンドのアプリケーション名。デフォルト barman_streaming_backup 。

スコープグローバル/サーバー/モデル。

streaming_conninfo

ストリーミングレプリケーションプロトコルの接続文字列。デフォルトの conninfo 。

スコープサーバー/モデル。

tablespace_bandwidth_limit

バックアップおよびリカバリー操作の特定のテーブルスペースの最大転送速度。 0 の値は、制限なしデフォルトを示します。

注釈

backup_method = rsync の場合にのみ適用されます。

スコープグローバル/サーバー/モデル。

バックアップ

これらの構成オプションは、 Barmanがバックアップを実行する方法に関連しています。

autogenerate_manifest

これは、バックアップマニフェストファイルの自動作成を許可するブールオプションです。 JSONドキュメントであるマニフェストファイルには、バックアップに含まれるすべてのファイルがリストされています。バックアップの完了時に生成され、backupディレクトリに保存されます。マニフェストファイルの形式は、 backup manifest format PostgreSQLドキュメントで概要を示した仕様に準拠しており、 pg_verifybackup ツールと互換性があります。デフォルトは false です。

注釈

backup_method が rsync でない場合、このオプションは無視されます。

スコープグローバル/サーバー/モデル。

backup_compression

バックアッププロセスの圧縮方法を指定します。 gzip 、 lz4 、 zstd 、または none に設定できます。選択した圧縮方法のCLIツールがBarmanとPostgresサーバーの両方で利用できることを確認します。

注釈

lz4 および zstd には、Postgresバージョン15以降が必要であることに注意してください。このオプションの設定を解除するか、 none を使用すると、非圧縮アーカイブデフォルトになります。 backup_method = postgres の場合のみサポートされます。

スコープグローバル/サーバー/モデル。

backup_compression_format

圧縮バックアップを保存するときに pg_basebackup が使用する形式を決定します。オプションは plain または tar で、設定されていない場合はデフォルトで tar 。 plain 形式は、 Postgresバージョン15以降を使用しており、 backup_compression_location が server に設定されている場合にのみ使用できます。

注釈

backup_method = postgres の場合のみサポートされます。

スコープグローバル/サーバー/モデル。

backup_compression_level

バックアップの圧縮レベルを整数として定義します。許容値は、 backup_compression で指定された圧縮方法によって異なります。

注釈

backup_method = postgres の場合のみサポートされます。

スコープグローバル/サーバー/モデル。

backup_compression_location

バックアップ中に圧縮を発生する場所を指定します client または server のいずれか。 server オプションは、Postgresバージョン15以降を使用している場合にのみ使用できます。

注釈

backup_method = postgres の場合のみサポートされます。

スコープグローバル/サーバー/モデル。

backup_compression_workers

バックアッププロセス中の圧縮に使用されるスレッドの数を設定します。これは、 backup_compression=zstd の場合にのみ適用されます。デフォルト値は0で、標準の圧縮動作を使用します。

注釈

backup_method = postgres の場合のみサポートされます。

スコープグローバル/サーバー/モデル。

backup_directory

サーバーのバックアップデータを保存するディレクトリを指定します。デフォルトの <barman_home>/<server_name> 。

スコープサーバー。

backup_method

Barmanがバックアップを実行するために使用する方法を定義します。オプションには次のものが含まれます

• rsync デフォルト SSHでrsyncコマンドを使用してバックアップを実行します ssh_command が必要 。

• postgres バックアップに pg_basebackup コマンドを使用します。

• local-rsync BarmanはPostgresデータベースと同じサーバーで同じユーザーとして実行され、rsyncファイルシステムコピーを実行すると仮定します。

• snapshot snapshot_provider オプションで指定されたクラウドプロバイダーのAPIを利用して、 snapshot_disks で定義されたディスクスナップショットを作成し、バックアップラベルとメタデータのみを独自のストレージに保存します。

スコープグローバル/サーバー/モデル。

backup_options

バックアップ中にBarmanがPostgresと対話する方法を制御します。これは、次のものを含めることができるコンマ区切りリストです。

• concurrent_backup デフォルト 同時バックアップを使用し、Postgresバージョン9.6以降で推奨され、スタンバイサーバーからのバックアップをサポートします。

• exclusive_backup 非推奨の排他的バックアップ方法を使用します。 15より前のPostgresバージョンのみ。このオプションは、将来的に削除される予定です。

• external_configuration バックアップ実行中の外部構成ファイルに関する警告を抑制します。

注釈

exclusive_backup と concurrent_backup は一緒に使用できません。

スコープグローバル/サーバー/モデル。

basebackups_directory

ベースバックアップが保存されるディレクトリを指定します。デフォルトの <backup_directory>/base 。

スコープサーバー。

basebackup_retry_sleep

ベースバックアップコピーが失敗した後、再試行するまでに待機する秒数を設定します。デフォルトは 30 秒です。負でない整数である必要があります。

注釈

これは、バックアップ操作とリカバリー操作の両方に適用されます。

スコープグローバル/サーバー/モデル。

basebackup_retry_times

エラーが発生した後のベースバックアップコピーの再試行回数を定義します。デフォルトは 0 再試行なしです。負でない整数である必要があります。

注釈

これは、バックアップ操作とリカバリー操作の両方に適用されます。

スコープグローバル/サーバー/モデル。

reuse_backup

backup_method=rsync を使用する場合、最後に使用可能なバックアップを再利用することにより、インクリメンタル バックアップのサポートを制御します。オプションは次のとおりです。

• off デフォルト 標準のフルバックアップ。

• copy サーバーの最後のバックアップを再利用し、変更されていないファイルのコピーを作成することによる、ファイルレベルのインクリメンタル バックアップバックアップ時間の短縮のためのみ

• link サーバーの最後のバックアップを再利用し、変更されていないファイルのハードリンクを作成することによる、ファイルレベルのインクリメンタル バックアップ バックアップ領域と時間の削減のため

注釈

このオプションは backup_method=postgres の場合無視されます。

スコープグローバル/サーバー/モデル。

worm_mode

on に設定している場合、WORMライトワンスリードメニーストレージのサポートを有効にし、 Barmanが不変ストレージのバックアップを正しく処理できるようにします。デフォルトは off です。

スコープグローバル/サーバー/モデル。

クラウド バックアップ

これらの構成オプションは、 Barmanがクラウドでバックアップを実行する方法に関連しています。

aws_await_snapshots_timeout

タイムアウトが発生する前にAWSスナップショットが作成されるのを待機する時間を秒単位で指定します。デフォルト値は 3600 秒です。これは正の整数である必要があります。

注釈

backup_method = snapshot および snapshot_provider = aws の場合にのみサポートされます。

スコープグローバル/サーバー/モデル。

aws_profile

AWSで認証するときに使用するAWSプロファイルの名前たとえば、AWS資格情報ファイルの INI セクション。

注釈

backup_method = snapshot および snapshot_provider = aws の場合にのみサポートされます。

スコープグローバル/サーバー/モデル。

aws_region

snapshot_instance および snapshot_disks で定義されたEC2 VMとストレージボリュームが存在するAWSリージョンを示します。

注釈

backup_method = snapshot および snapshot_provider = aws の場合にのみサポートされます。

スコープグローバル/サーバー/モデル。

aws_snapshot_lock_mode

スナップショットのロックモード。これは、 snapshot_instance および snapshot_disk が設定されている場合にのみ有効です。

許可されるオプション

• compliance 。

• governance 。

注釈

backup_method = snapshot および snapshot_provider = aws の場合にのみサポートされます。

スコープグローバル/サーバー/モデル。

aws_snapshot_lock_duration

ロック期間は、スナップショットがロックされた期間日単位であり、1〜36,500の範囲です。ロック期間または有効期限のいずれかを設定します両方ではありません。

注釈

backup_method = snapshot および snapshot_provider = aws の場合にのみサポートされます。

スコープグローバル/サーバー/モデル。

aws_snapshot_lock_cool_off_period

クーリングオフ期間は、 compliance モードでスナップショットをロックするときに指定できるオプションの時間時間単位で、1〜72の範囲で指定します。

注釈

backup_method = snapshot および snapshot_provider = aws の場合にのみサポートされます。

スコープグローバル/サーバー/モデル。

aws_snapshot_lock_expiration_date

ロックの期間は、将来の有効期限によって決まります。 YYYY-MM-DDTHH:MM:SS.sssZ 形式を使用して、スナップショット作成日時から少なくとも1日後である必要があります。ロック期間または有効期限のいずれかを設定します両方ではありません。

注釈

backup_method = snapshot および snapshot_provider = aws の場合にのみサポートされます。

スコープグローバル/サーバー/モデル。

azure_credential

認証に使用するAzure資格情報の種類を指定します azure-cli 、 managed-identity または default 。指定しない場合、デフォルトのAzure認証方法が使用されます。

注釈

backup_method = snapshot および snapshot_provider = azure の場合にのみサポートされます。

スコープグローバル/サーバー/モデル。

azure_resource_group

コンピューティングインスタンスと、 snapshot_instance および snapshot_disks で定義されたディスクを含むAzureリソースグループの名前を指定します。

注釈

backup_method = snapshot および snapshot_provider = azure の場合にのみサポートされます。

スコープグローバル/サーバー/モデル。

azure_subscription_id

snapshot_instance および snapshot_disks で定義されたインスタンスとストレージボリュームを所有するAzureサブスクリプションを識別します。

注釈

backup_method = snapshot および snapshot_provider = azure の場合にのみサポートされます。

スコープグローバル/サーバー/モデル。

gcp_project

snapshot_instance および snapshot_disks で定義されたインスタンスとストレージボリュームを所有するGCPプロジェクトのIDを指定します。

注釈

backup_method = snapshot および snapshot_provider = gcp の場合にのみサポートされます。

スコープグローバル/サーバー/モデル。

gcp_zone

スナップショットバックアップ用にコンピューティングインスタンスとディスクが配置されているアベイラビリティーゾーンを示します。

注釈

backup_method = snapshot および snapshot_provider = gcp の場合にのみサポートされます。

スコープサーバー/モデル。

snapshot_disks

このオプションは、クラウドスナップショットバックアップに含めるディスクのコンマ区切りリストです。

注釈

backup_method = snapshot の場合に必須。

snapshot_disks リストには、Postgresデータを保存するすべてのディスクが含まれていることを確認します。これらのリストされたディスクにないデータはバックアップに含まれず、リカバリ中に使用できません。

スコープサーバー/モデル。

snapshot_instance

ストレージボリュームが接続されているVMまたはコンピューティングインスタンスの名前。

注釈

backup_method = snapshot の場合に必須。

スコープサーバー/モデル。

snapshot_provider

スナップショットの作成に使用するクラウドプロバイダーの名前。サポートされている値 aws 、 azure および gcp 。

注釈

backup_method = snapshot の場合に必須。

スコープグローバル/サーバー/モデル。

フックスクリプト

これらの構成オプションは、フックスクリプトの実行前または実行後に関連しています。

post_archive_retry_script

WALファイルがアーカイブされた後に実行するフックスクリプトを指定します。 Barmanは、 SUCCESS (0)、 ABORT_CONTINUE (62)、または ABORT_STOP (63)を返すまで、このスクリプトを再試行します。アーカイブ後のシナリオでは、 ABORT_STOP は ABORT_CONTINUE と同じ効果があります。

スコープ グローバル/サーバー。

post_archive_script

WALファイルがアーカイブされた後に実行するフックスクリプトを指定します post_archive_retry_script 。

スコープ グローバル/サーバー。

post_backup_retry_script

ベースバックアップの後に実行するフックスクリプトを指定します。 Barmanは、 SUCCESS (0)、 ABORT_CONTINUE (62)、または ABORT_STOP (63)を返すまで、このスクリプトを再試行します。バックアップ後シナリオでは、 ABORT_STOP は ABORT_CONTINUE と同じ効果があります。

スコープ グローバル/サーバー。

post_backup_script

ベースバックアップの後に実行するフックスクリプトを指定します post_backup_retry_script 。

スコープ グローバル/サーバー。

post_delete_retry_script

バックアップを削除した後に実行するフックスクリプトを指定します。 Barmanは、 SUCCESS (0)、 ABORT_CONTINUE (62)、または ABORT_STOP (63)を返すまで、このスクリプトを再試行します。削除後シナリオでは、 ABORT_STOP は ABORT_CONTINUE と同じ効果があります。

スコープ グローバル/サーバー。

post_delete_script

post_delete_retry_script に従って、バックアップを削除した後に実行するフックスクリプトを指定します。

スコープ グローバル/サーバー。

post_recovery_retry_script

リカバリ後に実行するフックスクリプトを指定します。 Barmanは、 SUCCESS (0)、 ABORT_CONTINUE (62)、または ABORT_STOP (63)を返すまで、このスクリプトを再試行します。リカバリー後のシナリオでは、 ABORT_STOP は ABORT_CONTINUE と同じ効果があります。

スコープ グローバル/サーバー。

post_recovery_script

post_recovery_retry_script に従って、リカバリ後に実行するフックスクリプトを指定します。

スコープ グローバル/サーバー。

post_wal_delete_retry_script

WALファイルを削除した後に実行するフックスクリプトを指定します。 Barmanは、 SUCCESS (0)、 ABORT_CONTINUE (62)、または ABORT_STOP (63)を返すまで、このスクリプトを再試行します。 WAL削除後のシナリオでは、 ABORT_STOP は ABORT_CONTINUE と同じ効果があります。

スコープ グローバル/サーバー。

post_wal_delete_script

post_wal_delete_retry_script に従って、WALファイルを削除した後に実行するフックスクリプトを指定します。

スコープ グローバル/サーバー。

pre_archive_retry_script

pre_archive_script に続いて、メンテナンス中にWALファイルがアーカイブされる前に実行するフックスクリプトを指定します。再試行フックスクリプトとして、 Barmanは SUCCESS (0)、 ABORT_CONTINUE (62)、または ABORT_STOP (63)のいずれかを返すまでスクリプトを繰り返し実行します。 ABORT_STOP を返すと、障害がエスカレートし、WALアーカイブプロセスが停止します。

スコープ グローバル/サーバー。

pre_archive_script

WALファイルがメンテナンスによってアーカイブされる前に起動されるフックスクリプトを指定します。

スコープ グローバル/サーバー。

pre_backup_retry_script

pre_backup_script に続いて、ベースバックアップの前に実行するフックスクリプトを指定します。再試行フックスクリプトとして、 Barmanは SUCCESS (0)、 ABORT_CONTINUE (62)、または ABORT_STOP (63)を返すまで、スクリプトの実行を繰り返し試行します。 ABORT_STOP を返すと、障害がエスカレートし、バックアッププロセスが中断されます。

スコープ グローバル/サーバー。

pre_backup_script

ベースバックアップを開始する前に実行するフックスクリプトを指定します。

スコープ グローバル/サーバー。

pre_delete_retry_script

pre_delete_script に続いて、バックアップを削除する前に実行する再試行フックスクリプトを指定します。再試行フックスクリプトとして、 Barmanは SUCCESS (0)、 ABORT_CONTINUE (62)、または ABORT_STOP (63)を返すまで、スクリプトの実行を繰り返し試行します。 ABORT_STOP を返すと、障害がエスカレートし、バックアップの削除が中断されます。

スコープ グローバル/サーバー。

pre_delete_script

バックアップを削除する前に実行するフックスクリプトを指定します。

スコープ グローバル/サーバー。

pre_recovery_retry_script

pre_recovery_script に従って、リカバリーの前に実行する再試行フックスクリプトを指定します。再試行フックスクリプトとして、 Barmanは SUCCESS (0)、 ABORT_CONTINUE (62)、または ABORT_STOP (63)を返すまで、スクリプトの実行を繰り返し試行します。 ABORT_STOP を返すと、障害がエスカレートし、リカバリプロセスが中断されます。

スコープ グローバル/サーバー。

pre_recovery_script

リカバリを開始する前に実行するフックスクリプトを指定します。

スコープ グローバル/サーバー。

pre_wal_delete_retry_script

pre_wal_delete_script の前に実行される、WALファイル削除の再試行フックスクリプトを指定します。再試行フックスクリプトとして、 Barmanは SUCCESS (0)、 ABORT_CONTINUE (62)、または ABORT_STOP (63)を返すまで、スクリプトの実行を繰り返し試行します。 ABORT_STOP を返すと、障害がエスカレートし、WALファイルの削除が中断されます。

スコープ グローバル/サーバー。

pre_wal_delete_script

WALファイルを削除する前に実行するフックスクリプトを指定します。

スコープ グローバル/サーバー。

ログ先行書き込みWAL

これらの構成オプションは、 BarmanがPostreSQLサーバーの書き込み先行ログWALを管理する方法に関連しています。

compression

WALファイルの標準の圧縮アルゴリズムを指定します。オプションには次のものが含まれます。 lz4 、 xz 、 zstd 、 gzip 、 pygzip 、 pigz 、 bzip2 、 pybzip2 、 snappy および custom 。

バージョン 3.16 で非推奨: pygzip および pybzip2 圧縮オプションは非推奨であり、将来のリリースでは削除される予定です。代わりに、同等の gzip および bzip2 を使用してください。

バージョン 3.17 で非推奨: custom 圧縮オプションと関連する構成オプション custom_compression_filter 、 custom_decompression_filter 、および custom_compression_magic は非推奨であり、将来のリリースでは削除されます。代わりに、ビルトイン圧縮アルゴリズムのいずれかを使用します。

注釈

これらのオプションはすべて、圧縮が発生する場所にモジュールをインストールする必要があります。

custom オプションはカスタム圧縮用であり、次のオプションも設定する必要があります。

• custom_compression_filter 圧縮フィルター。

• custom_decompression_filter 解凍フィルタ

• custom_compression_magic カスタム圧縮walファイルを識別する16進文字列。

スコープグローバル/サーバー/モデル。

バージョン 3.17 で非推奨: この構成オプションは非推奨であり、将来のリリースでは削除される予定です。

custom_compression_filter

WALファイルのカスタム圧縮アルゴリズムを指定します。これはbashコマンドを作成するために内部で使用される string である必要があり、次の文字列 > /"$2/" < /"$1/"; の先頭にあります。標準出力に書き込み、入力ファイルは削除しません。

Tip

custom_compression_filter = /"xz -c/"

これは、 xz -c > /"$2/" < /"$1/"; を実行するのと同じです。

スコープグローバル/サーバー/モデル。

バージョン 3.17 で非推奨: この構成オプションは非推奨であり、将来のリリースでは削除される予定です。

custom_compression_magic

カスタムマジック値を定義して、WALファイルで使用されるカスタム圧縮アルゴリズムを識別します。これが設定されている場合、 Barmanは、指定されたアルゴリズムで既に圧縮されたWALにカスタム圧縮を適用することを回避します。構成されていない場合、 Barmanは事前圧縮されたものを含むすべてのWALファイルにカスタム圧縮を適用します。

Tip

たとえば、 xz 圧縮アルゴリズムでは、マジックナンバーを使用して .xz ファイルのフォーマットを検出します。

xzファイルの場合、マジックナンバーは次のバイトシーケンスです。

マジックナンバー FD 37 7A 58 5A 00

16進数表現では、これは次のように表すことができます。

16進数文字列 fd377a585a00

Barmanは custom_compression_magic の値の先頭に 0x が付けられることを想定しているため、次のようにその構成オプションを設定する必要があります。

custom_compression_magic = 0xfd377a585a00

参照 xz-file-format

スコープグローバル/サーバー/モデル。

バージョン 3.17 で非推奨: この構成オプションは非推奨であり、将来のリリースでは削除される予定です。

custom_decompression_filter

圧縮WALファイルのカスタム解凍アルゴリズムを指定します。これはbashコマンドを作成するために内部で使用される string である必要があり、次の文字列 > /"$2/" < /"$1/"; の先頭にあります。使用される圧縮アルゴリズムに対応する必要があります。

Tip

custom_compression_filter = /"xz -c -d/"

これは、 xz -c -d > /"$2/" < /"$1/"; を実行するのと同じです。

スコープグローバル/サーバー/モデル。

compression_level

選択した圧縮アルゴリズムで使用される圧縮レベルを指定します。有効な値は、選択したアルゴリズムまたは事前定義されたラベルのいずれかショートカットとして機能する low 、 medium 、および high のサポートされている範囲内の整数です。

• low 低レベルの圧縮を使用し、圧縮率よりも圧縮速度を優先します。

• medium 中レベルの圧縮を使用し、圧縮速度と圧縮率のバランスをとります。

• high 高レベルの圧縮を使用し、圧縮速度よりも圧縮率を優先します。

事前定義されたラベルは、以下に詳細を示すように、アルゴリズム固有のレベルにマッピングされます。

圧縮レベル

アルゴリズム	レベルレンジ	低い	中	ハイ
lz4	0〜16	0	6	10
xz	1〜9	1	3	5
zstd	-22〜22	1	4	9
gzip 、 pygzip および pigz	1〜9	1	6	9
bzip2 および pybzip2	1〜9	1	5	9

指定された圧縮レベルがアルゴリズムの最大レベルより大きい場合、その最大レベルが使用されます。同様に、最小レベルよりも低い場合、その最小レベルが使用されます。デフォルト値は medium です。

スコープグローバル/サーバー/モデル。

incoming_wals_directory

着信WALファイルをアーカイブするディレクトリを指定します。 archiver を有効にする必要があります。デフォルト <backup_directory>/incoming 。

スコープサーバー。

last_wal_maximum_age

最新のアーカイブされたWALファイルが該当する時間フレームを定義します。最新のWALファイルがこの期間よりも古い場合、barman checkコマンドはエラーを報告します。空のままの場合デフォルト、WALファイルの古さはチェックされません。フォーマットは last_backup_maximum_age と同じです。

スコープグローバル/サーバー/モデル。

max_incoming_wals_queue

barman checkコマンドがエラーを返す前に、着信キューストリーミングプールとアーカイブプールの両方を含むWALファイルの最大数を定義します。デフォルトは None 無効です。

スコープグローバル/サーバー/モデル。

streaming_wals_directory

ストリーミングWALファイルのためのディレクトリ。デフォルトの <backup_directory>/streaming 。

注釈

このオプションは、 streaming_archiver がアクティブな場合に適用されます。

スコープサーバー。

wal_conninfo

wal_conninfo 接続文字列は、 BarmanがWALを受信するレプリケーションスロットのステータスを監視するために使用されます。指定すると、これらのチェックでは wal_streaming_conninfo より優先されます。 wal_conninfo が設定されていないが、 wal_streaming_conninfo が設定されている場合、 wal_conninfo は wal_streaming_conninfo にフォールバックします。 wal_conninfo も wal_streaming_conninfo も設定されていない場合、 wal_conninfo は conninfo にフォールバックします。どちらの接続文字列も、 streaming_conninfo および conninfo で定義されたものと同じクラスター内のPostgresインスタンスにアクセスする必要があります。 wal_conninfo と wal_streaming_conninfo の両方が設定されている場合、 wal_conninfo のみが設定を読み取り、レプリケーションスロットのステータスを確認するために適切な権限を必要とします。ただし、 wal_streaming_conninfo のみが設定されている場合、これらのタスクを実行するには必要な権限が必要です。必要な権限には、 pg_monitor 、 pg_read_all_settings と pg_read_all_stats の両方、またはスーパーユーザー権限などのロールが含まれます。

スコープサーバー/モデル。

wal_streaming_conninfo

この接続文字列は、 BarmanがPostgresサーバーに接続するために使用され、ストリーミングレプリケーションを介してWALセグメントを受信し、 wal_conninfo が設定されていない場合にレプリケーションスロットのステータスを確認します。指定しない場合、 Barmanはこれらのタスクにデフォルトで streaming_conninfo を使用します。 wal_streaming_conninfo は、 streaming_conninfo で定義されたのと同じクラスター内のPostgresインスタンスに接続する必要があり、ストリーミングレプリケーションをサポートする必要があります。 wal_streaming_conninfo と wal_conninfo の両方が設定されている場合、 wal_conninfo のみが設定を読み取り、レプリケーションスロットのステータスを確認するために必要な権限を必要とします。 wal_streaming_conninfo のみを指定する場合、これらの権限が必要です。必要な権限には、 pg_monitor 、 pg_read_all_settings と pg_read_all_stats の両方、またはスーパーユーザー権限などのロールが含まれます。

スコープサーバー/モデル。

wals_directory

WALファイルを含むディレクトリ。デフォルトの <backup_directory>/wals 。

スコープサーバー。

xlogdb_directory

SERVER-xlog.db ファイルのカスタムディレクトリ。 SERVER はサーバー名です。このファイルには、アーカイブされたWALファイルのメタデータが保存され、 Barmanによって内部的に使用されます。設定されていない場合、デフォルトの wals_directory の値が使用されます。

スコープ グローバル/サーバー。

リストア

これらの構成オプションは、 Barmanが復元バックアップを管理する方法に関連しています。

local_staging_path

リカバリ中にブロックレベルのインクリメンタルバックアップを結合するためのローカルパスを指定します。この場所には、新しい合成バックアップを一時的に保存するための十分な領域が必要です。ブロックレベルのインクリメンタルバックアップからのリカバリーに必要です。

注釈

backup_method = postgres の場合にのみ適用されます。

バージョン 3.15 で非推奨: local_staging_path は非推奨であり、将来のリリースで削除される予定です。代わりに staging_path および staging_location を使用してください。

スコープグローバル/サーバー/モデル。

recovery_options

リカバリ操作のオプション。現在、 get-wal および delta-restore のみがサポートされています。 get-wal は、 リカバリ構成での基本的な restore_command の作成を有効にします。これは、 barman get-wal コマンドを使用してBarmanのWALアーカイブからWALファイルを直接取得します。 delta-restore を使用すると、barmanは既存のカスタムテーブルスペースとともに、既存の宛先ディレクトリにバックアップを上書きして復元できます。この設定は、コンマ区切りの値のリストを受け入れ、デフォルトで空です。

スコープグローバル/サーバー/モデル。

recovery_staging_path

圧縮バックアップからファイルをステージングするための復旧ホスト上のパスを指定します。この場所には、圧縮バックアップを一時的に保存するための十分な領域が必要です。

注釈

圧縮バックアップにのみ適用されます。

バージョン 3.15 で非推奨: recovery_staging_path は非推奨であり、将来のリリースで削除される予定です。代わりに staging_path および staging_location を使用してください。

スコープグローバル/サーバー/モデル。

staging_path

リストア中に中間ファイルがステージングされるパス。圧縮されたバックアップを復元する場合、最終的な宛先にコピーする前に、解凍の一時的な場所として機能します。インクリメンタル バックアップを復元する場合、最終的な宛先にコピーする前にバックアップが結合されます。この場所には、解凍/結合されたバックアップを保存するための十分な領域が必要です。デフォルトは /tmp です。

スコープグローバル/サーバー/モデル。

staging_location

staging_path がローカルパスかリモートパスであるかを指定します。有効な値は local および remote です。デフォルトは local です。

スコープグローバル/サーバー/モデル。

combine_mode

リストア中にインクリメンタル バックアップを組み合わせる場合、 pg_combinebackup のコピーモードを指定します。

オプションには次のものが含まれます

• copy デフォルト インクリメンタル バックアップを組み合わせる場合、標準のファイルコピーを使用します。

• link インクリメンタル バックアップを組み合わせる場合、ハードリンクを使用します。合成バックアップの再構成はより速くなりファイルコピーなし、使用するディスク領域は少なくなります。

• clone 新しいデータディレクトリにファイルをコピーする代わりに、効率的なファイルクローン作成一部のシステムでは「reflink」としても知られますを使用します。これにより、データファイルのほぼ瞬時のコピーが行われます。

• copy-file-range copy_file_range システムコールを使用して、効率的なコピーを行います。一部のファイルシステムでは、これにより clone と同様の結果が得られ、物理ディスクブロックを共有しますが、他のファイルシステムでは、ブロックをコピーする場合がありますが、最適化されたパスを介して実行します。

各モードの詳細と制限については、 pg_combinebackup documentation を参照してください。

スコープグローバル/サーバー/モデル。

リテンション ポリシー

これらの構成オプションは、 Barmanがバックアップの保持ポリシーを管理する方法に関連しています。

last_backup_maximum_age

最新のバックアップが含まれる時間フレームを定義します。最新のバックアップがこの期間よりも古い場合、barman checkコマンドはエラーを報告します。空のままの場合デフォルト、最新のバックアップは常に有効であるとみなされます。受け入れられる形式は /"n {DAYS|WEEKS|MONTHS|HOURS}/" で、 n は0より大きい整数です。

スコープグローバル/サーバー/モデル。

last_backup_minimum_size

最近成功したバックアップの最小許容サイズを指定します。最新のバックアップがこのサイズより小さい場合、barman checkコマンドはエラーを報告します。空のままの場合デフォルト、最新のバックアップは常に有効であるとみなされます。受け入れられるフォーマットは /"n {k|Ki|M|Mi|G|Gi|T|Ti}/" で、大文字と小文字が区別されます。ここで、 n は、ゼロより大きい整数で、オプションのSIまたはIECサフィックスが付きます。 kはk = 1000のキロを表し、KiはキロバイトKi = 1024を表します。残りのオプションは、より大きな測定単位についても同じ理由があります。

スコープグローバル/サーバー/モデル。

retention_policy

バックアップとWALファイルを保持する期間を定義します。このオプションを空白のままにした場合、保持ポリシーは適用されません。オプションには、冗長性とリカバリウィンドウポリシーが含まれます。

retention_policy = {REDUNDANCY value | RECOVERY WINDOW OF value {DAYS | WEEKS | MONTHS}}

• retention_policy = REDUNDANCY 2 は、バックアップカタログに2つのバックアップのみを保持し、新しいバックアップが作成されると、古いバックアップを自動的に削除します。数値は正の整数である必要があります。

• retention_policy = RECOVERY WINDOW OF 2 DAYS は、過去2日間の任意の時点にリカバリするために必要なバックアップのみを保持し、古いバックアップは自動的に削除します。期間番号は正の整数である必要があり、次のオプションを適用できます。 DAYS 、 WEEKS 、 MONTHS 。

スコープグローバル/サーバー/モデル。

retention_policy_mode

保持ポリシーを適用するためのモード。現在は auto のみをサポートしています。

スコープグローバル/サーバー/モデル。

wal_retention_policy

WALファイルを保持するためのポリシー。現在、 main のみが使用できます。

スコープグローバル/サーバー/モデル。

構成モデル

構成モデルは、Postgresサーバーを特定の cluster 名前の下で編成することにより、Postgresサーバーの構成オーバーライドを管理および適用する体系的なアプローチを提供します。

目的

構成モデルの主な目的は、同じ cluster によってグループ化されたPostgresサーバーの構成設定の管理を簡素化することです。モデルを使用することにより、一般的な構成オーバーライドのセットを適用でき、業務効率が向上します。これらはクラスター環境で特に有益であり、フェールオーバーイベント中に利用できるさまざまな構成モデルを作成できます。

アプリケーション

モデルファイルで定義された構成は、モデルで指定された同じ cluster 名前を共有するPostgresサーバーに適用できます。したがって、そのモデルを利用するサーバーはこれらの設定を継承でき、すべてのサーバーにわたって一貫した適応可能な構成を促進します。

使用法

モデルオプションは、サーバーセクションと同じ方法で識別されるモデルセクション内でのみ定義できます。サーバーセクションとモデルセクションの識別子の間に競合がないことを確認することが重要です。

構成モデルを適用するには、 barman config-switch SERVER_NAME MODEL_NAME を実行します。このコマンドは、指定されたクラスター名に関連付けられている関連Barmanサーバーへのモデルのオーバーライドの適用を容易にします。

オーバーライドを削除する場合は、モデル構成ファイルの削除だけでは効果がないため、次のようにコマンドで --reset 引数を使用して削除できます。 barman config-switch SERVER_NAME --reset 。

注釈

config-switch コマンドは、モデル名が存在し、サーバーと同じ cluster に関連付けられている場合にのみ成功します。さらに、一度にアクティブなモデルは1つだけです。異なるモデルでコマンドを複数回実行した場合、最後のモデルで定義されたオーバーライドのみが適用されます。

モデルからすべてのオプションを構成できるわけではありません。使用可能な構成の範囲を確認して、モデルに適用する設定を決定してください。

特典

• 一貫性 クラスター内の複数のBarmanサーバー全体で均一な構成を保証します。

• 効率 一元的な更新とオーバーライドを許可することにより、構成管理を簡素化します。

• 柔軟性 複数のモデルファイルを使用でき、必要に応じてさまざまなオーバーライドのセットを定義できる機能を提供します。

例

Barmanグローバル構成は、構成されているすべてのサーバーで共通です。したがって、特定の構成が必要な場合は、barmanグローバルスコープではなくサーバースコープに移動する必要があります。

次に、フィールドの説明とグローバル、サーバー、およびモデル構成のいくつかの例を示します。

グローバル構成

/etc/barman.conf

[barman]

barman_home = /var/lib/barman
barman_user = barman
configuration_files_directory = /etc/barman.d
log_file = /var/log/barman/barman.log
log_level = INFO

barman

• グローバルとなる構成を設定します。

• barman_home 、 configuration_files_directory 、 log_file 、 barman_user 、および log_level のロケーションを構成します。

サーバー構成-Rsync

/etc/barman.d/pg_server1_rsync.conf

[server1]

description =  "PostgreSQL server 1"
conninfo = host=pg1 user=barman port=5432 dbname=databasename
ssh_command = ssh postgres@pg1
backup_method = rsync
reuse_backup = link
archiver = on
parallel_jobs = 2
minimum_redundancy = 2
retention_policy = REDUNDANCY 4

server1

• conninfo を使用してBarmanからPostgresに接続します。

• ssh_command は、rsyncを使用する場合にBarmanサーバーからPostgresサーバーへのSSH接続を正しく作成するために必要です。

• backup_method を rsync および reuse_backup として設定して、ファイルレベルのインクリメンタル バックアップを有効にします。

• Postgres構成ファイル postgresql.conf で構成された archive_command を使用してWALを出荷するように archiver オプションを構成します。

• ジョブは並列処理に2つのワーカーを使用します。

• このサーバーから作成されるバックアップの minimum_redundancy および retention_policy を設定します。

サーバー構成 - pg_basebackup

/etc/barman.d/pg_server2_streaming.conf

[server2]

description =  "PostgreSQL server 2"
conninfo = host=pg2 user=barman port=5432 dbname=databasename
streaming_conninfo = host=pg2 user=streaming_barman port=5432 dbname=databasename
backup_method = postgres
streaming_archiver = on
slot_name = barman
create_slot = auto
minimum_redundancy = 5
retention_policy = RECOVERY WINDOW OF 7 DAYS
staging_path = /var/lib/barman/staging
staging_location = local
cluster = streaming

server2

• conninfo を使用してPostgresに接続します。これは、バックアップrsync、およびレプリケーションスロットのステータスを確認するために使用されます。

• streaming_conninfo を使用してPostgresに接続します。これは、バックアップpostgresに使用され、WALセグメントをストリーミングするための pg_receivewal プロセスを作成するために使用されます。

• backup_method を postgres として設定します。

• ストリーミングレプリケーション、Postgresサーバーで作成される slot_name 、および create_slot として auto を使用してWALを出荷するように streaming_archiver オプションを構成して、 Barmanがレプリケーションスロットが存在しない場合に自動的に作成を試行できます。

• このサーバーから作成されるバックアップの minimum_redundancy および retention_policy を設定します。

• ブロックレベルのインクリメンタルバックアップのリカバリーは、バックアップのチェーンを結合するための中間場所として staging_path を使用します。 staging_location が local に設定されているため、このパスはローカルパスBarmanと同じサーバーとみなされます。

• このサーバーをモデルが使用する streaming クラスターにグループ化します。

モデル構成1

/etc/barman.d/mdl_streaming_switchover.conf

[server2:switch_over_streaming_conn_to_pg3]

cluster = streaming
model = true
wal_conninfo = host=pg3 user=barman port=5432 dbname=databasename
wal_streaming_conninfo = host=pg3 user=streaming_barman port=5432 dbname=databasename
compression = gzip
backup_compression = gzip
staging_path = /var/lib/barman/recovery_staging
staging_location = local
retention_policy = RECOVERY WINDOW OF 14 DAYS

server2:switch_over_wal_streaming_conn_to_pg3

• このモデルを streaming という名前のクラスターにタグ付けして、構成をオーバーライドします。

• これをモデル model = true として構成します。

• wal_conninfo が設定されているため、この接続は特にWALストリーミングステータスを監視し、チェックを実行するために使用されます。

• wal_streaming_conninfo が設定されている場合、 Barmanはストリーミングレプリケーションプロトコルを介してWALセグメントを受信するときに streaming_conninfo の代わりにこれを使用します。 wal_conninfo が設定されていない場合、このオプションはWALストリーミングレプリケーションステータスの監視と確認にも使用され、適切な権限を持つユーザーを使用する必要があります。

• WALファイルは gzip で圧縮されます。

• すべてのバックアップは gzip で圧縮されます。

• 圧縮バックアップのリカバリーは、バックアップを解凍するための中間場所として staging_path を使用します。 staging_location が local に設定されているため、このパスはローカルパスBarmanと同じサーバーとみなされます。

• streaming クラスターでグループ化されたバックアップの retention_policy を設定します。

この例では、ストリーミング接続をpg3に切り替え、バックアップとWALファイルの圧縮を有効にし、retention_policyを変更するモデルをセットアップしました。 This is a way to stream WALs and backups from different hosts.

最終的な構成には次の設定があります。

[server2]

description =  "PostgreSQL server 2"
conninfo = host=pg2 user=barman port=5432 dbname=databasename
streaming_conninfo = host=pg2 user=streaming_barman port=5432 dbname=databasename
backup_method = postgres
streaming_archiver = on
slot_name = barman
create_slot = auto
minimum_redundancy = 5
retention_policy = RECOVERY WINDOW OF 14 DAYS
staging_path = /var/lib/barman/staging
staging_location = local
wal_conninfo = host=pg3 user=barman port=5433 dbname=databasename
wal_streaming_conninfo = host=pg3 user=streaming_barman port=5433 dbname=databasename
compression = gzip
backup_compression = gzip
staging_path = /var/lib/barman/recovery_staging
staging_location = local

モデル構成2

/etc/barman.d/mdl_streaming_failover

[server2:failover_conn_to_pg3]

cluster = streaming
model = true
conninfo = host=pg3 user=barman port=5433 dbname=databasename
streaming_conninfo = host=pg3 user=streaming_barman port=5433 dbname=databasename

server2:failover_conn_to_pg3

• このモデルを streaming という名前のクラスターにタグ付けして、構成をオーバーライドします。

• これをモデル model = true として構成します。

• conninfo が設定されているため、 Postgres接続をホスト pg3 に切り替えるために使用されます。

• streaming_conninfo が設定されているため、 Postgresストリーミング接続をホスト pg3 に切り替えるために使用されます。

この例では、pg2からpg3へのフェイルオーバー時にPostgres接続とストリーミング接続を切り替えるモデルをセットアップしました。

最終的な構成には次の設定があります。

[server2]

description =  "PostgreSQL server 2"
conninfo = host=pg3 user=barman port=5432 dbname=databasename
streaming_conninfo = host=pg3 user=streaming_barman port=5432 dbname=databasename
backup_method = postgres
streaming_archiver = on
slot_name = barman
create_slot = auto
minimum_redundancy = 5
retention_policy = RECOVERY WINDOW OF 7 DAYS
staging_path = /var/lib/barman/staging
staging_location = local

重要

構成ファイルのインプレース変更は表示されません。オーバーライドは内部的に適用され、コマンド barman show-servers SERVER_NAME を使用して設定の完全なリスト、または barman diagnose 出力を使用して、現在のサーバー構成を確認できます。