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インストールのクロスサイトバックアップ。以下の図:raw-latex:`ref{georedundancy-design}`は、2つのアベイラビリティーゾーン1つはヨーロッパに、もう1つは米国にあり、それぞれにプライマリPostgreSQLサーバーがあり、ローカルのBarmanインストールでバックアップされ、他のBarmanサーバーに中継されますpassive)、rsync / SSHを介した多層バックアップ用。地理的冗長性の詳細については、特定のセクションで入手できます。

An example of architecture with geo-redundancy { width=80% }

代わりにフックスクリプトのおかげで、 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のすべてのバージョンでストリーミングレプリケーションを使用することをお勧めします。

重要

Barmanは`pg_basebackup` を透過的に利用するため、インクリメンタル バックアップ、パラレル バックアップ、重複排除などの機能は、現在使用できません。この場合、帯域幅制限にはいくつかの制限があります-rsync を介した従来の方法と比較して。

pg_basebackup 制限が発生するすべての場合たとえば、インクリメンタル バックアップと重複排除のメリットが得られる非常に大規模なデータベースなど、rsync /SSHを使用したバックアップをお勧めします。

ストリーミングバックアップをお勧めする理由は、私たちの経験から、従来のバックアップよりもセットアップが簡単であるためです。また、ストリーミングバックアップでは、 Windows [^windows], で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ストリーミングのみを構成することをお勧めします。

注釈

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}`を参照してください。

Streaming-only backup (Scenario 1) { width=80% }

このシナリオでは、以下を構成する必要があります。

  1. 管理、調整、およびモニタリングを目的としたPostgreSQLへの標準接続

  2. 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) { width=80% }

SSHを介したWALアーカイブには以下が必要です。

  • PostgreSQLサーバーのpostgres ユーザーがBarmanサーバーのbarman ユーザーとして接続できる追加のSSH接続

  • PostgreSQLのarchive_command は、WALファイルをBarmanに出荷するように構成します

シナリオ2 rsync /SSHを介したバックアップ#

rsync /SSHバックアップインストールは、次の機能が必要な場合に必要です。

  • ファイルレベルのインクリメンタル バックアップ

  • パラレル バックアップ

  • テーブルスペースごとなど、帯域幅使用のより詳細な制御

Scenario 2 - Backup via rsync/SSH { width=80% }

このシナリオでは、以下を構成する必要があります。

  1. 管理、調整、およびモニタリングを目的としたPostgreSQLへの標準接続

  2. rsync が使用するベースバックアップ操作のためのSSH接続。これにより、 Barmanサーバーのbarman ユーザーはPostgreSQLサーバーのpostgres ユーザーとして接続できます。

  3. PostgreSQLのarchive_command が使用するWALアーカイブ用のSSH接続、これにより、PostgreSQLサーバーのpostgres ユーザーは、 Barmanサーバーのbarman ユーザーとして接続できます

手順3でWALアーカイブを構成する代わりに、 シナリオ1ストリーミングプロトコルを介したバックアップ の説明に従ってWALストリーミングを構成できます。これにより、archive_command の代わりにストリーミングレプリケーション接続が使用され、RPOが大幅に削減されます。 シナリオ1ストリーミングプロトコルを介したバックアップ と同様に、以下の図:raw-latex:`ref{scenario2b-design}`に示すように、WALストリーミングとWALアーカイブの両方を構成することもできます。

Backup via rsync/SSH with WAL streaming (Scenario 2b) { width=80% }