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

Top sikkerhedskopieringsværktøjer til PostgreSQL

PostgreSQL har ry for at være bundsolid fra begyndelsen, og har gennem årene akkumuleret en række imponerende funktioner. Men trygheden i, at dine on-disk-data er ACID-kompatible - hvis den ikke suppleres med en tilsvarende velgennemtænkt backup-strategi - kan let blive knust.

Sikkerhedskopieringstyper

Inden vi dykker ned i de tilgængelige værktøjer, lad os se på de tilgængelige PostgreSQL backup-typer, og hvad deres egenskaber er:

SQL-dumps (eller logiske)

  • Blokerer ikke læsere eller skribenter.
  • Rettet mod små sæt data på grund af den negative indvirkning på systembelastningen og den lange tid, der kræves til både sikkerhedskopiering og gendannelse. Ydeevnen kan øges med flaget –no-sync, men se man-siden for de risici, der er forbundet med at deaktivere ventetiden på skrivninger.
  • En ANALYSE efter gendannelse er påkrævet for at optimere statistikken.
  • Globale objekter såsom roller og tablespaces kan kun sikkerhedskopieres ved hjælp af pg_dumpall-værktøjet. Bemærk, at tablespace-mapper skal oprettes manuelt, før gendannelsen startes.
  • Understøtter parallelitet på bekostning af øget systembelastning. Læs man pg_dump for sine forbehold og særlige krav, f.eks. synkroniserede snapshots.
  • Dumps kan indlæses i nyere versioner af PostgreSQL eller endda en anden maskinarkitektur, men de er ikke garanteret at være bagudkompatible mellem større versioner, så en vis manuel redigering af dumpfilen kan være påkrævet.

Filsystem (eller fysisk)

  • Kræver, at databasen lukkes ned.
  • Hurtigere end logiske sikkerhedskopier.
  • Inkluderer klyngedata.
  • Kan kun gendannes på den samme større version af PostgreSQL.

Kontinuerlig arkivering (eller Point In Time Recovery eller PITR)

  • Velegnet til meget store databaser, hvor logiske eller fysiske sikkerhedskopier ville tage for lang tid.
  • Nogle mapper inde i databiblioteket kan udelukkes for at fremskynde processen.

Snapshots

  • Kræver operativsystemunderstøttelse - for eksempel fungerer LVM ganske godt, hvilket også bekræftes af NetBackup for PostgreSQL Agent.
  • Velegnet til applikationer, hvor både databibliotek og database skal være synkroniseret, f.eks. LAMP-applikationer, forudsat at de to snapshots er synkroniserede.
  • Anbefales ikke, når databasefilerne er gemt på tværs af flere filsystemer (skal snapshot af alle filsystemer samtidigt).

Sky

Alle cloud-udbydere implementerer sikkerhedskopier i deres PostgreSQL-tilbud. Logiske sikkerhedskopier kan udføres som normalt, mens fysiske backups og PITR er tilgængelige gennem skytjenestetilbuddene, da adgang til datalageret ikke er tilgængelig (se f.eks. Amazon Aurora for PostgreSQL). Derfor skal sikkerhedskopiering af PostgreSQL i skyen være et emne for en anden blog.

Agentbase

  • Kræver en agent installeret på mål.
  • Kan lave sikkerhedskopier på blokniveau, f.eks. COMMVAULT (installation understøttet kun på Windows).

Funktioner

Mens PostgreSQL ud af kassen leverer de nødvendige værktøjer til at udføre logiske, fysiske og PITR-sikkerhedskopier, er specialiserede backup-applikationer afhængige af de oprindelige PostgreSQL- og operativsystemværktøjer til at opfylde behovet for at implementere en sikkerhedskopieringsstrategi, der adresserer følgende punkter:

  • automatisering
  • frekvens
  • opbevaringsperiode
  • integritet
  • brugervenlighed

