Preambolo
Quanti attuali utenti Barman hanno pensato di salvare i backup in una destinazione remota nel cloud? Quanti hanno pensato di prendere quel backup direttamente dal server PostgreSQL stesso?
Bene, da Barman 2.10 ora è possibile!
Come?
Scopriamolo insieme nei seguenti articoli.
Requisiti
I due articoli seguenti vogliono essere un'introduzione pratica al nuovo barman-cloud-wal-archive
e barman-cloud-backup
strumenti aggiunti nel barman-cli
pacchetto.
La prima parte riguarderà il barman-cloud-wal-archive
comando mentre il secondo riguarderà il barman-cloud-backup
comando.
I lettori necessitano di una conoscenza di base dei metodi di archiviazione e backup WAL di PostgreSQL e di Barman. Si consiglia inoltre di conoscere le tecnologie cloud per soluzioni di archiviazione come Amazon S3.
Archivio WAL
Barman funge da archivio WAL remoto da molti anni e il pacchetto Barman CLI è stato progettato per estendere l'affidabilità e la robustezza dell'archiviazione sul lato PostgreSQL. Infatti barman-cli
fornisce script come barman-wal-restore
consentendo a un nodo di standby di ripristinare in modo intelligente e sicuro i file WAL da un archivio Barman tramite il restore_command
parametro nel postgresql.auto.conf
file (o recovery.conf
file fino a PostgreSQL 12) e barman-wal-archive
per archiviare file WAL da un nodo master a Barman tramite il archive_command
parametro configurato in postgresql.conf
file.
Archivio Cloud WAL
Grazie al feedback degli utenti, gli sviluppatori di Barman hanno introdotto due nuovi strumenti nella versione 2.10 :
barman-cloud-wal-archive
barman-cloud-backup
La versione 2.11 includerà due strumenti aggiuntivi per il ripristino, chiamati barman-cloud-wal-restore
e barman-cloud-restore
.
Questo post è interamente dedicato a barman-cloud-wal-archive
, che può archiviare file WAL nel cloud, consentendo l'archiviazione multilivello con Barman ed espandendo la politica di conservazione dei backup.
Infatti, barman-cloud-wal-archive
può essere usato come hook-script per configurare il pre_archive_retry_script
parametro in Barman, per copiare i file WAL nel cloud storage configurato, aumentando la ridondanza dell'archivio e consentendo di scegliere una policy di conservazione più lunga rispetto a quella di Barman.
Non è tutto!
barman-cloud-wal-archive
può sostituire il barman-wal-archive
comando nel archive_command
parametro, per archiviare direttamente i file WAL nel cloud, invece di copiarli nel server Barman. In questo modo, anche un cluster PostgreSQL che non dispone di un server di backup dedicato separato può fare affidamento su un servizio di archiviazione remota per archiviare i file WAL.
Come funziona?
Le seguenti istruzioni servono solo per installare e configurare barman-cloud-wal-archive
come archive_command
in PostgreSQL.
In primo luogo, decidi dove archiviare i file WAL. In questo articolo utilizzeremo Amazon S3, che, al momento in cui scriviamo, è l'unica tecnologia supportata. Sebbene altre tecnologie che supportano API simili a S3 (Google Cloud, DigitalOcean, Microsoft Azure, ecc.) possano funzionare con la libreria boto3, non sono state ancora testate.
Requisiti
- barman-cli 2.10 (o superiore)
- Account Amazon AWS
- awscli
- Secchio S3
- Un'istanza PostgreSQL
In questo articolo testeremo Barman CLI in una macchina virtuale con Debian Buster e PostgreSQL 12 che è già attivo e funzionante.
Installazione
-
- Installa il repository pubblico 2ndQuadrant
- Installa il pacchetto barman-cli
[email protected]:~# apt update [email protected]:~# apt install barman-cli
- Installa awscli
[email protected]:~# apt install awscli
Configurazione e configurazione
Leggiamo il manuale:
[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'). [...]
Quindi, per utilizzarlo correttamente dobbiamo solo configurare le credenziali AWS con il
awscli
strumento comepostgres
utente, copiando la chiave di accesso e la chiave segreta precedentemente create nella sezione IAM della console AWS:[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
Assicurati di avere un bucket S3 disponibile su AWS. Ho scelto di chiamarlo
barman-s3-test
per chiarire.
Dovremmo ora essere in grado di testare ilbarman-cloud-wal-archive
comando:[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
Lo stato di uscita conferma che il comando è riuscito. Ora possiamo aggiungere la seguente riga in fondo al file di configurazione di PostgreSQL e riavviare l'istanza:
archive_mode = on
[email protected]:~# systemctl restart [email protected]
Poiché i nostri dati verranno copiati in un archivio remoto, fuori dal nostro controllo, è importante che li archiviamo compressi e crittografato . Il
barman-cloud-wal-archive
comando supporta due diversi metodi di compressione:[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' [...]
L'opzione di crittografia informerà semplicemente il bucket S3 quale metodo utilizzare per archiviare i dati crittografati. I dati crittografati non possono essere letti da nessun altro utente AWS tranne il proprietario del bucket. Barman cloud non crittografa alcun oggetto prima di inviarlo a S3, chiede semplicemente al bucket di archiviarli crittografati se S3 è stato configurato correttamente. Tuttavia, qualsiasi connessione a S3 viene stabilita in modo sicuro tramite
https
.Aggiungiamo la seguente riga in fondo a
postgresql.conf
file:archive_command = 'barman-cloud-wal-archive -P barman-cloud -e AES256 -j s3://barman-s3-test/ pg12 %p'
Questa volta basta un solo ricaricamento della configurazione per applicare le nuove modifiche:
[email protected]:~$ psql -c “SELECT pg_reload_conf()”
Per verificare se il nuovo archive_command funziona, PostgreSQL dovrebbe produrre file WAL da archiviare, quindi dobbiamo fare un po' di traffico con l'aiuto di
pgbench
strumento:[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)
A questo punto dovremmo vedere i file WAL archiviati nel bucket S3. Verifichiamolo, costruendo il percorso di destinazione con il nome del server e la directory di destinazione WAL:
[email protected]:~$ aws s3 --profile barman-cloud ls s3://barman-s3-test/pg12/wals/ PRE 0000000100000000/
Diamo un'occhiata all'interno della directory 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
Ottimo!
I file WAL vengono compressi prima di essere caricati nel bucket S3 e vengono archiviati crittografati, facendoci risparmiare spazio (e denaro) e aumentando il livello di sicurezza dei nostri dati.
Conclusioni
Il
barman-cloud-wal-archive
comando è ciò che gli utenti hanno atteso a lungo.Se sei uno di quelli che ha utilizzato
pre_archive_retry_script
per implementare uno script personalizzato per il caricamento di file WAL in un bucket S3, questo può essere utilizzato come sostituto migliore perché è sviluppato e mantenuto dagli sviluppatori Barman, ed è testato e distribuito dal sistema 2ndQuadrant Continuous Delivery.Nel caso non ci avessi ancora pensato, questo apre nuove politiche di conservazione che possono essere più lunghe per il cloud storage rispetto a quelle locali di Barman, aumentando l'età degli oggetti nel cloud, risparmiando spazio sullo storage locale, impostando opportunamente una policy di conservazione più lunga nella configurazione dei bucket S3.
Altrimenti, può essere utilizzato come abbiamo fatto in questo articolo, per archiviare i file WAL direttamente dal server PostgreSQL. Sebbene ciò elimini un passaggio intermedio, l'RPO aumenta rispetto al metodo di streaming, perché PostgreSQL archivierà il file WAL solo dopo averlo chiuso. Pertanto in caso di problemi sul nodo PostgreSQL, potremmo perdere alcune modifiche. Quando possibile, consigliamo di implementare questo metodo insieme allo streaming su un server Barman per ottenere RPO=0 (con streaming sincrono).
Ora che disponiamo di un sistema di archiviazione continuo, possiamo eseguire il nostro primo backup su cloud utilizzando il
barman-cloud-backup
strumento.Ci vediamo nella seconda parte dell'articolo.