sql >> Databasteknik >  >> RDS >> PostgreSQL

Toppverktyg för säkerhetskopiering för PostgreSQL

PostgreSQL har ryktet om att vara stensäkert från början och har under åren samlat på sig en uppsättning imponerande funktioner. Men sinnesfriden att din data på disken är ACID-kompatibel – om den inte kompletteras med en likvärdig genomtänkt säkerhetskopieringsstrategi – kan lätt krossas.

Säkerhetskopieringstyper

Innan vi dyker in i de tillgängliga verktygen, låt oss titta på de tillgängliga PostgreSQL-säkerhetskopieringstyperna och vad deras egenskaper är:

SQL-dumpar (eller logiska)

  • Blockerar inte läsare eller skribenter.
  • Inriktad på små uppsättningar data på grund av den negativa inverkan på systembelastningen och den långa tid som krävs för både säkerhetskopiering och återställning. Prestandan kan ökas med flaggan –no-sync, men se man-sidan för riskerna förknippade med att inaktivera väntan på skrivningar.
  • En ANALYS efter återställning krävs för att optimera statistiken.
  • Globala objekt som roller och tabellutrymmen kan bara säkerhetskopieras med hjälp av verktyget pg_dumpall. Observera att tabellutrymmeskataloger måste skapas manuellt innan återställningen påbörjas.
  • Stöder parallellitet på bekostnad av ökad systembelastning. Läs man pg_dump för dess varningar och speciella krav t.ex. synkroniserade ögonblicksbilder.
  • Dumpar kan laddas i nyare versioner av PostgreSQL, eller till och med en annan maskinarkitektur, men de är inte garanterade att vara bakåtkompatibla mellan större versioner så viss manuell redigering av dumpfilen kan krävas.

Filsystem (eller fysiskt)

  • Kräver att databasen stängs av.
  • Snabbare än logiska säkerhetskopieringar.
  • Innehåller klusterdata.
  • Kan endast återställas på samma huvudversion av PostgreSQL.

Kontinuerlig arkivering (eller Point In Time Recovery eller PITR)

  • Lämplig för mycket stora databaser där logiska eller fysiska säkerhetskopieringar skulle ta för lång tid.
  • Vissa kataloger i datakatalogen kan uteslutas för att påskynda processen.

Ögonblicksbilder

  • Kräver operativsystemstöd — till exempel fungerar LVM ganska bra vilket också bekräftas av NetBackup för PostgreSQL Agent.
  • Lämplig för applikationer där både datakatalogen och databasen måste vara synkroniserade t.ex. LAMP-applikationer, förutsatt att de två ögonblicksbilderna är synkroniserade.
  • Rekommenderas inte när databasfilerna lagras i flera filsystem (måste ögonblicksbilda alla filsystem samtidigt).

moln

Alla molnleverantörer implementerar säkerhetskopior i sitt PostgreSQL-erbjudande. Logiska säkerhetskopieringar kan utföras som vanligt, medan fysiska säkerhetskopior och PITR är tillgängliga via molntjänstutbudet eftersom tillgång till datalagret inte är tillgängligt (se till exempel Amazon Aurora för PostgreSQL). Därför måste säkerhetskopiering av PostgreSQL i molnet vara ett ämne för en annan blogg.

Agentbas

  • Kräver en agent installerad på mål.
  • Kan göra säkerhetskopior på blocknivå, t.ex. COMMVAULT (installation stöds endast på Windows).

Funktioner

Medan PostgreSQL tillhandahåller de verktyg som krävs för att utföra logiska, fysiska och PITR-säkerhetskopior, förlitar sig specialiserade säkerhetskopieringsapplikationer på de inbyggda PostgreSQL- och operativsystemverktygen för att fylla behovet av att implementera en säkerhetskopieringsstrategi som tar itu med följande punkter:

  • automatisering
  • frekvens
  • lagringsperiod
  • integritet
  • användarvänlighet

Dessutom försöker PostgreSQL-säkerhetskopieringsverktyg att tillhandahålla funktioner som är gemensamma för generiska säkerhetskopieringsverktyg som:

  • inkrementella säkerhetskopior för att spara lagringsutrymme
  • säkerhetskopieringskataloger
  • möjlighet att lagra säkerhetskopior på plats eller i molnet
  • varning och avisering
  • omfattande rapportering
  • åtkomstkontroll
  • kryptering
  • grafiskt gränssnitt och instrumentpaneler
  • säkerhetskopior av fjärrvärdar
  • adaptiv genomströmning för att minimera belastningen på målen
  • hantera flera värdar parallellt
  • backup-orkestrering t.ex. jobbkedja
  • REST-API:er

