barmanを使用したアーキテクチャバックアップデザイン#
効果的なディザスターリカバリー計画は、注意深く設計されたアーキテクチャから始まります。重要な決定には、他の考慮事項の中でも、バックアップサーバーをホストする場所とバックアップとWALファイルを転送する方法の決定が含まれます。それを念頭に置いて、このセクションでは、 Barmanでバックアップを展開および管理するためのいくつかの異なるセットアップについて説明します。
Barmanをインストールする場所#
Barmanの基礎の1つは、ネットワークを介してデータベースサーバーからリモートで操作できる機能です。
理論的には、 Barmanサーバーを世界の別の地域、Postgresサーバーから数千マイル離れたデータセンターに配置することができます。現実的には、バックアップとリカバリー時間の両方を制御できるように、 BarmanサーバーをPostgresサーバーから遠すぎないようにします。
Barmanをセットアップするための「フリーサイズ」の方法はありませんが、特に従うことをお勧めする推奨事項がいくつかあります。
Barmanを専用サーバーにインストールします。
Postgresサーバーと同じストレージを共有しないでください。
Barmanをインフラ監視ツールと統合します。
運用に展開する前にすべてをテストします。
ディザスターリカバリーアーキテクチャのモデリングを開始するための良い方法には、次のものが含まれます。
次のようなPostgresとBarmanの場所に関して、いくつかの可能なアーキテクチャをデザインします。
同じデータセンター。
同じ大都市圏内の異なるデータセンター。
さまざまな大都市圏のさまざまなデータセンター。
各仮説の長所と短所を詳しく説明します。
費用対効果分析を使用して、システムの`SPOF`を評価します。
決定を下し、初期ソリューションを実装します。
それを念頭に置いて、 Barmanの非常に一般的なセットアップは、Postgresサーバーと同じデータセンターにインストールすることです。その場合、 SPOF`はデータセンター自分自身です。ただし、このような :term:`SPOF`のインパクトは、 :ref:`geographical redundancy Barman 2.6で導入された geographical redundancy などの機能で大幅に軽減できます。
地理的冗長性を使用すると、別のデータセンター/アベイラビリティーゾーンにあるBarmanインスタンスを依存して、Postgresノードと同じデータセンターにあるBarmanサーバーのコンテンツ全体を同期できます。また、 Barmanで地理的冗長性をグローバルレベルだけでなくサーバーレベルでも構成できることを考えると、一部のサーバーがローカルのPostgresサーバーに直接接続され、他のサーバーがサブセットをバックアップするBarmanのハイブリッドインストールを作成できます。さまざまなBarmanインストールクロスサイトバックアップ。以下の図は、2つのアベイラビリティーゾーン1つはヨーロッパに、もう1つは米国にあり、それぞれにプライマリPostgresサーバーがあり、ローカルのBarmanインストールでバックアップされ、多層バックアップのために他のBarmanサーバーパッシブとして定義に中継されます。 Rsync / SSH経由。地理的冗長性の詳細については、 geographical redundancy セクションで入手できます。
Hook Scripts のおかげで、 Barmanのバックアップは、tarを介したテープなどのさまざまなメディア、またはクラウドプロバイダーのオブジェクトストレージバケットのような場所にエクスポートできます。
どのような決定も永遠ではないことに注意してください。一方の方法で開始し、時間の経過とともに自分に最適なソリューションに適応できます。ただし、最初はシンプルにするようにしてください。
1人のBarman、多数のPostgresサーバー#
Barmanによって最初に紹介されたもう1つの関連機能は、マルチプルのサーバーのサポートです。 Barmanは、バージョンが異なる場合でも、複数のPostgresインスタンスからのバックアップデータを一元化した方法で保存できます。その結果、複雑なディザスターリカバリーアーキテクチャをモデル化し、Postgresサーバーが中央のBarmanサーバーを中心にローテーションする/「スタースキーマ」を形成できます。
すべてのアーキテクチャは、独自の方法で意味があります。実際の実験とテストに基づいて、自分に共鳴するもの、そして最も重要なことに、信頼できるものを選択してください。
バックアップ戦略#
バックアップ戦略の選択も、セットアップにおいて重要な役割を果たします。 Barmanは、トランスポートメカニズムとしてSSHを使用するRsync、またはPostgresストリーミングレプリケーションプロトコルを使用する pg_basebackup を使用してバックアップを取得できます。これら2つの方法のいずれかを選択することは、決定する必要がありますが、一般的な使用のために、現在サポートされているPostgresのすべてのバージョンでストリーミングレプリケーションを使用することをお勧めします。
注釈
Barmanはストリーミングバックアップを使用するときに pg_basebackup を利用するため、現在パラレルバックアップなどの機能は利用できません。この場合、帯域幅制限にはいくつかの制限があります-Rsyncを介した従来の方法と比較して。 17より前のPostgresバージョンでは、この方法を使用する場合、インクリメンタルバックアップも利用できません。
pg_basebackup の制限が問題を引き起こす場合、Rsync / SSHを使用したバックアップをお勧めします。
ストリーミングバックアップをお勧めする理由は、私たちの経験から、セットアップが簡単であるためです。また、ストリーミングバックアップでは、 WindowsでPostgresサーバーをバックアップでき、Dockerを使用する際に作業が簡単になります。
WALアーカイブ戦略#
Postgresバックアップの回復は、トランザクションログxlogまたはWALファイルとしても知られるを再生することに依存しています。したがって、WALファイルはベースバックアップとともにBarmanが保存して、復旧時に使用できるようにすることが重要です。これは、WALストリーミングまたは標準のWALアーカイブを使用してWALをBarmanサーバーにコピーすることにより実現できます。
1. WAL streaming involves transferring WAL files from the Postgres server with
pg_receivewal using the Postgres streaming replication protocol. With WAL streaming,
WALs are transferred while they are still being generated, which means that Barman
doesn't have to wait for WAL segments to be completely filled in order to receive them.
Such mechanism makes WAL streaming able to significantly reduce the risk of data loss,
bringing RPO down to near zero values. It is also possible to add Barman as a
synchronous WAL receiver in your Postgres cluster and achieve zero data loss (RPO=0).
With the use of replication slots, we can also assure that no WAL file is recycled
before being successfully received by Barman.
pg_receivewal のインストール方法の詳細については、 pre-requisites for wal streaming を参照してください。
注釈
WALストリーミングを使用する場合、常にプライマリノードからストリーミングすることをお勧めします。これは、フェイルオーバーが発生した場合でも、すべてのWALがBarmanによって受信されるようにするためです。
2. Barman also supports standard WAL file archiving, which is achieved using the
Postgres archive_command, either using Rsync/SSH or barman-wal-archive
from the barman-cli package. With this method, WAL files are archived only when
Postgres switches to a new WAL file, which normally happens every 16MB worth of data
changes. This approach offers more flexibility by allowing you to pick a tool of your
choice for transferring the WAL files.
WALストリーミングまたはWALアーカイブのいずれかを構成する必要があります。オプションでWALストリーミングと標準のWALアーカイブの両方を構成することが可能です。そのような場合、 Barmanは着信WALを自動的に重複排除します。これはフォールバックメカニズムを提供し、WALストリーミングが失敗した場合にもWALはBarmanのアーカイブにコピーされます。
一般的な使用の場合、WALストリーミングのみを構成することをお勧めします。
注釈
Barmanの以前のバージョンでは、WALアーカイブとWALストリーミングの両方を使用することを推奨していました。これは、9.4より前のPostgresバージョンがレプリケーションスロットをサポートしていないため、WALストリーミングだけではすべてのWALがBarmanのWALアーカイブに安全に保存されることを保証できないためです。 Postgresのサポートされているすべてのバージョンにレプリケーションスロットがあるため、WALストリーミングのみを構成するだけで十分です。
バックアップの2つの一般的なシナリオ#
あなたの人生を楽にするために、このセクションでは、 Barmanの特定のPostgresサーバーの2つの最も一般的なシナリオをまとめます。これは、 Barmanでバックアップすることにしたすべてのサーバーに対して行う必要がある決定であることに注意してください。これは、同じBarmanサーバー内で異種セットアップを使用できることを意味します。
pg および backup を使用して、それぞれPostgresおよびBarmanサーバーを参照します。ただし、実際には、アーキテクチャには、repmgr、pgBouncer、Nagios/Icingaなどの他のテクノロジーが含まれる可能性が高くなります。
シナリオ1ストリーミングプロトコルを介したバックアップ#
Streaming Backups で述べたように、このアプローチでは、 Postgresストリーミングプロトコルを使用してクラスターファイルをBarmanサーバーに転送します。これは、 pg_basebackup ユーティリティを使用して実行されます。 Barmanでは、 Barmanサーバー構成に backup_method = postgres を含めることにより、この方法を設定できます。
このアプローチでは、 Postgres 17以降で利用可能な pg_basebackup が提供する block-level incremental backups サポートを活用できます。ブロックレベルのインクリメンタルバックアップは、重複排除率の点でRsync戦略が提供する block-level incremental backups よりもはるかに効率的である傾向があります。
この方法は、WALファイルのWALストリーミングと組み合わせて使用されます。 Barmanの用語では、このセットアップは、バックアップおよびアーカイブ操作にSSH接続を使用しないため、ストリーミング専用のセットアップと呼ばれます。これは、Docker環境や高度に規制された環境などに特に適しており、非常に実用的です。
ストリーミングバックアップ方法は、通常、ほとんどのユースケースで推奨されるアプローチです。
次の図は、この設定が実際にどのように機能するかを示しています。
構成するには、次のものが必要です。
1.管理、調整、およびモニタリングを目的としたPostgresへの標準接続。
2. A streaming replication connection to be used by both pg_basebackup
(for base backup operations) and pg_receivewal (for WAL streaming).
シナリオ2 rsync / SSHを介したバックアップ#
rsync backups 概念で述べたように、このアプローチはRsyncに依存してバックアップファイルをBarmanサーバーに転送します。これは、サーバーをバックアップモードにし、Rsyncを使用してクラスターファイルを転送することにより実行されます。
このアプローチの主な利点は、バックアップ操作の実行時に parallel jobs を使用できることです。これにより、バックアップの全体的な時間を大幅に短縮できます。また、 parallel jobs を取得する機能も提供します。これは、重複排除のために以前のバックアップのファイルを再利用します。ファイルレベルのインクリメンタル バックアップは、各バックアップが他から完全に独立しているため、 parallel jobs よりも柔軟です。つまり、インクリメンタルバックアップに影響を与えることなくルートバックアップを削除できます。
この方法のもう1つの利点は、テーブルスペースごとなど、帯域幅の使用をより詳細に制御できることです。詳細については、 Managing Bandwidth Usage を確認してください。
次の図は、この設定が実際にどのように機能するかを示しています。
構成するには、次のものが必要です。
1.管理、調整、およびモニタリングを目的としたPostgresへの標準接続。
2. An SSH connection to be used by Rsync for base backup operations that allow the barman user on the Barman server to connect as the postgres user on the Postgres server.
3. An SSH connection for WAL archiving to be used by the archive_command in Postgres
that allows the postgres user on the Postgres server to connect as barman user
on the Barman server.
ハイブリッドシナリオ#
また、rsyncバックアップとWALストリーミングを組み合わせたハイブリッドアプローチを使用して、rsyncバックアップファイルレベルのインクリメンタルバックアップ、パラレルジョブなどとWALストリーミングのものより効率的なWAL転送の利点を備えた結果を達成することもできます。 、オプションのRPOゼロ）。
次の図は、この設定が実際にどのように機能するかを示しています。
これを行うには、 Barmanサーバー構成で backup_method を rsync として構成し、 streaming_archiver を on に設定する必要があります。また、WALアーカイブに pg_receivewal が使用するストリーミングレプリケーション接続と、Rsyncがベースバックアップ操作に使用するSSH接続も必要です。
WALアーカイブフォールバック冗長性#
Barmanを使用すると、WALストリーミングに加えてWALアーカイブを構成して、WALストリーミングが失敗した場合のフォールバックメカニズムを設けることができます。これは、上記で説明した backup_method 構成のいずれかで実行できます。
1. When using the streaming-only setup, described in the Scenario 1, you can also configure WAL archiving via SSH in addition to WAL streaming. In such scenarios, WAL archiving would act as a fallback mechanism in case WAL streaming failed.
2. When using the Rsync backup method, described in
Scenario 2, you can also
configure WAL streaming instead of using the archive_command in order to have a
lower RPO. You can also opt for configuring WAL streaming in addition to WAL
archiving and have both options.
いずれの場合も、 BarmanはWALファイルがアーカイブで重複していないことを自動的に確認し、1回のみ保存します。
地理的な冗長性#
Barmanの非常に一般的なセットアップは、PostgreSQLサーバーが存在するのと同じデータセンターにインストールすることです。この場合、単一障害点はデータセンターです。幸いなことに、このような`SPOF`の影響は、バックアップ層の数を増やすためにBarmanが提供する2つの機能のおかげで、緩和できます。
地理的冗長性Barman 2.6で導入
フックスクリプト
地理的冗長性を使用すると、別のデータセンター/アベイラビリティーゾーンにある別のBarmanインスタンスに依存し、プライマリBarmanサーバーのコンテンツ全体を同期できます。
さらにあります。Barmanで地理的冗長性をグローバルレベルだけでなくサーバーレベルでも構成できることを考えると、一部のサーバーがローカルのPostgreSQLサーバーに直接接続し、他のサーバーがサブセットをバックアップするBarmanのハイブリッドインストールを作成できます。さまざまなBarmanインストールのクロスサイトバックアップ。
以下の図は、2つのアベイラビリティーゾーン1つはヨーロッパに、もう1つは米国にあり、それぞれにプライマリPostgreSQLサーバーがあり、ローカルのBarmanインストールでバックアップされ、多層バックアップのために他のBarmanサーバーパッシブとして定義に中継されます。 rsync / SSH経由。地理的冗長性の詳細については、 Geographical Redundancy セクションで入手できます。
次の画像は、この設定が実際にどのように機能するかを示しています。
クラウド スナップショット バックアップ#
Barmanは、クラウドスナップショットバックアップもサポートしており、クラウド内のPostgresサーバーが存在するストレージボリュームのスナップショットを取得します。 Barmanは現在、Azure、Google、およびAWSでこの方法をサポートしています。この方法の前提条件は、Postgresサーバーが存在するクラウドプロバイダーによって異なるため、詳細については クラウド スナップショット バックアップ セクションを確認することをお勧めします。