機能の詳細 ========== このセクションでは、いくつかのBarman機能を紹介し、それらの適用性とそれらを使用するために必要な構成について説明します。 Barman構成で作業する多くのシナリオを作成できるため、このリストは包括的なものではありません。それにもかかわらず、一般的なパターンについて議論することは役立ちます。 バックアップ機能 ---------------- インクリメンタル バックアップ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ インクリメンタル バックアップは、既存のバックアップを参照として使用して、PostgreSQLサーバーから必要なデータの変更のみをコピーするバックアップの種類です。 \_WAL継続的アーカイブ_によって実装される差分バックアップと混同しないでください。 Barmanでのインクリメンタルバックアップの主な目的は次のとおりです。 - フルバックアップ処理にかかる時間の削減 - いくつかの定期的なバックアップが占有するディスク領域を削減します **データ重複排除** Barmanは現在、 **ファイルレベルのインクリメンタルバックアップ** ``rsync`` を使用および **ブロックレベルのインクリメンタルバックアップ** ``pg_basebackup`` を使用をサポートしています。 .. NOTE :: さまざまなバックアップタイプのインクリメンタルバックアップは、現在互換性がありません。つまり、ブロックレベルのインクリメンタルバックアップは`rsync` バックアップで取得できず、ファイルレベルのインクリメンタルバックアップはストリーミングバックアップ`pg_basebackup` で取得できません。 ファイルレベルのインクリメンタル バックアップ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ この機能は\ ``rsync`` および[hardlink][8]に大きく依存しているため、基になるオペレーティングシステムとバックアップデータが存在するファイルシステムの両方でサポートされている必要があります。 主な概念は、後続のベースバックアップが、前回のバックアップから変更されていないファイルを共有し、ディスク使用量の関連する節約につながるということです。これは、VLDBコンテキストと、高い割合の_読み取り専用の履歴テーブル_を含むデータベースに特に当てはまります。 Rsyncインクリメンタルバックアップは、 ``barman backup`` コマンドを透過的に管理する\ ``reuse_backup`` と呼ばれるグローバル/サーバーオプションを介して有効にできます。 3つの値を受け入れます。 - ``off`` 標準のフルバックアップデフォルト - ``link`` サーバーの最後のバックアップを再利用し、変更されていないファイルのハードリンクを作成することによるファイルレベルのインクリメンタル バックアップ バックアップ領域と時間の削減のため - ``copy`` サーバーの最後のバックアップを再利用し、変更されていないファイルのコピーを作成することによる、ファイルレベルのインクリメンタルバックアップバックアップ時間の短縮のためのみ 最も一般的なシナリオは、次のように\ ``reuse_backup`` を\ ``link`` に設定することです。 .. code:: ini reuse_backup = link これをグローバルレベルで設定すると、すべてのサーバーのインクリメンタル バックアップが自動的に有効になります。 最後の注意として、ユーザーは\ ``barman backup`` コマンドの\ ``--reuse-backup`` ランタイムオプションを介して\ ``reuse_backup`` オプションの設定をオーバーライドできます。同様に、実行時オプションは3つの値\ ``off`` 、\ ``link`` 、および\ ``copy`` を受け入れます。たとえば、次のとおりに1回限りのインクリメンタルバックアップを実行できます。 .. code:: bash barman backup --reuse-backup=link .. NOTE :: Postgresのブロックレベルのインクリメンタルバックアップとは異なり、Rsyncファイルレベルのインクリメンタルバックアップは自分自身で独立しています。つまり、重複排除に以前のバックアップを再利用したバックアップは、親バックアップが削除された場合にまったく侵害されません。前述のように、Rsyncバックアップの重複排除はハードリンクを使用して実装されるため、以前に再利用されたバックアップが削除されても、他のバックアップと共有されたファイルはディスクに残り、これらのファイルを使用した最後のバックアップも削除された場合にのみ削除されます。また、以前の完全バックアップが削除されたときに完全バックアップを取る必要がないことも意味します。各バックアップにはすべてのファイルが含まれ、心配せずに再利用できます。同様に、 `reuse_backup = off` を使用して、rsyncで完全なバックアップを取得する必要はありません。 `reuse_backup = link` で取得される最初のバックアップである場合、ハードリンクを作成する既存のファイルがないため、本質的に`off` のように動作します。 .. IMPORTANT :: `reuse_backup` オプションは、バックアップ方法として`rsync` または`local-rsync` とともに使用する必要があります。 ブロックレベルのインクリメンタル バックアップ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ バージョン3.11以降、 Barmanは、ネイティブ `incremental backup support introduced in PostgreSQL 17 `_ を活用したブロックレベルのインクリメンタルバックアップのサポートを導入しました。 ブロックレベルのインクリメンタルバックアップでは、重複排除はデータブロックレベルPostgreSQLのページで発生します。これは、最後のバックアップ以降に変更されたページのみを保存する必要があることを意味し、特に分散書き込みパターンを使用する大規模なデータベースの場合、より効率的なオプションになります。 PostgreSQLでは、この機能は `WAL Summarization `_ を使用して実装されるため、使用するにはデータベースサーバーで\ ``summarize_wal`` を有効にする必要があります。 バックアップコマンドの実行時に\ ``--incremental`` オプションを使用して、 Barmanでブロックレベルのインクリメンタルバックアップを実行できます。引数としてバックアップIDまたはバックアップIDショートカットを受け入れます。これは、重複排除の親として使用されるカタログ内の以前のバックアップ完全またはインクリメンタルを参照します。さらに、 ``last-full`` または\ ``latest-full`` を使用して、カタログ内の最新の適格なフルバックアップを参照することもできます。 .. code:: bash barman backup --incremental Barmanでブロックレベルのインクリメンタルバックアップを実行できるようにするには、次のことを行う必要があります。 - PostgreSQL 17以降。 - ``summarize_wal`` を有効にします。 - バックアップ方法として\ ``postgres`` を使用します。 .. NOTE:** Compressed backups are not **ye :: Barmanのブロックレベルのインクリメンタルバックアップの対象となります。 .. IMPORTANT :: ブロックレベルのインクリメンタル バックアップ間で`data_checksums` を有効にする場合、分岐したチェックラム構成はリカバリ中に問題が発生する可能性があるため、新しいフルバックアップを取ることをお勧めします。 帯域幅の使用を制限する ^^^^^^^^^^^^^^^^^^^^^^ ``bandwidth_limit`` オプショングローバル/サーバーごとを使用して、1秒あたりの最大キロバイト数を指定することにより、I/O帯域幅の使用を制限できます。デフォルトでは、制限なしを意味する0に設定されています。 .. IMPORTANT :: `bandwidth_limit` オプションは`postgres` バックアップ方法でサポートされていますが、 `tablespace_bandwidth_limit` オプションは`rsync` を使用する場合にのみ使用できます。 複数の表領域があり、1つ以上の表領域でバックアッププロシージャのI/Oワークロードを制限したい場合、 ``tablespace_bandwidth_limit`` オプショングローバル/サーバーごとを使用できます。 .. code:: ini tablespace_bandwidth_limit = tbname:bwlimit[, tbname:bwlimit, ...] このオプションは、テーブルスペース名と帯域幅制限キロバイト/秒で構成されるペアのコンマ区切りリストを受け入れます。 サーバーをバックアップするときに、 Barmanは上記のオプションで既存のテーブルスペースを見つけようとします。見つかった場合、指定された帯域幅制限が適用されます。それ以外の場合、そのサーバーのデフォルトの帯域幅制限が適用されます。 ネットワーク圧縮 ^^^^^^^^^^^^^^^^ 圧縮を使用して、転送されるデータのサイズを削減することが可能です。 ``network_compression`` オプショングローバル/サーバーごとを使用して有効にできます。 .. IMPORTANT :: `network_compression` オプションは、 `postgres` バックアップ方法では使用できません。 .. code:: ini network_compression = true|false このオプションを\ ``true`` に設定すると、ネットワーク転送中のデータ圧縮がバックアップとリカバリーの両方で有効になります。デフォルトでは、\ ``false`` に設定されます。 バックアップ圧縮 ^^^^^^^^^^^^^^^^ Barmanは、 pg_basebackupの圧縮機能を使用して、バックアッププロセス中にバックアップデータを圧縮できます。これは、 ``backup_compression`` 構成オプショングローバル/サーバーごとを使用して有効にできます。 .. IMPORTANT :: `backup_compression` およびこのセクションで説明するその他のオプションは、 `rsync` または`local-rsync` バックアップ方法では使用できません。 `postgres` バックアップ方法の場合のみ。 圧縮アルゴリズム ^^^^^^^^^^^^^^^^ このオプションを設定すると、 pg_basebackupは指定された圧縮アルゴリズムを使用してバックアップを圧縮します。現在、 Barmanでサポートされているアルゴリズムは\ ``gzip`` 、\ ``lz4`` 、\ ``zstd`` 、および\ ``none`` です。 ``none`` 圧縮アルゴリズムは、非圧縮のアーカイブを作成します。 .. code:: ini backup_compression = gzip|lz4|zstd|none Barmanでは、選択した圧縮アルゴリズムのCLIユーティリティをBarmanサーバーとPostgreSQLサーバーの両方で利用できる必要があります。 CLIユーティリティは、圧縮バックアップからバックアップラベルを抽出し、リカバリ中にPostgreSQLサーバーでバックアップを解凍するために使用されます。これらは、Debian、Ubuntu、RedHat、CentOS、およびSLESシステムに\ ``gzip`` 、\ ``lz4`` 、および\ ``zstd`` という名前のシステムパッケージを介してインストールできます。 .. Note :: Ubuntu 18.04bionicでは、 `liblz4-tool` パッケージで`lz4` ユーティリティを利用できます。 .. Note :: `zstd` バージョンは1.4.4以降である必要があります。 Debian 10 Buster、Ubuntu 18.04 bionic、およびSLES 12の`zstd` システムパッケージは、以前のバージョンをインストールします。 `backup_compression = zstd` はこれらのパッケージでは動作しません。 .. Note :: `lz4` および`zstd` は、PostgreSQLバージョン15以降でのみ使用できます。 .. IMPORTANT :: `backup_compression` を使用している場合、 `barman recover` が圧縮バックアップをリカバリできるように`recovery_staging_path` も設定する必要があります。 :ref:`圧縮バックアップのリカバリー <圧縮バックアップのリカバリー>` を参照してください。 詳細については、セクションをご覧ください。 圧縮ワーカー ^^^^^^^^^^^^ このオプションのパラメーターを使用すると、マルチプルのスレッドを使用して圧縮して、圧縮速度を向上させることができますデフォルトは0です。 .. code:: ini backup_compression_workers = 2 .. Note :: このオプションは、`zstd` 圧縮でのみ使用できます。 .. Note :: `zstd` バージョンは1.5.0以降である必要があります。またはマルチスレッドオプションでコンパイルされた1.4.4以上。 圧縮レベル ^^^^^^^^^^ 圧縮レベルは、 ``backup_compression_level`` オプションを使用して指定できます。これは、 ``backup_compression`` で指定された圧縮アルゴリズムでサポートされている整値に設定する必要があります。定義されていない場合、圧縮アルゴリズムのデフォルト値が使用されます。 ``none`` 圧縮は\ ``backup_compression_level=0`` のみをサポートしています。 .. Note :: `backup_compression_level` 使用可能な値とデフォルト値は、使用される圧縮アルゴリズムによって異なります。 詳細については、圧縮アルゴリズムのドキュメントを確認してください。 .. Note :: 15より前のPostgreSQLバージョンでは、 `gzip` は`backup_compression_level=0` をサポートしました。デフォルトの圧縮レベルを使用した結果 圧縮場所 ^^^^^^^^ PostgreSQLバージョン15以降でBarmanを使用する場合、サーバーで発生する圧縮つまりPostgreSQLがバックアップを圧縮するか、クライアントつまりpg_basebackupがバックアップを圧縮するように指定できます。これは、 ``backup_compression_location`` オプションを使用して実現できます。 .. IMPORTANT :: `backup_compression_location` オプションは、PostgreSQL 15以降で実行されている場合にのみ使用できます。 .. code:: ini backup_compression_location = server|client ``backup_compression_location = server`` を使用すると、圧縮作業をPostgreSQLサーバーに移動するというコストで、バックアップに必要なネットワーク帯域幅が削減されます。 ``backup_compression_location`` が\ ``server`` に設定されている場合、追加オプション\ ``backup_compression_format`` を\ ``plain`` に設定して、ディスクに書き込む前にpg_basebackupにデータを解凍させることができます。 圧縮形式 ^^^^^^^^ .. code:: ini backup_compression_format = plain|tar ``backup_compression_format`` が設定されていない場合、または値が\ ``tar`` である場合、バックアップは圧縮されたtarボールとしてディスクに書き込まれます。 ``plain`` および\ ``tar`` 形式の説明は、[pg_basebackup documentation][pg_basebackup-documentation]にあります。 .. IMPORTANT :: Barmanは外部ツールを使用して圧縮バックアップを管理します。 `backup_compression` および`backup_compression_format` によっては PostgresサーバーおよびBarmanサーバーに1つ以上のツールをインストールする必要がある場合があります。次の表は、構成に応じて選択するのに役立ちます。 .. csv-table:: :header: **backup_compression**,**backup_compression_format**,**Postgres server**,**Barman server** :widths: 15,12,12,20 :align: left :class: longtable gzip,plain,**tar** ,None gzip,tar,**tar** ,**tar** lz4,plain,"**tar, lz4** ",None lz4,tar,"**tar, lz4** ","**tar, lz4** " zstd,plain,"**tar, zstd** ",None zstd,tar,"**tar, zstd** ","**tar, zstd** " none,tar,**tar** ,**tar** 同時バックアップ ^^^^^^^^^^^^^^^^ 通常、バックアップ操作中に、 Barmanは_concurrentbackup_にPostgreSQLネイティブファンクション\ ``pg_start_backup`` および\ ``pg_stop_backup`` を使用します。[^ABOUT_CONCURRENT_BACKUP]これは、PostgreSQL 9.6以降のバックアップを取る推奨方法ですが、PostgreSQLではファンクションの名前が\ ``pg_backup_start`` および\ ``pg_backup_stop`` に変更されていることに注意してください15ベータ）。 [^ABOUT_CONCURRENT_BACKUP] コンカレントバックアップは、\_ストリーミングレプリケーションプロトコル_たとえば、\ ``pg_basebackup`` のようなツールを使用するテクノロジーです。 コンカレントバックアップでは、推奨されるバックアップアプローチであるだけでなく、 Barmanを使用した次のアーキテクチャシナリオも可能になります。\ ``rsync`` を使用した **スタンバイサーバーからのバックアップ** 。 デフォルトでは、\ ``backup_options`` は\ ``concurrent_backup`` に設定されます。バージョン15より前のPostgreSQLサーバーで排他的バックアップが必要な場合、ユーザーは\ ``backup_options`` を\ ``exclusive_backup`` に設定する必要があります。 ``backup_options`` が\ ``concurrent_backup`` に設定されている場合、 Barmanはサーバーの_コンカレントバックアップモード_をアクティブにし、次の2つの単純なルールに従います。 - ``ssh_command`` は、宛先のPostgresサーバーを指している必要があります - ``conninfo`` は、宛先のPostgresデータベース上のデータベースを指している必要があります。 .. IMPORTANT :: コンカレントバックアップの場合、現在Barmanは、フルバックアップの終了WALファイルが実際に出荷されたかどうかを判断できません。PostgreSQL自分自身がWALファイルが正しくアーカイブされていることを確認する排他的バックアップとは反対です。そのWALファイルがBarmanによって受信およびアーカイブされるまで、フルバックアップは一貫しているとは見なされないことに注意してください。 Barman 2.5では、 `WAITING_FOR_WALS` と呼ばれる新しい状態を導入しました。これは、 `check-backup` コマンド `cron` コマンドによって実行される通常のメンテナンスジョブの一部によって管理されます。 Barman 2.10から、 `barman backup` コマンドで`--wait` オプションを使用できます。 スタンバイの同時バックアップ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ スタンバイをバックアップする場合、次の[configuration options][config-options]はスタンバイサーバーを指す必要があります。 - ``conninfo`` - ``streaming_conninfo`` ``backup_method = postgres`` または\ ``streaming_archiver = on`` を使用する場合 - ``ssh_command`` ``backup_method = rsync`` を使用する場合 次の構成オプションは、プライマリサーバーを指す必要があります。 - ``primary_conninfo`` Barmanは\ ``primary_conninfo`` を使用してプライマリで新しいWALに切り替えるため、WALスイッチが自然に発生するのを待たずにスタンバイに対する同時バックアップを完了できます。 .. NOTE :: プライマリへの書き込みトラフィックがほとんどまたは全くないときにスタンバイをバックアップする場合、 `primary_conninfo` を設定することが特に重要です。 Barman 3.8.0現在、 ``primary_conninfo`` が設定されている場合、サーバーに\ ``primary_checkpoint_timeout`` オプションを追加できます。これは、新しいWALファイルが生成されるのを強制的に実行する前にBarmanが待機する最大時間秒です。プライマリのチェックポイント。 ``primary_checkpoint_timeout`` オプションは、プライマリサーバーで設定された\ ``archive_timeout`` オプションの値より大きい秒数に設定する必要があります。 ``primary_conninfo`` が設定されていない場合、バックアップは引き続き実行されますが、プライマリの現在のWALセグメントがバックアップに必要な最新のWALよりも新しくなるまで、停止バックアップステージで待機します。 Barmanでは、現在WALファイルとバックアップデータが同じPostgreSQLサーバーから取得することを必要としています。スタンバイがプライマリに昇格する場合、バックアップとWALは引き続き有効ですが、バックアップの取得とWALの受信に新しいスタンバイを使用するようにBarman構成を更新することができます。 WALは、WALストリーミングまたはWALアーカイブを使用してスタンバイから取得できます。 WALストリーミングを使用するには、 :ref:`WALストリーミング ` セクションの指示に従ってください。 スタンバイからWALアーカイブを使用するには、 :ref:`WAL archiving via archive_command <#wal-archiving-via-archive_command>` セクションの指示に従って、 *さらに* 、スタンバイサーバーのPostgreSQL構成で\ ``archive_mode = always`` を設定します。 .. NOTE :: PostgreSQL 10以前では、 Barmanは、スタンバイで同時に有効になっているWALストリーミングとWALアーカイブを処理できません。したがって、WALストリーミングを使用する場合はWALアーカイブを無効にする必要があります。その逆も可能です。これは、PostgreSQL 10以前のバージョンで生成されたWALが論理的に等価でもバイナリレベルで異なる可能性があり、 Barmanが2つのWALが同一であることの検出に失敗するためです。 即時チェックポイント ^^^^^^^^^^^^^^^^^^^^ バックアップを開始する前に、 Barmanはチェックポイントを要求します。これにより、追加のワークロードが生成されます。通常、そのチェックポイントは、PostgreSQLサーバーのワークロード制御の設定に従って調整されます。これは、バックアップが遅延する可能性があることを意味します。 このデフォルトの動作は、 ``immediate_checkpoint`` 構成グローバル/サーバーオプションデフォルトで\ ``false`` に設定を介して変更できます。 ``immediate_checkpoint`` が\ ``true`` に設定されている場合、PostgreSQLはワークロードを制限しようとせず、チェックポイントは最大速度で発生し、できるだけ早くバックアップを開始します。 次の2つのオプションのいずれかを指定して\ ``barman backup`` を発行することにより、いつでも構成オプションの動作をオーバーライドできます。 - ``--immediate-checkpoint`` 、即時チェックポイントを強制します。 - ``--no-immediate-checkpoint`` 、チェックポイントが発生するのを強制的に待機します。 ローカルバックアップ ^^^^^^^^^^^^^^^^^^^^ .. Warning :: BarmanとPostgreSQLは同じサーバー上にあり、同じ単一障害点の一部であるため、実稼働環境での使用はお勧めできません。一部のEnterpriseDB顧客は、特定の状況で、最も重要なことに、会社が提供する24時間365日の運用サービスの下で使用するために、 Barmanにローカルバックアップのサポートを追加することを要求しました。現在、この機能を使用するには、ソースからインストールするか、権限、ロギング、cron構成の点で`postgres` ユーザーの環境をカスタマイズする必要があります。 特別な状況では、 BarmanはPostgreSQLインスタンスが存在するのと同じサーバーにインストールでき、バックアップデータはPGDATAおよび該当する場合はテーブルスペースとは別のボリュームに保存されます。通常、これらのボリュームは、NFSのようなファイルシステムを備えたネットワークストレージアプライアンスにあります。 このアーキテクチャはEnterpriseDBによって承認されていません。 RPOとRTOの点でより良い結果を伴う、PostgreSQLのビジネス継続性エクスペリエンスを強化するために、EnterpriseDBは引き続き、レプリケーションと監視を目的とした監視ウィットネス サーバのように機能できるBarmanのリモートインストールを使用したシェアードナッシングアーキテクチャをお勧めします。 ローカルバックアップの唯一の要件は、 BarmanがPostgreSQLサーバーと同じユーザーで実行されることです。通常は\ ``postgres`` です。 CommunityパッケージはデフォルトでBarmanを\ ``barman`` ユーザーの下にインストールすることを考えると、このユースケースでは以下を含む手動インストール手順が必要です。 - cron構成 - logrotateを含むログ構成 Barmanで特定のサーバーのローカルバックアップを使用するには、 ``backup_method`` から\ ``local-rsync`` に設定する必要があります。この機能は本質的に同等の\ ``rsync`` と同じであり、代わりにSSHに依存し、リモートで動作します。 ``local-rsync`` では、ファイルシステムのコピーはローカルで\ ``rsync`` コマンドを発行して実行されますこのため、 BarmanはPostgreSQLと同じユーザーで実行する必要があります。 ``local-pg13`` という名前のサーバーのローカルバックアップの構成の抜粋は次のとおりです。 .. code:: ini [local-pg13] description = "Local PostgreSQL 13" backup_method = local-rsync ... アーカイブ機能 -------------- WAL圧縮 ^^^^^^^ 構成ファイルで\ ``compression`` オプションが設定されている場合、 ``barman cron`` コマンドはWALファイルを圧縮します。このオプションでは、5つの値を使用できます。 - ``bzip2`` Bzip2圧縮用 ``bzip2`` ユーティリティが必要 - ``gzip`` Gzip圧縮の場合 ``gzip`` ユーティリティが必要 - ``pybzip2`` Bzip2圧縮用 Pythonの内部圧縮モジュールを使用 - ``pygzip`` Gzip圧縮の場合Pythonの内部圧縮モジュールを使用します - ``pigz`` Pigz圧縮用 ``pigz`` ユーティリティが必要 - ``custom`` カスタム圧縮用。次のオプションも設定する必要があります。 - ``custom_compression_filter`` 圧縮フィルタ - ``custom_decompression_filter`` 解凍フィルタ - ``custom_compression_magic`` カスタム圧縮walファイルを識別する16進文字列 *注:* ``pybzip2`` および\ ``pygzip`` を除くすべてのメソッドでは、 ``barman archive-wal`` が新しいプロセスをフォークする必要があります。 同期WALストリーミング ^^^^^^^^^^^^^^^^^^^^^ Barmanは、同期スタンバイサーバーのようにトランザクションWALファイルを収集することにより、目標復旧ポイントをゼロにすることもできます。 このようなシナリオを構成するには、 Barmanサーバーは :ref:`PostgreSQLストリーミング接続 ` を介してWALをアーカイブするように構成し、 ``receive-wal`` プロセスはPostgreSQLサーバーの同期スタンバイとして存在する必要があります。 まず、 ``show-servers`` コマンドを使用してBarman ``receive-wal`` プロセスのアプリケーション名を取得する必要があります。 .. code:: bash barman@backup$ barman show-servers pg|grep streaming_archiver_name streaming_archiver_name: barman_receive_wal 次に、アプリケーション名を同期スタンバイとして\ ``postgresql.conf`` ファイルに追加する必要があります。 .. code:: ini synchronous_standby_names = barman_receive_wal .. IMPORTANT :: これは単なる構成例であり、 Barmanが同期スタンバイノードになる資格があることを示しています。 Barmanのみを使用することをお勧めするわけではありません。このトピックの詳細については、PostgreSQLドキュメントから_["Synchronous Replication"][synch]_を読むことができます。 構成をリロードするには、PostgreSQLサーバーを再起動する必要があります。 サーバーが正しく構成されている場合、 ``replication-status`` コマンドは、同期ストリーミングクライアントとして\ ``receive_wal`` プロセスを表示します。 .. code:: bash [root@backup ~]# barman replication-status pg Status of streaming clients for server pg: Current xlog location on master: 0/9000098 Number of streaming clients: 1 1. #1 Sync WAL streamer Application name: barman_receive_wal Sync stage : 3/3 Remote write Communication : TCP/IP IP Address : 139.59.135.32 / Port: 58262 / Host: - User name : streaming_barman Current state : streaming (sync) Replication slot: barman WAL sender PID : 2501 Started at : 2016-09-16 10:33:01.725883+00:00 Sent location : 0/9000098 (diff: 0 B) Write location : 0/9000098 (diff: 0 B) Flush location : 0/9000098 (diff: 0 B) カタログ管理機能 ---------------- 最小限の冗長性の安全性 ^^^^^^^^^^^^^^^^^^^^^^ ``minimum_redundancy`` と呼ばれるグローバル/サーバーごとの構成オプションを使用して、PostgreSQLサーバーの定期バックアップの最小数を定義できます。デフォルトでは0に設定されています。 この値を0より大きい数値に設定することにより、 Barmanは常にサーバーカタログに少なくともその数のバックアップがあることを保証します。 これにより、誤った\ ``barman delete`` 操作から保護されます。 .. IMPORTANT:: 保持ポリシー設定が最小冗長要件と衝突しないことを確認します。 Barmanのログで、このトピックに関するメッセージがないかを定期的に確認します。 リテンションポリシー ^^^^^^^^^^^^^^^^^^^^ Barmanは、バックアップの **リテンションポリシー** をサポートしています。 バックアップ保持ポリシーは、バックアップおよび関連アーカイブログ書き込み先行ログセグメントを、リカバリ手順のために保持する必要がある期間を決定するユーザー定義のポリシーです。 ユーザーの要求に基づいて、 Barmanは、現在の保持ポリシーを満たすために必要な定期バックアップと、これらのバックアップの完全なリカバリに必要なアーカイブWALファイルを保持します。 Barmanユーザーは、 **バックアップ冗長性** 定期バックアップの数または **リカバリウィンドウ** 長さの観点からリテンションポリシーを定義できます。 冗長性に基づいたリテンションポリシー 冗長性ベースのリテンションポリシーでは、ユーザーは保持する定期バックアップの数を決定します。冗長ベースのリテンションポリシーは、リカバリウィンドウを使用するリテンションポリシーと対比されます。 リカバリウィンドウに基づいたリテンションポリシー リカバリウィンドウは、 Barmanバックアップ保持ポリシーの1つであり、 DBAが期間を指定し、 Barmanがポイントインタイムリカバリーに必要なバックアップおよび/またはアーカイブされたWALファイルのリカバリウィンドウ中の任意の時点での保持を保証します。間隔は常に現在の時刻で終了し、ユーザーが指定した日数だけ過去に戻ります。たとえば、リテンションポリシーが7日間のリカバリウィンドウに設定されており、現在時刻が金曜日の午前9時30分である場合、 Barmanは1日の午前9時30分にポイントインタイムリカバリーを可能にするために必要なバックアップを保持します。前の金曜日。 .. IMPORTANT:: ブロックレベルのインクリメンタル バックアップは、保持ポリシー処理中に考慮されません。これは、この種のインクリメンタルバックアップが回復可能であるためには、チェーンを生成するフルバックアップまでのすべての親バックアップに依存するためです。バックアップチェーンの一貫性を維持するために、保持ポリシーを適用するときにフルバックアップのみが考慮されます。 > 仕組み> リテンションポリシーが適用されると、 Barmanはブロックレベルのインクリメンタルバックアップを無視し、フルバックアップのステータスにのみ焦点を当てます。 > フルバックアップがKEEP:FULL、KEEP:STANDALONE、またはVALIDとしてマークされている場合、ステータスVALIDはすべての依存ブロックレベルのインクリメンタルバックアップにマークされます。フルバックアップがOBSOLETEとしてマークされている場合、それに依存するすべてのブロックレベルのインクリメンタルバックアップもOBSOLETEとしてマークされ、削除されます。 スコープ ^^^^^^^^ リテンションポリシーは以下に対して定義できます。 - **PostgreSQLの定期的なベースバックアップ** ``retention_policy`` 構成オプションを介して - **アーカイブログ** 、ポイントインタイムリカバリー用 ``wal_retention_policy`` 構成オプションを介して .. IMPORTANT:: 時間ディメンションでは、アーカイブログは定期バックアップの時間ウィンドウに含まれる必要があります。 ここには、完全または部分的なポイントインタイムリカバリーという2つの一般的なユースケースがあります。 完全なポイント インタイム リカバリーシナリオ ベースバックアップとアーカイブログは同じ保持ポリシーを共有するため、最初に使用可能なバックアップから任意の時点で復旧できます。 部分的なポイント インタイム リカバリーシナリオ ベースバックアップの保持ポリシーはアーカイブログの保持ポリシーよりも広く、たとえば、ユーザーは過去6か月の完全な週次バックアップを保持できますが、過去4週間のアーカイブログ最後のものから開始する任意の時点でのリカバリを許可4つの定期的な毎週のバックアップ）。 .. IMPORTANT:: 現在、 Barmanは、 `wal_retention_policy` オプションを`main` にコンストレインすることにより、**完全なポイントインタイムリカバリー**シナリオのみを実装しています。 仕組み ^^^^^^ Barmanのリテンションポリシーは次のとおりです。 - **自動** ``barman cron`` によって適用 - **マニュアル** Barmanは、古いバックアップを単に報告し、削除できます。 .. IMPORTANT:: 現在、 Barmanは手動適用を実装していません。この機能は将来のバージョンで利用できるようになる予定です。 構成と構文 ^^^^^^^^^^ リテンションポリシーは、次の構成オプションを介して定義できます。 - ``retention_policy`` ベースバックアップ保持用 - ``wal_retention_policy`` アーカイブログ保持用 - ``retention_policy_mode`` ``auto`` にのみ設定できますリテンションポリシーは\ ``barman cron`` コマンドによって自動的に適用されます。 これらの構成オプションは、グローバルレベルとサーバーレベルの両方で定義できるため、ユーザーはマルチサーバー環境で最大限の柔軟性を実現します。 ``retention_policy`` の構文 ''''''''''''''''''''''''''' ``retention_policy`` を介したベースバックアップリテンションポリシーの一般的な構文は次のとおりです。 .. code:: ini retention_policy = {REDUNDANCY value | RECOVERY WINDOW OF value {DAYS | WEEKS | MONTHS}} そこで - 構文は大文字と小文字を区別します - ``value`` は整数であり、> 0です - **冗長リテンションポリシー** の場合 - ``value`` はサーバーの最小冗長レベル以上である必要がありますその値が割り当てられていない場合、警告が生成されます - 最初の有効なバックアップは値番目のバックアップです逆順の時系列で - **リカバリウィンドウポリシー** - の場合、復旧可能ポイントは次のとおりです。現在時間 - window - 最初の有効なバックアップは、復旧可能ポイントの前の最初に使用可能なバックアップです。逆順の時系列の値はサーバーの最小冗長レベル以上である必要がありますその値に割り当てられず、警告が生成された場合 デフォルトでは、 ``retention_policy`` は空です保持期間は適用されません。 ``wal_retention_policy`` の構文 ''''''''''''''''''''''''''''''' 現在、\ ``wal_retention_policy`` の唯一の許可値は特別な値\ ``main`` であり、アーカイブログの保持ポリシーをベースバックアップの保持ポリシーにマップします。 フックスクリプト ---------------- Barmanを使用すると、データベース管理者は次の2つのイベントでフックスクリプトを実行できます。 - バックアップの前後 - バックアップの削除の前後 - WALファイルがアーカイブされる前と後 - WALファイルが削除される前と後 Barmanが管理できるフックスクリプトには2種類があります。 - 標準フックスクリプト - リトライフックスクリプト これら2種類のフックスクリプトの唯一の違いは、 Barmanはリターンコードをチェックせずに標準フックスクリプトを1回だけ実行するのに対し、再試行フックスクリプトは、リターンコードによっては複数回実行される場合があることです。 具体的には、再試行フックスクリプトを実行するときに、 Barmanはリターンコードをチェックし、スクリプトが\ ``SUCCESS`` 標準のリターンコード\ ``0`` 、または\ ``ABORT_CONTINUE`` リターンコード\ ``62`` 、または\ ``ABORT_STOP`` リターンコード\ ``63`` のいずれかを返すまで、無期限に再試行します。 Barmanは、他の戻りコードを再試行の一時的な失敗として扱います。ユーザーにはより多くの権限が与えられます。フックスクリプトは、障害が一時的なものであるかどうかを指定することにより、ワークフローを制御できます。また、 ’pre’フックスクリプトの場合、\ ``ABORT_STOP`` を返すことにより、ユーザーはBarmanに失敗してメインオペレーションを中断するように要求できます。 フックスクリプトは次の順序で実行されます。 1. 標準の’pre’フックスクリプト存在する場合 2. retry ’pre’フックスクリプト存在する場合 3. 実際のイベントつまりバックアップオペレーションまたはWALアーカイブ、再試行’pre’フックスクリプトが\ ``ABORT_STOP`` で中止されなかった場合 4. 再試行 ’post’フックスクリプト存在する場合 5. 標準の’post’フックスクリプト存在する場合 フックスクリプトによって生成された出力は、 Barmanのログファイルに書き込まれます。 .. NOTE:: 現在、`ABORT_STOP` は、再試行'post'フックスクリプトによって無視されます。これらの場合、追加の警告をログに記録することとは別に、`ABORT_STOP` は`ABORT_CONTINUE` のように動作します。 バックアップスクリプト ^^^^^^^^^^^^^^^^^^^^^^ これらのスクリプトは、次のグローバル構成オプションサーバーごとにオーバーライドできます。 - ``pre_backup_script`` \_hook script_はベースバックアップの_before_実行されました。1回のみ、終了コードはチェックなし - ``pre_backup_retry_script`` \_retryフックスクリプト_ベースバックアップの_before_実行され、成功または中止されるまで繰り返し - ``post_backup_retry_script`` \_retryフックスクリプト_ベースバックアップの_after_実行され、成功または中止されるまで繰り返し - ``post_backup_script`` \_hook script_ベースバックアップの後に実行されました1回のみ、終了コードはチェックなし スクリプト定義はシェルに渡され、任意の終了コードを返すことができます。 \_retry_スクリプトの場合にのみ、 Barmanはリターンコードをチェックします :ref:`フックスクリプト <フックスクリプト>` を参照してください。 シェル環境には次の変数が含まれます。 - ``BARMAN_BACKUP_DIR`` バックアップ先ディレクトリ - ``BARMAN_BACKUP_ID`` バックアップのID - ``BARMAN_CONFIGURATION`` Barmanが使用する構成ファイル - ``BARMAN_ERROR`` エラーメッセージある場合 ``post`` フェーズのみ - ``BARMAN_PHASE`` スクリプトのフェーズ、\ ``pre`` または\ ``post`` のいずれか - ``BARMAN_PREVIOUS_ID`` 以前のバックアップのID存在する場合 - ``BARMAN_RETRY`` 再試行スクリプトの場合は\ ``1`` 、それ以外の場合は\ ``0`` - ``BARMAN_SERVER`` サーバーの名前 - ``BARMAN_STATUS`` バックアップのステータス - ``BARMAN_VERSION`` Barmanのバージョン バックアップ削除スクリプト ^^^^^^^^^^^^^^^^^^^^^^^^^^ バージョン **2.4** では、バックアップ前および後の削除スクリプトを導入しました。 以前のスクリプトと同様に、バックアップ削除スクリプトはグローバル構成オプション内で構成でき、サーバーごとにそれらをオーバーライドすることが可能です。 - ``pre_delete_script`` \_hook script_は、バックアップの削除の_before_に起動され、1回のみ、終了コードはチェックされません - ``pre_delete_retry_script`` \_retryフックスクリプト_バックアップの削除の_before_実行され、成功または中止されるまで繰り返し - ``post_delete_retry_script`` \_retryフックスクリプト_バックアップの削除の後_実行され、成功または中止されるまで繰り返し - ``post_delete_script`` \_hook script_は、バックアップの削除後に1回だけ、終了コードはチェックせずに起動されました スクリプトはシェルを介して実行され、任意の終了コードを結果ことができます。 \_retry_スクリプトの場合にのみ、 Barmanはリターンコードをチェックします上部のセクションを参照してください。 削除スクリプトは、バックアップスクリプトと同じ環境変数に加えて、以下を使用します。 - ``BARMAN_NEXT_ID`` 次のバックアップのID存在する場合 WALアーカイブスクリプト ^^^^^^^^^^^^^^^^^^^^^^^ バックアップスクリプトと同様に、アーカイブスクリプトはグローバル構成オプションサーバーごとにオーバーライドできます。 - ``pre_archive_script`` WALファイルがメンテナンス通常\ ``barman cron`` によってアーカイブされる前に_hook script_実行され、1回のみ、終了コードはチェックされません - ``pre_archive_retry_script`` \_retryフックスクリプト_は、WALファイルがメンテナンス通常\ ``barman cron`` によってアーカイブされる_before_実行され、成功または中止されるまで繰り返します - ``post_archive_retry_script`` WALファイルがメンテナンスによってアーカイブされた後、\_retryフックスクリプト_実行され、成功または中止されるまで繰り返し - ``post_archive_script`` WALファイルがメンテナンスによってアーカイブされた後、\_hook script_実行されました。1回のみ、終了コードはチェックされません スクリプトはシェルを介して実行され、任意の終了コードを結果ことができます。 \_retry_スクリプトの場合にのみ、 Barmanはリターンコードをチェックします上部のセクションを参照してください。 アーカイブスクリプトは、バックアップスクリプトといくつかの環境変数を共有します。 - ``BARMAN_CONFIGURATION`` Barmanが使用する構成ファイル - ``BARMAN_ERROR`` エラーメッセージある場合 ``post`` フェーズのみ - ``BARMAN_PHASE`` スクリプトのフェーズ、\ ``pre`` または\ ``post`` のいずれか - ``BARMAN_SERVER`` サーバーの名前 次の変数はアーカイブスクリプトに固有です。 - ``BARMAN_SEGMENT`` WALファイルの名前 - ``BARMAN_FILE`` WALファイルのフルパス - ``BARMAN_SIZE`` WALファイルのサイズ - ``BARMAN_TIMESTAMP`` WALファイルのタイムスタンプ - ``BARMAN_COMPRESSION`` WALファイルに使用される圧縮の種類 WAL削除スクリプト ^^^^^^^^^^^^^^^^^ バージョン **2.4** では、WAL削除前後のスクリプトを導入しています。 他のフックスクリプトと同様に、wal deleteスクリプトはグローバル構成オプションで構成でき、サーバーごとにそれらをオーバーライドすることが可能です。 - ``pre_wal_delete_script`` WALファイルの削除の_before_に_hook script_実行されました - ``pre_wal_delete_retry_script`` \_retryフックスクリプト_は、WALファイルの削除の_before_実行され、成功または中止されるまで繰り返します - ``post_wal_delete_retry_script`` \_retryフックスクリプト_WALファイルの削除の後_実行され、成功または中止されるまで繰り返し - ``post_wal_delete_script`` WALファイルの削除の後に_フックスクリプト_実行されました スクリプトはシェルを介して実行され、任意の終了コードを結果ことができます。 \_retry_スクリプトの場合にのみ、 Barmanはリターンコードをチェックします上部のセクションを参照してください。 WAL削除スクリプトは、WALアーカイブスクリプトと同じ環境変数を使用します。 リカバリスクリプト ^^^^^^^^^^^^^^^^^^ バージョン **2.4** では、リカバリー前後のスクリプトを導入しています。 以前のスクリプトと同様に、リカバリスクリプトはグローバル構成オプション内で構成でき、サーバーごとにオーバーライドすることが可能です。 - ``pre_recovery_script`` \_hook script_は、バックアップのリカバリーの_before_に起動された、1回のみ、終了コードはチェックされません - ``pre_recovery_retry_script`` \_retryフックスクリプト_バックアップのリカバリーの_before_実行、成功または中止するまで繰り返します - ``post_recovery_retry_script`` \_retryフックスクリプト_バックアップのリカバリーの後に実行され、成功または中止されるまで繰り返します - ``post_recovery_script`` \_hook script_は、バックアップのリカバリーの後に起動され、1回のみ、終了コードはチェックされません スクリプトはシェルを介して実行され、任意の終了コードを結果ことができます。 \_retry_スクリプトの場合にのみ、 Barmanはリターンコードをチェックします上部のセクションを参照してください。 リカバリスクリプトは、バックアップスクリプトと同じ環境変数に加えて、以下を使用します。 - ``BARMAN_DESTINATION_DIRECTORY`` 新しいインスタンスがリカバリされるディレクトリ - ``BARMAN_TABLESPACES`` テーブルスペース再配置マップJSON存在する場合 - ``BARMAN_REMOTE_COMMAND`` リカバリーで使用されるsecure Shellコマンド存在する場合 - ``BARMAN_RECOVER_OPTIONS`` リカバリー追加オプションJSON存在する場合 カスタマイズ ------------ ロックファイルディレクトリ ^^^^^^^^^^^^^^^^^^^^^^^^^^ Barmanでは、 ``barman_lock_directory`` グローバルオプションを介してロックファイルのディレクトリを指定できます。 ロックファイルは、グローバルおよびサーバーレベルで同時作業を調整するために使用されますたとえば、 cron操作、バックアップ操作、WALアーカイブへのアクセスなど。 デフォルトでは、下位互換性の理由から、\ ``barman_lock_directory`` は\ ``barman_home`` に設定されます。 .. TIP:: ユーザーは、実行時変数データ専用のディレクトリ、たとえば `/var/run/barman` などの揮発性パーティションのディレクトリを使用することをお勧めします。 バイナリパス ^^^^^^^^^^^^ バージョン1.6.0の時点で、 Barmanでは、global/serverオプション ``path_prefix`` を使用して、 Barmanが実行可能ファイルを検索する1つ以上のディレクトリを指定できます。 ``path_prefix`` が提供される場合、コロンで区切られた1つ以上のディレクトリのリストが含まれている必要があります。 Barmanは、最初にこれらのディレクトリ内を検索し、次に\ ``PATH`` 環境変数で指定されたディレクトリを検索します。 デフォルトでは、\ ``path_prefix`` オプションは空です。 クラスター管理システムとの統合 ------------------------------ Barmanは、スタンバイサーバーストリーミングレプリケーションまたは従来のファイルベースのログ配布を使用および[repmgr][repmgr]のような高可用性ツールと統合するように設計されています。 アーキテクチャの観点から、WALファイルをBarmanサーバーに直接アーカイブするようにPostgreSQLを構成する必要があります。 Barmanは、 ``get-wal`` フレームワークのおかげで、WALハブとして使用することもできます。このために、すべてのスタンバイサーバーで ``barman-cli`` パッケージの一部である\ ``barman-wal-restore`` スクリプトを使用できます。 ``replication-status`` コマンドを使用すると、管理対象サーバー、特にホットスタンバイサーバーとWALストリーマーに接続されているストリーミングクライアントに関する情報を取得できます。 構成モデル ^^^^^^^^^^ 構成モデルは、構成オプションのオーバーライドのセットを定義します。これらのオーバーライドは、構成モデルと同じクラスターの一部であるBarmanサーバーに適用できます。これらはクラスター環境を処理する場合に役立つため、たとえば、フェールオーバーイベントに応答してBarmanサーバーの構成を変更できます。 例として、次のノードを含むPostgreSQLクラスターがあるとします。 - ``pg-node-1`` プライマリ - ``pg-node-2`` スタンバイ - ``pg-node-3`` スタンバイ プライマリノードからバックアップしており、次のオプションを含む構成があるとします。 .. code:: ini [my-barman-server] cluster = my-cluster conninfo = host=pg-node-1 user=barman database=postgres streaming_conninfo = host=pg-node-1 user=streaming_barman ; other options... たとえば、次のようなそのクラスターの構成モデルを作成できます。 .. code:: ini [my-barman-server:backup-from-pg-node-2] cluster = my-cluster model = true conninfo = host=pg-node-2 user=barman database=postgres streaming_conninfo = host=pg-node-2 user=streaming_barman これは、次のコマンドで\ ``pg-node-1`` から\ ``pg-node-2`` へのフェイルオーバーに適用できるため、新しいプライマリノードからバックアップを開始します。 .. code:: bash barman config-switch my-barman-server my-barman-server:backup-from-pg-node-2 これにより、クラスター構成オプションが選択したモデルで定義された値でオーバーライドされます。 *注* モデルからすべてのオプションを設定できるわけではありません。 [section 5 of the ‘man’ page][man5]を参照して、モデルに適用されるスコープの設定を確認してください。 .. *注意* `pg-backup-api `_ をチェックすることに興味があるかもしれません。これは、REST APIをスタートし、 ``barman config-switch`` を含む\ ``barman`` コマンドを実行するためのリモート要求をリッスンすることができます。 パラレルジョブ -------------- デフォルトでは、 Barmanはバックアップとリカバリ操作の両方でファイルコピーに1つのワーカーのみを使用します。バージョン2.2から、ファイルコピーを実行するワーカーの数をカスタマイズできるようになりました。この場合、コピーされるファイルはすべてのパラレルワーカーに等しく分散されます。 グローバルスコープとサーバースコープで構成し、対応する構成ファイルにこれらを追加できます。 .. code:: ini parallel_jobs = n ``n`` は、ファイルコピー操作で使用されるパラレルワーカーの目的の数です。デフォルト値は1です。 いずれの場合も、ユーザーは実行時に\ ``backup`` または\ ``recover`` コマンドを実行するときにこの値をオーバーライドできます。たとえば、次のように4つのパラレルワーカーを使用できます。 .. code:: bash barman backup --jobs 4 server1 または、次のとおりです。 .. code:: bash barman backup --j 4 server1 このパラレルジョブ機能は、 ``rsync`` /SSHを介して構成されたサーバーでのみ利用可能であることに注意してください。ストリーミングプロトコルを介して構成されたサーバーの場合、 Barmanは現在1つのワーカーのみに制限されている\ ``pg_basebackup`` に依存します。 パラレルジョブとsshd MaxStartups ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Barmanは、SSHサーバーで許可される非認証の同時接続の最大数を超えないように、並列Rsyncジョブが開始されるレートを制限します。この最大値は、sshdパラメーター\ ``MaxStartups`` で定義されます。\ ``MaxStartups`` を超える接続が作成されたが、まだ認証されていない場合、SSHサーバーは一部またはすべての接続をドロップする場合があり、その結果、バックアップまたはリカバリーが失敗する場合があります。 ほとんどのプラットフォームでのsshd ``MaxStartups`` のデフォルト値は10です。したがって、 Barmanは10のバッチで並列ジョブを開始し、1秒の期間内に複数のジョブのバッチを開始しません。これにより、1秒あたり10ジョブの有効なレート制限が得られます。 この制限は、次の2つの構成オプションを使用して変更できます。 - ``parallel_jobs_start_batch_size`` 単一のバッチで開始する並列ジョブの最大数。 - ``parallel_jobs_start_batch_period`` ジョブの単一バッチが開始される秒単位の時間。 たとえば、2秒の期間内に5つ以下の新しいRsyncジョブが作成されないようにするには、次のとおりです。 .. code:: ini parallel_jobs_start_batch_size = 5 parallel_jobs_start_batch_period = 2 ``barman backup`` および\ ``barman recover`` コマンドの両方で次の引数を使用して、構成オプションをオーバーライドできます。 - ``--jobs-start-batch-size`` - ``--jobs-start-batch-period`` 地理的な冗長性 -------------- Barmanを使用して **カスケードバックアップアーキテクチャ** をセットアップすることが可能です。バックアップサーバーのソースは、PostgreSQLサーバーではなくBarmanインストールです。 この機能を使用すると、ユーザーはPostgreSQLバックアップの_地理的に分散_コピーを透過的に保持できます。 Barmanの用語では、PostgreSQLサーバーではなくBarmanインストールに接続されているバックアップサーバーは **パッシブノード** と定義されます。パッシブノードは\ ``primary_ssh_command`` オプションを介して構成され、グローバルプライマリBarmanインストールのフルレプリカの場合とサーバーレベル_direct_および_passive_サーバーの両方を持つ混合シナリオの場合の両方で使用できます。 情報の同期 ^^^^^^^^^^ ``barman sync-info`` コマンドは、 Barmanサーバーの現在のステータスに関する情報を収集するために使用されます。同期に役立ちます。使用可能な構文は次のとおりです。 .. code:: bash barman sync-info [--primary] [ []] コマンドは、以下を含むJSONオブジェクトを結果ます。 - そのサーバーのステータスが\ ``DONE`` であるすべてのバックアップを含むマップ - アーカイブされたすべてのWALファイルのリスト - サーバーの構成 - 最後の読み取り位置_xlogデータベースファイル_内 - 最後に読み取られたWALファイルの名前 JSON応答には、\ ``master`` ノードと\ ``passive`` ノード間の同期に必要なすべての情報が含まれています。 ``--primary`` が指定されている場合、コマンドはローカルにではなく、定義されたプライマリノードで実行されます。 構成 ^^^^ サーバーを\ ``passive node`` として構成するのは簡単な操作です。サーバー構成に次のオプションを追加するだけです。 .. code:: ini primary_ssh_command = ssh barman@primary_barman このオプションは、プライマリサーバーへのSSH接続パラメーターを指定し、パッシブサーバーのバックアップデータのソースを指定します。 ``-c/--config`` オプションを使用してbarmanを呼び出しており、パッシブノードがプライマリノードでbarmanを呼び出すときに同じオプションを使用する場合、次のオプションを追加します。 .. code:: ini forward_config_path = true ノードの同期 ^^^^^^^^^^^^ ノードが\ ``passive`` としてマークされている場合、 Barmanによって特別な方法で扱われます。 - 標準のメンテナンス操作から除外されます - ``barman backup`` を含むPostgreSQLへの直接操作は禁止されています パッシブサーバーとそのプライマリ間の同期は、以下を透過的に呼び出す\ ``barman cron`` によって自動的に管理されます。 1. ``barman sync-info --primary`` 、同期情報を収集するため 2. ``barman sync-backup`` 、プライマリノードで使用可能なすべてのバックアップのローカルコピーを作成するため 3. ``barman sync-wals`` 、プライマリノードで使用可能なすべてのWALファイルをローカルにコピーするため 手動同期 ^^^^^^^^ ``barman cron`` はパッシブ/プライマリノードの同期を自動的に管理しますが、次の方法でバックアップの同期を手動でトリガーすることが可能です。 .. code:: bash barman sync-backup ``sync-backup`` barmanを起動すると、primary_ssh_コマンドを使用してマスターサーバーに接続し、リモートマシンにバックアップが存在する場合、rsyncを使用してすべてのファイルのコピーを開始します。バックアップごとに1つの同期プロセスのみが許可されます。 WALファイルは、次の方法で同期することもできます。 .. code:: bash barman sync-wals クラウドスナップショットバックアップ ------------------------------------ スナップショットバックアップは、クラウドストレージボリュームの1つ以上のスナップショットで構成されるバックアップです。 次のいずれかのコマンドを使用して、 :ref:`suitable PostgreSQL server <#prerequisites-for-cloud-snapshots>` のスナップショットバックアップを取得できます。 - BarmanサーバーがWALの保存とメタデータのバックアップに使用されている場合、 ``barman backup`` と :ref:`required configuration operations for snapshots <#configuration-for-snapshot-backups>` 。 - Barmanサーバーがなく、代わりにクラウドオブジェクトストアがWALとバックアップメタデータに使用されている場合に、必要な :ref:`command line arguments <#barman-cloud-backup-for-snapshots>` を備えた\ ``barman-cloud-backup`` 。 スナップショットバックアップの詳細 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ スナップショットバックアップを取得する高レベルのプロセスは次のとおりです。 1. Barmanは一連のプリフライトチェックを実行して、スナップショットオプション、インスタンス、ディスクを検証します。 2. Barmanは、[PostgreSQLbackup API][postgres-low-level-base-backup]を使用してバックアップを開始します。 3. クラウドプロバイダーAPIを使用して、指定された各ディスクのスナップショットをトリガーします。 Barmanは、次のディスクに移動する前に、アプリケーションの一貫性を保証するためにスナップショットが必要な状態に到達するまで待機します。 4. 各ディスクのデバイス名などの追加のプロバイダー固有データは、バックアップメタデータに保存されます。 5. 各ディスクのマウントポイントとマウントオプションは、バックアップメタデータに保存されます。 6. Barmanは、PostgreSQLバックアップAPIを使用してバックアップを停止します。 クラウドプロバイダーのAPI呼び出しは、backupコマンドが実行されるノードで行われます。これは、 Barmanサーバー ``barman backup`` を使用する場合 または PostgreSQLサーバー ``barman-cloud-backup`` を使用する場合 。 次のプリフライトチェックは、各バックアップの前に、およびスナップショットバックアップ用に構成されたサーバーに対して\ ``barman check`` が実行されたときに実行されます。 - ``snapshot_instance`` およびプロバイダ固有の引数で指定されたコンピューティングインスタンスが存在します。 ・ ``snapshot_disks`` で指定されたディスクが存在する。 - ``snapshot_disks`` で指定されたディスクは\ ``snapshot_instance`` に接続されています。 - ``snapshot_disks`` で指定されたディスクは\ ``snapshot_instance`` にマウントされます。 スナップショットバックアップからのリカバリー ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Barmanは現在、スナップショットバックアップからの完全に自動化されたリカバリーを実行しません。これは、スナップショットからの復旧には、新しいインフラストラクチャのプロビジョニングと管理が必要であり、Terraformなどの専用のインフラストラクチャアズコードソリューションでより適切に処理されるためです。 ただし、 ``barman recover`` コマンドは、スナップショットリカバリインスタンスの検証、安全でないオプションのPostgreSQL構成のチェックなどのリカバリ後タスクを実行し、必要なPITRオプションを設定するために使用できます。また、backup_labelファイルを適切な場所にコピーしバックアップラベルがボリュームスナップショットに保存されないため、必要なWAL全体をコピーします ``--get-wal`` 復旧オプションを使用しない場合、取得するようにPostgreSQL ``restore_command`` を構成しますWAL)。 ``barman-cloud-backup`` で作成されたバックアップを復元する場合は、 ``barman recover`` の代わりにより制限的な :ref:`barman-cloud-restore for スナップショット ` コマンドを使用する必要があります。 スナップショットバックアップからのリカバリーは、次の手順で構成されます。 1. バックアップ中に作成されたスナップショットごとに、新しいディスクをプロビジョニングします。 2. 手順1でプロビジョニングされた各ディスクがバックアップメタデータに従って接続およびマウントされるコンピューティングインスタンスをプロビジョニングします。 3. :ref:`barman recover <#recover>` または :ref:`barman-cloud-restore for スナップショット ` コマンドを使用して、リカバリーを検証およびファイナライズします。 ステップ1および2は、既存のインフラストラクチャアズコードシステムで最適に処理されますが、これらの手順を手動でまたはカスタムスクリプトを使用して実行することもできます。 これらの手順を実行する際には、次のリソースが役立つ場合があります。 - 例[recovery script for GCP][snapshot-recovery-script]。 - 例[runbook for Azure][snapshot-recovery-runbook-azure]。 上記のリソースは、バックアップ/リカバリー環境に関する仮定を立てているため、さらにカスタマイズせずに本番使用に適していると考えられるべきではありません。 リカバリインスタンスがプロビジョニングされ、バックアップスナップショットからクローンされたディスクが接続およびマウントされたら、次の追加引数を使用して\ ``barman recover`` を実行します。 - ``--remote-ssh-command`` リカバリインスタンスにログインするために必要なsshコマンド。 - ``--snapshot-recovery-instance`` クラウドプロバイダーの必要なリカバリインスタンスの名前。 - スナップショットプロバイダーに固有の追加引数。 例 .. code:: bash barman recover SERVER_NAME BACKUP_ID REMOTE_RECOVERY_DIRECTORY \ --remote-ssh-command ssh USER@HOST \ --snapshot-recovery-instance INSTANCE_NAME Barmanは、バックアップがスナップショットバックアップであることを自動的に検出し、接続されたディスクがそのバックアップのスナップショットからクローンされたことを確認します。 Barmanは、バックアップラベルとWALを適切な場所にコピーし、PostgreSQL構成に必要な復旧オプションを設定することにより、PostgreSQLの復旧を準備します。 ``gcp`` プロバイダーでは、次の追加の\ ``barman recover`` 引数を使用できます。 - ``--gcp-zone`` リカバリインスタンスが存在するアベイラビリティーゾーンの名前。提供されない場合、 Barmanはサーバー構成で設定された\ ``gcp_zone`` の値を使用します。 ``azure`` プロバイダーでは、次の追加の\ ``barman recover`` 引数を使用できます。 - ``--azure-resource-group`` リカバリインスタンスが属するリソースグループ。提供されない場合、 Barmanはサーバー構成で設定された\ ``azure_resource_group`` の値を使用します。 ``aws`` プロバイダーでは、次の追加の\ ``barman recover`` 引数を使用できます。 - ``--aws-region`` リカバリインスタンスが存在するAWSリージョン。提供されない場合、 Barmanはサーバー構成で設定された\ ``aws_region`` の値を使用します。 スナップショットバックアップを復旧する場合、次の\ ``barman recover`` 引数/config変数は使用できないことに注意してください。 .. csv-table:: :header: **Command argument**,**Config variable** . :widths: auto :align: left :class: longtable `--bwlimit`,`bandwidth_limit` `--jobs`,`parallel_jobs` `--recovery-staging-path`,`recovery_staging_path` `--tablespace`,N/A スナップショットバックアップのバックアップメタデータ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ リカバリディスクとインスタンスがインフラストラクチャアズコード、アドホック自動化、または手動でプロビジョニングされるかどうかにかかわらず、 Barmanを照会して、特定のバックアップに必要なスナップショットを見つける必要があります。これは、バックアップの各スナップショットの詳細を提供する :ref:`barman show-backup <#show-backup>` を使用して実現できます。例 .. code:: bash $ barman show-backup primary 20230123T131430 Backup 20230123T131430: Server Name : primary System Id : 7190784995399903779 Status : DONE PostgreSQL Version : 140006 PGDATA directory : /opt/postgres/data Server information: Checksums : on Snapshot information: provider : gcp project : project_id device_name : pgdata snapshot_name : barman-av-ubuntu20-primary-pgdata-20230123t131430 snapshot_project : project_id Mount point : /opt/postgres Mount options : rw,noatime device_name : tbs1 snapshot_name : barman-av-ubuntu20-primary-tbs1-20230123t131430 snapshot_project : project_id Mount point : /opt/postgres/tablespaces/tbs1 Mount options : rw,noatime ``--format=json`` オプションは、外部ツールと統合する場合に使用できます。例 .. code:: bash $ barman --format=json show-backup primary 20230123T131430 ... "snapshots_info": { "provider": "gcp", "provider_info": { "project": "project_id" }, "snapshots": [ { "mount": { "mount_options": "rw,noatime", "mount_point": "/opt/postgres" }, "provider": { "device_name": "pgdata", "snapshot_name": "barman-av-ubuntu20-primary-pgdata-20230123t131430", "snapshot_project": "project_id" } }, { "mount": { "mount_options": "rw,noatime", "mount_point": "/opt/postgres/tablespaces/tbs1" }, "provider": { "device_name": "tbs1", "snapshot_name": "barman-av-ubuntu20-primary-tbs1-20230123t131430", "snapshot_project": "project_id", } } ] } ... ``barman-cloud-backup`` で取得されたバックアップの場合、同様の[barman-cloud-backup-show][pgbarman-barman-cloud-backup-show]コマンドがあり、 ``barman-cloud-backup-list`` とともに使用して、クラウドオブジェクトストアのバックアップメタデータを照会できます。 ``snapshots_info/provider_info`` および\ ``snapshots_info/snapshots/*/provider`` で使用可能なメタデータは、以降のセクションで説明するように、クラウドプロバイダーによって異なります。 GCPプロバイダー固有のメタデータ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``snapshots_info/provider_info`` では、次のフィールドが使用できます。 - ``project`` バックアップとリカバリーに関係するリソースを所有するプロジェクトのGCPプロジェクトID。 ``snapshots_info/snapshots/*/provider`` では、次のフィールドが使用できます。 - ``device_name`` スナップショットのソースディスクがバックアップ時にバックアップVMに接続された短いデバイス名。 - ``snapshot_name`` スナップショットの名前。 - ``snapshot_project`` スナップショットを所有するGCPプロジェクトID。 Azureプロバイダー固有のメタデータ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``snapshots_info/provider_info`` では、次のフィールドが使用できます。 - ``subscription_id`` バックアップとリカバリーに関係するリソースを所有するAzureサブスクリプションID。 - ``resource_group`` バックアップに関係するリソースが属するAzureリソースグループ。 ``snapshots_info/snapshots/*/provider`` では、次のフィールドが使用できます。 - ``location`` スナップショットが取得されたディスクのAzureの場所。 - ``lun`` バックアップ時にスナップショットが取得されたディスクを識別するLUN。 - ``snapshot_name`` スナップショットの名前。 AWSプロバイダー固有のメタデータ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``snapshots_info/provider_info`` では、次のフィールドが使用できます。 - ``account_id`` バックアップの作成に使用されたリソースを所有するAWSアカウントのID。 - ``region`` バックアップに関係するリソースが存在するAWSリージョン。 ``snapshots_info/snapshots/*/provider`` では、次のフィールドが使用できます。 - ``device_name`` バックアップ時にバックアップVMでソースディスクがマッピングされたデバイス。 - ``snapshot_id`` AWSによって割り当てられたスナップショットのID。 - ``snapshot_name`` スナップショットの名前。