Labbinställning

För den här övningen har jag ställt in en kommando-och-kontroll-värd där jag ska installera säkerhetskopieringsverktygen, som också kör två PostgreSQL-instanser - 9.6 och 10 - installerade från PGDG-förråd:

[[email protected] ~]# ps -o user,pid,ppid,args --forest -U postgres
USER       PID  PPID COMMAND
postgres  4535     1 /usr/pgsql-10/bin/postmaster -D /var/lib/pgsql/10/data/
postgres  4538  4535  \_ postgres: logger process
postgres  4540  4535  \_ postgres: checkpointer process
postgres  4541  4535  \_ postgres: writer process
postgres  4542  4535  \_ postgres: wal writer process
postgres  4543  4535  \_ postgres: autovacuum launcher process
postgres  4544  4535  \_ postgres: stats collector process
postgres  4545  4535  \_ postgres: bgworker: logical replication launcher
postgres  4481     1 /usr/pgsql-9.6/bin/postmaster -D /var/lib/pgsql/9.6/data/
postgres  4483  4481  \_ postgres: logger process
postgres  4485  4481  \_ postgres: checkpointer process
postgres  4486  4481  \_ postgres: writer process
postgres  4487  4481  \_ postgres: wal writer process
postgres  4488  4481  \_ postgres: autovacuum launcher process
postgres  4489  4481  \_ postgres: stats collector process

[[email protected] ~]# netstat -npeelt | grep :543
tcp   0  0  127.0.0.1:5432  0.0.0.0:*  LISTEN  26  79972  4481/postmaster
tcp   0  0  127.0.0.1:5433  0.0.0.0:*  LISTEN  26  81801  4535/postmaster
tcp6  0  0  ::1:5432        :::*       LISTEN  26  79971  4481/postmaster
tcp6  0  0  ::1:5433        :::*       LISTEN  26  81800  4535/postmaster

Jag har också ställt in två fjärranslutna PostgreSQL-instanser som kör samma version 9.6 respektive 10:

[[email protected] ~]# ps -o user,pid,ppid,args --forest -U postgres
USER       PID  PPID COMMAND
postgres 10972     1 /usr/pgsql-9.6/bin/postmaster -D /var/lib/pgsql/9.6/data/
postgres 10975 10972  \_ postgres: logger process
postgres 10977 10972  \_ postgres: checkpointer process
postgres 10978 10972  \_ postgres: writer process
postgres 10979 10972  \_ postgres: wal writer process
postgres 10980 10972  \_ postgres: autovacuum launcher process
postgres 10981 10972  \_ postgres: stats collector process

[[email protected] ~]# netstat -npeelt | grep :5432
tcp   0  0  0.0.0.0:5432  0.0.0.0:*  LISTEN  26  34864  10972/postmaster
tcp6  0  0  :::5432       :::*       LISTEN  26  34865  10972/postmaster


[[email protected] ~]# ps -o user,pid,ppid,args --forest -U postgres
USER       PID  PPID COMMAND
postgres 10829     1 /usr/pgsql-10/bin/postmaster -D /var/lib/pgsql/10/data/
postgres 10831 10829  \_ postgres: logger process
postgres 10833 10829  \_ postgres: checkpointer process
postgres 10834 10829  \_ postgres: writer process
postgres 10835 10829  \_ postgres: wal writer process
postgres 10836 10829  \_ postgres: autovacuum launcher process
postgres 10837 10829  \_ postgres: stats collector process
postgres 10838 10829  \_ postgres: bgworker: logical replication launcher

[[email protected] ~]# netstat -npeelt | grep :5432
tcp   0  0  0.0.0.0:5432  0.0.0.0:*  LISTEN  26  34242  10829/postmaster
tcp6  0  0  :::5432       :::*       LISTEN  26  34243  10829/postmaster

Använd sedan pgbench för att skapa en datamängd:

pgbench=# \dt+
                          List of relations
 Schema |       Name       | Type  |  Owner   |  Size   | Description
--------+------------------+-------+----------+---------+-------------
 public | pgbench_accounts | table | postgres | 128 MB  |
 public | pgbench_branches | table | postgres | 40 kB   |
 public | pgbench_history  | table | postgres | 0 bytes |
 public | pgbench_tellers  | table | postgres | 40 kB   |
