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:... のようなエポック修飾子がある場合に必要になることがよくあります。

Barman構成#

BarmanサーバーのBarmanホームディレクトリは、クラスター変数barman_home を使用して設定できます。デフォルト値は/var/lib/barman です。

各Barmanサーバーでは、グローバル構成ファイルが/etc/barman.conf として作成されます。このファイルには、多くのBarman構成変数のデフォルト値が含まれています。バックアップされるPostgresサーバーごとに、追加のBarman構成ファイルが作成されます。たとえば、サーバーone をバックアップするには、ファイルは/etc/barman.d/one.conf で、バックアップはBarmanホームディレクトリのサブディレクトリone に保存されます。構成ファイルとディレクトリ名は、バックアップされたインスタンスのbackup_name 設定から取得されます。この設定のデフォルトはインスタンス名です。

次の変数はバックアップインスタンスで設定でき、接頭辞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

バックアップスケジュール#

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インスタンスをplatform: bare として宣言することにより、クラスターを混合プラットフォームクラスターに変更した可能性があります。これには、この変更に対応するようにconfig.yml の他の部分を調整する必要がある場合があります。具体的には、 instance_defaults``セクションには、クラスター内のすべてのインスタンスに適用される設定のみを含める必要があります。たとえば、\ ``instance_defaults に、platform: aws でのみ有効なtype などの設定が含まれている場合、その設定をinstance_defaults からAWSプラットフォームを使用するインスタンスにのみ移動する必要があります。

### 共有Barmanサーバーの特別な考慮事項

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

Barmanサーバーを共有するクラスター内の2つのインスタンスが同じ名前を使用していないことを確認します。 tpaexec configure の--cluster-prefixed-hostnames オプションは、この点で役立つ場合があります。
Barmanの構成と設定は、共通のBarmanサーバーを使用するすべてのクラスターで同期したままにして、1つのクラスターが特定の構成をセットアップし、構成が欠落しているか別の値を使用しているために他のクラスターがセットアップしないシナリオを回避する必要があります。
異なるクラスターにわたってバックアップされるインスタンスのPostgresのバージョンは、同じである必要があります。
共通のBarmanサーバーを使用する異なるクラスターは、デフォルトをオーバーライドしようとするときにBarmanパッケージの異なるバージョンを指定できません。

共有Barmanサーバーのサポートの向上を続けているため、これらの一部は将来のリリースで対応される可能性があります。

!!!警告

共通のBarmanノードを共有するクラスターのプロビジョニングを解除するときは、特に注意してください。特に、 Barmanを展開した最初のクラスターが非ベアプラットフォームを使用する場合。 Barmanは最初のクラスターによって既にプロビジョニング解除され、もう存在しないため、最初にBarmanをプロビジョニングおよび展開した最初のクラスターをプロビジョニング解除すると、 Barmanノードを共有する他のクラスターが事実上一貫性のない状態のままになります。 !!!

Barman

目次