Forstå replikering

Se for Dem at De har en svært viktig bok. Hva om De mistet den? De ville ønsket en kopi, ikke sant?

Databasereplikering fungerer på samme måte! Det er prosessen med å opprette og vedlikeholde flere kopier av databasen.

Dette sørger for at dataene er trygge og alltid tilgjengelige, selv om noe går galt med originalen.

En av de viktigste grunnene til å bruke replikering er høy tilgjengelighet.

• Hvis hoveddatabaseserveren (originalen) krasjer, ønsker De ikke at programmene skal slutte å fungere.
• Med replikering kan en annen kopi raskt ta over.
• Dette minimerer nedetiden og holder tjenestene i stabil drift.

Tenk på et populært nettsted. Tusenvis av brukere kan lese data samtidig.

Hvis alle disse forespørslene treffer én enkelt database, kan den bli betydelig tregere.

Med replikering kan De fordele leseforespørsler på flere kopier, fordele belastningen og forbedre ytelsen for alle.

Katastrofer skjer: maskinvarefeil, naturhendelser eller til og med menneskelige feil.

Det er avgjørende for katastrofegjenoppretting å ha databasen replikert til en annen fysisk plassering eller server.

Hvis det primære datasenteret går offline, kan De bytte til en replikert kopi og dermed forhindre datatap og langvarige driftsavbrudd for virksomheten.

Det vanligste oppsettet for replikering er arkitekturen Primary-Standby (ofte kalt Master-Slave).

• Primary-serveren er den opprinnelige databasen, der alle dataendringer (skrivinger) utføres.
• Standby-serveren(e) er kopiene som mottar endringer fra primærserveren.
• Standby-servere er vanligvis skrivebeskyttet og brukes som sikkerhetskopier eller for å skalere lesing.

Primærserveren er selve hjertet i det replikerte systemet. Den har ansvar for:

• Å håndtere alle innkommende skriveoperasjoner (INSERT, UPDATE, DELETE).
• Å generere Write-Ahead Log (WAL), som registrerer hver eneste endring.
• Å sende disse WAL-postene til standby-serverne.

Tenk på den som den opprinnelige forfatteren, som skriver nye kapitler og sender dem til kopiredaktører.

Standby-serverens hovedformål er å speile primærserveren. Oppgavene omfatter:

• Å motta WAL-poster fra primærserveren.
• Å bruke disse WAL-postene på sin egen database slik at den holdes synkronisert.
• Å betjene skrivebeskyttede spørringer og dermed redusere belastningen på primærserveren.

Den fungerer som kopiredaktøren som oppdaterer sin kopi med nye kapitler fra forfatteren.

Selve kjernen i PostgreSQL-replikering er Write-Ahead Log (WAL).

WAL er en sekvens med poster som beskriver alle endringer som er gjort i databasefilene.

Før data faktisk skrives til disken, registreres endringen i WAL. Dette sikrer dataintegritet og varighet.

WAL er avgjørende for replikering fordi:

• Primærserveren strømmer WAL-postene sine til standby-serveren(e).
• Standby-serveren «spiller deretter av» disse WAL-postene.
• Ved å spille av WAL rekonstruerer standby-serveren den nøyaktige tilstanden til primærdatabasen.

Denne effektive mekanismen sikrer at standby-serverne er konsistente kopier av primærserveren.

Du har nettopp lært de grunnleggende konseptene innen databasereplikering!

• Replikering oppretter kopier av databasen for høy tilgjengelighet, skalering av lesing og gjenoppretting etter katastrofer.
• Det vanligste oppsettet består av en Primary-server og én eller flere Standby-servere.
• Write-Ahead Log (WAL) er avgjørende fordi den registrerer alle endringer og strømmes til standby-serverne for å holde dem synkronisert.

Deretter skal vi se nærmere på hvordan fysisk strømmebasert replikering settes opp!