Ops\u00e6tning af replikering mellem to databaser giver fejltolerance mod uventede uheld. Det anses for at v\u00e6re den bedste strategi til at opn\u00e5 h\u00f8j tilg\u00e6ngelighed under katastrofer.<\/p>\n
I denne artikel dykker vi ned i de forskellige strategier, der kan implementeres af backend-udviklere<\/a> til problemfri PostgreSQL-replikation. PostgreSQL replikering er defineret som processen med at kopiere data fra en PostgreSQL-databaseserver<\/a> til en anden server. Kildedatabaseserveren er ogs\u00e5 kendt som den “prim\u00e6re” server, mens den databaseserver, der modtager de kopierede data, er kendt som “replika”-serveren.<\/p>\n PostgreSQL-databasen f\u00f8lger en simpel replikationsmodel, hvor alle skrivninger g\u00e5r til en prim\u00e6r knude. Den prim\u00e6re knude kan derefter anvende disse \u00e6ndringer og sende dem til sekund\u00e6re knuder.<\/p>\n Failover er en metode til at genoprette data, hvis den prim\u00e6re server<\/a> af en eller anden grund giver op. S\u00e5 l\u00e6nge du har konfigureret PostreSQL til at administrere din fysiske streamingreplikation, vil du – og dine brugere – v\u00e6re beskyttet mod nedetid p\u00e5 grund af en fejl p\u00e5 den prim\u00e6re server.<\/p>\n Bem\u00e6rk, at failover-processen kan tage noget tid at ops\u00e6tte og starte. Der er ingen indbyggede v\u00e6rkt\u00f8jer til overv\u00e5gning og omfang af serverfejl i PostgreSQL, s\u00e5 du bliver n\u00f8dt til at v\u00e6re kreativ.<\/p>\n Heldigvis beh\u00f8ver du ikke at v\u00e6re afh\u00e6ngig af PostgreSQL til failover. Der findes dedikerede v\u00e6rkt\u00f8jer, der muligg\u00f8r automatisk failover og automatisk skift til standby, hvilket reducerer nedetiden for databasen<\/a>.<\/p>\n Ved at ops\u00e6tte failover-replikation garanterer du n\u00e6sten h\u00f8j tilg\u00e6ngelighed ved at sikre, at standbys er tilg\u00e6ngelige, hvis den prim\u00e6re server nogensinde bryder sammen.<\/p>\n Her er et par vigtige fordele ved at udnytte PostgreSQL replikering:<\/p>\n Generelt tror folk, at n\u00e5r man dribler med en prim\u00e6r og sekund\u00e6r arkitektur, er der kun \u00e9n m\u00e5de at ops\u00e6tte backups<\/a> og replikering p\u00e5. PostgreSQL-implementeringer kan imidlertid f\u00f8lge en af disse tre metoder<\/a>:<\/p>\n PostgreSQL-streamingreplikation, ogs\u00e5 kendt som WAL-replikation, kan ops\u00e6ttes problemfrit efter installation af PostgreSQL p\u00e5 alle servere. Denne tilgang til replikering er baseret p\u00e5 at flytte WAL-filerne fra den prim\u00e6re til m\u00e5ldatabasen.<\/p>\n Du kan implementere PostgreSQL-streamingreplikation ved at bruge en prim\u00e6r-sekund\u00e6r konfiguration. Den prim\u00e6re server er den prim\u00e6re instans, der h\u00e5ndterer den prim\u00e6re database og alle dens operationer. Den sekund\u00e6re server fungerer som den supplerende instans og udf\u00f8rer alle \u00e6ndringer i den prim\u00e6re database p\u00e5 sig selv og genererer i den forbindelse en identisk kopi. Den prim\u00e6re server er en skrive\/l\u00e6se-server, mens den sekund\u00e6re server kun er skrivebeskyttet.<\/p>\n Ved denne metode skal du konfigurere b\u00e5de den prim\u00e6re knude og standbyknuden. I de f\u00f8lgende afsnit forklares de trin, der er n\u00f8dvendige for at konfigurere dem nemt.<\/p>\n Du kan konfigurere den prim\u00e6re knude til streamingreplikation ved at udf\u00f8re f\u00f8lgende trin:<\/p>\n For at initialisere databasen<\/a> kan du bruge kommandoen Brugeren skal angive et password og et brugernavn til den givne foresp\u00f8rgsel. N\u00f8gleordet replikation bruges til at give brugeren de n\u00f8dvendige rettigheder. En eksempelforesp\u00f8rgsel ville se nogenlunde s\u00e5dan ud:<\/p>\n Dern\u00e6st kan du konfigurere streamingegenskaberne med PostgreSQL-konfigurationsfilen (postgresql.conf<\/strong>), der kan \u00e6ndres som f\u00f8lger:<\/p>\n Her er lidt baggrund omkring de parametre, der blev brugt i det foreg\u00e5ende uddrag:<\/p>\n N\u00e5r du har \u00e6ndret parametrene i filen postgresql.conf<\/strong>, kan en ny replikeringspost i filen pg_hba.conf<\/strong> give serverne mulighed for at etablere en forbindelse med hinanden med henblik p\u00e5 replikering.<\/p>\n Du kan normalt finde denne fil i PostgreSQL’s datamappe. Du kan bruge f\u00f8lgende kodestump til det samme:<\/p>\n N\u00e5r kodeudsnittet er blevet udf\u00f8rt, tillader den prim\u00e6re server en bruger kaldet F\u00f8lg disse trin for at konfigurere standbyknuden til streamingreplikation:<\/p>\n For at konfigurere standbyknuden skal du bruge v\u00e6rkt\u00f8jet De parametre, der anvendes i ovenn\u00e6vnte syntaks, er f\u00f8lgende:<\/p>\n Dern\u00e6st skal du kontrollere, om replikeringskonfigurationsfilen findes. Hvis den ikke g\u00f8r det, kan du generere replikeringskonfigurationsfilen som recovery.conf<\/strong>.<\/p>\n Du skal oprette denne fil i datamappen i PostgreSQL-installationen. Du kan generere den automatisk ved at bruge indstillingen Recovery.conf<\/strong>-filen skal indeholde f\u00f8lgende kommandoer:<\/p>\n De parametre, der anvendes i ovenn\u00e6vnte kommandoer, er f\u00f8lgende:<\/p>\n Hvis du vil oprette en forbindelse, skal du angive brugernavn, IP-adresse og password som v\u00e6rdier for parameteren primary_conninfo. F.eks:<\/p>\n Endelig kan du genstarte den sekund\u00e6re server for at afslutte konfigurationsprocessen.<\/p>\n Streaming replikering er dog forbundet med flere udfordringer, f.eks:<\/p>\n Metoden med replikeret blokanordning er afh\u00e6ngig af diskspejling (ogs\u00e5 kendt som volumenreplikation). I denne metode skrives \u00e6ndringer til et vedvarende volumen, som synkront spejles til et andet volumen.<\/p>\n Den ekstra fordel ved denne metode er dens kompatibilitet og holdbarhed af data i cloud-milj\u00f8er med alle relationelle databaser, herunder PostgreSQL, MySQL og SQL Server<\/a>, for blot at n\u00e6vne nogle f\u00e5.<\/p>\n Diskspejlingstilgangen til PostgreSQL-replikering kr\u00e6ver dog, at du replikerer b\u00e5de WAL-log- og tabeldata. Da hver skrivning til databasen nu skal g\u00e5 synkront over netv\u00e6rket, har du ikke r\u00e5d til at miste en enkelt byte, da det kan efterlade din database i en korrupt tilstand.<\/p>\n Denne metode udnyttes normalt ved hj\u00e6lp af Azure PostgreSQL og Amazon RDS.<\/p>\n WAL best\u00e5r af segmentfiler (16 MB som standard). Hvert segment har en eller flere poster. En logsekvenspost (LSN) er en pegepind til en post i WAL, der fort\u00e6ller dig om positionen\/placeringen, hvor posten er blevet gemt i logfilen.<\/p>\n En standby-server udnytter WAL-segmenter – ogs\u00e5 kendt som XLOGS i PostgreSQL-terminologi – til l\u00f8bende at replikere \u00e6ndringer fra den prim\u00e6re server. Du kan bruge write-ahead logging til at sikre holdbarhed og atomicitet i et DBMS ved at serialisere bidder af byte-array-data (hver med et unikt LSN) til stabil lagring, f\u00f8r de anvendes i en database.<\/p>\n Anvendelse af en mutation p\u00e5 en database kan f\u00f8re til forskellige filsystemoperationer. Et relevant sp\u00f8rgsm\u00e5l er, hvordan en database kan sikre atomicitet i tilf\u00e6lde af en serverfejl som f\u00f8lge af str\u00f8mafbrydelse, mens den er midt i en filsystemopdatering. N\u00e5r en database starter op, starter den en opstarts- eller replay-proces, som kan l\u00e6se de tilg\u00e6ngelige WAL-segmenter og sammenligne dem med det LSN, der er gemt p\u00e5 hver dataside (hver dataside er markeret med LSN’et for den seneste WAL-record, der p\u00e5virker siden).<\/p>\n Streamingreplikation forfiner logforsendelsesprocessen. I stedet for at vente p\u00e5 WAL-skiftet sendes posterne, efterh\u00e5nden som de oprettes, hvilket mindsker replikationsforsinkelsen.<\/p>\n Streamingreplikation er ogs\u00e5 bedre end logforsendelse, fordi standby-serveren er forbundet med den prim\u00e6re server via netv\u00e6rket ved hj\u00e6lp af en replikationsprotokol. Den prim\u00e6re server kan derefter sende WAL-poster direkte over denne forbindelse uden at skulle v\u00e6re afh\u00e6ngig af scripts, der leveres af slutbrugeren.<\/p>\n Logforsendelse er defineret som kopiering af logfiler til en anden PostgreSQL-server for at generere en anden standby-server ved at genindspille WAL-filer. Denne server er konfigureret til at arbejde i genoprettelsestilstand, og dens eneste form\u00e5l er at anvende alle nye WAL-filer, efterh\u00e5nden som de dukker op.<\/p>\n Denne sekund\u00e6re server bliver derefter en varm backup af den prim\u00e6re PostgreSQL-server. Den kan ogs\u00e5 konfigureres til at v\u00e6re en l\u00e6sereplica, hvor den kan tilbyde foresp\u00f8rgsler med skrivebeskyttet l\u00e6sning, ogs\u00e5 kaldet hot standby.<\/p>\n Duplikering af WAL-filer, efterh\u00e5nden som de oprettes, til en anden placering end undermappen Scriptet kan udnytte kommandoen Andre logbaserede konfigurationer omfatter:<\/p>\n En proces kaldet WAL-modtager, der k\u00f8rer p\u00e5 standby-serveren, udnytter forbindelsesoplysningerne i parameteren For at starte streamingreplikation kan frontend’en sende replikationsparameteren i startmeddelelsen. En boolsk v\u00e6rdi p\u00e5 true, yes, 1 eller ON lader backend’en<\/a> vide, at den skal g\u00e5 i fysisk replikering walsender-tilstand.<\/p>\n WAL-sender er en anden proces, der k\u00f8rer p\u00e5 den prim\u00e6re server og er ansvarlig for at sende WAL-posterne til standby-serveren, efterh\u00e5nden som de bliver genereret. WAL-modtageren gemmer WAL-posterne i WAL, som om de blev oprettet af klientaktivitet fra lokalt tilsluttede klienter.<\/p>\n N\u00e5r WAL-posterne n\u00e5r frem til WAL-segmentfilerne, bliver standby-serveren konstant ved med at afspille WAL-posterne igen, s\u00e5 prim\u00e6r- og standby-serveren er opdateret.<\/p>\n I dette afsnit f\u00e5r du en dybere forst\u00e5else af de almindeligt anvendte modeller (single-master og multi-master replikering), typer (fysisk og logisk replikering) og tilstande (synkron og asynkron) for PostgreSQL replikering.<\/p>\n Skalerbarhed betyder at tilf\u00f8je flere ressourcer\/hardware til eksisterende knudepunkter for at forbedre databasens evne til at lagre og behandle flere data, hvilket kan opn\u00e5s horisontalt og vertikalt. PostgreSQL-replikering er et eksempel p\u00e5 horisontal skalerbarhed, som er meget vanskeligere at implementere end vertikal skalerbarhed. Vi kan opn\u00e5 horisontal skalerbarhed hovedsageligt ved hj\u00e6lp af single-master replikation (SMR) og multi-master replikation (MMR).<\/p>\n Ved single-master-replikation kan data kun \u00e6ndres p\u00e5 en enkelt knude, og disse \u00e6ndringer replikeres til en eller flere knudepunkter. De replikerede tabeller i replika-databasen m\u00e5 ikke acceptere nogen \u00e6ndringer, undtagen \u00e6ndringer fra den prim\u00e6re server. Selv hvis de g\u00f8r det, replikeres \u00e6ndringerne ikke tilbage til den prim\u00e6re server.<\/p>\n Oftest er SMR tilstr\u00e6kkeligt til applikationen, fordi det er mindre kompliceret at konfigurere og administrere, og fordi der ikke er nogen risiko for konflikter. Single-master-replikering er ogs\u00e5 ensrettet, da replikeringsdata hovedsageligt str\u00f8mmer i \u00e9n retning, nemlig fra den prim\u00e6re til replika-databasen.<\/p>\n I nogle tilf\u00e6lde er SMR alene m\u00e5ske ikke tilstr\u00e6kkeligt, og det kan v\u00e6re n\u00f8dvendigt at implementere MMR. MMR giver mulighed for, at mere end \u00e9n knude kan fungere som prim\u00e6r knude. \u00c6ndringer af tabelr\u00e6kker i mere end \u00e9n udpeget prim\u00e6r database replikeres til deres modstykke-tabeller i alle andre prim\u00e6re databaser. I denne model anvendes der ofte konfliktl\u00f8sningsordninger for at undg\u00e5 problemer som f.eks. duplikerede prim\u00e6re n\u00f8gler.<\/p>\n Der er nogle f\u00e5 fordele ved at anvende MMR, nemlig<\/p>\n Ulempen ved implementering af MMR er imidlertid kompleksiteten og vanskeligheden ved at l\u00f8se konflikter.<\/p>\n Flere filialer og applikationer tilbyder MMR-l\u00f8sninger, da PostgreSQL ikke underst\u00f8tter det nativt. Disse l\u00f8sninger kan v\u00e6re open source<\/a>-l\u00f8sninger, gratis eller betalte. En s\u00e5dan udvidelse<\/a> er bidirektionel replikering (BDR), som er asynkron og er baseret p\u00e5 PostgreSQL’s logiske afkodningsfunktion.<\/p>\n Da BDR-applikationen gengiver transaktioner p\u00e5 andre knudepunkter, kan gengivelsesoperationen mislykkes, hvis der er en konflikt mellem den transaktion, der anvendes, og den transaktion, der er beg\u00e5et p\u00e5 den modtagende knudepunkt.<\/p>\n Der findes to typer PostgreSQL-replikering: logisk og fysisk replikering.<\/p>\n En simpel logisk<\/em> operation – Fysisk replikering vedr\u00f8rer normalt filer og mapper. Den ved ikke, hvad disse filer og mapper repr\u00e6senterer. Disse metoder bruges til at opretholde en fuld kopi af alle data i en enkelt klynge, typisk p\u00e5 en anden maskine, og de udf\u00f8res p\u00e5 filsystemniveau eller diskniveau og anvender n\u00f8jagtige blokadresser.<\/p>\n Logisk replikation er en m\u00e5de at reproducere dataenheder og deres \u00e6ndringer p\u00e5, baseret p\u00e5 deres replikationsidentitet (normalt en prim\u00e6r n\u00f8gle). I mods\u00e6tning til fysisk replikering omhandler den databaser, tabeller og DML-operationer og udf\u00f8res p\u00e5 databaseklyngeniveau. Den anvender en udgivelses-<\/em> og abonnementsmodel<\/em>, hvor en eller flere abonnenter<\/em> abonnerer p\u00e5 en eller flere publikationer<\/em> p\u00e5 en udgiverknude<\/em>.<\/p>\n Replikationsprocessen starter med at tage et \u00f8jebliksbillede af dataene i udgiverdatabasen og derefter kopiere dem til abonnenten. Abonnenterne henter data fra de publikationer, de abonnerer p\u00e5, og kan senere genudgive data for at muligg\u00f8re kaskadeopdatering eller mere komplekse konfigurationer. Abonnenten anvender dataene i samme r\u00e6kkef\u00f8lge som udgiveren, s\u00e5ledes at der garanteres transaktionsm\u00e6ssig konsistens for publikationer inden for et enkelt abonnement, ogs\u00e5 kendt som transaktionsm\u00e6ssig replikering.<\/p>\n De typiske anvendelsestilf\u00e6lde for logisk replikering er f\u00f8lgende:<\/p>\n Subscriber-databasen opf\u00f8rer sig p\u00e5 samme m\u00e5de som enhver anden PostgreSQL-instans og kan bruges som udgiver for andre databaser ved at definere dens publikationer.<\/p>\n N\u00e5r abonnenten behandles som skrivebeskyttet af programmet, vil der ikke v\u00e6re nogen konflikter fra et enkelt abonnement. P\u00e5 den anden side, hvis der er andre skrivninger udf\u00f8rt enten af et program eller af andre abonnenter til det samme s\u00e6t tabeller, kan der opst\u00e5 konflikter.<\/p>\n PostgreSQL underst\u00f8tter begge mekanismer samtidig. Logisk replikation giver mulighed for finkornet kontrol over b\u00e5de datareplikation og sikkerhed.<\/p>\n Der er hovedsageligt to tilstande for PostgreSQL-replikering: synkron og asynkron. Synkron replikering g\u00f8r det muligt at skrive data til b\u00e5de den prim\u00e6re og sekund\u00e6re server p\u00e5 samme tid, mens asynkron replikering sikrer, at dataene f\u00f8rst skrives til hosten og derefter kopieres til den sekund\u00e6re server.<\/p>\n Ved synkron replikering anses transaktioner i den prim\u00e6re database f\u00f8rst for at v\u00e6re afsluttet, n\u00e5r \u00e6ndringerne er blevet replikeret til alle replikaer. Replikaserverne skal alle v\u00e6re tilg\u00e6ngelige hele tiden, for at transaktionerne kan afsluttes p\u00e5 den prim\u00e6re database. Den synkrone replikeringstilstand anvendes i avancerede transaktionsmilj\u00f8er med krav om \u00f8jeblikkelig failover.<\/p>\n I asynkron tilstand kan transaktioner p\u00e5 den prim\u00e6re server erkl\u00e6res for afsluttet, n\u00e5r \u00e6ndringerne kun er blevet foretaget p\u00e5 den prim\u00e6re server. Disse \u00e6ndringer replikeres s\u00e5 senere i replikkerne. Replikaserverne kan forblive usynkroniserede i en vis periode, kaldet replikationsforsinkelse. I tilf\u00e6lde af et nedbrud kan der opst\u00e5 datatab, men det overhead, som asynkron replikering giver, er lille, s\u00e5 det er acceptabelt i de fleste tilf\u00e6lde (det overbelaster ikke hosten). Failover fra den prim\u00e6re database til den sekund\u00e6re database tager l\u00e6ngere tid end synkron replikering.<\/p>\n I dette afsnit vil vi demonstrere hvordan PostgreSQL replikeringsprocessen ops\u00e6ttes p\u00e5 et Linux-operativsystem. I dette tilf\u00e6lde bruger vi Ubuntu 18.04 LTS og PostgreSQL 10.<\/p>\n
\nHvad er PostgreSQL replikering?<\/h2>\n
![\"En](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/PostgreSQL-Replication-Illustration.png\")
Hvad er automatisk fejlfinding?<\/h3>\n
Fordele ved at bruge PostgreSQL Replication<\/h2>\n
\n
S\u00e5dan fungerer PostgreSQL replikering<\/h2>\n
\n
Metode 1: Streaming<\/h3>\n
Konfiguration af den prim\u00e6re knude<\/h4>\n
Trin 1: Initialis\u00e9r databasen<\/h5>\n
initdb<\/code> utility command. Derefter kan du oprette en ny bruger med replikeringsrettigheder ved at bruge f\u00f8lgende kommando:<\/p>\nCREATE USER 'example_username' REPLICATION LOGIN ENCRYPTED PASSWORD 'example_password';<\/code><\/pre>\nCREATE USER 'rep_username' REPLICATION LOGIN ENCRYPTED PASSWORD 'rep_password';<\/code><\/pre>\nTrin 2: Konfigurer Streaming-egenskaber<\/h5>\n
wal_level = logical\nwal_log_hints = on\nmax_wal_senders = 8\nmax_wal_size = 1GB\nhot_standby = on<\/code><\/pre>\n\n
wal_log_hints<\/code>:<\/strong> Denne parameter er n\u00f8dvendig for pg_rewind<\/code> -funktionen, som er praktisk, n\u00e5r standby-serveren ikke er synkroniseret med den prim\u00e6re server.<\/li>\nwal_level<\/code>:<\/strong> Du kan bruge denne parameter til at aktivere PostgreSQL streaming replikation, med mulige v\u00e6rdier, herunder minimal<\/code>, replica<\/code>, eller logical<\/code>.<\/li>\nmax_wal_size<\/code>:<\/strong> Dette kan bruges til at angive st\u00f8rrelsen af WAL-filer, der kan bevares i logfiler.<\/li>\nhot_standby<\/code>:<\/strong> Du kan udnytte denne parameter til en read-on-forbindelse med den sekund\u00e6re, n\u00e5r den er indstillet til ON.<\/li>\nmax_wal_senders<\/code>:<\/strong> Du kan bruge max_wal_senders<\/code> til at angive det maksimale antal samtidige forbindelser, der kan etableres med standbyserverne.<\/li>\n<\/ul>\nTrin 3: Opret ny post<\/h5>\n
host replication rep_user IPaddress md5<\/code><\/pre>\nrep_user<\/code> at oprette forbindelse og fungere som standby-server ved at bruge den angivne IP til replikation. F.eks:<\/p>\nhost replication rep_user 192.168.0.22\/32 md5<\/code><\/pre>\nKonfigurering af standby-knude<\/h4>\n
Trin 1: Sikkerhedskopiering af prim\u00e6r knude<\/h5>\n
pg_basebackup<\/code> til at generere en sikkerhedskopi af den prim\u00e6re knude. Dette vil tjene som udgangspunkt for standbyknuden. Du kan bruge dette hj\u00e6lpeprogram med f\u00f8lgende syntaks:<\/p>\npg_basebackp -D -h -X stream -c fast -U rep_user -W<\/code><\/pre>\n\n
-h<\/code>:<\/strong> Du kan bruge dette til at n\u00e6vne den prim\u00e6re host.<\/li>\n-D<\/code>:<\/strong> Denne parameter angiver den mappe, du arbejder p\u00e5 i \u00f8jeblikket.<\/li>\n-C<\/code>:<\/strong> Du kan bruge denne parameter til at angive kontrolpunkterne.<\/li>\n-X<\/code>:<\/strong> Denne parameter kan bruges til at medtage de n\u00f8dvendige transaktionslogfiler.<\/li>\n-W<\/code>:<\/strong> Du kan bruge denne parameter til at bede brugeren om et password, f\u00f8r der oprettes en forbindelse til databasen.<\/li>\n<\/ul>\nTrin 2: Ops\u00e6tning af konfigurationsfil til replikering<\/h5>\n
-R<\/code> i v\u00e6rkt\u00f8jet pg_basebackup<\/code>.<\/p>\nstandby_mode = 'on'\n\nprimary_conninfo = 'host=<master_host> port=<postgres_port> user=<replication_user> password=<password> application_name=\"host_name\"'\n\nrecovery_target_timeline = 'latest'<\/code><\/pre>\n\n
primary_conninfo<\/code>:<\/strong> Du kan bruge dette til at oprette en forbindelse mellem den prim\u00e6re og den sekund\u00e6re server ved at udnytte en forbindelsesstreng.<\/li>\nstandby_mode<\/code>:<\/strong> Denne parameter kan f\u00e5 den prim\u00e6re server til at starte som standby-server, n\u00e5r den t\u00e6ndes.<\/li>\nrecovery_target_timeline<\/code>:<\/strong> Du kan bruge denne parameter til at indstille genoprettelsestiden.<\/li>\n<\/ul>\nprimary_conninfo = 'host=192.168.0.26 port=5432 user=rep_user password=rep_pass'<\/code><\/pre>\nTrin 3: Genstart sekund\u00e6r server<\/h5>\n
\n
Metode 2: Replikeret blokanordning<\/h3>\n
Metode 3: WAL<\/h3>\n
Log Shipping-baseret replikering (blokniveau)<\/h4>\n
Replikering baseret p\u00e5 logforsendelse (filniveau)<\/h4>\n
Kontinuerlig WAL-arkivering<\/h4>\n
pg_wal<\/code> for at arkivere dem, kaldes WAL-arkivering. PostgreSQL kalder et script, som brugeren har angivet til arkivering, hver gang en WAL-fil oprettes.<\/p>\nscp<\/code> til at duplikere filen til et eller flere steder, f.eks. en NFS-montering. N\u00e5r de er arkiveret, kan WAL-segmentfilerne udnyttes til at gendanne databasen p\u00e5 et hvilket som helst tidspunkt.<\/p>\n\n
Detaljer om WAL-streamingprotokollen<\/h4>\n
primary_conninfo<\/code> i recovery.conf<\/strong> og opretter forbindelse til den prim\u00e6re server ved hj\u00e6lp af en TCP\/IP-forbindelse.<\/p>\n![\"Et](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/WAL-Streaming-Protocol-Details.png\")
Elementer af PostgreSQL-replikering<\/h2>\n
Modeller for PostgreSQL-databasereplikering<\/h3>\n
\n
Typer af PostgreSQL-replikering<\/h3>\n
initdb<\/code> – ville udf\u00f8re den fysiske operation med at oprette en basismappe for en klynge. P\u00e5 samme m\u00e5de vil en simpel logisk<\/em> operation CREATE DATABASE<\/code> udf\u00f8re den fysiske<\/em> operation med at oprette en undermappe i basismappen.<\/p>\n\n
Replikationsformer<\/h3>\n
S\u00e5dan ops\u00e6ttes PostgreSQL replikering<\/h2>\n