(4 rows)

Verktyg

En lista över vanliga säkerhetskopieringsverktyg finns i PostgreSQL Wiki — Säkerhetskopiering. Jag har utökat listan med produkter jag har stött på under åren och från en nyligen genomförd internetsökning.

Amanda

Amanda är agentbaserad, öppen källkod och stöder PostgreSQL direkt via ampgsql API. När detta skrivs stöder inte version 3.5.1 tabellutrymmen (se man ampgsql).

Zmanda tillhandahåller en företagsversion som också är öppen källkod, dock inte direkt tillgänglig för nedladdning som en testversion.

Amanda kräver en dedikerad backup-värd eftersom server- och klientpaketen utesluter varandra:

[[email protected] ~]# rpm -qp --conflicts ./amanda-backup_client-3.5.1-1.rhel7.x86_64.rpm
amanda-backup_server
[[email protected] ~]# rpm -qp --conflicts ./amanda-backup_server-3.5.1-1.rhel7.x86_64.rpm
amanda-backup_client

Följ den grundläggande konfigurationsguiden för att ställa in servern och klienten och konfigurera sedan PostgreSQL API.

Här är en git diff från mitt labb:

  • Server:

    • öka serverns säkerhetskopieringsutrymme:

      --- a/etc/amanda/omiday/amanda.conf
      				+++ b/etc/amanda/omiday/amanda.conf
      				@@ -13,7 +13,7 @@ amrecover_changer "changer"
      
      				tapetype "TEST-TAPE"
      				define tapetype TEST-TAPE {
      				1.  length 100 mbytes
      				2.  length 500 mbytes
      					filemark 4 kbytes
      				}
      • definiera PostgreSQL-målet (och inaktivera exempelsäkerhetskopiering):

        --- a/etc/amanda/omiday/disklist
        +++ b/etc/amanda/omiday/disklist
        @@ -1,3 +1,2 @@
        -localhost /etc simple-gnutar-local
        +#localhost /etc simple-gnutar-local
        +10.1.9.243 /var/lib/pgsql/9.6/data dt_ampgsql
  • Klient:

    • config:

      --- /dev/null
      +++ b/etc/amanda/omiday/amanda-client.conf
      @@ -0,0 +1,5 @@
      +property "PG-DATADIR" "/var/lib/pgsql/9.6/data"
      +property "PG-ARCHIVEDIR" "/var/lib/pgsql/9.6/archive"
      +property "PG-HOST" "/tmp"
      +property "PG-USER" "amandabackup"
      +property "PG-PASSFILE" "/etc/amanda/pg_passfile"
      • autentiseringsfil:

        --- /dev/null
        +++ b/etc/amanda/pg_passfile
        @@ -0,0 +1 @@
        +/tmp:*:*:amandabackup:pass
    • auktorisera servern:

      --- a/var/lib/amanda/.amandahosts
      +++ b/var/lib/amanda/.amandahosts
      @@ -1,2 +1,3 @@
      localhost amandabackup amdump
      localhost.localdomain amandabackup amdump
      +10.1.9.231 amandabackup amdump
    • PostgreSQL-autentisering:

      --- a/var/lib/pgsql/9.6/data/pg_hba.conf
      +++ b/var/lib/pgsql/9.6/data/pg_hba.conf
      @@ -79,7 +79,8 @@
      # "local" is for Unix domain socket connections only
      local   all             all                                     trust
      # IPv4 local connections:
      -host    all             all             127.0.0.1/32            ident
      +host    all             all             127.0.0.1/32            trust
      +host    all             amandabackup    10.1.9.243/32           trust
      # IPv6 local connections:
      host    all             all             ::1/128                 ident
      # Allow replication connections from localhost, by a user with the
    • PostgreSQL-konfiguration:

      --- a/var/lib/pgsql/9.6/data/postgresql.conf
      +++ b/var/lib/pgsql/9.6/data/postgresql.conf
      @@ -178,6 +178,7 @@ dynamic_shared_memory_type = posix  # the default is the first option
      
      #wal_level = minimal                   # minimal, replica, or logical
                                             # (change requires restart)
      +wal_level = replica
      #fsync = on                            # flush data to disk for crash safety
                                                      # (turning this off can cause
                                                      # unrecoverable data corruption)
      @@ -215,10 +216,12 @@ dynamic_shared_memory_type = posix        # the default is the first option
      
      #archive_mode = off            # enables archiving; off, on, or always
                                    # (change requires restart)
      +archive_mode = on
      #archive_command = ''          # command to use to archive a logfile segment
                                    # placeholders: %p = path of file to archive
                                    #               %f = file name only
                                    # e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
      +archive_command = 'test ! -f /var/lib/pgsql/9.6/archive/%f && cp %p /var/lib/pgsql/9.6/archive/%f'
      #archive_timeout = 0           # force a logfile segment switch after this
                                    # number of seconds; 0 disables

