PostgreSQL heeft de reputatie vanaf het begin ijzersterk te zijn en heeft in de loop der jaren een reeks indrukwekkende functies verzameld. De gemoedsrust dat uw gegevens op de schijf ACID-compatibel zijn - als ze niet worden aangevuld met een gelijkwaardige, goed doordachte back-upstrategie - kan echter gemakkelijk worden vernietigd.
Back-uptypes
Laten we, voordat we in de beschikbare tools duiken, eens kijken naar de beschikbare PostgreSQL-back-uptypen en wat hun kenmerken zijn:
SQL-dumps (of logisch)
- Blokkt geen lezers of schrijvers.
- Gericht op kleine gegevenssets vanwege de negatieve impact op de systeembelasting en de lange tijd die nodig is voor zowel back-up- als herstelbewerkingen. De prestaties kunnen worden verhoogd met de vlag –no-sync, maar raadpleeg de man-pagina voor de risico's die gepaard gaan met het uitschakelen van het wachten op schrijven.
- Een ANALYSE na het herstellen is vereist om de statistieken te optimaliseren.
- Van globale objecten zoals rollen en tabelruimten kan alleen een back-up worden gemaakt met het hulpprogramma pg_dumpall. Merk op dat tablespace-mappen handmatig moeten worden gemaakt voordat het herstel wordt gestart.
- Ondersteunt parallellisme ten koste van een hogere systeembelasting. Lees man pg_dump voor zijn voorbehouden en speciale vereisten, b.v. gesynchroniseerde snapshots.
- Dumps kunnen worden geladen in nieuwere versies van PostgreSQL, of zelfs in een andere machine-architectuur, maar er wordt niet gegarandeerd dat ze achterwaarts compatibel zijn tussen de belangrijkste versies, dus enige handmatige bewerking van het dumpbestand kan nodig zijn.
Bestandssysteem (of fysiek)
- Vereist dat de database wordt afgesloten.
- Sneller dan logische back-ups.
- Omvat clustergegevens.
- Kan alleen worden hersteld op dezelfde hoofdversie van PostgreSQL.
Continu archiveren (of Point In Time Recovery of PITR)
- Geschikt voor zeer grote databases waar logische of fysieke back-ups te lang zouden duren.
- Sommige mappen in de gegevensmap kunnen worden uitgesloten om het proces te versnellen.
Momentopnamen
- Ondersteuning van het besturingssysteem vereist — LVM werkt bijvoorbeeld vrij goed, wat ook wordt bevestigd door NetBackup voor PostgreSQL Agent.
- Geschikt voor toepassingen waarbij zowel de gegevensmap als de database synchroon moeten zijn, b.v. LAMP-applicaties, op voorwaarde dat de twee snapshots gesynchroniseerd zijn.
- Niet aanbevolen wanneer de databasebestanden zijn opgeslagen op meerdere bestandssystemen (moet tegelijkertijd snapshots maken van alle bestandssystemen).
Cloud
Alle cloudproviders implementeren back-ups in hun PostgreSQL-aanbod. Logische back-ups kunnen zoals gewoonlijk worden uitgevoerd, terwijl fysieke back-ups en PITR beschikbaar zijn via het aanbod van cloudservices omdat toegang tot de gegevensopslag niet beschikbaar is (zie bijvoorbeeld Amazon Aurora voor PostgreSQL). Daarom moet het maken van een back-up van PostgreSQL in de cloud een onderwerp zijn voor een andere blog.
Agentenbestand
- Vereist een agent die op doelen is geïnstalleerd.
- Kan back-ups op blokniveau maken, b.v. COMMVAULT (installatie alleen ondersteund op Windows).
Functies
Hoewel PostgreSQL kant-en-klaar de tools biedt die nodig zijn om logische, fysieke en PITR-back-ups uit te voeren, vertrouwen gespecialiseerde back-uptoepassingen op de native PostgreSQL- en besturingssysteemtools om te voorzien in de behoefte aan het implementeren van een back-upstrategie die de volgende punten aanpakt:
- automatisering
- frequentie
- bewaarperiode
- integriteit
- gebruiksgemak
Bovendien proberen PostgreSQL-back-uptools functies te bieden die gemeenschappelijk zijn voor generieke back-uptools, zoals:
- incrementele back-ups om opslagruimte te besparen
- back-upcatalogi
- mogelijkheid om back-ups op locatie of in de cloud op te slaan
- waarschuwing en melding
- uitgebreide rapportage
- toegangscontrole
- encryptie
- grafische interface en dashboards
- back-ups van externe hosts
- adaptieve doorvoer om de belasting op de doelen te minimaliseren
- het gelijktijdig afhandelen van meerdere hosts
- back-up orkestratie b.v. banen ketenen
- REST API's
Lab-opstelling
Voor deze oefening heb ik een command-and-control-host opgezet waar ik de back-uptools zal installeren, die ook twee PostgreSQL-instanties uitvoert - 9.6 en 10 - die zijn geïnstalleerd vanuit PGDG-repositories:
[[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
Ik heb ook twee externe PostgreSQL-instanties ingesteld met dezelfde versies 9.6 en respectievelijk 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
Gebruik vervolgens pgbench om een dataset aan te maken:
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)
Extra
Een lijst met veelgebruikte back-uptools is te vinden in de sectie PostgreSQL Wiki — Back-up. Ik heb de lijst aangevuld met producten die ik in de loop der jaren en van een recente zoekopdracht op internet ben tegengekomen.
Amanda
Amanda is op agenten gebaseerd, open source en ondersteunt PostgreSQL out of the box via de ampgsql API. Op het moment van schrijven ondersteunt versie 3.5.1 geen tablespaces (zie man ampgsql).
Zmanda biedt een enterprise-versie die ook open source is, maar niet direct als proefversie beschikbaar is om te downloaden.
Amanda heeft een speciale back-uphost nodig omdat de server- en clientpakketten elkaar uitsluiten:
[[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
Volg de basisconfiguratiegids om de server en client in te stellen en configureer vervolgens de PostgreSQL API.
Hier is een git diff uit mijn lab:
-
Server:
-
verhoog de serverback-upruimte:
--- 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 }
-
definieer het PostgreSQL-doel (en schakel voorbeeldback-up uit):
--- 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
-
-
-
Klant:
-
configuratie:
--- /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"
-
authenticatiebestand:
--- /dev/null +++ b/etc/amanda/pg_passfile @@ -0,0 +1 @@ +/tmp:*:*:amandabackup:pass
-
-
autoriseer de server:
--- 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-authenticatie:
--- 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-configuratie:
--- 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
-
Nadat de bovenstaande configuratie is voltooid, voert u de back-up uit:
[[email protected] ~]$ amdump omiday
En verifieer:
[[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)
Het terugzetten vanaf een back-up omvat meer handmatige stappen, zoals uitgelegd in de herstelsectie.
Volgens de Amanda Enterprise FAQ is de volgende verbetering van toepassing op ons PostgreSQL-voorbeeld:
- beheerconsole voor automatisering van back-up, bewaarbeleid en planningen
- back-up naar Amazon S3-cloudopslag
Barman
Barman is een noodhersteloplossing voor PostgreSQL die wordt onderhouden door 2ndQuadrant. Het is ontworpen om back-ups voor meerdere databases te beheren en heeft de mogelijkheid om te herstellen naar een eerder tijdstip met behulp van de PITR-functie van PostgreSQL.
De kenmerken van Barman in één oogopslag:
- verwerkt meerdere doelen
- ondersteuning voor verschillende PostgreSQL-versies
- geen gegevensverlies
- streaming en/of standaard archivering van WAL's
- lokaal of extern herstel
- vereenvoudigd punt in tijd herstel
Zoals opgemerkt in de Barman-handleiding, is ondersteuning voor incrementele back-ups, parallelle taken, gegevensdeduplicatie en netwerkcompressie alleen beschikbaar bij gebruik van de rsync-optie. Ook wordt het streamen van WAL's vanuit een stand-by met het archive_command momenteel niet ondersteund.
Na het volgen van de instructies in de handleiding voor het instellen van de omgeving kunnen we verifiëren:
-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
Alles is in orde, dus we kunnen testen door een back-up van de twee hosts te maken:
-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
Maak een lijst van de back-upcatalogus:
-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
De inhoud van een bepaalde back-up weergeven:
-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
Toen Barman was geconfigureerd voor synchrone WAL-streaming, kunnen we de replicatiestatus verifiëren:
-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)
Verdere verbeteringen kunnen worden toegevoegd met behulp van de meegeleverde hook-scripts.
Tot slot, voor liefhebbers van commandoregels, wordt Barman geleverd met volledige TAB-aanvulling.
EDB-hulpprogramma voor back-up en herstel (BART)
EDB BART is een gesloten brontoepassing die wordt aangeboden door EnterpriseDB. Het combineert de PostgreSQL native Filesystem Level Backup en PITR in een gebruiksvriendelijke tool die de volgende functies biedt:
- retentiebeleid
- incrementele back-ups
- complete, hot, fysieke back-ups van meerdere Postgres Plus Advanced Server- en PostgreSQL-databaseservers
- back-up- en herstelbeheer van de databaseservers op lokale of externe hosts
- gecentraliseerde catalogus voor back-upgegevens
- back-upgegevens opslaan in gecomprimeerde indeling
- controlesomverificatie
Hoewel de proefversie voor de nieuwste versie v2.1 alleen kan worden verkregen via een yum repo-verzoek, bieden het artikel Data Backup Made Easy en de productdocumentatiegids wat informatie voor diegenen die nieuwsgierig zijn naar meer.
Download de whitepaper vandaag PostgreSQL-beheer en -automatisering met ClusterControlLees wat u moet weten om PostgreSQL te implementeren, bewaken, beheren en schalenDownload de whitepaperpgBackRest
pgBackRest implementeert een volledige systeemback-up die niet afhankelijk is van de algemene tools tar en rsync. Het wordt momenteel gehost en beschikbaar gesteld door CrunchyData onder een MIT-licentie. Zie Erkenning voor details over de oorsprong ervan.
Het biedt alle functies die je mag verwachten van een PostgreSQL-gecentreerde tool:
- hoge doorvoer voor back-up/herstel
- volledige, incrementele en differentiële back-ups
- retentiebeleid
- maak een back-up en herstel de integriteitsverificatie via bestandscontrolesommen en integratie met PostgreSQL-paginacontrolesommen.
- mogelijkheid om back-ups te hervatten
- streamingcompressie en controlesommen
- Amazon S3-ondersteuning voor cloudopslag
- Encryptie
..en veel meer. Raadpleeg de projectpagina voor details.
De installatie vereist een 64-bits Linux/Unix-systeem en wordt beschreven in de gebruikershandleiding. De gids laat de lezer ook kennismaken met de belangrijkste concepten, erg handig voor mensen die nieuw zijn met PostgreSQL of opslagtechnologie.
Hoewel de gids opdrachtvoorbeelden voor Debian/Ubuntu gebruikt, is de pgBackRest beschikbaar in de PGDG yum-repository, en het installatieprogramma zal alle afhankelijkheden binnenhalen:
Installeren:
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
Laten we twee clusters opzetten, pg96 en pg10, die elk één knoop hebben:
-
control node (“repository” in de gids):
[[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
-
cluster #1:
[[email protected] ~]# cat /etc/pgbackrest.conf [global] log-level-file=detail repo1-host=repository [pg96] pg1-path=/var/lib/pgsql/9.6/data
-
cluster #2:
[[email protected] ~]# cat /etc/pgbackrest.conf [global] log-level-file=detail repo1-host=repository [pg10] pg1-path=/var/lib/pgsql/10/data
Voer vervolgens back-ups uit en geef de back-upcatalogus weer:
-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 ondersteunt parallellisatie van back-up en herstel — volgens het voorbeeld in de handleiding maken we back-ups met één CPU en werken vervolgens de configuratie bij om 2 CPU's te gebruiken:
--- 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
Het resultaat:
-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
Met 2 CPU's liep de back-up bijna 20% sneller, wat een groot verschil kan maken bij het uitvoeren van een grote dataset.
Conclusie
PostgreSQL-gerichte back-uptools bieden, zoals verwacht, meer opties dan tools voor algemene doeleinden. De meeste PostgreSQL-back-uptools bieden dezelfde kernfunctionaliteit, maar hun implementatie introduceert beperkingen die alleen kunnen worden ontdekt door de documentatie zorgvuldig te volgen om het product te testen.
Daarnaast biedt ClusterControl een scala aan back-up- en herstelfuncties die u kunt gebruiken als onderdeel van uw databasebeheerconfiguratie.