すべてのpostgresqlサーバーをバックアップするために専用サーバーにbarmanをインストールしました。サーバーの1つが100Gbスペースを使用しており、命令barman backup myserver
には23時間かかります。長すぎると思いますが、基準点がありません。それは一般的ですか?そのような状況を改善するために私は何を調査する必要がありますか?サーバーをストリーミングするための設定は次のとおりです
; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Backup settings (via pg_basebackup)
; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
backup_method = postgres
;streaming_backup_name = barman_streaming_backup
; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; WAL streaming settings (via pg_receivexlog)
; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
streaming_archiver = on
slot_name = barman
;streaming_archiver_name = barman_receive_wal
;streaming_archiver_batch_size = 50
minimum_redundancy = 3
last_backup_maximum_age = '3 DAYS'
retention_policy = 'RECOVERY WINDOW OF 16 DAYS'
あなたはおそらくネットワーク帯域幅が制限されている範囲にいます。報告された23時間に対して9時間かかりますが、それはオーバーヘッド、非効率、または競合するネットワーク使用によって説明される可能性があります。
ネットワーク圧縮をオンにしてみることができます。これには、バックアップ方法を変更する必要があります。そのため、「ssh_command」を構成する必要があります。
ssh_command=ssh [email protected]
backup_method = rsync
network_compression=true
もちろん、これにより、サーバーが圧縮を行うためにサーバーにCPUオーバーヘッドが発生します。
Streaming_archiveの代わりにsshを使用するシナリオの方が優れており、バックアップ時間は2時間未満で、圧縮により必要なスペースが3分の1に減少します。これが私が使用した設定です:
ssh_command = ssh postgres@conn_Host
conninfo = Host=conn_Host user=conn_user dbname=conn_db
backup_method = rsync
reuse_backup = link
archiver = on
network_compression = true
minimum_redundancy = 3
last_backup_maximum_age = '3 DAYS'
retention_policy = 'RECOVERY WINDOW OF 31 DAYS'
wal_retention_policy = main