Replikeringsspor og WAL-administrasjon
Forstå replikeringsspor for garantert oppbevaring av WAL og avanserte teknikker for håndtering av WAL-filer.
Replikeringsspor og WAL-administrasjon er en gratis leksjon i Avansert PostgreSQL: Indeksering, partisjonering og replikering på CoddyKit. Dette er leksjon 3 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Avansert PostgreSQL: Indeksering, partisjonering og replikering, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Avansert PostgreSQL: Indeksering, partisjonering og replikering inneholder totalt 4 leksjoner.
WAL: Hjertet i PostgreSQL
Grunnlaget for PostgreSQLs pålitelighet og replikering er Write-Ahead Log (WAL). Se på WAL som en journal som registrerer alle endringer som gjøres i databasen.
- Alle transaksjoner skriver til WAL før dataene bekreftes på disken.
- Dette sikrer dataintegriteten, selv om serveren krasjer.
- Standby-servere bruker WAL til å gjenskape endringer fra primærserveren og holde seg synkroniserte.
Utfordringen med å beholde WAL
Som standard frigjør PostgreSQL gamle WAL-filer for å spare diskplass. Dette fungerer fint på en frittstående server, men skaper en utfordring for replikering.
Hvis en standby-server blir for langt etter, kan de nødvendige WAL-filene allerede være fjernet fra primærserveren. Dette fører til:
- Replikeringsfeil: Standby-serveren klarer ikke å ta igjen forspranget.
- Manuell inngripen: Det blir nødvendig å synkronisere standby-serveren fullstendig på nytt.
Introduksjon til replikeringsspor
Replikeringsspor er PostgreSQLs løsning på problemet med å beholde WAL. Et replikeringsspor er et permanent objekt på primærserveren som hindrer at WAL-segmenter som trengs av en standby-server eller en logisk dekoder, fjernes automatisk.
- De garanterer at WAL-filer beholdes til de er lest.
- De sporer fremdriften til hver tilkoblede mottaker.
- Sporene sikrer at en standby-server alltid kan ta igjen forspranget, selv etter et langvarig avbrudd.
Slik sørger spor for trygg lagring av WAL
Når en replikasjonsplass er aktiv, vil primærserveren ikke slette WAL-filer som plassens forbruker (for eksempel en standby-server eller en logisk dekodingsprosess) ennå ikke har bekreftet som behandlet.
Dette oppretter et «bokmerke» i WAL-strømmen. Primærserveren sletter WAL-segmenter først når alle aktive plasser har passert dette punktet.
Opprette en fysisk plass
Fysiske replikasjonsplasser brukes med fysisk strømmereplikering. De sporer LSN-en (Log Sequence Number) til standby-serveren og sørger for at alle nødvendige WAL-filer beholdes for denne standby-serveren.
For å opprette en fysisk plass bruker du funksjonen pg_create_physical_replication_slot(). Erstatt my_physical_slot med et beskrivende navn.
SELECT pg_create_physical_replication_slot('my_physical_slot');Opprette en logisk plass
Logiske replikasjonsplasser brukes til logisk replikering (PostgreSQLs pub/sub-modell) eller andre programmer som bruker logisk dekoding. De dekoder WAL til en strøm med logiske endringer (for eksempel INSERT, UPDATE og DELETE).
Du angir en plugin (for eksempel pgoutput for innebygd logisk replikering) for å definere hvordan WAL-poster skal transformeres. Erstatt my_logical_slot med navnet du ønsker.
SELECT pg_create_logical_replication_slot('my_logical_slot', 'pgoutput');Overvåke replikasjonsplasser
Det er avgjørende å overvåke replikasjonsplassene for å sikre at de er aktive og ikke holder tilbake for mange WAL-filer. Visningen pg_replication_slots gir detaljert informasjon:
slot_name: Navnet på plassen.active: True hvis en forbruker er tilkoblet.restart_lsn: Den eldste WAL-LSN-en som plassen fortsatt trenger.confirmed_flush_lsn: For logiske plasser: LSN-en som forbrukeren har bekreftet.
Prøv å kjøre denne spørringen for å se eksisterende plasser:
SELECT
slot_name,
slot_type,
active,
restart_lsn,
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS wal_lag
FROM pg_replication_slots;Slette en replikasjonsplass
Når en standby-server eller logisk forbruker ikke lenger trengs, er det viktig å slette replikasjonsplassen. En ubrukt plass vil fortsette å samle opp WAL-filer på ubestemt tid, noe som kan fylle opp diskplassen på primærserveren!
Bruk funksjonen pg_drop_replication_slot() og oppgi navnet på plassen. Vær forsiktig: Hvis du sletter en aktiv plass, kobles forbrukeren fra.
SELECT pg_drop_replication_slot('my_physical_slot');Administrere diskplass og inaktive plasser
Replikasjonsplasser er kraftige, men de medfører også et ansvar: å administrere diskplassen. Inaktive plasser er en vanlig årsak til at primærservere går tom for diskplass.
- Kontroller regelmessig
pg_replication_slotsfor inaktive plasser. - Hvis en standby-server er permanent frakoblet, må du slette plassen umiddelbart.
- Overvåk
wal_lag(som vist i overvåkingsspørringen) for å oppdage trege forbrukere.
Proaktiv administrasjon forebygger driftsavbrudd!
Test om plassadministrasjon
Du har en primærserver og en standby-server som ble tatt ut av drift forrige uke. Replikasjonsplassen for denne standby-serveren, kalt old_standby_slot, ble ikke slettet. Hva er den mest sannsynlige konsekvensen for primærserveren?
Oppsummering: Replikasjonsplasser
I denne leksjonen lærte vi om PostgreSQLs replikasjonsplasser, en viktig funksjon for robust replikering og logisk dekoding.
- Plasser garanterer at WAL beholdes for tilkoblede forbrukere.
- Det finnes to typer: fysiske for strømmereplikering og logiske for logisk dekoding.
- Du kan opprette, overvåke (ved hjelp av
pg_replication_slots) og, ikke minst, slette plasser. - Administrer alltid plassene nøye for å unngå problemer med diskplassen som skyldes inaktive plasser!
Lær deg Avansert PostgreSQL: Indeksering, partisjonering og replikering med en AI-veileder – gratis
Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.
- Kurs
- 11
- Leksjoner
- 44
Ofte stilte spørsmål
Er leksjonen «Replikeringsspor og WAL-administrasjon» gratis?
Ja – hele teksten i «Replikeringsspor og WAL-administrasjon» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Avansert PostgreSQL: Indeksering, partisjonering og replikering-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Avansert PostgreSQL: Indeksering, partisjonering og replikering inneholder totalt 4 leksjoner.
Hva lærer jeg i «Replikeringsspor og WAL-administrasjon»?
Forstå replikeringsspor for garantert oppbevaring av WAL og avanserte teknikker for håndtering av WAL-filer. Du øver på Avansert PostgreSQL: Indeksering, partisjonering og replikering med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.
Trenger jeg erfaring for å begynne med Avansert PostgreSQL: Indeksering, partisjonering og replikering?
Ingen tidligere erfaring er nødvendig. Avansert PostgreSQL: Indeksering, partisjonering og replikering på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 3 av 4.
Hvor lang tid tar leksjonen «Replikeringsspor og WAL-administrasjon»?
De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.
Kan jeg skrive og kjøre kode i denne Avansert PostgreSQL: Indeksering, partisjonering og replikering-leksjonen?
Ja. Alle Avansert PostgreSQL: Indeksering, partisjonering og replikering-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.
Alle leksjonene i dette kurset
- Kaskadereplikering
- Multi-master-replikering (BDR)
- Replikeringsspor og WAL-administrasjon
- Logisk dekoding og endringsdatafangst