Design and architecture

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

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

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

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

  • Barmanを専用サーバーにインストール

  • PostgreSQLサーバーと同じストレージを共有しないでください

  • Barmanを監視インフラストラクチャ```` [^nagios]``と統合します

  • 本番環境に展開する前にすべてをテストします

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

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

  • PostgreSQLとBarmanに関して、次のようないくつかの可能なアーキテクチャを設計します。 1.同じデータセンター 2.同じ大都市圏の異なるデータセンター 3.異なるデータセンター

  • 各仮説の長所と短所を詳しく説明する

  • 費用対効果分析により、システムの単一障害点（SPOF）を評価します

  • あなたの決定を下し、最初の解決策を実装する

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

  1. 地理的冗長性 （ Barman 2.6で導入）

  2. フックスクリプト

地理的冗長性を使用すると、別のデータセンター/アベイラビリティーゾーンにあるBarmanインスタンスを利用して、ソースBarmanサーバーのコンテンツ全体を同期できます。さらにあります： Barmanで地理的冗長性をグローバルレベルだけでなくサーバーレベルでも構成できることを考えると、一部のサーバーがローカルPostgreSQLサーバーに直接接続され、他のサーバーがサブセットをバックアップするBarmanのハイブリッドインストールを作成できますさまざまなBarmanインストールの（クロスサイトバックアップ）。以下の図:raw-latex:`ref{georedundancy-design}`は、2つのアベイラビリティーゾーン（1つはヨーロッパ、1つは米国）を示しています。それぞれにプライマリPostgreSQLサーバーがあります。ローカルのBarmanインストールでバックアップされ、他のBarmanサーバー（として定義されます）でリレーされますパッシブ）rsync / SSHを介した多層バックアップの場合。 geo冗長性の詳細については、特定のセクションを参照してください。

An example of architecture with geo-redundancy { width=80% }

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

決定は永遠ではないことを忘れないでください。この方法で始めて、時間をかけて自分に最適なソリューションに適応できます。ただし、最初はシンプルに保つようにしてください。

1つのBarman、多くのPostgreSQLサーバー

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

```` ^recver セクション「リカバリーの要件」で詳しく説明されているように、リカバリーに適用されます。

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

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

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

  • 1つのPostgreSQLインスタンス（ホスト名pg ）

  • Barmanを備えた1つのバックアップサーバー（ホスト名backup ）

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

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

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

重要

Barmanは透過的に`pg_basebackup` を利用するため、増分バックアップ、並列バックアップ、重複排除などの機能は現在利用できません。この場合、帯域幅制限にはいくつかの制限があります-rsync を介した従来の方法と比較して。

pg_basebackup の制限が発生するすべての場合（たとえば、増分バックアップと重複排除のメリットを享受できる非常に大規模なデータベース）には、 rsync /SSHを使用したバックアップをお勧めします。

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

Barman WALアーカイブ

PostgreSQLバックアップの回復は、トランザクションログ（xlogまたはWALファイルとも呼ばれます）の再生に依存しています。したがって、WALファイルはBarmanによってベースバックアップと一緒に保存され、リカバリ時に利用できるようにすることが不可欠です。これは、WALストリーミングまたは標準のWALアーカイブを使用して、WALをBarmanのWALアーカイブにコピーすることで達成できます。

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

Barmanは、PostgreSQLのarchive_command を使用して達成される標準のWALファイルアーカイブもサポートしています（ rsync /SSHを介して、またはbarman-cli パッケージのbarman-wal-archive を介して）。この方法では、PostgreSQLが新しいWALファイルに切り替わった場合にのみ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}`を参照してください。

Streaming-only backup (Scenario 1) { width=80% }

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

1.管理、調整、および監視を目的としたPostgreSQLへの標準接続

  1. 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) { width=80% }

SSH経由のWALアーカイブには以下が必要です。

  • PostgreSQLサーバーのpostgres ユーザーがBarmanサーバーにbarman ユーザーとして接続できるようにする追加のSSH接続

  • PostgreSQLのarchive_command は、WALファイルをBarmanに出荷するように構成されます

シナリオ2：rsync /SSH経由のバックアップ

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

  • ファイルレベルの増分バックアップ

  • パラレルバックアップ

  • テーブルスペースごとを含む、帯域幅使用量のより細かい制御

Scenario 2 - Backup via rsync/SSH { width=80% }

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

1.管理、調整、および監視を目的としたPostgreSQLへの標準接続

  1. Barmanサーバーのbarman ユーザーがPostgreSQLサーバーのpostgres ユーザーとして接続できるようにするrsync が使用するベースバックアップ操作用のSSH接続

  2. PostgreSQLのarchive_command が使用するWALアーカイブ用のSSH接続。これにより、PostgreSQLサーバーのpostgres ユーザーがBarmanサーバーのbarman ユーザーとして接続できます。

ステップ3でWALアーカイブを構成する代わりに、 シナリオ1：ストリーミングプロトコルを介したバックアップ で説明されているようにWALストリーミングを構成できます。これにより、 archive_command の代わりにストリーミングレプリケーション接続が使用され、RPOが大幅に削減されます。

シナリオ1：ストリーミングプロトコルを介したバックアップ と同様に、以下の図:raw-latex:`ref{scenario2b-design}`に示すように、WALストリーミングとWALアーカイブの両方を構成することもできます。

Backup via rsync/SSH with WAL streaming (Scenario 2b) { width=80% }