デザインとアーキテクチャー¶
Barmanをインストールする場所¶
Barmanの基礎の1つは、ネットワークを介してデータベースサーバーからリモートで操作する機能です。
理論的には、 BarmanサーバーをPostgreSQLサーバーから数千マイル離れた世界の別の場所に置くことができます。現実的には、 BarmanサーバーをPostgreSQLサーバーから離れすぎないようにして、バックアップとリカバリの両方の時間を制御します。
Barmanをセットアップする「フリーサイズ」の方法はありませんが、特に従うことをお勧めする推奨事項がいくつかあります。
専用サーバーにBarmanをインストール
PostgreSQLサーバーと同じストレージを共有しないでください
Barmanを監視インフラストラクチャ [1] と統合
実稼働に展開する前にすべてをテストします
ディザスター リカバリー アーキテクチャのモデル化を開始する合理的な方法は次のとおりです。
PostgreSQLおよびBarmanに関して、次のようないくつかの可能なアーキテクチャを設計します。
1.同じデータセンター
2.同じ大都市圏の別のデータセンター
3.別のデータセンター
各仮説の長所と短所を詳しく説明する
費用対効果分析により、システムの単一障害点（SPOF）を評価します
あなたの決定を下し、最初の解決策を実装する
そうは言っても、 Barmanの非常に一般的なセットアップは、PostgreSQLサーバーがあるのと同じデータセンターにインストールすることです。この場合、単一障害点はデータセンターです。幸いなことに、 Barmanが提供するバックアップ層の数を増やす2つの機能のおかげで、このようなSPOFの影響を軽減できます。
地理的な冗長性 （ 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によって最初に導入されたもう1つの関連機能は、マルチプルサーバーのサポートです。 Barmanは、バージョンが異なる場合でも、複数のPostgreSQLインスタンスからのバックアップデータを一元的に保存できます。 [^recver]
^recver は、セクション「リカバリーの要件」で詳しく説明されているように、リカバリーに適用されます。
その結果、複雑なディザスターリカバリーアーキテクチャをモデル化して、PostgreSQLサーバーが中央のBarmanサーバーを中心にローテーションする「スタースキーマ」を形成できます。
すべてのアーキテクチャには、独自の方法があります。実際の実験とテストに基づいて、あなたの共感を呼ぶものを選択してください。
これ以降、簡単にするために、このガイドでは基本的なアーキテクチャを前提としています。
1つのPostgreSQLインスタンス（ホスト名
pg）Barmanを備えた1つのバックアップサーバー（ホスト名
backup）
ストリーミングバックアップとrsync / SSH¶
従来、
Barmanは常にSSHを介してリモートで操作し、物理バックアップ操作にrsync
を利用していました。バージョン2.0では、 pg_basebackup
を介したバックアップ操作用のPostgreSQLのストリーミングレプリケーションプロトコルのネイティブサポートが導入されています。
これら2つの方法のいずれかを選択する必要があります。
一般的に、 Barman 2.0以降、PostgreSQL 9.4以降ではストリーミングレプリケーションのバックアップが推奨されます。さらに、テーブルスペースを利用しない場合、PostgreSQL 9.2からストリーミングバックアップを使用できます。
重要
Barmanは`pg_basebackup` を透過的に利用するため、増分バックアップ、並列バックアップ、重複排除、ネットワーク圧縮などの機能は現在使用できません。この場合、 rsync を介した従来の方法と比較して、帯域幅の制限にはいくつかの制限があります。
rsync
/SSHを介した従来のバックアップは、8.3以降のPostgreSQLのすべてのバージョンで使用できます。
pg_basebackup
の制限が発生するすべての場合（たとえば、増分バックアップと重複排除の恩恵を受けることができる非常に大規模なデータベース）。
ストリーミングバックアップをお勧めする理由は、私たちの経験に基づくと、従来のバックアップよりもセットアップが簡単だからです。また、ストリーミングバックアップを使用すると、 Windows [3] , でPostgreSQLサーバーをバックアップでき、Dockerでの作業が簡単になります。
標準アーカイブ、WALストリーミング…またはその両方¶
PostgreSQLのポイントインタイムリカバリでは、トランザクションログ（xlogまたはWALファイルとも呼ばれます）をベースバックアップと一緒に保存する必要があります。
伝統的に、 BarmanはPostgreSQLのarchive_command （通常はrsync
/SSHを介して、今は barman-cli パッケージのbarman-wal-archive
を介して）を介した標準のWALファイルシッピングをサポートしてきました。この方法では、PostgreSQLが新しいWALファイルに切り替えた場合にのみWALファイルがアーカイブされます。簡単にするために、これは通常16MB相当のデータ変更ごとに発生します。
Barman
1.6.0では、トランザクションログをアーカイブするための追加の方法として、
pg_receivewal （PostgreSQL 10より前はpg_receivexlog
としても知られています）を介したPostgreSQLサーバー9.2以降のWALファイルのストリーミングが導入されています。
WALストリーミングはデータ損失のリスクを減らし、RPOをゼロに近い値に下げることができます。
Barman 2.0では、PostgreSQLサーバー9.4以降でのレプリケーションスロットのサポートが導入されたため、WALストリーミングのみの構成が可能になりました。さらに、 BarmanをPostgreSQL 9.5（またはそれ以降）のクラスターに同期WALレシーバーとして追加し、 ゼロデータ損失 （RPO = 0）を達成できるようになりました。
場合によっては、やむを得ず、従来のアーカイブの使用を余儀なくされます。その他では、両方を使用するか、WALストリーミングのみを使用するかを選択できます。特別な理由がない限り、信頼性と堅牢性を最大限に高めるために、両方のチャネルを使用することをお勧めします。
バックアップの2つの一般的なシナリオ¶
作業を楽にするために、 Barmanの特定のPostgreSQLサーバーの最も一般的な2つのシナリオを以下にまとめます。
これは、 Barmanでバックアップすることを決定したすべてのサーバーに対して行う必要があることに注意してください。これは、同じインストール内で異種のセットアップを使用できることを意味します。
前述のように、PostgreSQLサーバー（pg
）とBarmanサーバー（backup
）のみについて考えます。ただし、実際には、アーキテクチャにはrepmgr、pgBouncer、Nagios/Icingaなどの他のテクノロジーが含まれる可能性があります。
シナリオ1：ストリーミングプロトコルを介したバックアップ¶
PostgreSQL 9.4以降を使用しており、データベースが一般的なユースケースシナリオに該当する場合、おそらくストリーミングバックアップインストールを決定することになります-以下の図: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環境に特に適しており、非常に実用的です。
ただし、前述のように、標準のアーカイブを構成して、より堅牢なアーキテクチャを実装することもできます。以下の図:raw-latex:`ref{scenario1b-design}`を参照してください。
この代替アプローチには以下が必要です。
PostgreSQLサーバーの
postgresユーザーがBarmanサーバーにbarmanユーザーとして接続できるようにする追加のSSH接続PostgreSQLの
archive_commandは、WALファイルをBarmanに出荷するように構成されています
このアーキテクチャは、テーブルスペースを使用しないPostgreSQL 9.2/9.3ユーザーも利用できます。
シナリオ2：rsync /SSHによるバックアップ¶
SSHを介したrsync
の従来のセットアップは、次の場合に使用できる唯一のオプションです。
PostgreSQLサーバーバージョン8.3、8.4、9.0または9.1
テーブルスペースを使用しているPostgreSQLサーバーバージョン9.2または9.3
増分バックアップ、並列バックアップ、および重複排除
バックアップ中のネットワーク圧縮
表領域ベースを含む、帯域幅使用量のより細かい制御
Scenario 2 - Backup via rsync/SSH¶
このシナリオでは、次を構成する必要があります。
1.管理、調整、および監視を目的としたPostgreSQLへの標準接続
Barmanサーバーの
barmanユーザーがPostgreSQLサーバーにpostgresユーザーとして接続できるようにするrsyncが使用するベースバックアップ操作用のSSH接続PostgreSQLの
archive_commandが使用し、PostgreSQLサーバーのpostgresユーザーがBarmanサーバーにbarmanユーザーとして接続できるWALアーカイブ用のSSH接続
PostgreSQL 9.2以降、WALストリーミングに使用されるストリーミングレプリケーション接続を追加して、RPOを大幅に削減できます。このより堅牢な実装を図:raw-latex:`ref{scenario2b-design}`に示します。
Backup via rsync/SSH with WAL streaming (Scenario 2b):raw-latex:label{scenario2b-design}¶