Derudover forsøger PostgreSQL-sikkerhedskopieringsværktøjer at levere funktioner, der er fælles for generiske sikkerhedskopieringsværktøjer, såsom:

  • inkrementelle sikkerhedskopier for at spare lagerplads
  • sikkerhedskopikataloger
  • mulighed for at gemme sikkerhedskopier på stedet eller i skyen
  • advarsler og meddelelser
  • omfattende rapportering
  • adgangskontrol
  • kryptering
  • grafisk grænseflade og dashboards
  • sikkerhedskopier af fjernværter
  • adaptiv gennemstrømning for at minimere belastningen på målene
  • håndtering af flere værter parallelt
  • backup-orkestrering, f.eks. jobkæde
  • REST API'er

Laboratorieopsætning

Til denne øvelse har jeg konfigureret en kommando-og-kontrol-vært, hvor jeg skal installere sikkerhedskopieringsværktøjerne, som også kører to PostgreSQL-instanser - 9.6 og 10 - installeret fra PGDG-lagre:

[[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

Jeg har også opsat to eksterne PostgreSQL-instanser, der kører de samme versioner 9.6 og henholdsvis 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

Brug derefter pgbench til at oprette et datasæt:

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)

Værktøjer

En liste over almindelige sikkerhedskopieringsværktøjer kan findes i PostgreSQL Wiki — Sikkerhedskopieringssektionen. Jeg har udvidet listen med produkter, jeg er stødt på gennem årene og fra en nylig internetsøgning.

Amanda

Amanda er agentbaseret, open source og understøtter PostgreSQL ud af boksen via ampgsql API. Når dette skrives, understøtter version 3.5.1 ikke tablespaces (se man ampgsql).

Zmanda leverer en virksomhedsversion, som også er open source, dog ikke direkte tilgængelig til download som en prøveversion.

Amanda kræver en dedikeret backup-vært, da server- og klientpakkerne udelukker hinanden:

[[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ølg den grundlæggende konfigurationsvejledning for at konfigurere serveren og klienten, og konfigurer derefter PostgreSQL API.

Her er en git diff fra mit laboratorium:

  • Server:

    • øge serverens backupplads:

      --- 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
      				}
      • definer PostgreSQL-målet (og deaktiver prøvesikkerhedskopiering):

        --- 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"
      • godkendelsesfil:

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

      --- 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-godkendelse:

      --- 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 du har gennemført ovenstående konfiguration, kør sikkerhedskopien:

[[email protected] ~]$ amdump omiday

Og bekræft:

[[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)

Gendannelse fra backup involverer flere manuelle trin som forklaret i gendannelsessektionen.

Ifølge Amanda Enterprise FAQ vil følgende forbedring gælde for vores PostgreSQL-eksempel:

  • administrationskonsol til automatisering af sikkerhedskopiering, opbevaringspolitikker og tidsplaner
  • sikkerhedskopi til Amazon S3 cloud storage

Barmand

Barman er en disaster recovery-løsning til PostgreSQL vedligeholdt af 2ndQuadrant. Det er designet til at administrere sikkerhedskopier til flere databaser og har mulighed for at gendanne til et tidligere tidspunkt ved hjælp af PITR-funktionen i PostgreSQL.

Barmans funktioner på et øjeblik:

  • håndterer flere mål
  • understøttelse af forskellige PostgreSQL-versioner
  • nul datatab
  • streaming og/eller standardarkivering af WAL'er
  • lokal eller fjerngendannelse
  • forenklet gendannelse på tidspunktet

Som nævnt i Barman-manualen er understøttelse af inkrementelle sikkerhedskopier, parallelle job, datadeduplikering og netværkskomprimering kun tilgængelig, når du bruger rsync-indstillingen. Desuden er streaming af WAL'er fra en standby ved hjælp af archive_command ikke understøttet i øjeblikket.

Efter at have fulgt instruktionerne i manualen til opsætning af miljøet kan vi bekræfte:

-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

Alt tjekker OK, så vi kan teste ved at sikkerhedskopiere de to værter:

-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

Liste sikkerhedskopieringskataloget:

-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

Visning af indholdet for en bestemt sikkerhedskopi:

-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 blev konfigureret til synkron WAL-streaming, kan vi bekræfte replikeringsstatussen:

-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)

Yderligere forbedringer kan tilføjes ved hjælp af de medfølgende hook-scripts.

Til sidst, for kommandolinjeelskere, kommer Barman med fuld TAB-fuldførelse.

EDB Backup and Recovery Tool (BART)

EDB BART er en proprietær applikation med lukket kilde, leveret af EnterpriseDB. Det kombinerer PostgreSQL native Filesystem Level Backup og PITR til et brugervenligt værktøj med følgende funktioner:

  • opbevaringspolitikker
  • inkrementelle sikkerhedskopier
  • komplete, varme, fysiske sikkerhedskopier af flere Postgres Plus Advanced Server- og PostgreSQL-databaseservere
  • sikkerhedskopiering og gendannelsesstyring af databaseserverne på lokale eller eksterne værter
  • centraliseret katalog til sikkerhedskopiering af data
  • gem backup-data i komprimeret format
  • kontrolsumsbekræftelse

Mens prøveversionen for den seneste version v2.1 kun kan fås via en yum-repo-anmodning, giver artiklen Data Backup Made Easy og produktdokumentationsguiden nogle oplysninger til dem, der er nysgerrige efter at lære mere.

Download Whitepaper Today PostgreSQL Management &Automation med ClusterControlFå flere oplysninger om, hvad du skal vide for at implementere, overvåge, administrere og skalere PostgreSQLDownload Whitepaper

pgBackRest

pgBackRest implementerer en komplet systemsikkerhedskopiering, der ikke er afhængig af de almindelige værktøjer tar og rsync. Det er i øjeblikket hostet og gjort tilgængeligt af CrunchyData under en MIT-licens. Se Anerkendelse for detaljer om dens oprindelse.

Det tilbyder alle de funktioner, man kan forvente af et PostgreSQL-centreret værktøj:

  • høj backup/gendannelseskapacitet
  • fuld, trinvis og differentiel sikkerhedskopiering
  • opbevaringspolitikker
  • Sikkerhedskopier og gendan integritetsbekræftelse gennem filkontrolsummer og integration med PostgreSQL-sidekontrolsummer.
  • mulighed for at genoptage sikkerhedskopiering
  • streaming-komprimering og kontrolsummer
  • Amazon S3 cloud storage support
  • Kryptering

..og meget mere. Se projektsiden for detaljer.

Installationen kræver et 64-bit Linux/Unix-system, og det er beskrevet i brugervejledningen. Vejledningen introducerer også læseren til hovedkoncepterne, meget nyttige for dem, der er nye til PostgreSQL eller lagringsteknologi.

Selvom guiden bruger kommandoeksempler til Debian/Ubuntu, er pgBackRest tilgængelig i PGDG yum-lageret, og installationsprogrammet vil trække alle afhængigheder ind:

Installerer:

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

Lad os opsætte to klynger, pg96 og pg10, der hver har en node:

  • kontrolknude ("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
  • klynge #1:

    [[email protected] ~]# cat /etc/pgbackrest.conf
    [global]
    log-level-file=detail
    repo1-host=repository
    
    [pg96]
    pg1-path=/var/lib/pgsql/9.6/data
  • klynge #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 derefter sikkerhedskopier og vis backupkataloget:

-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 understøtter parallelisering af sikkerhedskopiering og gendannelse — efter eksemplet i vejledningen sikkerhedskopierer vi med én CPU og opdaterer derefter konfigurationen til at bruge 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 kørte sikkerhedskopien næsten 20 % hurtigere, hvilket kan gøre en stor forskel, når du kører mod et stort datasæt.

Konklusion

PostgreSQL-centrerede sikkerhedskopieringsværktøjer tilbyder, som forventet, flere muligheder end værktøjer til generelle formål. De fleste PostgreSQL-sikkerhedskopieringsværktøjer tilbyder den samme kernefunktionalitet, men deres implementering introducerer begrænsninger, som kun kan opdages ved nøje at følge dokumentationen for at prøvekøre produktet.

Derudover tilbyder ClusterControl en række sikkerhedskopierings- og gendannelsesfunktioner, som du kan bruge som en del af din databasestyringsopsætning.


  1. mysqli eller PDO - hvad er fordele og ulemper?

  2. konverter datostreng til mysql datetime-felt

  3. Fjernelse af sporfiler med ADRCI

  4. Værelse bedste måder at oprette sikkerhedskopier til offline applikation?