Serverコマンド#
前のセクションで述べたように、サーバーコマンドはPostgreSQLサーバーまたはBarmanのその領域で直接動作し、そのステータスの確認、メンテナンス操作の実行、バックアップの作成、およびWALアーカイブの管理に役立ちます。
archive-wal#
archive-wal
コマンドは、特定のサーバーのWALファイルに対してメンテナンス操作を実行します。この操作には、ストリーミング接続またはarchive_command
またはその両方から受信したWALファイルの処理が含まれます。
重要
archive-wal コマンドは、直接呼び出すことができますが、 cron 汎用コマンドから開始されるように設計されています。
バックアップ#
backup
コマンドは、指定されたサーバーの完全なバックアップ_basebackup_を取得します。新しいバックアップに対応する構成パラメーターをオーバーライドできる複数のオプションがあります。詳細については、マニュアルページを参照してください。
次の使用で、特定のサーバーの完全なバックアップを実行できます。
barman backup <server_name>
Tip
barman backup all を使用して、構成済みのすべてのサーバーを順次バックアップできます。
Tip
barman backup <server_1_name> <server_2_name> を使用して、<server_1_name> および`<server_2_name>` サーバーの両方をシークエンシャルにバックアップできます。
Barmanでインクリメンタルバックアップを取る方法については、incrementalbackupsectionを確認してください。
Barman 2.10では、 backup コマンドの-w /--wait
オプションを導入しました。設定されると、
Barmanはバックアップの状態を一時的にWAITING_FOR_WALS
に保存し、必要なすべてのWALファイルがアーカイブされるのを待ってから、状態をDONE
に設定し、バックアップ後フックスクリプトを続行します。
--wait-timeout オプションが提供される場合、
Barmanは指定された秒数の後にWALファイルの待機を停止し、状態はWAITING_FOR_WALS
のままになります。 cron
コマンドは、不足しているWALファイルがアーカイブされていることを確認し続け、バックアップにDONE
としてラベル付けします。
check#
check
コマンドを使用して、特定のサーバーへの接続と構成の一貫性を確認できます。
barman check <server_name>
Tip
barman check all を使用して、構成されているすべてのサーバーを確認できます。
重要
check コマンドは、おそらくBarmanが実装する最も重要な機能です。アラートおよび監視インフラストラクチャと統合することをお勧めします。 --nagios オプションを使用すると、Nagios / Icingaのプラグインを簡単に作成できます。
config-update#
config-update コマンドは、
Barmanでサーバーとモデルの構成を作成または更新するために使用されます
config-update コマンドを実行する構文は次のとおりです。
barman config-update <json_changes>
json_changes
は、ドキュメントの配列を含むJSON文字列である必要があります。各ドキュメントには、次のキーが含まれている必要があります。
scopeBarmanサーバーまたはBarmanモデルを作成または更新するかに応じて、serverまたはmodelのいずれか。
また、 `scope
`の値に応じて、次のキーのいずれかが含まれる必要があります。
server_namescopeがserverの場合、このキーにBarmanサーバー名を入力する必要があります。model_namescopeがmodelの場合、このキーにBarmanモデル名を入力する必要があります。
これらに加えて、各ドキュメントに1つ以上のBarman構成オプションとそれらの目的の値を入力する必要があります。
これは、 Barmanサーバー my_server をarchiver=on
およびstreaming_archiver=off で更新する例です。
barman config-update \
‘[{“scope”: “server”, “server_name”: “my_server”, “archiver”: “on”, “streaming_archiver”: “off”}]’
注意
barman config-updateコマンドは、barman_homeの下に作成される.barman.auto.confという名前のファイルに構成オプションを書き込みます。その構成ファイルはより優先され、 Barmanグローバル構成ファイル通常は/etc/barman.confからの値と、configuration_files_directoryごとにインクルードファイル通常は/etc/barman.dのファイルからの値をオーバーライドします。後で、何らかの理由で、これらのファイルの構成オプションを手動で変更することにした場合は、そのことに注意してください。
config-switch#
config-switch
コマンドは、モデルを介して定義された構成オーバーライドのセットをBarmanサーバーに適用するために使用されます。
Barmanサーバーの最終構成は、サーバーの構成と選択したモデルによって適用されたオーバーライドで構成されます。モデルはクラスター環境で特に役立つため、たとえば、フェールオーバーイベントに応答して使用できるさまざまな構成モデルを作成できます。
config-switch コマンドを介してモデルを適用する構文は次のとおりです。
barman config-switch <server_name> <model_name>
注意 コマンドは
<model_name>が存在し、<server_name>と同じclusterに属している場合にのみ成功します。注 一度にアクティブにできるモデルは1つだけです。異なるモデルでコマンドを2回実行した場合、最後に定義されたオーバーライドのみが適用されます。
サーバーの既存のアクティブモデルを適用解除するための構文は次のとおりです。
barman config-switch <server_name> --reset
これは、アクティブなモデルによって以前に設定されていたオーバーライドの適用解除を処理します。
注 このコマンドは、特定の状況からの復旧にも役立ちます。以前に構成されたが、構成に存在しないアクティブなモデルを使用するサーバーがある場合。
generate-manifest#
このコマンドは、バックアップがリモートで作成され、
pg_basebackupが関係せず、backup_manifest
ファイルがバックアップに存在しない場合に役立ちます。
barmanサーバーのバックアップを使用して、backup_idからbackup_manifest
ファイルを生成します。ファイルが既に存在する場合、generateコマンドは中止されます。
コマンドの例
barman generate-manifest <server_name> <backup_id>
backup_id backup id stablesのいずれかが使用できます。
このコマンドは、次のようにpost_backupフックスクリプトとして使用することもできます。
post_backup_script=barman generate-manifest ${BARMAN_SERVER} ${BARMAN_BACKUP_ID}
get-wal#
Barmanでは、ユーザーがget-wal
コマンドを介してWALアーカイブから_xlog_ファイルを要求できます。
barman get-wal [-o OUTPUT_DIRECTORY][-j|-x] <server_name> <wal_id>
要求されたWALファイルがサーバーアーカイブで見つかった場合、特に指定しない限り、非圧縮コンテンツはSTDOUT
に返されます。
get-wal コマンドでは、次のオプションが使用できます。
-oを使用すると、ユーザーはBarmanが要求されたWALファイルをデポジットする宛先ディレクトリを指定できます-jは、bzip2アルゴリズムを使用して出力を圧縮します-xは、gzipアルゴリズムを使用して出力を圧縮します-p SIZEは、要求されたファイルから開始して、アーカイブからWALファイルまでをピークます
リカバリオペレーション中にget-wal を使用し、
Barmanサーバーをサーバーの_WALハブ_に変換することが可能です。これは、
get-wal 値をrecovery_options
グローバル/サーバー構成オプションに追加することにより、自動的に達成できます。
recovery_options = get-wal
recovery_options
は、コンマ区切り値のリストを受け入れるグローバル/サーバーオプションです。リカバリオペレーション中にキーワードget-wal
が存在する場合、 Barmanはrestore_command
を設定してリカバリ構成を準備し、barman get-wal
が必要なWALファイルを取得するために使用されるようにします。同様に、実行時にrecover
コマンドの--get-wal オプションを使用できます。
recovery_options でget-wal
が設定されているが、リカバリオペレーション中に必要ない場合、
--no-get-wal オプションをrecover
コマンドとともに使用して、get-wal
リカバリオプションを無効にできます。
これは、ローカルリカバリのrestore_command の例です。
restore_command = sudo -u barman barman get-wal SERVER %f > %p
get-wal コマンドは、常にbarman
ユーザーとして呼び出す必要があること、およびカタログからWALファイルを読み取るには正しい権限が必要であることに注意してください。これが、この例でsudo -u barman
を使用する理由です。
リモートリカバリーにrecovery_options からget-wal
を設定すると、代わりにbarman-wal-restore
スクリプトを使用してrestore_command が生成されます。
barman-wal-restore
は、SSH接続エラーを管理する、より復元力の高いシェルスクリプトです。
このスクリプトには、WALファイルの自動圧縮および解凍や、PostgreSQLがいずれかのWALファイルを適用しているときに次のWALファイルを取得できる_peek_機能など、多くの便利なオプションが含まれています。これは、 PostgreSQLとBarman間の帯域幅の使用を最適化する優れた方法です。
barman-wal-restore は、 barman-cli パッケージで入手できます。
これは、リモートリカバリのrestore_command の例です。
restore_command = barman-wal-restore -U barman backup SERVER %f %p
SSHを使用してBarmanサーバーと通信するため、 postgres
ユーザーがバックアップサーバーにbarman
としてログインするには、SSHキー認証が必要です。
SSHデフォルトの22以外のポートを使用する必要がある場合は、 --port
オプションを追加して、SSH接続に使用するポートを指定できます。
barman-wal-restore
がBarmanサーバーに接続できること、および必要なPostgreSQLサーバーが次のコマンドでWALファイルを送信するようにBarmanで構成されていることを確認できます。
barman-wal-restore --test backup pg DUMMY DUMMY
backup はBarmanがインストールされているホストであり、pg
はBarmanで構成されたPostgreSQLサーバーの名前であり、DUMMYはプレースホルダーです。barman-wal-restore
には、WALファイル名と宛先ディレクトリの2つの引数が必要ですが、これらは無視されます。
すべてが正しく構成されている場合、次の出力が表示されるはずです。
Ready to retrieve WAL files from the server pg
barman-wal-restore
コマンドの詳細については、PostgreSQLサーバーでman barman-wal-restore
と入力してください。
list-backups#
次の使用で、特定のサーバーで使用可能なバックアップのカタログをリストできます。
barman list-backups <server_name>
Tip
サーバー名として`all` を使用して、すべてのサーバーのバックアップの完全なリストを要求できます。
機械読み取り可能な出力を取得するには、 --minimal
オプションを使用できます。JSON形式で出力を取得するには、
--format=json オプションを使用できます。
resume-xlogdb#
all
ショートカットを使用して、特定のサーバーまたはすべてのサーバーのWALアーカイブのコンテンツをいつでも再生成できます。
WALアーカイブはxlog.db ファイルに含まれており、
Barmanによって管理されるすべてのサーバーには独自のコピーがあります。
xlog.db ファイルは、 rebuild-xlogdb
コマンドでリビルドできます。これにより、アーカイブされたすべてのWALファイルがスキャンされ、アーカイブのメタデータが再生成されます。
例
barman rebuild-xlogdb <server_name>
resume-wal#
このコマンドは、ストリーミングプロトコルを使用してPostgreSQLストリーミング接続からWALファイルを受信するreceive-wal
プロセスを管理します。
レシーブウォールプロセス管理#
オプションを指定せずにコマンドを実行すると、receive-wal
プロセスが開始されます。このコマンドは、 pg_receivewal
PostgreSQLコマンドに基づいています。
barman receive-wal <server_name>
注釈
receive-wal コマンドはフォアグラウンドプロセスです。
--stop
オプションを使用してコマンドを実行すると、現在実行中のreceive-wal
プロセスが停止されます。
receive-wal
プロセスは、ステータスファイルを使用して、トランザクションログの最後に書き込まれたレコードを追跡します。ステータスファイルをクリーニングする必要がある場合、
--reset オプションを使用できます。
重要
レプリケーションスロットを使用していない場合は、 wal_keep_segments またはPostgreSQLバージョン13.0以降では`wal_keep_size` の値に依存します。データベースのワークロードの高いピークでは、receive-wal プロセスが遅延し、非同期になる場合があることに注意してください。予防措置として、 Barmanでは現在、ユーザーが`--reset` オプションを使用してコマンドを手動で実行して、誤った仮定を避けることを必要としています。
レプリケーションスロット管理#
receive-wal プロセスは、
BarmanがWALアーカイブ手順に必要なレプリケーションスロットを作成またはドロップするのにも役立ちます。
--create-slot オプションを使用すると、slot_name
構成オプションの後に名前付けられたレプリケーションスロットがPostgreSQLサーバーに作成されます。
--drop-slot では、以前のレプリケーションスロットが削除されます。
レプリケーションステータス#
replication-status コマンドは、
Barmanサーバー構成されている場合のreceive-wal
プロセスを含む、PostgreSQLサーバーに現在接続されているストリーミングクライアントのステータスを報告します。
次のようにコマンドを実行できます。
barman replication-status <server_name>
Tip
サーバー名として`all` を使用して、すべてのサーバーのレプリカの完全なステータスレポートを要求できます。
機械可読な出力を得るには、 --minimal オプションを使用できます。
show-servers#
次の使用で、特定のサーバーの構成パラメーターを表示できます。
barman show-servers <server_name>
Tip
サーバー名として`all` を使用して、完全な構成レポートを要求できます。
ステータス#
status コマンドは、PostgreSQLサーバーまたはサーバー名としてall
を使用する場合はすべてのサーバーのライブ情報とステータスを表示します。
barman status <server_name>
switch-wal#
このコマンドは、 PostgreSQLサーバーを別のトランザクションログファイルWALに切り替え、現在のログファイルを閉じ、受信、アーカイブできるようにします。
barman switch-wal <server_name>
最後のトランザクションログファイルのスイッチ以降、トランザクションアクティビティが存在しない場合、
--force オプションを使用してスイッチを強制する必要があります。
--archive
オプションは、xlogスイッチの後にWALアーカイブをトリガーするようにBarmanに要求します。デフォルトでは、30秒のタイムアウトが適用されますこれは--archive-timeout
で変更できます。 WALファイルを受信しない場合、エラーが返されます。
注釈
Barman 2.1および2.2では、このコマンドは`switch-xlog` と呼ばれていました。 PostgreSQL 10以降との名前付けの一貫性のために名前が変更されました。
verify-backup#
verify-backup
コマンドは、バックアップからbackup_manifestファイルを使用し、それに対してpg_verifybackup
を実行します。
barman verify-backup <server_name> <backup_id>
このコマンドは、 pg_verifybackup <path_to_backup_manifest> -n
PG>=13で使用可能 pg_verifybackup
バックアップサーバーにインストールする必要があります。
rsyncバックアップの場合、 generate-manifest コマンドで使用できます。
backup_id backup id stablesのいずれかが使用できます。