PostgreSQL
 sql >> Database >  >> RDS >> PostgreSQL

Barman Cloud – Parte 1:Archivio WAL

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

  1. barman-cli 2.10 (o superiore)
  2. Account Amazon AWS
  3. awscli
  4. Secchio S3
  5. 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

    1. Installa il repository pubblico 2ndQuadrant
    2. Installa il pacchetto barman-cli
      [email protected]:~# apt update
      [email protected]:~# apt install barman-cli
    3. 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 come postgres 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 il barman-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.