デザインとアーキテクチャ#

Barmanをインストールする場所#

Barmanの基礎の1つは、ネットワークを介してデータベースサーバーからリモートで操作できる機能です。

理論的には、 BarmanサーバーをPostgreSQLサーバーから数千マイル離れた世界の別の地域のデータセンターに配置することができます。現実的には、バックアップとリカバリー時間の両方を制御できるように、 BarmanサーバーをPostgreSQLサーバーから遠すぎないようにします。

Barmanをセットアップするための_“フリーサイズ”_方法はありませんが、特に従うことをお勧めする推奨事項がいくつかあります。

専用サーバーにBarmanをインストールする
PostgreSQLサーバーと同じストレージを共有しないでください
Barmanをモニタリングインフラストラクチャと統合します[^nagios]
運用環境に展開する前にすべてをテスト

[^nagios] Nagios/Icingaとの統合は、 Barmanの最も重要な機能の1つであり真の救世主であるbarman check --nagios コマンドのおかげで簡単です。

ディザスターリカバリーアーキテクチャのモデリングを開始する合理的な方法は、次のことです。

PostgreSQLとBarmanに関して、いくつかの可能なアーキテクチャをデザインします。
1. 同じデータセンターre
2. 同じ首都圏の異なるデータセンター
3. 異なるデータセンター
各仮説の長所と短所を詳しく説明します
費用対効果分析を使用して、システムの単一障害点SPOFを評価します
決定を下し、最初のソリューションを実装します

そうは言っても、 Barmanの非常に一般的なセットアップは、PostgreSQLサーバーが存在するのと同じデータセンターにインストールされることです。この場合、単一障害点はデータセンターです。幸いなことに、このようなSPOFの影響は、バックアップ層の数を増やすためにBarmanが提供する2つの機能のおかげで、緩和できます。

地理的冗長性 Barman 2.6で導入
フックスクリプト

地理的冗長性_を使用すると、別のデータセンター/アベイラビリティーゾーンにあるBarmanインスタンスを依存して、ソースBarmanサーバーのコンテンツ全体を同期できます。さらにありますBarmanの_ハイブリッドインストール_を作成できます。さまざまなBarmanインストールの_クロスサイトバックアップ。以下の図:raw-latex:`ref{georedundancy-design}`は、2つのアベイラビリティーゾーン1つはヨーロッパに、もう1つは米国にあり、それぞれにプライマリPostgreSQLサーバーがあり、ローカルのBarmanインストールでバックアップされ、他のBarmanサーバーに中継されます_passive_)、rsync / SSHを介した多層バックアップ用。地理的冗長性の詳細については、特定のセクションで入手できます。

An example of architecture with geo-redundancy#

代わりに_hook scripts_のおかげで、 Barmanのバックアップをtar を介した_tape_などのさまざまなメディア、またはAmazonクラウドの_S3バケット_のような場所にエクスポートできます。

どのような決定も永遠ではないことに注意してください。この方法で開始し、時間の経過とともに自分に最適なソリューションに適応できます。ただし、最初はシンプルにするようにしてください。

1つのBarman、多数のPostgreSQLサーバー#

Barmanによって最初に導入されたもう1つの関連機能は、マルチプルサーバーのサポートです。 Barmanは、バージョンが異なる場合でも、複数のPostgreSQLインスタンスからのバックアップデータを一元化した方法で保存できます。 [^recver]

[^recver] _「リカバリの要件」_セクションで詳細に説明しているように、同じ[PostgreSQLのPITRの要件][requirements_recovery]がリカバリに適用されます。

その結果、複雑なディザスターリカバリーアーキテクチャをモデル化し、PostgreSQLサーバーが中央のBarmanサーバーを中心にローテーションする「スタースキーマ」を形成できます。

すべてのアーキテクチャは、独自の方法で意味があります。実際の実験とテストに基づいて、自分に共鳴するもの、そして最も重要なことに、信頼できるものを選択してください。

これ以降、簡単にするために、このガイドでは基本的なアーキテクチャを前提とします。

1つのPostgreSQLインスタンスホスト名pg
Barmanホスト名backup を使用した1つのバックアップサーバー

ストリーミングバックアップとrsync / SSH#

Barmanは、トランスポートメカニズムとしてSSHを使用するRsync、またはPostgreSQLのストリーミングレプリケーションプロトコルを使用するpg_basebackup を使用してバックアップを取得できます。

これら2つの方法のいずれかを選択することは、決定する必要がありますが、一般的な使用のために、現在サポートされているPostgreSQLのすべてのバージョンでストリーミングレプリケーションを使用することをお勧めします。

pg_basebackup の制限が問題を引き起こす場合、 rsync /SSHを使用したバックアップをお勧めします。

