sql >> Databasteknik >  >> RDS >> PostgreSQL

Automatiserad testning av PostgreSQL-säkerhetskopior

Enbart att ha regelbundna säkerhetskopior av din PostgreSQL-databas är inte tillräckligt för en snabbåterställning – du måste se till att säkerhetskopieringsfilerna är tillgängliga och hälsosamma om och när det krävs för en återställningsprocedur. Läs vidare för att se några exempel på hur du ställer in automatisk testning av PostgreSQL-säkerhetskopior.

Säkerhetskopieringar gjorda med pg_basebackup

pg_basebackup säkerhetskopior innehåller hela datakatalogen för ett databaskluster. Den här katalogen är vanligtvis packad till en tarball, ibland med en extra tarball för WAL-filer som skapades sedan säkerhetskopieringen startade.

För att testa en sådan pg_basebackup tarball, packa först upp tarballen i en tom katalog. Om det finns en separat WAL-fil tarball, packa upp den i pg_wal katalog i den nya katalogen:

$ mkdir backup-test
$ cd backup-test
$ tar --no-same-owner xvf /path/to/base.tar.gz
$ mkdir -p pg_wal
$ cd pg_wal
$ tar --no-same-owner xvf /path/to/pg_wal.tar.gz

Du kan nu starta en PostgreSQL-serverprocess för denna katalog:

$ pg_ctl -D path/to/backup-test start

(Obs:pg_ctl är ett kommandoradsverktyg som ingår i Postgres standarddistribution. Det är tillgängligt överallt där Postgres själv är, liknande de andra inkluderade verktygen som psql och pg_dump .Läs mer om pg_ctl här.)

Om det redan finns en PostgreSQL-server installerad/körs på den här maskinen, vill du förmodligen starta på en annan port än standardporten 5432:

$ pg_ctl -D path/to/backup-test -o "-p 6000 -k /tmp" start

Om allt har lyckats hittills vill du kontrollera om data i din återställda databas är sunda. Om du har automatiserade testskript att köra mot din databas, skulle nu vara ett bra tillfälle att starta åtminstone en liten uppsättning av dessa tester mot denna återställda databas. Om inte, kan du hacka ihop några snabbkontroller med psql:

$ psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"

Ovanstående kommando gör en enkel fråga mot en tabell som borde finnas. Exitkoden för psql bör berätta om frågan lyckades eller inte. Naturligtvis kan du köra mer komplexa frågor, eller köra en .sql-fil, eller till och med ett separat testskript som ansluter till den här databasen och kör tester.

När du är klar med testningen kan du stoppa Postgres-serverprocessen med:

$ pg_ctl -D path/to/backup-test stop

Och rensa hela den extraherade databasklusterkatalogen:

$ rm -rf path/to/backup-test

Så här ser det ut när allt är sammanställt:

#!/bin/bash

# exit immediately if any step fails 
set -eo pipefail

# fetch the latest backup
# TODO: copy out base.tar.gz and pg_wal.tar.gz of latest backup

# create a directory to work in
BACKUP_DIR=/tmp/backup-test
rm -rf $BACKUP_DIR
mkdir $BACKUP_DIR

# unpack the backup archives
tar -C $BACKUP_DIR --no-same-owner xvf /path/to/base.tar.gz
mkdir -p $BACKUP_DIR/pg_wal
tar -C $BACKUP_DIR/pg_wal --no-same-owner xvf /path/to/pg_wal.tar.gz

# start a new Postgres server for the cluster on port 6000
pg_ctl -D $BACKUP_DIR -o "-p 6000 -k /tmp" start

# perform a simple test
psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"

# shutdown the server
pg_ctl -D $BACKUP_DIR stop

# cleanup the files
rm -rf $BACKUP_DIR /path/to/base.tar.gz /path/to/pg_wal.tar.gz

Säkerhetskopieringar gjorda med pg_dump

pg_dump verktyg (dokument) kan också användas för att skapa säkerhetskopior – detta är mer flexibelt genom att du valfritt kan välja den databas/schema/tabeller du vill säkerhetskopiera, i motsats tillpg_basebackup vilket är en allt-eller-inget-process.

Med pg_dump , kan du generera en enda .sql skript eller ett binärt .pgdmp fil som innehåller all data (och valfritt även DDL-satserna för att skapa tabeller/index etc.). För att återställa en sådan fil måste du ansluta till en livedatabasserver och köra SQL-kommandona i .sql/.pgdmp-filen. Medan du kan använda den vanliga psql för att köra .sql-filen måste du använda pg_restore kommando (docs) för att köra .pgdmp-filen.

För att testa sådana säkerhetskopior hämtar vi först filen och skapar sedan ett nytt, tomt databaskluster:

$ rm -rf path/to/backup-test
$ pg_ctl -D path/to/backup-test initdb

och starta en PostgreSQL-server på den, lyssna på port 6000 som tidigare:

