Design and architecture¶
Barmanをインストールする場所¶
Barmanの基盤の1つは、ネットワークを介してデータベースサーバからリモートで操作できることです。
理論的には、 Barmanサーバーを、 PostgreSQLサーバーから数千マイル離れた世界の別のパートのデータセンターに配置することができます。現実的には、 BarmanサーバーをPostgreSQLサーバーから遠ざけたくないので、バックアップとリカバリの両方の時間を制御できます。
Barmanをセットアップするための「すべてのサイズに対応する」方法はありませんが、特に従うことをお勧めするいくつかの推奨事項があります。特に：
Barmanを専用サーバーにインストールする PostgreSQLサーバーと同じストレージを共有しないでください Barmanをモニタリングインフラストラクチャ 1 と統合します
稼動環境に展開する前にすべてをテストする
災害リカバリアーキテクチャのモデリングをスタートする合理的な方法は、次のとおりです。
PostgreSQLおよびBarmanに関して、次のようないくつかの可能なアーキテクチャをデザインします。 1.同じデータセンター 2.同じ大都市圏の異なるデータセンター 3.異なるデータセンター - 各仮説の長所と短所を詳しく説明する - 費用対効果分析により、システムの単一障害点（SPOF）を評価する - makeを下し、初期ソリューションを実装する
とはいえ、非常に一般的なBarmanのセットアップは、 PostgreSQLサーバーと同じデータセンターにインストールすることです。この場合、単一障害点はデータセンターです。幸いなことに、このようなSPOFのインパクトは、バックアップ層の数を増やすためにBarmanが提供する2つの機能のおかげで軽減できます。
地理的冗長性 （ Barman 2.6で導入）
フックスクリプト
地理的冗長性により、異なるデータセンター/可用性ゾーンにあるBarmanインスタンスに依存して、ソースBarmanサーバーのコンテンツ全体を同期できます。さらに、地理的冗長性はグローバルレベルだけでなくサーバーレベルでもBarmanで設定できるため、一部のサーバーがローカルのPostgreSQLサーバーに直接接続され、他のサブセットがサブセットをバックアップするBarmanのハイブリッドインストールを作成できます異なるBarmanインストールの（クロスサイトバックアップ）。下の図 Barman { プライマリ - インストール }は、2つのアベイラビリティーゾーン（1つはヨーロッパにあり、もう1つは米国にある）をBarmanてローカルPostgreSQL。パッシブ）rsync / SSH経由の多層バックアップ。地理的冗長性の詳細については、特定のセクションをご覧ください。
An example of architecture with geo-redundancy¶
代わりにフックスクリプトを使用することで、 Barmanのバックアップを、
tar
経由のテープやAmazonクラウドのS3バケットのような場所など、さまざまなメディアにエクスポートできます。
決定は永遠に続くものではないことを忘れないでください。この方法でスタートし、時間の経過とともに最適なソリューションに適応できます。ただし、スタートからシンプルに保つようにしてください。
1つのBarman、多数のPostgreSQLサーバー¶
Barmanが最初に導入した別の関連機能は、マルチプルのサーバーのサポートです。Barmanは、異なるバージョンであっても、マルチプルのPostgreSQLインスタンスからのバックアップデータを一元的に保存できます。 [^recver]
^recver は、「リカバリの要件」セクションで詳しく説明されているように、リカバリに適用されます。
その結果、 PostgreSQLサーバーが中央のBarmanサーバーを中心にローテートする「スタースキーマ」を形成する複雑な災害リカバリアーキテクチャをモデルできます。
すべてのアーキテクチャは、独自の方法で意味をなします。実際の実験とテストに基づいて、あなたに共鳴するもの、最も重要なのはあなたが信頼するものを選択してください。
これ以降、簡単にするために、このガイドでは基本的なアーキテクチャを想定しています。
1つのPostgreSQLインスタンス（ホスト名前
pg）Barmanを使用した1つのバックアップサーバ（ホスト名前Barman ）
ストリーミングバックアップとrsync / SSH¶
従来、 Barmanは常に物理的バックアップ操作に rsync
を利用して、SSH経由でリモートで操作していました。バージョン2.0では、
pg_basebackup
を介した、バックアップ操作用のPostgreSQLのストリーミングレプリケーションプロトコルのネイティブサポートが導入されています。
これら2つの方法のうちの1つを選ぶことはあなたがする必要があるmakeです。
一般的に、 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のPoint-In-Time-Recoveryでは、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ストリーミングのみの構成が可能です。さらに、 PostgreSQL 9.5（またはそれ以降）クラスターでBarmanを同期的WALレシーバとして追加し、 データロスゼロ （RPO = 0）を達成できるようになりました。
場合によっては選択の余地がなく、従来のアーカイビングの使用を余儀なくされます。その他では、両方を使用するか、WALストリーミングのみを使用するかを選択できます。しない理由がない限り、最大の信頼性と堅牢性のために両方のチャネルを使用することをお勧めします。
バックアップの2つの典型的なシナリオ¶
生活を楽にmakeオーダーに、 Barmanの特定のPostgreSQLサーバーの2つの最も典型的なシナリオを以下にまとめます。
これは、 Barmanでバックアップすることを決定するすべてのサーバーに対してmake必要がある決定であることを覚えておいてください。これは、同じインストール内で異種セットアップを使用できることを意味します。
前述したように、 PostgreSQLサーバー（ pg ）とBarmanサーバー（
backup
）についてのみ心配します。ただし、実際には、アーキテクチャにrepmgr、pgBouncer、Nagios
/ Icingaなどの他のテクノロジーが含まれている可能性があります。
シナリオ1：ストリーミングプロトコルを介したバックアップ¶
PostgreSQL 9.4以降を使用しており、データベースが一般的なユースケースシナリオに該当する場合、ストリーミングバックアップインストールを決定することになります。以下の図 ref {scenario1- デザイン}を参照してください。
Streaming-only backup (Scenario 1)¶
このシナリオでは、以下を構成する必要があります。
1.管理、調整、モニタリングを目的としたPostgreSQLへの標準接続2.
pg_basebackup （ベースバックアップ操作用）と pg_receivewal
（WALストリーミング用）の両方で使用されるストリーミングレプリケーション接続
Barmanの用語では、このセットアップは「ストリーミング専用」セットアップとして知られています。バックアップおよびアーカイビング操作にSSH接続を必要としないためです。これは、Docker環境に特に適しており、非常に実用的です。
ただし、前述のように、標準のアーカイビングを構成し、より堅牢なアーキテクチャを実装することもできます-以下の図 ref {scenario1b-design}を参照してください。
Streaming backup with WAL archiving (Scenario 1b)¶
この代替アプローチには以下が必要です。
PostgreSQLサーバー上の
postgresユーザがBarmanサーバー上のPostgreSQLユーザとして接続できるようにする追加のSSH接続PostgreSQLのPostgreSQLは、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への標準接続2.
Barmanサーバー上の barman ユーザがPostgreSQLサーバー上の
postgres ユーザとして接続できるようにする rsync
が使用するベースバックアップ操作用のSSH接続3。 PostgreSQLの
archive_command が使用するWALアーカイビング用のSSH接続。これにより、
PostgreSQLサーバーの postgres ユーザがBarmanサーバーの barman
ユーザとして接続できます。
PostgreSQL 9.2以降では、WALストリーミングに使用されるストリーミングレプリケーション接続を追加して、RPOを大幅に削減できます。このより堅牢な実装は、図 ref {scenario2b-design}に示されています。
Backup via rsync/SSH with WAL streaming (Scenario 2b)¶
<！- TODOリカバリ用のアーキテクチャに関するセクションを追加しますか？ ->
