Design and architecture ======================= Barmanをインストールする場所 ---------------------------- Barmanの基礎の1つは、ネットワークを介してデータベースサーバーからリモートで操作できる機能です。 理論的には、 BarmanサーバーをPostgreSQLサーバーから数千マイル離れた世界の別の地域のデータセンターに配置することができます。現実的には、バックアップとリカバリー時間の両方を制御できるように、 BarmanサーバーをPostgreSQLサーバーから遠すぎないようにします。 Barmanをセットアップするための「フリーサイズ」の方法はありませんが、特に従うことをお勧めする推奨事項がいくつかあります。 - 専用サーバーにBarmanをインストールする - PostgreSQLサーバーと同じストレージを共有しないでください - Barmanを監視インフラストラクチャと統合します [1]_ - 運用環境に展開する前にすべてをテスト ディザスターリカバリーアーキテクチャのモデリングを開始する合理的な方法は、次のことです。 - PostgreSQLとBarmanに関して、いくつかの可能なアーキテクチャをデザインします。 1. 同じデータセンターre 2. 同じ首都圏の異なるデータセンター 3. 異なるデータセンター - 各仮説の長所と短所を詳しく説明します - 費用対効果分析を使用して、システムの単一障害点SPOFを評価します - 決定を下し、最初のソリューションを実装します そうは言っても、 Barmanの非常に一般的なセットアップは、PostgreSQLサーバーが存在するのと同じデータセンターにインストールされることです。この場合、単一障害点はデータセンターです。幸いなことに、このようなSPOFの影響は、バックアップ層の数を増やすためにBarmanが提供する2つの機能のおかげで、緩和できます。 1. **地理的冗長性** Barman 2.6で導入 2. **フックスクリプト** 地理的な冗長性を使用すると、別のデータセンター/アベイラビリティーゾーンにあるBarmanインスタンスを依存して、ソースBarmanサーバーのコンテンツ全体を同期できます。さらにありますBarmanで地理的冗長性をグローバルレベルだけでなくサーバーレベルでも構成できることを考えると、一部のサーバーがローカルのPostgreSQLサーバーに直接接続し、他のサーバーがサブセットをバックアップするBarmanのハイブリッドインストールを作成できます。さまざまなBarmanインストールのクロスサイトバックアップ。以下の図は、2つのアベイラビリティーゾーン1つはヨーロッパに、もう1つは米国にあり、それぞれにプライマリPostgreSQLサーバーがあり、ローカルのBarmanインストールでバックアップされ、他のBarmanサーバーに中継されますpassive)、rsync / SSHを介した多層バックアップ用。地理的冗長性の詳細については、特定のセクションで入手できます。 |An example of architecture with geo-redundancy| 代わりにフックスクリプトのおかげで、 Barmanのバックアップは、\ ``tar`` を介したテープなどのさまざまなメディア、またはAmazonクラウドのS3バケットのような場所にエクスポートできます。 どのような決定も永遠ではないことに注意してください。この方法で開始し、時間の経過とともに自分に最適なソリューションに適応できます。ただし、最初はシンプルにするようにしてください。 1つのBarman、多数のPostgreSQLサーバー ------------------------------------- Barmanによって最初に導入されたもう1つの関連機能は、マルチプルサーバーのサポートです。 Barmanは、バージョンが異なる場合でも、複数のPostgreSQLインスタンスからのバックアップデータを一元化した方法で保存できます。 [^recver] \` `^recver `_ リカバリーの要件」セクションで詳細を参照して、リカバリーに適用します。 その結果、複雑なディザスターリカバリーアーキテクチャをモデル化し、PostgreSQLサーバーが中央のBarmanサーバーを中心にローテーションする「スタースキーマ」を形成できます。 すべてのアーキテクチャは、独自の方法で意味があります。実際の実験とテストに基づいて、自分に共鳴するもの、そして最も重要なことに、信頼できるものを選択してください。 これ以降、簡単にするために、このガイドでは基本的なアーキテクチャを前提とします。 - 1つのPostgreSQLインスタンスホスト名\ ``pg`` - Barmanホスト名\ ``backup`` を使用した1つのバックアップサーバー ストリーミングバックアップとrsync / SSH --------------------------------------- Barmanは、トランスポートメカニズムとしてSSHを使用するRsync、またはPostgreSQLのストリーミングレプリケーションプロトコルを使用する\ ``pg_basebackup`` を使用してバックアップを取得できます。 これら2つの方法のいずれかを選択することは、決定する必要がありますが、一般的な使用のために、現在サポートされているPostgreSQLのすべてのバージョンでストリーミングレプリケーションを使用することをお勧めします。 .. IMPORTANT:: Barmanは`pg_basebackup` を透過的に利用するため、インクリメンタル バックアップ、パラレル バックアップ、重複排除などの機能は、現在使用できません。この場合、帯域幅制限にはいくつかの制限があります-`rsync` を介した従来の方法と比較して。 ``pg_basebackup`` 制限が発生するすべての場合たとえば、インクリメンタル バックアップと重複排除のメリットが得られる非常に大規模なデータベースなど、\ ``rsync`` /SSHを使用したバックアップをお勧めします。 ストリーミングバックアップをお勧めする理由は、私たちの経験から、従来のバックアップよりもセットアップが簡単であるためです。また、ストリーミングバックアップでは、 Windows [2]_ , でPostgreSQLサーバーをバックアップでき、Dockerを使用する際に作業が簡単になります。 Barman WALアーカイブ -------------------- PostgreSQLバックアップの回復は、トランザクションログxlogまたはWALファイルとしても知られるを再生することに依存しています。したがって、WALファイルはベースバックアップとともにBarmanによって保存され、復旧時に使用できるようにすることが重要です。これは、WALストリーミングまたは標準のWALアーカイブを使用して、WALをBarmanのWALアーカイブにコピーすることで実現できます。 WALストリーミングには、レプリケーションスロットを使用して\ ``pg_receivewal`` を使用してPostgreSQLサーバーからWALファイルをストリーミングすることが含まれます。 WALストリーミングは、データ損失のリスクを削減し、RPOをゼロ値に近い値に下げることができます。 PostgreSQLクラスターの同期WALレシーバーとしてBarmanを追加し、 **ゼロデータ損失** 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ストリーミングのみを構成することをお勧めします。 .. NOTE:: 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:: html |Streaming-only backup (Scenario 1)| このシナリオでは、以下を構成する必要があります。 1. 管理、調整、およびモニタリングを目的としたPostgreSQLへの標準接続 2. ``pg_basebackup`` ベースバックアップ操作の場合と\ ``pg_receivewal`` WALストリーミングの場合の両方で使用されるストリーミングレプリケーション接続 Barmanの用語では、このセットアップは、バックアップおよびアーカイブ操作にSSH接続を使用しないため、 **ストリーミング専用** セットアップとして知られています。これは、Docker環境に特に適しており、非常に実用的です。 :ref:`Barman WALアーカイブ ` で説明したように、WALストリーミングに加えて、SSHを介してWALアーカイブを構成できます。以下の図を参照してください。 |Streaming backup with WAL archiving (Scenario 1b)| 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への標準接続 2. ``rsync`` が使用するベースバックアップ操作のためのSSH接続。これにより、 Barmanサーバーの\ ``barman`` ユーザーはPostgreSQLサーバーの\ ``postgres`` ユーザーとして接続できます。 3. PostgreSQLの\ ``archive_command`` が使用するWALアーカイブ用のSSH接続、これにより、PostgreSQLサーバーの\ ``postgres`` ユーザーは、 Barmanサーバーの\ ``barman`` ユーザーとして接続できます 手順3でWALアーカイブを構成する代わりに、 :ref:`シナリオ1ストリーミングプロトコルを介したバックアップ <シナリオ1ストリーミングプロトコルを介したバックアップ>` の説明に従ってWALストリーミングを構成できます。これにより、\ ``archive_command`` の代わりにストリーミングレプリケーション接続が使用され、RPOが大幅に削減されます。 :ref:`シナリオ1ストリーミングプロトコルを介したバックアップ <シナリオ1ストリーミングプロトコルを介したバックアップ>` と同様に、以下の図に示すように、WALストリーミングとWALアーカイブの両方を構成することもできます。 |Backup via rsync/SSH with WAL streaming (Scenario 2b)| .. [1] Nagios/Icingaとの統合は、 Barmanの最も重要な機能の1つであり、真の救世主である\ \ ``barman check --nagios`` コマンドのおかげで簡単です。 .. [2] WindowsでのPostgreSQLサーバーのバックアップは可能ですが、継続的インテグレーションシステムの一部ではないため、まだ実験的です。詳細については、「 Windowsベースのサーバーをセットアップする方法」セクションを参照してください。 .. |An example of architecture with geo-redundancy| image:: /images/barman-architecture-georedundancy.png :width: 70% .. |Streaming-only backup (Scenario 1)| image:: /images/barman-architecture-scenario1.png :width: 70% .. |Streaming backup with WAL archiving (Scenario 1b)| image:: /images/barman-architecture-scenario1b.png :width: 70% .. |Scenario 2 - Backup via rsync/SSH| image:: /images/barman-architecture-scenario2.png :width: 70% .. |Backup via rsync/SSH with WAL streaming (Scenario 2b)| image:: /images/barman-architecture-scenario2b.png :width: 70%