PostgreSQL kan arbejde separat på flere maskiner med samme datastruktur, hvilket gør applikationens vedholdenhedslag mere modstandsdygtigt og forberedt på en uventet hændelse, der kan kompromittere tjenestens kontinuitet.
Idéen bag dette er at forbedre systemets responstid ved at distribuere anmodningerne i et "Round Robin"-netværk, hvor hver tilstedeværende node er en klynge. I denne type opsætning er det ikke vigtigt, hvilken af anmodningerne vil blive leveret til at blive behandlet, da svaret altid vil være det samme.
I denne blog vil vi forklare, hvordan man replikerer en PostgreSQL-klynge ved hjælp af værktøjerne i programinstallationen. Den anvendte version er PostgreSQL 11.5, den nuværende stabile, generelt tilgængelige version til styresystemet Debian Buster. For eksemplerne i denne blog antages det, at du allerede er fortrolig med Linux.
PostgreSQL-programmer
Inde i mappen /usr/bin/ er programmet ansvarligt for at administrere klyngen.
# 1. Lists the files contained in the directory
# 2. Filters the elements that contain 'pg_' in the name
ls /usr/bin/ | grep pg_Aktiviteter udført gennem disse programmer kan udføres sekventielt eller endda i kombination med andre programmer. At køre en blok af disse aktiviteter gennem en enkelt kommando er muligt takket være et Linux-program, der findes i samme mappe, kaldet make.
For at liste de tilstedeværende klynger, brug programmet pg_lsclusters. Du kan også bruge make til at køre det. Dets arbejde afhænger af en fil ved navn Makefile, som skal være i den samme mappe, hvor kommandoen skal køre.
# 1. The current directory is checked
pwd
# 2. Creates a directory
mkdir ~/Documents/Severalnines/
# 3. Enroute to the chosen directory
cd ~/Documents/Severalnines/
# 4. Create the file Makefile
touch Makefile
# 5. Open the file for editingDefinitionen af en blok er vist nedenfor med navnet ls og et enkelt program, der skal køres, pg_lsclusters.
# 1. Block name
ls:
# 2. Program to be executed
pg_lsclustersFilen Makefile kan indeholde flere blokke, og hver kan køre så mange programmer, som du har brug for, og endda modtage parametre. Det er bydende nødvendigt, at linjerne, der hører til en udførelsesblok, er korrekte ved at bruge tabuleringer til indrykning i stedet for mellemrum.
Brugen af make til at køre programmet pg_lsclusters opnås ved at bruge kommandoen make ls.
# 1. Executes pg_lsclusters
make lsResultatet opnået i en nylig PostgreSQL-installation bringer en enkelt klynge kaldet main, allokeret på port 5432 i operativsystemet. Når programmet pg_createcluster bruges, allokeres en ny port til den nye oprettede klynge med værdien 5432 som udgangspunkt, indtil en anden er fundet i stigende rækkefølge.
Write Ahead Logging (WAL)
Denne replikeringsprocedure består i at lave en sikkerhedskopi af en fungerende klynge, som fortsætter med at modtage opdateringer. Hvis dette gøres på den samme maskine, går mange af fordelene ved denne teknik tabt.
Skalering af et system horisontalt sikrer større tilgængelighed af tjenesten, som hvis der opstår hardwareproblemer, ville det ikke gøre den store forskel, da der er andre maskiner klar til at påtage sig arbejdsbyrden.
WAL er det udtryk, der bruges til at repræsentere en intern kompleks algoritme til PostgreSQL, der sikrer integriteten af de transaktioner, der foretages på systemet. Dog skal kun en enkelt klynge have ansvaret for at få adgang til den med skrivetilladelse.
Arkitekturen har nu tre forskellige typer klynger:
- En primær med ansvar for at skrive til WAL;
- En replika klar til at overtage den primære post;
- Forskellige andre replikaer med WAL-læsepligt.
Skrivehandlinger er alle aktiviteter, der har til formål at ændre datastrukturen, enten ved at indtaste nye elementer eller ved at opdatere og slette eksisterende poster.
PostgreSQL-klyngekonfiguration
Hver klynge har to mapper, en med dens konfigurationsfiler og en anden med transaktionslogfiler. Disse er placeret i henholdsvis /etc/postgresql/11/$(cluster) og /var/lib/postgresql/11/$(cluster) (hvor $(cluster) er navnet på klyngen).
Filen postgresql.conf oprettes umiddelbart efter at klyngen er blevet oprettet ved at køre programmet pg_createcluster, og egenskaberne kan ændres til tilpasning af en klynge.
Det anbefales ikke at redigere denne fil direkte, fordi den indeholder næsten alle egenskaber. Deres værdier er blevet kommenteret ud med symbolet # i begyndelsen af hver linje, og flere andre linjer er kommenteret ud med instruktioner til ændring af egenskabsværdierne.
Det er muligt at tilføje endnu en fil, der indeholder de ønskede ændringer, blot rediger en enkelt egenskab med navnet include, og erstat standardværdien #include ='' med include ='postgresql.replication.conf'.
Før du starter klyngen, skal du have tilstedeværelsen af filen postgresql.replication.conf i den samme mappe, hvor du finder den originale konfigurationsfil, kaldet postgresql.conf.
# 1. Block name
create:
# 2. Creates the cluster
pg_createcluster 11 $(cluster) -- --data-checksums
# 3. Copies the file to the directory
cp postgresql.replication.conf /etc/postgresql/11/$(cluster)/
# 4. A value is assigned to the property
sed -i "s|^#include = ''|include = 'postgresql.replication.conf'|g" /etc/postgresql/11/$(cluster)/postgresql.confBrugen af --data-checksums i oprettelsen af klyngen tilføjer et højere niveau af integritet til dataene, hvilket koster en smule ydeevne, men er meget vigtigt for at undgå korruption af filerne, når overføres fra en klynge til en anden.
Procedurerne beskrevet ovenfor kan genbruges til andre klynger ved blot at overføre en værdi til $(cluster) som en parameter i udførelsen af programmet make.
# 1. Executes the block 'create' by passing a parameter
sudo make create cluster=primaryNu hvor en kort automatisering af opgaverne er etableret, er det, der mangler at blive gjort, definitionen af filen postgresql.replication.conf i henhold til behovet for hver klynge.
Replikering på PostgreSQL
To måder at replikere en klynge er mulige, den ene er komplet, den anden involverer hele klyngen (kaldet Streaming Replication) og en anden kan delvis eller komplet (kaldet Logical Replication).
De indstillinger, der skal angives for en klynge, falder i fire hovedkategorier:
- Hovedserver
- Standby-servere
- Sende servere
- Abonnenter
Som vi så tidligere, er WAL en fil, der indeholder de transaktioner, der foretages på klyngen, og replikeringen er transmissionen af disse filer fra en klynge til en anden.
Inde i indstillingerne i filen postgresql.conf kan vi se egenskaber, der definerer klyngens adfærd i forhold til WAL-filerne, såsom størrelsen af disse filer.
# default values
max_wal_size = 1GB
min_wal_size = 80MBEn anden vigtig egenskab kaldet max_wal_senders. At tilhøre en klynge med karakteristiske sendeservere er mængden af processer, der er ansvarlige for at sende disse filer til andre klynger, idet de altid skal have en værdi mere end antallet af klynger, der afhænger af deres modtagelse.
WAL-filer kan gemmes til transmission til en klynge, der forbinder sent, eller som har haft nogle problemer med at modtage dem, og som har brug for tidligere filer i forhold til det aktuelle tidspunkt, med egenskaben wal_keep_segments som specifikationen for hvor mange WAL-filsegmenter, der skal vedligeholdes af en klynge.
En replikeringsplads er en funktionalitet, der gør det muligt for klyngen at gemme WAL-filer, der er nødvendige for at forsyne en anden klynge med alle posterne, med muligheden max_replication_slots som egenskab.
# default values
max_wal_senders = 10
wal_keep_segments = 0
max_replication_slots = 10Når hensigten er at outsource lagringen af disse WAL-filer, kan en anden metode til behandling af disse filer bruges, kaldet Kontinuerlig arkivering.
Kontinuerlig arkivering
Dette koncept giver dig mulighed for at dirigere WAL-filerne til en bestemt placering ved hjælp af et Linux-program og to variabler, der repræsenterer stien til filen og dens navn, såsom %p og %f, hhv.
Denne egenskab er deaktiveret som standard, men dens brug kan nemt implementeres ved at trække ansvaret for en klynge tilbage fra at gemme sådanne vigtige filer og kan tilføjes til filen postgresql.replication.conf.
# 1. Creates a directory
mkdir ~/Documents/Severalnines/Archiving
# 2. Implementation on postgresql.replication.conf
archive_mode = on
archive_command = 'cp %p ~/Documents/Severalnines/Archiving/%f'
# 3. Starts the cluster
sudo systemctl start [email protected]Efter klyngeninitialiseringen skal nogle egenskaber muligvis ændres, og det kan være nødvendigt at genstarte klyngen. Nogle egenskaber kan dog kun genindlæses uden behov for en fuldstændig genstart af en klynge.
Information om sådanne emner kan fås gennem kommentarerne i filen postgresql.conf, der vises som # (bemærk:ændring kræver genstart).
Hvis dette er tilfældet, er en enkel måde at løse det på med Linux-programmet systemctl, som tidligere blev brugt til at starte klyngen, og man behøver kun at tilsidesætte muligheden for at genstarte.
Når en fuldstændig genstart ikke er påkrævet, kan klyngen selv omtildele sine egenskaber gennem en forespørgsel, der kører i sig selv, men hvis flere klynger kører på samme maskine, vil det være nødvendigt at sende en parameter indeholdende den portværdi, som klyngen er tildelt på operativsystemet.
# Reload without restarting
sudo -H -u postgres psql -c ‘SELECT pg_reload_conf();’ -p 5433I eksemplet ovenfor kræver egenskaben archive_mode en genstart, mens archive_command ikke gør det. Efter denne korte introduktion til dette emne, lad os se på, hvordan en replika-klynge kan sikkerhedskopiere disse arkiverede WAL-filer ved hjælp af Point In Time Recovery (PITR).
PostgreSQL-replikeringspunkt-i-tidsgendannelse
Dette suggestive navn tillader en klynge at gå tilbage til sin tilstand fra en bestemt tidsperiode. Dette gøres gennem en egenskab kaldet recovery_target_timeline, som forventer at modtage en værdi i datoformat, såsom 2019-08-22 12:05 GMT, eller den seneste tildeling, der informerer om behovet for en gendannelse op til den sidste eksisterende post.
Programmet pg_basebackup, når det kører, laver en kopi af en mappe, der indeholder data fra en klynge til en anden placering. Dette program har en tendens til at modtage flere parametre, som er en af dem -R, som opretter en fil med navnet recovery.conf i den kopierede mappe, som igen ikke er den samme som den, der indeholder de andre konfigurationsfiler, der tidligere er set, såsom postgresql.conf .
Filen recovery.conf gemmer de parametre, der er videregivet i udførelsen af programmet pg_basebackup, og dens eksistens er essentiel for implementeringen af streamingreplikering, fordi det er i den, at den omvendte operation til den kontinuerlige arkivering kan udføres.
# 1. Block name
replicate:
# 2. Removes the current data directory
rm -rf /var/lib/postgresql/11/$(replica)
# 3. Connects to primary cluster as user postgres
# 4. Copies the entire data directory
# 5. Creates the file recovery.conf
pg_basebackup -U postgres -d postgresql://localhost:$(primaryPort) -D /var/lib/postgresql/11/$(replica) -P -R
# 6. Inserts the restore_command property and its value
echo "restore_command = 'cp ~/Documents/Severalnines/Archiving/%f %p'" >> /var/lib/postgresql/11/$(replica)/recovery.conf
# 7. The same is done with recovery_target_timeline
echo "recovery_target_timeline = 'latest'" >> /var/lib/postgresql/11/$(replica)/recovery.confDenne replikatblok specificeret ovenfor skal køres af operativsystemets postgres-bruger for at undgå potentielle konflikter med, hvem der er ejeren af klyngedataene, postgres eller brugerroden.
Replika-klyngen står stadig og baster den for at starte replikationen, idet replika-klyngen-processen kaldet pg_walreceiver interagerer med den primære klynge kaldet pg_walsender over en TCP-forbindelse.
# 1. Executes the block ‘replicate’ by passing two parameters
sudo -H -u postgres make replicate replica=replica primaryPort=5433
# 2. Starts the cluster replica
sudo systemctl start [email protected]Verifikation af tilstanden af denne replikeringsmodel, kaldet Streaming Replication, udføres af en forespørgsel, der køres på den primære klynge.
# 1. Checks the Streaming Replication created
sudo -H -u postgres psql -x -c ‘select * from pg_stat_replication;’ -p 5433Konklusion
I denne blog viste vi, hvordan man opsætter asynkron streaming-replikering mellem to PostgreSQL-klynger. Husk dog, at der findes sårbarheder i koden ovenfor, for eksempel anbefales det ikke at bruge postgres-brugeren til at udføre en sådan opgave.
Replikeringen af en klynge giver flere fordele, når den bruges på den rigtige måde og har nem adgang til de API'er, der kommer til at interagere med klyngerne.