前文
現在のBarmanユーザーの何人が、クラウド内のリモートの宛先にバックアップを保存することを考えていますか？ PostgreSQLサーバー自体から直接そのバックアップを取ることを考えた人はどれくらいいますか？
ええと、バーマン2.10以来 これが可能になりました！
どのように？
次の記事で一緒にそれを発見しましょう。
要件
次の2つの記事は、新しいbarman-cloud-wal-archiveの実用的な紹介となることを目的としています。 およびbarman-cloud-backup barman-cliに追加されたツール パッケージ。
最初の部分では、barman-cloud-wal-archiveについて説明します。 2番目のコマンドはbarman-cloud-backupをカバーします コマンド。
読者には、PostgreSQL WALのアーカイブとバックアップの方法、およびBarmanの基本的な知識が必要です。また、AmazonS3などのストレージソリューションのクラウドテクノロジーを知っておくことをお勧めします。
WALアーカイブ
Barmanは長年にわたってリモートWALアーカイブとして機能しており、Barman CLIパッケージは、PostgreSQL側でアーカイブの信頼性と堅牢性を拡張するように設計されています。実際、barman-cli barman-wal-restoreのようなスクリプトを提供します restore_commandを使用して、スタンバイノードがBarmanアーカイブからWALファイルをスマートかつ安全に復元できるようにします。 postgresql.auto.confのパラメータ ファイル（またはrecovery.conf PostgreSQLまでのファイル12）、およびbarman-wal-archive archive_commandを介してマスターノードからBarmanにWALファイルをアーカイブする postgresql.confで設定されたパラメータ ファイル。
クラウドWALアーカイブ
ユーザーのフィードバックのおかげで、Barmanの開発者はバージョン 2.10で2つの新しいツールを導入しました。 ：
-
barman-cloud-wal-archive -
barman-cloud-backup
バージョン2.11には、barman-cloud-wal-restoreと呼ばれるリカバリ用の2つの追加ツールが含まれます。 およびbarman-cloud-restore 。
この投稿は完全にbarman-cloud-wal-archiveに捧げられています 、WALファイルをクラウドに保存し、Barmanを使用した多層アーカイブを有効にし、バックアップ保持ポリシーを拡張できます。
実際、barman-cloud-wal-archive pre_archive_retry_scriptを構成するフックスクリプトとして使用できます Barmanのパラメータ。構成されたクラウドストレージにWALファイルをコピーし、アーカイブの冗長性を高め、Barmanよりも長い保存ポリシーを選択できるようにします。
それだけではありません！
barman-cloud-wal-archive barman-wal-archiveを置き換えることができます archive_commandのコマンド パラメータ。WALファイルをBarmanサーバーにコピーするのではなく、クラウドに直接アーカイブします。このように、個別の専用バックアップサーバーを持たないPostgreSQLクラスターでも、リモートストレージサービスに依存してWALファイルをアーカイブできます。
どのように機能しますか？
次の手順は、barman-cloud-wal-archiveをインストールして構成するためのものです。 archive_commandとして PostgreSQLで。
まず、WALファイルをアーカイブする場所を決定します。この記事では、Amazon S3を使用します。これは、執筆時点でサポートされている唯一のテクノロジーです。 S3のようなAPIをサポートする他のテクノロジー（Google Cloud、DigitalOcean、Microsoft Azureなど）はboto3ライブラリで動作しますが、まだテストされていません。
要件
- barman-cli 2.10（またはそれ以降）
- AmazonAWSアカウント
- awscli
- S3バケット
- PostgreSQLインスタンス
この記事では、 Barman CLIをテストします Debian Busterを搭載した仮想マシンで およびPostgreSQL12 すでに稼働しています。
インストール
-
- 2ndQuadrantパブリックリポジトリをインストールする
- barman-cliパッケージをインストールします
[email protected]:~# apt update [email protected]:~# apt install barman-cli
- awscliをインストールします
[email protected]:~# apt install awscli
構成とセットアップ
マニュアルを読みましょう：
[email protected]:~$ man barman-cloud-wal-archive [...] SYNOPSIS barman-cloud-wal-archive [OPTIONS] DESTINATION_URL SERVER_NAME WAL_PATH [...] POSITIONAL ARGUMENTS DESTINATION_URL URL of the cloud destination, such as a bucket in AWS S3. For example: s3://BUCKET_NAME/path/to/folder (where BUCKET_NAME is the bucket you have created in AWS). SERVER_NAME the name of the server as configured in Barman. WAL_PATH the value of the `%p' keyword (according to `archive_command'). [...]
したがって、これを適切に使用するには、
awscliを使用してAWSクレデンシャルを設定する必要があります。postgresとしてのツール ユーザー、AWSコンソールのIAMセクションで以前に作成したアクセスキーとシークレットキーをコピーします：[email protected]:~$ aws configure --profile barman-cloud AWS Access Key ID [None]: AKI***************** AWS Secret Access Key [None]: **************************************** Default region name [None]: eu-west-1 Default output format [None]: json
AWSで利用可能なS3バケットがあることを確認してください。私はそれを
barman-s3-testと呼ぶことにしました 明確にするために。
これで、barman-cloud-wal-archiveをテストできるようになります。 コマンド：[email protected]:~$ barman-cloud-wal-archive -t -P barman-cloud s3://barman-s3-test/ pg12 /var/lib/postgresql/12/main/pg_wal/000000010000000000000001 [email protected]:~$ echo $? 0
終了ステータスは、コマンドが成功したことを確認します。これで、PostgreSQL構成ファイルの最後に次の行を追加して、インスタンスを再起動できます。
archive_mode = on[email protected]:~# systemctl restart [email protected]
データは管理外のリモートストレージにコピーされるため、圧縮して保存することが重要です。 および暗号化 。
barman-cloud-wal-archiveコマンドは、2つの異なる圧縮方法をサポートしています。[email protected]:~$ barman-cloud-wal-archive --help [...] -z, --gzip gzip-compress the WAL while uploading to the cloud -j, --bzip2 bzip2-compress the WAL while uploading to the cloud -e ENCRYPTION, --encryption ENCRYPTION Enable server-side encryption for the transfer. Allowed values: 'AES256', 'aws:kms' [...]
暗号化オプションは、暗号化されたデータを保存するために使用する方法をS3バケットに通知するだけです。暗号化されたデータは、バケットの所有者以外のAWSユーザーが読み取ることはできません。 Barmanクラウドは、オブジェクトをS3に送信する前に暗号化せず、S3が適切に構成されている場合は、暗号化して保存するようバケットに要求するだけです。ただし、S3への接続は、
httpsを介して安全に確立されます。 。postgresql.confの下部に次の行を追加しましょう ファイル：archive_command = 'barman-cloud-wal-archive -P barman-cloud -e AES256 -j s3://barman-s3-test/ pg12 %p'今回は、構成をリロードするだけで、新しい変更を適用できます。
[email protected]:~$ psql -c “SELECT pg_reload_conf()”
新しいarchive_commandが機能しているかどうかをテストするには、PostgreSQLがアーカイブするWALファイルを生成する必要があるため、
pgbenchを使用してトラフィックを生成する必要があります。 ツール：[email protected]:~$ createdb pg_bench_db [email protected]:~$ pgbench -i -s10 pg_bench_db [some irrelevant output here] [email protected]:~$ pgbench -c 10 -j 2 -T 30 pg_bench_db starting vacuum...end. transaction type: <builtin: TPC-B (sort of)> scaling factor: 10 query mode: simple number of clients: 10 number of threads: 2 duration: 30 s number of transactions actually processed: 84501 latency average = 3.552 ms tps = 2815.224687 (including connections establishing) tps = 2815.427535 (excluding connections establishing)
この時点で、S3バケットにアーカイブされたWALファイルが表示されます。サーバー名とWAL宛先ディレクトリを使用してターゲットパスを作成し、確認してみましょう。
[email protected]:~$ aws s3 --profile barman-cloud ls s3://barman-s3-test/pg12/wals/ PRE 0000000100000000/
0000000100000000ディレクトリの内部を見てみましょう：
[email protected]:~$ aws s3 --profile barman-cloud ls s3://barman-s3-test/pg12/wals/0000000100000000/ 2020-01-08 08:20:54 1624168 000000010000000000000001.bz2 2020-01-08 08:21:00 293422 000000010000000000000002.bz2 2020-01-08 08:21:06 301934 000000010000000000000003.bz2 2020-01-08 08:21:11 295648 000000010000000000000004.bz2 2020-01-08 08:21:16 293675 000000010000000000000005.bz2 2020-01-08 08:21:21 299348 000000010000000000000006.bz2 2020-01-08 08:21:27 551249 000000010000000000000007.bz2 2020-01-08 08:21:33 976523 000000010000000000000008.bz2 2020-01-08 08:21:37 4542104 000000010000000000000009.bz2 2020-01-08 08:21:46 5052693 00000001000000000000000A.bz2
すばらしい！
WALファイルはS3バケットにアップロードされる前に圧縮され、暗号化されて保存されるため、スペース（およびコスト）が節約され、データのセキュリティレベルが向上します。
結論
barman-cloud-wal-archiveコマンドは、ユーザーが長い間待っていたものです。pre_archive_retry_scriptを使用したことがある方 WALファイルをS3バケットにアップロードするためのカスタムスクリプトを実装する場合、これはBarman開発者によって開発および保守され、2ndQuadrant継続的デリバリーシステムによってテストおよび配信されるため、より適切な代替として使用できます。まだ考えていない場合は、これにより新しい保持ポリシーが開かれ、Barmanローカルポリシーよりもクラウドストレージの方が長くなる可能性があります。適切に設定することで、ローカルストレージのスペースを節約しながら、クラウド内のオブジェクトの年齢を増やすことができます。 S3バケットの構成でのより長い保持ポリシー。
それ以外の場合は、この記事で行ったように、PostgreSQLサーバーから直接WALファイルをアーカイブするために使用できます。これにより中間ステップが削除されますが、 RPO PostgreSQLはWALファイルを閉じた後にのみアーカイブするため、ストリーミング方式と比較して増加します。したがって、PostgreSQLノードで問題が発生した場合、一部の変更が失われる可能性があります。可能であれば、 RPO =0 を達成するために、Barmanサーバーへのストリーミングと一緒にこのメソッドを実装することをお勧めします。 （同期ストリーミングを使用）。
継続的なアーカイブシステムが導入されたので、最初のクラウドバックアップを実行できます。
barman-cloud-backupを使用する ツール。記事の後半でお会いしましょう。