Design and architecture¶
Barmanをインストールする場所¶
Barmanの基礎の1つは、ネットワークを介してデータベースサーバーからリモートで操作する機能です。
理論的には、 BarmanサーバーをPostgreSQLサーバーから数千マイル離れた世界の別の場所に置くことができます。現実的には、 BarmanサーバーをPostgreSQLサーバーから離れすぎないようにして、バックアップとリカバリの両方の時間を制御します。
Barmanをセットアップする「フリーサイズ」の方法はありませんが、特に従うことをお勧めする推奨事項がいくつかあります。
専用サーバーにBarmanをインストール
PostgreSQLサーバーと同じストレージを共有しないでください
Barmanを監視インフラストラクチャ[nagios] と統合
実稼働に展開する前にすべてをテストします
[nagios]:
Barmanの最も重要な機能の1つであり、真の命の恩人であるbarman check --nagios
コマンドのおかげで、Nagios / Icingaとの統合は簡単です。
ディザスター リカバリー アーキテクチャのモデル化を開始する合理的な方法は次のとおりです。
PostgreSQLおよびBarmanに関して、次のようないくつかの可能なアーキテクチャを設計します。
1.同じデータセンター
2.同じ大都市圏の別のデータセンター
3.異なるデータセンター
各仮説の長所と短所を詳しく説明する
費用対効果分析を使用して、システムの単一障害点（SPOF）を評価します
決定を下し、最初の解決策を実装する
そうは言っても、 Barmanの非常に一般的なセットアップは、PostgreSQLサーバーがあるのと同じデータセンターにインストールすることです。この場合、単一障害点はデータセンターです。幸いなことに、このようなSPOFの影響は、 Barmanが提供するバックアップ層の数を増やす2つの機能のおかげで軽減できます。
地理的な冗長性 （ Barman 2.6で導入）
フックスクリプト
地理的な冗長性を使用すると、別のデータセンター/アベイラビリティーゾーンにあるBarmanインスタンスを利用して、ソースBarmanサーバーのコンテンツ全体を同期できます。さらにあります： Barmanでは地理的冗長性をグローバルレベルだけでなくサーバーレベルでも構成できるため、一部のサーバーがローカルのPostgreSQLサーバーに直接接続され、他のサーバーがサブセットをバックアップするBarmanのハイブリッドインストールを作成できますさまざまなBarmanインストールの（クロスサイトバックアップ）。以下の図:raw-latex:`ref{georedundancy-design}`は、2つのアベイラビリティーゾーン（1つはヨーロッパに、もう1つは米国）を示しています。それぞれには、ローカルのBarmanインストールでバックアップされ、他のBarmanサーバーで中継されます（パッシブ）rsync / SSHを介した多層バックアップの場合。 geo冗長性の詳細については、特定のセクションを参照してください。
An example of architecture with geo-redundancy:raw-latex:label{georedundancy-design}¶
代わりにフックスクリプトのおかげで、 Barmanのバックアップは、tar
を介したテープ、またはAmazonクラウドのS3バケットなどのさまざまなメディアにエクスポートできます。
決定は永遠ではないことを忘れないでください。この方法で始めて、時間をかけて自分に最適なソリューションに適応できます。ただし、最初はシンプルに保つようにしてください。
1つのBarman、多くのPostgreSQLサーバー¶
Barmanによって最初に導入された別の関連機能は、マルチプルサーバーのサポートです。 Barmanは、バージョンが異なる場合でも、複数のPostgreSQLインスタンスからのバックアップデータを一元的に保存できます。 [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 [windows] でPostgreSQLサーバーをバックアップでき、Dockerでの作業が簡単になります。
[windows]: WindowsでのPostgreSQLサーバーのバックアップは可能ですが、まだ継続的インテグレーションシステムの一部ではないため、まだ実験的です。詳細については、「 Windowsベースのサーバーのセットアップ方法」を参照してください。
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ストリーミングのみを構成することをお勧めします。
注釈
Barmanの以前のバージョンは、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):raw-latex:label{scenario1-design}¶
このシナリオでは、次を構成する必要があります。
1.管理、調整、および監視を目的とした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):raw-latex:label{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¶
このシナリオでは、次を構成する必要があります。
1.管理、調整、および監視を目的としたPostgreSQLへの標準接続
Barmanサーバーの
barmanユーザーがPostgreSQLサーバーのpostgresユーザーとして接続できるようにするrsyncが使用するベースバックアップ操作用のSSH接続PostgreSQLの
archive_commandが使用し、PostgreSQLサーバーのpostgresユーザーがBarmanサーバーにbarmanユーザーとして接続できるWALアーカイブ用のSSH接続
ステップ3でWALアーカイブを構成する代わりに、 シナリオ1：ストリーミングプロトコルを介したバックアップ
で説明されているようにWALストリーミングを構成できます。これにより、
archive_command
の代わりにストリーミングレプリケーション接続が使用され、RPOが大幅に削減されます。
シナリオ1：ストリーミングプロトコルを介したバックアップ と同様に、以下の図:raw-latex:`ref{scenario2b-design}`に示すように、WALストリーミングとWALアーカイブの両方を構成することもできます。
Backup via rsync/SSH with WAL streaming (Scenario 2b):raw-latex:label{scenario2b-design}¶
