Design and architecture

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

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

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

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

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

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

  • Barmanを監視インフラストラクチャ [1] と統合

  • 実稼働に展開する前にすべてをテストします

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

  • 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つは米国）を示しています。それぞれには、ローカルのBarmanインストールでバックアップされ、他のBarmanサーバーで中継されます（パッシブ）rsync / SSHを介した多層バックアップの場合。 geo冗長性の詳細については、特定のセクションを参照してください。

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

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

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

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

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

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

すべてのアーキテクチャには、独自の方法があります。実際の実験とテストに基づいて、あなたの心に響くものを選択してください。最も重要なことです。

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

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

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

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

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

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

重要

Because Barman transparently makes use of pg_basebackup , features such as incremental backup, parallel backup, and deduplication are currently not available. In this case, bandwidth limitation has some restrictions - compared to the traditional method via rsync .

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

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

Barman WALアーカイブ

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

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

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

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

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

注釈

Previous versions of Barman recommended that both WAL archiving and WAL streaming were used. This was because PostreSQL versions older than 9.4 did not support replication slots and therefore WAL streaming alone could not guarantee all WALs would be safely stored in Barman's WAL archive. Since all supported versions of PostgreSQL now have replication slots it is sufficient to configure only WAL streaming.

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

作業を楽にするために、 Barmanの特定のPostgreSQLサーバーの最も一般的な2つのシナリオを以下にまとめます。

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

前述のように、PostgreSQLサーバー（pg ）とBarmanサーバー（backup ）のみについて考えます。ただし、実際には、アーキテクチャにはrepmgr、pgBouncer、Nagios/Icingaなどの他のテクノロジーが含まれる可能性があります。

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

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

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

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

  1. pg_basebackup （ベースバックアップ操作の場合）とpg_receivewal （WALストリーミングの場合）の両方で使用されるストリーミングレプリケーション接続

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

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

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

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

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

シナリオ2：rsync /SSHによるバックアップ

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

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

  • 並列バックアップ

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

Scenario 2 - Backup via rsync/SSH

Scenario 2 - Backup via rsync/SSH

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

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

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

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

ステップ3でWALアーカイブを構成する代わりに、 Scenario 1: Backup via streaming protocol で説明されているようにWALストリーミングを構成できます。これにより、 archive_command の代わりにストリーミングレプリケーション接続が使用され、RPOが大幅に削減されます。

Scenario 1: Backup via streaming protocol と同様に、以下の図:raw-latex:`ref{scenario2b-design}`に示すように、WALストリーミングとWALアーカイブの両方を構成することもできます。