sql >> Databasteknik >  >> RDS >> PostgreSQL

Barman 2.11:barman-cloud-restore och barman-cloud-wal-restore

Tack vare de nya verktygen barman-cloud-restore och barman-cloud-wal-restore introducerad i Barman 2.11 , är det nu möjligt att utföra återställningen av en PostgreSQL-instans med en fullständig säkerhetskopia som tidigare körts med barman-cloud-wal-archive och barman-cloud-backup kommandon. Låt oss tillsammans upptäcka hur man implementerar detta i följande artikel.


Det är värt att notera att i Barman 2.11 finns alla molnverktyg för Barman nu i ett separat paket som heter barman-cli-cloud .

Krav

1. barman-cli-cloud paket
2. En PostgreSQL-instans
3. En AWS S3 hink
4. En andra virtuell maskin där återställningen ska utföras

I den här artikeln kommer vi att testa barman-cli-cloud funktioner i en virtuell maskin med Debian Buster och PostgreSQL 12. För att korrekt följa instruktionerna i den här artikeln, antar vi också att du har:

  • konfigurerade Postgres för att arkivera WAL-filer till en befintlig S3-bucket med barman-cloud-wal-archive
  • körde en säkerhetskopia och skickade den till samma S3-bucket via barman-cloud-backup

Du kan enkelt uppnå detta genom att följa instruktionerna i dessa tidigare bloggartiklar:

  • Barman Cloud – Del 1:WAL Archive
  • Barman Cloud – Del 2:Cloud Backup

Konfigurera återställningsservern

Som ett resultat har vi en S3-hink på AWS som heter barman-s3-test som redan innehåller WAL-filerna och säkerhetskopian arkiverad via barman-cloud-wal-archive och barman-cloud-backup verktyg, nu måste vi korrekt konfigurera en server som kommer att vara värd för återställningen av PostgreSQL-instansen.

1. Installera PostgreSQL 12 från det officiella PGDG-förrådet

2. Installera 2ndQuadrant Public repository

3. Installera barman-cli-cloud paket:

[email protected]:~# apt [email protected]:~# apt install barman-cli-cloud

4. Installera awscli paket:

[email protected]:~# apt install awscli

5. Konfigurera AWS-uppgifter med awscli-verktyget som postgres-användare:

[email protected]:~$ aws configure --profile barman-cloudAWS Access Key ID [Ingen]:AKI******************AWS Secret Access Key [Ingen] ]:**************************************** Standardregionsnamn [Inget]:eu -west-1Standard utdataformat [Ingen]:json

Utför återställningsproceduren

Nu när återställningsservern är korrekt konfigurerad är vi redo att starta återställningsproceduren.

Barman 2.11 introducerar barman-cloud-backup-list kommando som låter dig hämta information om säkerhetskopiorna som gjorts med barman-cloud-backup :

[email protected]:~$ barman-cloud-backup-list \ --profile barman-cloud \ s3://barman-s3-test pg12Backup ID Sluttid Början Wal20200713T120856 2020-07-13 12:09:05 00000001000000000000000C

Vi är nu redo att utföra återställningen med barman-cloud-restore kommando:

[email protected]:~$ barman-cloud-restore \ --profile barman-cloud \ s3://barman-s3-test \ pg12 20200713T120856 \ /var/lib/postgresql/12/main/ 

När återställningen avslutas framgångsrikt kan vi kontrollera PGDATA-katalogens innehåll:

[email protected]:~$ ls /var/lib/postgresql/12/main/PG_VERSION global pg_hba.conf pg_multixact pg_serial pg_stat_tmp pg_twophase postgresql.auto.confbackup_label pg_commit_ts pg_ident.conf pg_notify pg_snapshots pg_subtrans pg_wal postgresql.confbase pg_dynshmem pg_logical pg_replslot pg_stat pg_tblspc pg_xact

Nu, för att vara säkra på att återställningsprocessen fungerade korrekt, måste vi starta den återställda PostgreSQL-instansen och verifiera att allt fungerar som förväntat. Denna process kräver några ytterligare steg.

För det första, eftersom vi är på ett Debian-system, måste vi kopiera filerna som innehåller PostgreSQL-konfigurationen under /etc/postgresql/12/main/ katalog:

[email protected]:~$ cp /var/lib/postgresql/12/main/postgresql.conf /etc/postgresql/12/main/[email protected]:~$ cp /var/lib/postgresql /12/main/pg_hba.conf /etc/postgresql/12/main/[email protected]:~$ cp /var/lib/postgresql/12/main/pg_ident.conf /etc/postgresql/12/main/

