Barman#
インスタンスにconfig.ymlでbarman
ロールが付与されている場合、TPAは Barman サーバーとして構成して、backup
設定で名前を付けている他のインスタンスのバックアップを取得します。
instances:
- Name: one
backup: two
…
- Name: two
role:
- barman
…
複数のpostgres インスタンスは、backup
と同じ名前のBarmanサーバーを持つことができます。同様に、1つのpostgres
インスタンスは、そのbackup
として名前付けたBarmanサーバーのリストを持つことができ、バックアップはすべての名前付けサーバーに取得されます。
デフォルトのBarman構成は、 pg_receivewalを使用してPostgreSQLに接続し、WALの継続的なバックアップを取得し、週に2回sshでのrsyncを使用してインスタンスの完全なバックアップを取得します。完全なバックアップとWALは、過去4週間の任意のポイントにリカバリーできるように十分な期間保持されます。
Barmanパッケージバージョン#
デフォルトでは、TPAはBarmanの最新バージョンをインストールします。
config.yml ファイルのcluster_vars
セクションの下にbarman_package_version: xxx
を含めることにより、インストールされるBarmanパッケージのバージョンを指定できます。
cluster_vars:
…
barman_package_version: 1.56.2-1
…
aptまたはyumが受け入れるバージョン指定子を使用できます。
バージョンが一致しない場合は、 *
ワイルドカードを追加してみてください。これは、パッケージバージョンに2:...
のようなエポック修飾子がある場合に必要になることがよくあります。
WAL復元圧縮フラグ#
TPAは、インストールされたBarmanバージョンを自動的に検出し、restore_command
設定でbarman-wal-restore の正しい圧縮フラグを選択します。
Barman >= 3.12
--keep-compressionを使用します-zオプションはこのリリースでは非推奨でした。Barman < 3.12
-zを使用します
restore_command
の構成後にBarmanがインストールされるため、最初の展開では、検出ができない場合があります。この場合、TPAはデフォルトで--keep-compression
になります。これは、デフォルトでインストールされる最新のBarmanバージョンと一致します。古いBarmanバージョンを展開する場合は、
barman_package_version
を明示的に設定して、正しいフラグが選択されていることを確認します。
Barman構成#
BarmanサーバーのBarmanホームディレクトリは、クラスター変数barman_home
を使用して設定できます。デフォルト値は/var/lib/barman です。
各Barmanサーバーでは、グローバル構成ファイルが/etc/barman.conf
として作成されます。このファイルには、多くのBarman構成変数のデフォルト値が含まれています。バックアップされるPostgresサーバーごとに、追加のBarman構成ファイルが作成されます。たとえば、サーバーone
をバックアップするには、ファイルは/etc/barman.d/one.conf
で、バックアップはBarmanホームディレクトリのサブディレクトリone
に保存されます。構成ファイルとディレクトリ名は、プロビジョニングステップの前にvars
セクションで定義されたバックアップインスタンスのbackup_name
設定から変更できます。
- Name: myPrimary
backup: myBarman
platform: bare
ip_address: x.x.x.x
node: 1
role:
- primary
vars:
backup_name: my_backup
次の変数はバックアップインスタンスで設定でき、接頭辞barman_
が削除された状態でBarmanの構成に渡されます。
variable |
default |
|---|---|
barman_archiver |
false |
barman_log_file |
/var/log/barman.log |
barman_backup_method |
rsync |
barman_compression |
pigz |
barman_reuse_backup |
link |
barman_parallel_jobs |
1 |
barman_backup_options |
concurrent_backup |
barman_immediate_checkpoint |
false |
barman_network_compression |
false |
barman_basebackup_retry_times |
3 |
barman_basebackup_retry_sleep |
30 |
barman_minimum_redundancy |
3 |
barman_retention_policy |
RECOVERY WINDOW OF 4 WEEKS |
barman_last_backup_maximum_age |
1 WEEK |
barman_pre_archive_retry_script |
|
barman_post_backup_retry_script |
|
barman_post_backup_script |
|
barman_streaming_wals_directory |
|
backup_name |
backed up instance's name |
バックアップ スケジュール#
TPAは、/etc/cron.d/barman
にcronジョブをインストールします。これは1分ごとに実行され、barman cron
を呼び出してメンテナンスタスクを実行します。
バックアップされるインスタンスごとに、そのインスタンスのバックアップを取得する別のcronジョブを/etc/cron.d/<backup_name>
にインストールします。このジョブは、インスタンスのbarman_backup_interval
変数で決定されたとおりに実行され、デフォルトでは、毎週水曜日と土曜日の04:00にバックアップを取得します。
SSHキー#
TPAは、 postgres およびbarman
ユーザーのsshキーペアを生成し、それぞれの~/.sshディレクトリにインストールし、お互いのauthorized_keysファイルに追加します。
postgresユーザーは、WALセグメント構成されている場合をアーカイブするためにbarmanサーバーにssh接続できる必要があり、barmanユーザーはPostgresインスタンスにssh接続して、バックアップを取得または復元できる必要があります。
barman およびbarman_role Postgresユーザー#
TPAは、2人のPostgresユーザーbarman およびbarman_role
を作成します。
TPAバージョン <23.35 は、 barman
Postgresユーザーをsuperuser として作成しました。
23.35 から barman ユーザーはNOSUPERUSER
で作成されるため、既存のクラスターに再展開すると、 barman
Postgresユーザーからsuperuser 属性が削除されます。代わりに、
barman_role には必要な特権セットが付与され、 barman
ユーザーにはbarman_role メンバーシップが付与されます。
これにより、
Barman Manual で提供される特権セットを使用して、 barman
ユーザーにsuperuser 属性を付与することを回避します。
共有Barmanサーバー#
注釈
23.35より前のTPAバージョンを使用して作成されたクラスターで共有Barman機能を使用するには、以下を行う必要があります。a) 共有Barmanインスタンスの作成をサポートするTPAのバージョンにアップグレードします。 b)TPAをアップグレードした後、$first-clusterでdeployを実行して、TPAが後続のクラスターが共有Barmanノードに対してスムーズに実行されるように必要な構成変更を加えられるように。
一部の展開では、複数のクラスターで単一のBarmanサーバーを共有する必要がある場合があります。
tpaexec内の共有Barmanサーバーの展開は、既存のBarmanサーバーを使用する予定がある特定のクラスター構成のBarmanサーバーインスタンスの下でvars:
を介して設定できるbarman_shared 設定を介してサポートされています。
barman_shared
はブール変数であるため、可能な値はtrueおよびfalseデフォルトです。共有シナリオでBarman構成を変更する場合、複数のクラスターにわたる構成が同期したままであることを確認して、1つのクラスターが特定の構成を追加し、2番目のクラスターがそれをオーバーライドするシナリオを回避する必要があります。
複数のクラスターで共有Barmanサーバーを使用するための一般的なワークフローを以下に説明します。
barmanロールを持つインスタンスを使用してTPAクラスターを作成しますこの例では、’first-cluster’と呼びます。2番目のクラスターsecond-cluster例では、この特定のBarmanインスタンスを共有Barmanサーバーインスタンスとして$clusters/first-clusterから参照し、プラットフォームとして
bareを使用するため、実行時に新しいBarmanインスタンスを作成しようとしません条項。また、このクラスターがアクセスするために使用できるBarmanインスタンスのIPアドレスを指定します。
- Name: myBarman
node: 5
role:
- barman
platform: bare
ip_address: x.x.x.x
vars:
barman_shared: true
2番目のクラスターがプロビジョニングされたら、展開を実行する前に、sshを介してBarmanサーバーインスタンスにアクセスできることを確認します。
ssh-copy-idを介して2番目のクラスターの公開キーをBarmanサーバーインスタンスにコピーすることにより、このアクセスを許可でき、sshを実行して、パスワードを指定せずにログインできることを確認します。
# add first-clusters key to the ssh-agent
cd $clusters/first-cluster
ssh-add id_first-clutser
cd $clusters/second-cluster
ssh-keyscan -t rsa,ecdsa -4 $barman-server-ip >> tpa_known_hosts
ssh-copy-id -i id_second-cluster.pub -o UserKnownHostsFile=tpa_known_hosts $user@$barman-server-ip
ssh -F ssh_config $barman-server
Barmanユーザーのキーを最初のクラスターから2番目のクラスターにコピーします
mkdir $clusters/second-cluster/keys
cp $clusters/first-cluster/keys/id_barman* clusters/second-cluster/keys
tpaexec deploy $clusters/second-clusterを実行します
Barmanサーバーインスタンスを共有するクラスターをセットアップするときは、注意する必要があります。このようなセットアップを試行する前に、考慮する必要がある重要な側面が多数あります。
Barmanサーバーを共有するクラスター内の2つのインスタンスが同じ名前を使用していないことを確認します。
tpaexec configureの--cluster-prefixed-hostnamesオプションは、この点で役立つ場合があります。Barmanの構成と設定は、共通のBarmanサーバーを使用するすべてのクラスターで同期したままにして、1つのクラスターが特定の構成をセットアップし、構成が欠落しているか別の値を使用しているために他のクラスターがセットアップしないシナリオを回避する必要があります。
異なるクラスターにわたってバックアップされるインスタンスのPostgresのバージョンは、同じである必要があります。
共通のBarmanサーバーを使用する異なるクラスターは、デフォルトをオーバーライドしようとするときにBarmanパッケージの異なるバージョンを指定できません。
共有Barmanサーバーのサポートの向上を続けているため、これらの一部は将来のリリースで対応される可能性があります。
警告
共通のBarmanノードを共有するクラスターのプロビジョニングを解除するときは、特に注意してください。特に、 Barmanを展開した最初のクラスターが非ベアプラットフォームを使用する場合。 Barmanノードは最初のクラスターによって既にプロビジョニング解除され、もう存在しないため、最初にBarmanをプロビジョニングおよび展開した最初のクラスターをプロビジョニング解除すると、 Barmanノードを共有する他のクラスターが事実上一貫性のない状態のままになります。
特定のパッケージバージョンにアップグレードしようとする場合は、
config.yml のbarman_package_version
が更新されて、目的のバージョンを反映していることを確認します。目的のバージョンを追加の引数としてtpaexec upgrade
コマンドに渡すこともできます。
- e barman_package_version="<desired version>"
package version selection and upgrade のセクションを参照してください
詳細については、
アップグレードのためにBarmanを選択するには、 tpaexec upgrade
コマンドに渡される--components フラグに barman またはall
が含まれていることを確認します
component selection for upgrade のセクションを参照してください
詳細については、