När ovanstående konfiguration är klar, kör säkerhetskopieringen:

[[email protected] ~]$ amdump omiday

Och verifiera:

[[email protected] ~]$ amreport omiday
Hostname: cc
Org     : omiday
Config  : omiday
Date    : April 14, 2018

These dumps were to tape MyData01.
The next tape Amanda expects to use is: MyData02.


STATISTICS:
                        Total       Full      Incr.   Level:#
                        --------   --------   --------  --------
Estimate Time (hrs:min)     0:00
Run Time (hrs:min)          0:00
Dump Time (hrs:min)         0:00       0:00       0:00
Output Size (meg)            0.1        0.0        0.1
Original Size (meg)         16.0        0.0       16.0
Avg Compressed Size (%)      0.5        --         0.5
DLEs Dumped                    1          0          1  1:1
Avg Dump Rate (k/s)         33.7        --        33.7

Tape Time (hrs:min)         0:00       0:00       0:00
Tape Size (meg)              0.1        0.0        0.1
Tape Used (%)                0.0        0.0        0.0
DLEs Taped                     1          0          1  1:1
Parts Taped                    1          0          1  1:1
Avg Tp Write Rate (k/s)    830.0        --       830.0


USAGE BY TAPE:
Label                 Time         Size      %  DLEs Parts
MyData01              0:00          83K    0.0     1     1


NOTES:
planner: tapecycle (3) <= runspercycle (3)
planner: Last full dump of 10.1.9.243:/var/lib/pgsql/9.6/data on tape MyData04 overwritten in 3 runs.
taper: tape MyData01 kb 83 fm 1 [OK]


DUMP SUMMARY:
                                                               DUMPER STATS   TAPER STATS
HOSTNAME     DISK                    L ORIG-KB  OUT-KB  COMP%  MMM:SS   KB/s MMM:SS   KB/s
-------------------------------------- ---------------------- -------------- -------------
10.1.9.243   /var/lib/pgsql/9.6/data 1   16416      83    0.5    0:02   33.7   0:00  830.0

(brought to you by Amanda version 3.5.1)

Återställning från säkerhetskopia innebär fler manuella steg som förklaras i återställningsavsnittet.

Enligt Amanda Enterprise FAQ skulle följande förbättring gälla för vårt PostgreSQL-exempel:

  • hanteringskonsol för automatisering av säkerhetskopiering, lagringspolicyer och scheman
  • säkerhetskopiering till Amazon S3 molnlagring

Barman

Barman är en katastrofåterställningslösning för PostgreSQL som underhålls av 2ndQuadrant. Den är utformad för att hantera säkerhetskopior för flera databaser och har möjlighet att återställa till en tidigare tidpunkt med hjälp av PITR-funktionen i PostgreSQL.

Barmans funktioner i ett ögonkast:

  • hanterar flera mål
  • stöd för olika PostgreSQL-versioner
  • noll dataförlust
  • strömning och/eller standardarkivering av WALs
  • lokal eller fjärråterställning
  • förenklad tidpunktsåterställning

Som noterats i Barman Manual är stöd för inkrementella säkerhetskopieringar, parallella jobb, datadeduplicering och nätverkskomprimering endast tillgängligt när du använder alternativet rsync. Dessutom stöds inte streaming av WAL från ett standby-läge med archive_command för närvarande.

Efter att ha följt instruktionerna i manualen för att ställa in miljön kan vi verifiera:

-bash-4.2$ barman list-server
db1 - master
db2 - replica