ストリーミングバックアップをお勧めする理由は、私たちの経験から、従来のバックアップよりもセットアップが簡単であるためです。また、ストリーミングバックアップでは、 Windows[^windows]でPostgreSQLサーバーをバックアップでき、Dockerを使用する際に作業が簡単になります。

[^windows] WindowsでのPostgreSQLサーバーのバックアップは可能ですが、継続的インテグレーションシステムの一部ではないため、まだ実験的です。詳細については、セクション_” Windowsベースのサーバーをセットアップする方法”_を参照してください。

Barman WALアーカイブ#

PostgreSQLバックアップの復旧は、トランザクションログ_xlog_またはWALファイルとしても知られるを再生することに依存しています。したがって、WALファイルはベースバックアップとともにBarmanによって保存され、復旧時に使用できるようにすることが重要です。これは、WALストリーミングまたは標準のWALアーカイブを使用して、WALをBarmanのWALアーカイブにコピーすることで実現できます。

WALストリーミングには、レプリケーションスロットを使用してpg_receivewal を使用してPostgreSQLサーバーからWALファイルをストリーミングすることが含まれます。 WALストリーミングは、データ損失のリスクを削減し、RPOを_近い_ゼロ_値に下げることができます。 PostgreSQLクラスターの同期WALレシーバーとしてBarmanを追加し、 ゼロデータ損失 RPO=0を達成することもできます。

Barmanは、 PostgreSQLのarchive_command rsync /SSHまたはbarman-cli パッケージのbarman-wal-archive 経由のいずれかを使用して実現される標準のWALファイルアーカイブもサポートしています。この方法では、 PostgreSQLが新しいWALファイルに_switches_した場合にのみWALファイルがアーカイブされます。簡単にするために、これは通常16MB相当のデータが変更されるごとに発生します。

WALストリーミングまたはWALアーカイブのいずれかが構成されていることが必須です。オプションでWALストリーミングと標準のWALアーカイブの両方を構成することが可能です。そのような場合、 Barmanは着信WALを自動的に重複排除します。これはフォールバックメカニズムを提供し、WALストリーミングが失敗した場合にもWALはBarmanのアーカイブにコピーされます。

一般的な使用の場合、WALストリーミングのみを構成することをお勧めします。

注釈

Barmanの以前のバージョンでは、WALアーカイブ*とWALストリーミングの両方を使用することを推奨していました。これは、9.4より前のPostreSQLバージョンがレプリケーションスロットをサポートしていないため、WALストリーミングだけではすべてのWALがBarmanのWALアーカイブに安全に保存されることを保証できないためです。 PostgreSQLのサポートされているすべてのバージョンにレプリケーションスロットがあるため、WALストリーミングのみを構成するだけで十分です。

バックアップの2つの一般的なシナリオ#

あなたの人生を楽にするために、以下に、 Barmanの特定のPostgreSQLサーバーの2つの最も一般的なシナリオを要約します。

これは、 Barmanでバックアップすることにしたすべてのサーバーに対して行う必要がある決定であることに注意してください。これは、同じインストール内で異種セットアップを使用できることを意味します。

前述のように、PostgreSQLサーバーpg とBarmanサーバーbackup のみを心配します。ただし、実際には、アーキテクチャには、repmgr、pgBouncer、Nagios/Icingaなどの他のテクノロジーが含まれる可能性が高くなります。

シナリオ1ストリーミングプロトコルを介したバックアップ#

ほとんどのユースケースでは、ストリーミングバックアップインストールをお勧めします。以下の図:raw-latex:`ref{scenario1-design}`を参照してください。

このシナリオでは、以下を構成する必要があります。

管理、調整、およびモニタリングを目的としたPostgreSQLへの標準接続
pg_basebackup ベースバックアップ操作の場合とpg_receivewal WALストリーミングの場合の両方で使用されるストリーミングレプリケーション接続

Barmanの用語では、このセットアップは、バックアップおよびアーカイブ操作にSSH接続を使用しないため、 ストリーミング専用 セットアップとして知られています。これは、Docker環境に特に適しており、非常に実用的です。

Barman WALアーカイブで説明したように、WALストリーミングに加えて、SSHを介してWALアーカイブを構成できます。以下の図:raw-latex:`ref{scenario1b-design}`を参照してください。

Streaming backup with WAL archiving (Scenario 1b)#

SSHを介したWALアーカイブには以下が必要です。

PostgreSQLサーバーのpostgres ユーザーがBarmanサーバーのbarman ユーザーとして接続できる追加のSSH接続
PostgreSQLのarchive_command は、WALファイルをBarmanに出荷するように構成します

シナリオ2 `rsync` /SSHを介したバックアップ#

rsync /SSHバックアップインストールは、次の機能が必要な場合に必要です。

ファイルレベルのインクリメンタルバックアップ
パラレルバックアップ
テーブルスペースごとなど、帯域幅使用のより詳細な制御