För det andra, skapa recovery.signal fil:

[email protected]:~$ tryck på /var/lib/postgresql/12/main/recovery.signal

Inaktivera sedan archive_command för att förhindra att den återställda instansen skriver i samma hink som den ursprungliga instansen:

[email protected]:~$ echo \"archive_command ='cd .'\">> /etc/postgresql/12/main/postgresql.conf

Efter det måste du konfigurera PostgreSQL för att hämta WAL-filerna från den senaste tillgängliga tidslinjen från S3-bucket genom att använda barman-cloud-wal-restore i restore_command :

[email protected]:~$ echo \"restore_command ='barman-cloud-wal-restore --profile barman-cloud s3://barman-s3-test pg12 %f %p'\">> / etc/postgresql/12/main/[email protected]:~$ echo \"recovery_target_timeline ='senaste'\">> /etc/postgresql/12/main/postgresql.conf

VIKTIGT :Innan du fortsätter, se till att PostgreSQL-instansen inte körs och att målkatalogen (standardpostgreSQL-datakatalogen) är tom.

Äntligen är vi redo att starta den nya återställda instansen:

[email protected]:~# systemctl omstart [email protected]

Bra! Som vi kan se från PostgreSQL-loggen återställs WAL-filer från S3-bucket och instansen startades korrekt:

[email protected]:~$ less /var/log/postgresql/postgresql-12-main.log...2020-07-13 12:43:25.093 UTC [9458] LOGG:startar PostgreSQL 12.3 (Debian 12.3-1.pgdg100+1) på x86_64-pc-linux-gnu, kompilerad av gcc (Debian 8.3.0-6) 8.3.0, 64-bit2020-07-13 12:43:25.093 UTC [9458] LOG lyssnar på IPv4-adress "127.0.0.1", port 54322020-07-13 12:43:25.095 UTC [9458] LOGG:lyssnar på Unix-socket "/var/run/postgresql/.s.PGSQL.5432"2020-2020 13 12:43:25.111 UTC [9459] LOGG:databassystemet avbröts; senast känd 2020-07-13 12:08:56 UTC2020-07-13 12:43:25.508 UTC [9459] LOGG:startar arkivåterställning 2020-07-13 12:43:26.010 UTC [9459] logglogg. filen "00000001000000000000000C" från archive2020-07-13 12:43:26.052 UTC [9459] LOGG:gör om börjar vid 0/C0000282020-07-13 12:07-13 12:43:26.052 UTC [9459] LOGG:gör om börjar vid 0/C0000282020-07-13 12:07-13 12:43:26.052 UTC:konsekvent tillstånd 08:4549:0100000000000000000000000000000000000000 -07-13 12:43:26.054 UTC [9458] LOGG:databassystemet är redo att acceptera skrivskyddade anslutningar2020-07-13 12:43:26.469 UTC [9459] LOGG:återställd loggfil "0000000100000000000000000000000000000000000000000000000000000000000000000000000000000002 13 12:43:26.823 UTC [9459] LOGG:gör om gjort vid 0/D0001B02020-07-13 12:43:27.242 UTC [9459] LOGG:återställd loggfil "000000010000000000002D-30000000000002D-72D" UTC [9459] LOGG:vald ny tidslinje ID:22020-07-13 12:43:27.644 UTC [9459] LOGG:arkivåterställning färdig2020-07-13 12:43:27.979 UTC [9458] LOGG:databassystemet är redo att acceptera anslutningar

Slutsats

Som vanligt med alla nya utgåvor av Barman rekommenderar vi att alla uppdaterar sina system till den senaste versionen. En komplett lista över ändringar och buggfixar finns här.

Observera att om du redan använder barman-cloud-wal-archive eller barman-cloud-backup installerat via RPM/Apt-paketet och du uppgraderar ditt system måste du installera barman-cli-cloud paket. Detta beror på det faktum att med Barman 2.11-versionen är alla molnrelaterade verktyg en del av barman-cli-cloud paket enligt beskrivningen i början av artikeln.

Nästa versioner av Barman kan förbättra användbarheten och automatiseringsmöjligheterna för återställningskommandot, till exempel genom att förbereda en recovery.conf eller recovery.signal fil som den faktiska Barman gör.


  1. Är SQLFiddle trasig? Fel för Oracle, SQL Server, ...?

  2. Beräknad kolumn i EF Code First

  3. Hur man ställer in MariaDB för att använda vertikal utdata

  4. MySQL vs MariaDB vs Percona Server:Jämförelse av säkerhetsfunktioner