-bash-4.2$ barman check db1
Server db1:
      PostgreSQL: OK
      is_superuser: OK
      PostgreSQL streaming: OK
      wal_level: OK
      replication slot: OK
      directories: OK
      retention policy settings: OK
      backup maximum age: OK (no last_backup_maximum_age provided)
      compression settings: OK
      failed backups: OK (there are 0 failed backups)
      minimum redundancy requirements: OK (have 0 backups, expected at least 0)
      pg_basebackup: OK
      pg_basebackup compatible: OK
      pg_basebackup supports tablespaces mapping: OK
      archive_mode: OK
      archive_command: OK
      continuous archiving: OK
      pg_receivexlog: OK
      pg_receivexlog compatible: OK
      receive-wal running: OK
      archiver errors: OK

-bash-4.2$ barman check db2
Server db2:
      PostgreSQL: OK
      is_superuser: OK
      PostgreSQL streaming: OK
      wal_level: OK
      replication slot: OK
      directories: OK
      retention policy settings: OK
      backup maximum age: OK (no last_backup_maximum_age provided)
      compression settings: OK
      failed backups: OK (there are 0 failed backups)
      minimum redundancy requirements: OK (have 0 backups, expected at least 0)
      pg_basebackup: OK
      pg_basebackup compatible: OK
      pg_basebackup supports tablespaces mapping: OK
      archive_mode: OK
      archive_command: OK
      continuous archiving: OK
      pg_receivexlog: OK
      pg_receivexlog compatible: OK
      receive-wal running: OK
      archiver errors: OK

Allt kontrolleras OK, så vi kan testa genom att säkerhetskopiera de två värdarna:

-bash-4.2$ barman backup db1
Starting backup using postgres method for server db1 in /var/lib/barman/db1/base/20180414T091155
Backup start at LSN: 0/240001B0 (000000010000000000000024, 000001B0)
Starting backup copy via pg_basebackup for 20180414T091155
Copy done (time: 2 seconds)
Finalising the backup.
This is the first backup for server db1
WAL segments preceding the current backup have been found:
      000000010000000000000023 from server db1 has been removed
Backup size: 201.9 MiB
Backup end at LSN: 0/26000000 (000000010000000000000025, 00000000)
Backup completed (start time: 2018-04-14 09:11:55.783708, elapsed time: 2 seconds)
Processing xlog segments from file archival for db1
      000000010000000000000023
      000000010000000000000024
      000000010000000000000025.00000028.backup
Processing xlog segments from streaming for db1
      000000010000000000000024

-bash-4.2$ barman backup db2
Starting backup using postgres method for server db2 in /var/lib/barman/db2/base/20180414T091225
Backup start at LSN: 0/B0000D0 (00000001000000000000000B, 000000D0)
Starting backup copy via pg_basebackup for 20180414T091225
Copy done (time: 3 seconds)
Finalising the backup.
This is the first backup for server db2
WAL segments preceding the current backup have been found:
      000000010000000000000009 from server db2 has been removed
      00000001000000000000000A from server db2 has been removed
Backup size: 196.8 MiB
Backup end at LSN: 0/D000000 (00000001000000000000000C, 00000000)
Backup completed (start time: 2018-04-14 09:12:25.619005, elapsed time: 3 seconds)
Processing xlog segments from file archival for db2
      00000001000000000000000B
      00000001000000000000000C.00000028.backup
Processing xlog segments from streaming for db2
      00000001000000000000000B

Lista säkerhetskopieringskatalogen:

-bash-4.2$ barman list-backup all
db1 20180414T091155 - Sat Apr 14 09:11:58 2018 - Size: 217.9 MiB - WAL Size: 0 B
db2 20180414T091225 - Sat Apr 14 09:12:28 2018 - Size: 212.8 MiB - WAL Size: 0 B

Visar innehållet för en viss säkerhetskopia:

-bash-4.2$ barman list-files db1 20180414T091155 | head
/var/lib/barman/db1/base/20180414T091155/backup.info
/var/lib/barman/db1/base/20180414T091155/data/backup_label
/var/lib/barman/db1/base/20180414T091155/data/PG_VERSION
/var/lib/barman/db1/base/20180414T091155/data/postgresql.auto.conf
/var/lib/barman/db1/base/20180414T091155/data/pg_ident.conf
/var/lib/barman/db1/base/20180414T091155/data/postgresql.conf
/var/lib/barman/db1/base/20180414T091155/data/pg_hba.conf

När Barman konfigurerades för synkron WAL-strömning kan vi verifiera replikeringsstatusen:

-bash-4.2$ barman replication-status db1
Status of streaming clients for server 'db1':
Current LSN on master: 0/26000528
Number of streaming clients: 1

