Server commands¶
前のセクションで述べたように、サーバーコマンドはPostgreSQLサーバーまたはその領域で動作し、ステータスの確認、メンテナンスオペレーションの実行、バックアップ、 Barmanアーカイブの管理に役立ちます。
archive-wal¶
archive-wal
コマンドは、特定のサーバーのWALファイルに対してメンテナンス操作を実行します。この操作には、ストリーミング接続またはarchive_command
またはその両方から受信したWALファイルの処理が含まれます。
重要
archive-wal コマンドは、直接呼び出すことができますが、 cron 一般コマンドから起動するように設計されています。
backup¶
backup コマンドは、指定されたサーバーの完全バックアップ（base
backup）を取得します。新しいバックアップに対応する構成パラメーターをオーバーライドできるオプションがいくつかあります。詳細については、マニュアルページを参照してください。
次を使用して、特定のサーバーの完全バックアップを実行できます。
barman backup <server_name>
Tip
barman backup all を使用して、構成済みのすべてのサーバーを順次バックアップできます。
Tip
barman backup <server_1_name<server_2_name> を使用して、 <server_1_name> と`<server_2_name>` サーバーの両方を順次バックアップできます。
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のプラグインを簡単に作成できます。
generate-manifest¶
このコマンドは、バックアップがリモートで作成され、pg_basebackupが関与せず、backup_manifest
ファイルがバックアップに存在しない場合に役立ちます。
barmanサーバーのバックアップを使用して、backup_idからbackup_manifest
ファイルを生成します。ファイルが既に存在する場合、生成コマンドは中断されます。
コマンド例：
barman generate-manifest <server_name> <backup_id>
``` backup_id [backup idshortcuts]{#backup-id-shortcuts}のいずれかを使用できます。
このコマンドは、次のようにpost_backupフックスクリプトとして使用することもできます。
```bash
post_backup_script=barman generate-manifest ${BARMAN_SERVER} ${BARMAN_BACKUP_ID}
get-wal¶
Barmanでは、ユーザーがget-wal
コマンドを使用してWALアーカイブからxlogファイルを要求できます。
barman get-wal [-o OUTPUT_DIRECTORY]() <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 オプションを使用できます。
get-wal がrecovery_options
に設定されているが、リカバリー操作中には必要ない場合、 --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ファイルを取得できるピーク機能など、多くの便利なオプションがあります。これは、 PostgreSQL とBarman間の帯域幅使用を最適化する優れた方法です。
barman-wal-restore は、 barman-cli パッケージで利用できます。
これは、リモートリカバリのrestore_command の例です。
restore_command = barman-wal-restore -U barman backup SERVER %f %p
Barmanサーバーとの通信にSSHを使用するため、 postgres
ユーザーがバックアップサーバーにbarman
としてログインするにはSSHキー認証が必要です。
SSHのデフォルトの22以外のポートを使用する必要がある場合は、 --port
オプションを追加して、SSH接続に使用するポートを指定できます。
barman-wal-restore
がBarmanサーバーに接続できること、および必要なPostgreSQLサーバーがBarmanで次のコマンドでWALファイルを送信するように構成されていることを確認できます。
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 オプションを使用します。
rebuild-xlogdb¶
いつでも、特定のサーバー（または all
ショートカットを使用してすべてのサーバー）のWALアーカイブのコンテンツを再生成できます。
WALアーカイブはxlog.db ファイルに含まれており、
Barmanが管理するすべてのサーバーには独自のコピーがあります。
xlog.db ファイルは、 rebuild-xlogdb
コマンドでリビルドできます。これにより、アーカイブされたすべてのWALファイルがスキャンされ、アーカイブのメタデータが再生成されます。
例：
barman rebuild-xlogdb <server_name>
receive-wal¶
このコマンドは、ストリーミングプロトコルを使用してPostgreSQLストリーミング接続からWALファイルを受信するreceive-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¶
replication-status コマンドは、
Barmanサーバー（構成されている場合）のreceive-wal
プロセスを含む、現在PostgreSQLサーバーに接続されているストリーミングクライアントのステータスを報告します。
次のようにコマンドを実行できます。
barman replication-status <server_name>
Tip
サーバー名として all を使用して、すべてのサーバーのレプリカの完全なステータスレポートを要求できます。
機械可読な出力を得るには、 --minimal オプションを使用します。
show-servers¶
次のコマンドで、特定のサーバーの構成パラメーターを表示できます。
barman show-servers <server_name>
Tip
サーバー名として`all` を使用して完全な構成レポートを要求できます。
status¶
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¶
verify
コマンドは、バックアップからのbackup_manifestファイルを使用し、それに対してpg_verifybackup
を実行します。
edb_notranlate_17
このコマンドはpg_verifybackup <path_to_backup_manifest> -n
を呼び出します（PG>=13で使用可能） pg_verifybackup
バックアップサーバーにインストールする必要があります。
rsyncバックアップの場合、 generate-manifest コマンドで使用できます。
backup_id backup idshortcutsのいずれかを使用できます。
