デザインとアーキテクチャ ======================== Barmanをインストールする場所 ---------------------------- Barmanの基礎の1つは、ネットワークを介してデータベースサーバーからリモートで操作できる機能です。 理論的には、 BarmanサーバーをPostgreSQLサーバーから数千マイル離れた世界の別の地域のデータセンターに配置することができます。現実的には、バックアップとリカバリー時間の両方を制御できるように、 BarmanサーバーをPostgreSQLサーバーから遠すぎないようにします。 Barmanをセットアップするための\_“フリーサイズ”\_方法はありませんが、特に従うことをお勧めする推奨事項がいくつかあります。 - 専用サーバーにBarmanをインストールする - PostgreSQLサーバーと同じストレージを共有しないでください - Barmanをモニタリングインフラストラクチャと統合します[^nagios] - 運用環境に展開する前にすべてをテスト [^nagios] Nagios/Icingaとの統合は、 Barmanの最も重要な機能の1つであり真の救世主である\ ``barman check --nagios`` コマンドのおかげで簡単です。 ディザスターリカバリーアーキテクチャのモデリングを開始する合理的な方法は、次のことです。 - PostgreSQLとBarmanに関して、いくつかの可能なアーキテクチャをデザインします。 1. 同じデータセンターre 2. 同じ首都圏の異なるデータセンター 3. 異なるデータセンター - 各仮説の長所と短所を詳しく説明します - 費用対効果分析を使用して、システムの単一障害点SPOFを評価します - 決定を下し、最初のソリューションを実装します そうは言っても、 Barmanの非常に一般的なセットアップは、PostgreSQLサーバーが存在するのと同じデータセンターにインストールされることです。この場合、単一障害点はデータセンターです。幸いなことに、このようなSPOFの影響は、バックアップ層の数を増やすためにBarmanが提供する2つの機能のおかげで、緩和できます。 1. **地理的冗長性** Barman 2.6で導入 2. **フックスクリプト** *地理的冗長性_を使用すると、別のデータセンター/アベイラビリティーゾーンにあるBarmanインスタンスを依存して、ソースBarmanサーバーのコンテンツ全体を同期できます。さらにありますBarmanの_ハイブリッドインストール_を作成できます。さまざまなBarmanインストールの_クロスサイトバックアップ*\ 。以下の図:raw-latex:`\ref{georedundancy-design}`は、2つのアベイラビリティーゾーン1つはヨーロッパに、もう1つは米国にあり、それぞれにプライマリPostgreSQLサーバーがあり、ローカルのBarmanインストールでバックアップされ、他のBarmanサーバーに中継されます_passive\_)、rsync / SSHを介した多層バックアップ用。地理的冗長性の詳細については、特定のセクションで入手できます。 .. figure:: /images/barman-architecture-georedundancy.png :width: 70% :alt: An example of architecture with geo-redundancy An example of architecture with geo-redundancy 代わりに_hook scripts_のおかげで、 Barmanのバックアップを\ ``tar`` を介した_tape_などのさまざまなメディア、またはAmazonクラウドの_S3バケット_のような場所にエクスポートできます。 どのような決定も永遠ではないことに注意してください。この方法で開始し、時間の経過とともに自分に最適なソリューションに適応できます。ただし、最初はシンプルにするようにしてください。 1つのBarman、多数のPostgreSQLサーバー ------------------------------------- Barmanによって最初に導入されたもう1つの関連機能は、マルチプルサーバーのサポートです。 Barmanは、バージョンが異なる場合でも、複数のPostgreSQLインスタンスからのバックアップデータを一元化した方法で保存できます。 [^recver] [^recver] \_「リカバリの要件」\_セクションで詳細に説明しているように、同じ[PostgreSQLのPITRの要件][requirements_recovery]がリカバリに適用されます。 その結果、複雑なディザスターリカバリーアーキテクチャをモデル化し、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[^windows]でPostgreSQLサーバーをバックアップでき、Dockerを使用する際に作業が簡単になります。 [^windows] WindowsでのPostgreSQLサーバーのバックアップは可能ですが、継続的インテグレーションシステムの一部ではないため、まだ実験的です。詳細については、セクション\_” Windowsベースのサーバーをセットアップする方法”\_を参照してください。 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ファイルに_switches_した場合にのみ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-latex:`\ref{scenario1-design}`を参照してください。 .. raw:: html .. figure:: /images/barman-architecture-scenario1.png :width: 70% :alt: Streaming-only backup (Scenario 1) Streaming-only backup (Scenario 1) このシナリオでは、以下を構成する必要があります。 1. 管理、調整、およびモニタリングを目的としたPostgreSQLへの標準接続 2. ``pg_basebackup`` ベースバックアップ操作の場合と\ ``pg_receivewal`` WALストリーミングの場合の両方で使用されるストリーミングレプリケーション接続 Barmanの用語では、このセットアップは、バックアップおよびアーカイブ操作にSSH接続を使用しないため、 **ストリーミング専用** セットアップとして知られています。これは、Docker環境に特に適しており、非常に実用的です。 :ref:`Barman WALアーカイブ ` で説明したように、WALストリーミングに加えて、SSHを介してWALアーカイブを構成できます。以下の図:raw-latex:`\ref{scenario1b-design}`を参照してください。 .. figure:: /images/barman-architecture-scenario1b.png :width: 70% :alt: Streaming backup with WAL archiving (Scenario 1b) Streaming backup with WAL archiving (Scenario 1b) SSHを介したWALアーカイブには以下が必要です。 - PostgreSQLサーバーの\ ``postgres`` ユーザーがBarmanサーバーの\ ``barman`` ユーザーとして接続できる追加のSSH接続 - PostgreSQLの\ ``archive_command`` は、WALファイルをBarmanに出荷するように構成します シナリオ2 ``rsync`` /SSHを介したバックアップ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``rsync`` /SSHバックアップインストールは、次の機能が必要な場合に必要です。 - ファイルレベルのインクリメンタル バックアップ - パラレル バックアップ - テーブルスペースごとなど、帯域幅使用のより詳細な制御 .. figure:: /images/barman-architecture-scenario2.png :width: 70% :alt: Scenario 2 - Backup via 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ストリーミングプロトコルを介したバックアップ>` と同様に、以下の図:raw-latex:`\ref{scenario2b-design}`に示すように、WALストリーミングとWALアーカイブの両方を構成することもできます。 .. figure:: /images/barman-architecture-scenario2b.png :width: 70% :alt: Backup via rsync/SSH with WAL streaming (Scenario 2b) Backup via rsync/SSH with WAL streaming (Scenario 2b) .. raw:: html