1. Async WAL streamer
   Application name: barman_receive_wal
   Sync stage      : 3/3 Remote write
   Communication   : TCP/IP
   IP Address      : 10.1.9.231 / Port: 37278 / Host: -
   User name       : streaming_barman
   Current state   : streaming (async)
   Replication slot: barman
   WAL sender PID  : 2046
   Started at      : 2018-04-14 09:04:03.019323+00:00
   Sent LSN   : 0/26000528 (diff: 0 B)
   Write LSN  : 0/26000528 (diff: 0 B)
   Flush LSN  : 0/26000000 (diff: -1.3 KiB)

Ytterligare förbättringar kan läggas till med hjälp av de medföljande hook-skripten.

Slutligen, för kommandoradsälskare kommer Barman med fullständig TAB-komplettering.

EDB Backup and Recovery Tool (BART)

EDB BART är en proprietär applikation med sluten källkod som tillhandahålls av EnterpriseDB. Den kombinerar PostgreSQL infödda Filesystem Level Backup och PITR till ett lättanvänt verktyg med följande funktioner:

  • lagringspolicyer
  • inkrementella säkerhetskopior
  • kompletta, heta, fysiska säkerhetskopior av flera Postgres Plus Advanced Server och PostgreSQL-databasservrar
  • hantering av säkerhetskopiering och återställning av databasservrarna på lokala eller fjärranslutna värdar
  • centraliserad katalog för säkerhetskopiering av data
  • lagra säkerhetskopierade data i komprimerat format
  • kontrollsummaverifiering

Även om testversionen för den senaste versionen v2.1 endast kan erhållas via en yum-repo-förfrågan, erbjuder artikeln Data Backup Made Easy och produktdokumentationsguiden lite information för dem som är nyfikna på att lära sig mer.

Ladda ner Whitepaper Today PostgreSQL Management &Automation med ClusterControlLäs om vad du behöver veta för att distribuera, övervaka, hantera och skala PostgreSQLDladda Whitepaper

pgBackRest

pgBackRest implementerar en fullständig systemsäkerhetskopiering som inte är beroende av de vanliga verktygen tar och rsync. Den är för närvarande värd och görs tillgänglig av CrunchyData under en MIT-licens. Se Recognition för detaljer om dess ursprung.

Den erbjuder alla funktioner man kan förvänta sig av ett PostgreSQL-centrerat verktyg:

  • hög säkerhetskopierings-/återställningskapacitet
  • fullständiga, inkrementella och differentiella säkerhetskopior
  • lagringspolicyer
  • Säkerhetskopiera och återställ integritetsverifiering genom filkontrollsummor och integration med PostgreSQL sidkontrollsummor.
  • möjlighet att återuppta säkerhetskopiering
  • strömningskomprimering och kontrollsummor
  • Stöd för Amazon S3 molnlagring
  • Kryptering

..och mycket mera. Se projektsidan för detaljer.

Installationen kräver ett 64-bitars Linux/Unix-system och det beskrivs i användarhandboken. Guiden introducerar också läsaren till huvudkoncepten, mycket användbara för dem som är nya inom PostgreSQL eller lagringsteknik.

Även om guiden använder kommandoexempel för Debian/Ubuntu är pgBackRest tillgängligt i PGDG yum-förvaret, och installationsprogrammet kommer att dra in alla beroenden:

Installerar:

pgbackrest       x86_64  2.01-1.rhel7     pgdg10  36k

Installing       for     dependencies:
perl-DBD-Pg      x86_64  2.19.3-4.el7     base    195k
perl-DBI         x86_64  1.627-4.el7      base    802k
perl-Digest-SHA  x86_64  1:5.85-4.el7     base    58k
perl-JSON-PP     noarch  2.27202-2.el7    base    55k
perl-Net-Daemon  noarch  0.48-5.el7       base    51k
perl-PlRPC       noarch  0.2020-14.el7    base    36k
perl-XML-LibXML  x86_64  1:2.0018-5.el7   base    373k
perl-version     x86_64  3:0.99.07-2.el7  base    84k

