Barman ====== インスタンスにconfig.ymlで\ ``barman`` ロールが付与されている場合、TPAは `Barman `_ サーバーとして構成して、\ ``backup`` 設定で名前を付けている他のインスタンスのバックアップを取得します。 .. code:: yaml 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パッケージのバージョンを指定できます。 .. code:: yaml 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`` 設定から変更できます。 .. code:: yaml - Name: myPrimary backup: myBarman platform: bare ip_address: x.x.x.x node: 1 role: - primary vars: backup_name: my_backup 次の変数はバックアップインスタンスで設定でき、接頭辞\ ``barman_`` が削除された状態でBarmanの構成に渡されます。 .. csv-table:: :header: variable,default :widths: 25,15 :align: left :class: longtable 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,"" barman_path_prefix,_backed up node's postgres bin dir_ backup_name,_backed up instance's name_ バックアップ スケジュール ------------------------- TPAは、\ ``/etc/cron.d/barman`` にcronジョブをインストールします。これは1分ごとに実行され、\ ``barman cron`` を呼び出してメンテナンスタスクを実行します。 バックアップされるインスタンスごとに、そのインスタンスのバックアップを取得する別のcronジョブを\ ``/etc/cron.d/`` にインストールします。このジョブは、インスタンスの\ ``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サーバー ------------------ .. Note:: 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アドレスを指定します。 .. code:: yaml - Name: myBarman node: 5 role: - barman platform: bare ip_address: x.x.x.x vars: barman_shared: true 3. 2番目のクラスターがプロビジョニングされたら、展開を実行する前に、sshを介してBarmanサーバーインスタンスにアクセスできることを確認します。 ``ssh-copy-id`` を介して2番目のクラスターの公開キーをBarmanサーバーインスタンスにコピーすることにより、このアクセスを許可でき、sshを実行して、パスワードを指定せずにログインできることを確認します。 .. code:: shell # 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 4. Barmanユーザーのキーを最初のクラスターから2番目のクラスターにコピーします .. code:: shell mkdir $clusters/second-cluster/keys cp $clusters/first-cluster/keys/id_barman* clusters/second-cluster/keys 5. ``tpaexec deploy $clusters/second-cluster`` を実行します .. Note Mixed-platform clusters:: 共有Barmanインスタンスを`platform: bare` として宣言することにより、クラスターを混合プラットフォームクラスターに変更した可能性があります。これには、この変更に対応するように`config.yml` の他の部分を調整する必要がある場合があります。具体的には、 `instance_defaults` セクションには、クラスター内のすべてのインスタンスに適用される設定のみを含める必要があります。たとえば、`instance_defaults` に、`platform: aws` でのみ有効な`type` などの設定が含まれている場合、その設定を`instance_defaults` からAWSプラットフォームを使用するインスタンスにのみ移動する必要があります。 .. :: ### さまざまなPostgreSQLバージョンでのノードのバックアップ 単一のBarmanサーバーは、自分自身とは異なるPostgreSQLメジャーバージョンを実行するPostgresインスタンスをバックアップできます。 ``/etc/barman.d/.conf`` のサーバーごとの構成ファイルは、バックアップされたノード自分自身の\ ``postgres_bin_dir`` から\ ``path_prefix`` を設定するため、 Barmanはバックアップする各ノードの正しいクライアントバイナリ ``pg_basebackup`` や\ ``pg_receivewal`` などを使用します。 ``/etc/barman.conf`` のグローバル\ ``path_prefix`` は、 Barmanホスト自分のbinディレクトリをポイントし続け、同じバージョンのシナリオのデフォルトとして機能します。 バックアップノードの\ ``postgres_version`` がBarmanホストの\ ``postgres_version`` と異なる場合、TPAは一致するPostgresクライアントパッケージをBarmanホストに自動的にインストールするため\ ``delegate_to`` を介して、サーバーごとの\ ``path_prefix`` は実際のバイナリに解決されます。 これが機能するには、 Barmanホストが追加のPostgreSQLバージョンのパッケージリポジトリにアクセスできる必要があります。 EDBエンタープライズリポジトリ ``edb_repositories: ["enterprise"]`` は、サポートされているすべてのメジャーバージョンをキャリーし、この要件を満たします。 TPAの\ ``sys/repositories`` ロールは、ホスト自分の\ ``postgres_version`` 以外のすべてのメジャーバージョンのPGDGエントリを無効にするため、PGDGのみの展開では、 Barmanホストで対応する\ ``pgdgNN`` リポジトリエントリを自分で有効にする必要があります。 特定のノードで解決されたパスをオーバーライドするには、そのノードの\ ``vars`` で\ ``barman_path_prefix`` を設定します上記の変数テーブルを参照してください。 エアギャップクラスター ^^^^^^^^^^^^^^^^^^^^^^ エアギャップクラスター\ ``use_local_repo_only: true`` では、 Barmanホストにクロスバージョンクライアントをインストールするには、一致するPostgresクライアントパッケージがBarmanクラスターの\ ``local-repo`` に既に存在する必要があります。 ``tpaexec download-packages`` は、クラスターごとに単一のPostgresメジャーのパッケージを取得するため、デフォルトでは、追加メジャークライアントパッケージはプリフェッチされません。 エアギャップ共有Barmanセットアップで追加のPostgresメジャーでノードをバックアップする予定がある場合は、追加バージョンを導入するクラスターを展開する前に、追加メジャークライアントパッケージをBarmanクラスターの\ ``local-repo`` にコピーします。 ディレクトリレイアウトについては :ref:`Managing clusters in a disconnected or air-gapped environment ` を、 ``local-repo`` にデータを入力する方法については :ref:`tpaexec download-packages ` を参照してください。 共有Barmanサーバーの特別な考慮事項 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Barmanサーバーインスタンスを共有するクラスターをセットアップするときは、注意する必要があります。このようなセットアップを試行する前に、考慮する必要がある重要な側面が多数あります。 1. Barmanサーバーを共有するクラスター内の2つのインスタンスが同じ名前を使用していないことを確認します。 ``tpaexec configure`` の\ ``--cluster-prefixed-hostnames`` オプションは、この点で役立つ場合があります。 2. Barmanの構成と設定は、共通のBarmanサーバーを使用するすべてのクラスターで同期したままにして、1つのクラスターが特定の構成をセットアップし、構成が欠落しているか別の値を使用しているために他のクラスターがセットアップしないシナリオを回避する必要があります。 3. 異なるクラスターにわたってバックアップされるインスタンスのPostgresのバージョンは、同じである必要があります。 4. 共通のBarmanサーバーを使用する異なるクラスターは、デフォルトをオーバーライドしようとするときにBarmanパッケージの異なるバージョンを指定できません。 共有Barmanサーバーのサポートの向上を続けているため、これらの一部は将来のリリースで対応される可能性があります。 .. Warning:: 共通のBarmanノードを共有するクラスターのプロビジョニングを解除するときは、特に注意してください。特に、 Barmanを展開した最初のクラスターが非ベアプラットフォームを使用する場合。 Barmanノードは最初のクラスターによって既にプロビジョニング解除され、もう存在しないため、最初にBarmanをプロビジョニングおよび展開した最初のクラスターをプロビジョニング解除すると、 Barmanノードを共有する他のクラスターが事実上一貫性のない状態のままになります。 .. :: ## `tpaexec upgrade` を使用したマイナー更新 特定のパッケージバージョンにアップグレードしようとする場合は、 ``config.yml`` の\ ``barman_package_version`` が更新されて、目的のバージョンを反映していることを確認します。目的のバージョンを追加の引数として\ ``tpaexec upgrade`` コマンドに渡すこともできます。 .. code:: shell - e barman_package_version="" :ref:`package version selection and upgrade ` のセクションを参照してください 詳細については、 アップグレードのためにBarmanを選択するには、 ``tpaexec upgrade`` コマンドに渡される\ ``--components`` フラグに ``barman`` または\ ``all`` が含まれていることを確認します :ref:`component selection for upgrade ` のセクションを参照してください 詳細については、