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サーバーを使用するための一般的なワークフローを以下に説明します。

  1. barman ロールを持つインスタンスを使用してTPAクラスターを作成しますこの例では、’first-cluster’と呼びます。

  2. 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
  1. 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
  1. Barmanユーザーのキーを最初のクラスターから2番目のクラスターにコピーします

mkdir $clusters/second-cluster/keys
cp $clusters/first-cluster/keys/id_barman* clusters/second-cluster/keys
  1. tpaexec deploy $clusters/second-cluster を実行します

Barmanサーバーインスタンスを共有するクラスターをセットアップするときは、注意する必要があります。このようなセットアップを試行する前に、考慮する必要がある重要な側面が多数あります。

  1. Barmanサーバーを共有するクラスター内の2つのインスタンスが同じ名前を使用していないことを確認します。 tpaexec configure の--cluster-prefixed-hostnames オプションは、この点で役立つ場合があります。

  2. Barmanの構成と設定は、共通のBarmanサーバーを使用するすべてのクラスターで同期したままにして、1つのクラスターが特定の構成をセットアップし、構成が欠落しているか別の値を使用しているために他のクラスターがセットアップしないシナリオを回避する必要があります。

  3. 異なるクラスターにわたってバックアップされるインスタンスのPostgresのバージョンは、同じである必要があります。

  4. 共通の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 のセクションを参照してください

詳細については、