$ pg_ctl -D path/to/backup-test -o "-p 6000 -k /tmp" start

Det är möjligt att generera pg_dump filer som är helt fristående, men det är också möjligt att generera dem för att inte vara så. Beroende på hur dumpen genererades kan därför vissa installationssteg krävas:

  • skapa en databas
  • skapa tabeller, index etc.
  • bevilja privilegier

När det är gjort kan du antingen använda psql eller pg_restore för att få tillbaka data till liv:

# for .sql files
$ psql -p 6000 -h /tmp -v ON_ERROR_STOP=1 -1 -b -f path/to/dump.sql 

# for .pgdmp files
$ pg_restore -p 6000 -h /tmp -d mydb -C -1 -f path/to/dump.pgdmp

Som tidigare, vid denna tidpunkt, kan tester utföras för att säkerställa att de lagrade data är korrekta.

Så här ser det ut, allt tillsammans:

#!/bin/bash

# exit immediately if any step fails 
set -eo pipefail

# fetch the latest dump
# TODO: copy out the dump.sql or dump.pgdmp of latest backup

# create an empty database cluster
BACKUP_DIR=/tmp/backup-test
rm -rf $BACKUP_DIR
pg_ctl -D $BACKUP_DIR initdb

# start a new Postgres server for the cluster on port 6000
pg_ctl -D $BACKUP_DIR -o "-p 6000 -k /tmp" start

# TODO: perform any specific setup steps here

# restore the file, .sql:
psql -p 6000 -h /tmp -v ON_ERROR_STOP=1 -1 -b -f path/to/dump.sql 
# or .pgdmp:
pg_restore -p 6000 -h /tmp -d mydb -C -1 -f path/to/dump.pgdmp

# perform a simple test
psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"

# shutdown the server
pg_ctl -D $BACKUP_DIR stop

# cleanup the files
rm -rf $BACKUP_DIR /path/to/dump.*

Se upp för utlösare

När du återställer en pg_dump säkerhetskopiering, data infogas i tabeller, ungefär som när en applikation gör det. Om du har triggers som ansluter till externa tjänster för att meddela om radinfogningar, är det bäst att inaktivera dem under återställningsproceduren.

När du anropar pg_dump för att skicka sql-filer kan du använda alternativet--disable-triggers för att berätta för pg_dump för att generera skript för att inaktivera triggarna medan du infogar.

När du anropar pg_restore på en databas som redan har triggers kan du använda --disable-triggers i pg_restore för att uppnå samma effekt.

PITR-testning

Point-in-time-recovery (PITR) i Postgres förlitar sig på en fullständig säkerhetskopia som tagits med pg_basebackup , och en sekvens av WAL-filer från den punkten fram till den tidpunkt då du vill återställa. Testning av PITR innebär därför att testa den fullständiga säkerhetskopian såväl som de efterföljande WAL-filerna.

För automatisk säkerhetskopieringstestning har vi inget specifikt återställningsmål. Alla arkiverade WAL-filer från den senaste säkerhetskopieringen och framåt tills den senaste bör testas. Det enklaste sättet att testa detta är att följa samma steg som för pg_basebackup testmetod, med bara ett ytterligare steg. Efter att ha packat upp den senaste säkerhetskopian, hämta alla relevanta och tillgängliga WAL-filer och placera dem i pg_wal innan du startar Postgres-servern. Närmare bestämt:

#!/bin/bash

# exit immediately if any step fails 
set -eo pipefail

# fetch the latest backup
# TODO: copy out base.tar.gz and pg_wal.tar.gz of latest backup

# create a directory to work in
BACKUP_DIR=/tmp/backup-test
rm -rf $BACKUP_DIR
mkdir $BACKUP_DIR

# unpack the backup archives
tar -C $BACKUP_DIR --no-same-owner xvf /path/to/base.tar.gz
mkdir -p $BACKUP_DIR/pg_wal
tar -C $BACKUP_DIR/pg_wal --no-same-owner xvf /path/to/pg_wal.tar.gz

# --> this is the new extra step <--
# TODO: fetch all WAL files from the WAL archive since the last
# backup, and place them in $BACKUP_DIR/pg_wal

# start a new Postgres server for the cluster on port 6000
pg_ctl -D $BACKUP_DIR -o "-p 6000 -k /tmp" start

# perform a simple test
psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"

# shutdown the server
pg_ctl -D $BACKUP_DIR stop

# cleanup the files
rm -rf $BACKUP_DIR /path/to/base.tar.gz /path/to/pg_wal.tar.gz

Detta bör verifiera om både den senaste säkerhetskopian och efterföljande WAL-filer är bra, så att de kan användas för PITR om och när det behövs.


  1. Hur man hämtar två kolumndata i A,B-format i Oracle

  2. Lagra filer i SQL-databas med FILESTREAM – Del 2

  3. SQL Server 2017 Steg för steg Installation -2

  4. Arbeta med Java Data i Alteryx