Låt oss ställa in två kluster, pg96 och pg10, som var och en har en nod:

  • kontrollnod ("repository" i guiden):

    [[email protected] ~]# cat /etc/pgbackrest.conf
    [global]
    repo1-path=/var/lib/pgbackrest
    repo1-retention-full=2
    start-fast=y
    
    [pg96]
    pg1-path=/var/lib/pgsql/9.6/data
    pg1-host=db1
    pg1-host-user=postgres
    
    [pg10]
    pg1-path=/var/lib/pgsql/10/data
    pg1-host=db2
    pg1-host-user=postgres
  • kluster #1:

    [[email protected] ~]# cat /etc/pgbackrest.conf
    [global]
    log-level-file=detail
    repo1-host=repository
    
    [pg96]
    pg1-path=/var/lib/pgsql/9.6/data
  • kluster #2:

    [[email protected] ~]# cat /etc/pgbackrest.conf
    [global]
    log-level-file=detail
    repo1-host=repository
    
    [pg10]
    pg1-path=/var/lib/pgsql/10/data

Kör sedan säkerhetskopior och visa säkerhetskopieringskatalogen:

-bash-4.2$ pgbackrest --stanza=pg96 info
stanza: pg96
   status: ok

   db (current)
      wal archive min/max (9.6-1): 00000001000000000000003D / 00000001000000000000003D

      full backup: 20180414-120727F
            timestamp start/stop: 2018-04-14 12:07:27 / 2018-04-14 12:08:01
            wal start/stop: 00000001000000000000003D / 00000001000000000000003D
            database size: 185.6MB, backup size: 185.6MB
            repository size: 12.1MB, repository backup size: 12.1MB
-bash-4.2$ pgbackrest --stanza=pg10 info
stanza: pg10
   status: ok

   db (current)
      wal archive min/max (10-1): 000000010000000000000012 / 000000010000000000000012

      full backup: 20180414-120810F
            timestamp start/stop: 2018-04-14 12:08:10 / 2018-04-14 12:08:38
            wal start/stop: 000000010000000000000012 / 000000010000000000000012
            database size: 180.5MB, backup size: 180.5MB
            repository size: 11.6MB, repository backup size: 11.6MB

pgBackRest stöder parallellisering av säkerhetskopiering och återställning — enligt exemplet i guiden, backar vi med en CPU och uppdaterar sedan konfigurationen för att använda 2 CPU:er:

--- a/etc/pgbackrest.conf
+++ b/etc/pgbackrest.conf
@@ -2,6 +2,7 @@
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
start-fast=y
+process-max=2

[pg96]
pg1-host=db1

Resultatet:

-bash-4.2$ pgbackrest --stanza=pg96 info
stanza: pg96
    status: ok

    db (current)
        wal archive min/max (9.6-1): 00000001000000000000003D / 000000010000000000000041

        full backup: 20180414-120727F
            timestamp start/stop: 2018-04-14 12:07:27 / 2018-04-14 12:08:01
            wal start/stop: 00000001000000000000003D / 00000001000000000000003D
            database size: 185.6MB, backup size: 185.6MB
            repository size: 12.1MB, repository backup size: 12.1MB

        incr backup: 20180414-120727F_20180414-121434I
            timestamp start/stop: 2018-04-14 12:14:34 / 2018-04-14 12:14:52
            wal start/stop: 00000001000000000000003F / 00000001000000000000003F
            database size: 185.6MB, backup size: 8.2KB
            repository size: 12.1MB, repository backup size: 431B
            backup reference list: 20180414-120727F

        incr backup: 20180414-120727F_20180414-121853I
            timestamp start/stop: 2018-04-14 12:18:53 / 2018-04-14 12:19:08
            wal start/stop: 000000010000000000000041 / 000000010000000000000041
            database size: 185.6MB, backup size: 8.2KB
            repository size: 12.1MB, repository backup size: 429B
            backup reference list: 20180414-120727F

Med 2 CPU:er gick säkerhetskopieringen nästan 20 % snabbare, vilket kan göra stor skillnad när du körs mot en stor datamängd.

Slutsats

PostgreSQL-centrerade säkerhetskopieringsverktyg erbjuder, som förväntat, fler alternativ än verktyg för allmänna ändamål. De flesta PostgreSQL-säkerhetskopieringsverktyg erbjuder samma kärnfunktionalitet, men deras implementering introducerar begränsningar som bara kan upptäckas genom att noggrant följa dokumentationen för att testköra produkten.

Dessutom erbjuder ClusterControl en rad säkerhetskopierings- och återställningsfunktioner som du kan använda som en del av din databashanteringskonfiguration.


  1. COS() Exempel i SQL Server

  2. Introduktion till PostgreSQL

  3. Android sqlite, begränsa antalet rader i databasen

  4. Hur använder jag ROW_NUMBER()?