PostgreSQL streaming replikering vs logisk replikering

Jeg betragter mig selv som lidt af en opdagelsesrejsende. I visse ting altså. Jeg vil typisk altid bestille den samme mad fra en velkendt restaurant, fordi frygt for skuffelse opvejer min frygt for at prøve noget nyt.

Og selvfølgelig har et sultent menneske en tendens til bare at spise ikke?

Alligevel, når det kommer til teknologi, især SQL (PostgreSQL), har jeg en tendens til at snuble fuld fart (min definition af udforskning) ind i ofte ukendte områder med håb om at lære. Hvilken bedre måde at lære end erfaring?

Så hvad i alverden har denne vandring at gøre med logisk og streaming-replikering i PostgreSQL?

Jeg er en komplet novice inden for disse områder med ingen viden. Ja, jeg har omtrent lige så stor forståelse for dette område af Postgres, som jeg har inden for astrofysik.

Fik jeg nævnt, at jeg ikke havde nogen viden?

Derfor vil jeg i dette blogindlæg forsøge at fordøje forskellene i disse typer af replikering. Uden praktisk erfaring fra den virkelige verden kan jeg ikke love dig 'Be all end all ' manuskript til replikering.

Sandsynligvis vil andre, der er mindre fortrolige med dette særlige område (såsom jeg selv), drage fordel af dette blogindlæg.

Erfarne brugere og udviklere med på turen, jeg håber at se dig i kommentarerne nedenfor.

Et par basisdefinitioner

I den brede betydning af begrebet, hvad betyder replikering?

Replikering som defineret på Wiktionary har dette at sige:

"Proces, hvorved et objekt, en person, et sted eller en idé kan kopieres efterlignet eller reproduceret."

Alligevel er det femte punkt på listen mere relevant for dette blogindlæg, og jeg føler, at vi også bør se på det:

"(computing) Processen med hyppige elektroniske data, der kopierer en database i én computer eller server til en database i en anden, så alle brugere deler det samme informationsniveau. Bruges til at forbedre systemets fejltolerance."

Nu er der noget vi kan komme ind på. Omtalen af ​​kopiering af data fra en server eller database til en anden? Vi er i velkendt territorium nu...

Så hvis vi tilføjer, hvad vi kender fra den definition, hvad er definitionerne af streaming replikering og logisk replikering?

Lad os se, hvad PostgreSQL Wiki har at tilbyde:

Streaming-replikering:"giver mulighed for kontinuerligt at sende og anvende WAL XLOG-posterne på et vist antal standby-servere for at holde dem opdaterede.

Og PostgreSQL-dokumentationen har denne definition for logisk replikering:

"Logisk replikering er en metode til at replikere dataobjekter og deres ændringer, baseret på deres replikeringsidentitet (normalt en primær nøgle). Vi bruger udtrykket logisk i modsætning til fysisk replikering, som bruger nøjagtige blokadresser og byte-for-byte replikering. "

Kapitel 19.6 Replikering fra den officielle dokumentation er også fyldt med lækkerier, så vær sikker og besøg den kilde.

Nedenfor vil jeg forsøge at videregive forskellene i lægmands vilkår. (Husk, at hvis jeg snubler, er jeg en novice.) Dette er en ekstrem oversigt på 'højt niveau'.

Logisk replikering

En "kilde"-database opretter en PUBLICATION ved hjælp af CREATE PUBLICATION-kommandoen. (Jeg tænker på dette i enkle vendinger som 'afsenderen'.)

Dokumentationen betegner den som udgiver.

Denne udgiverdatabase har de data, vi ønsker at replikere. Alligevel skal vi have noget at replikere til, og det er her, udgiverens modpart(er) kommer ind. 'Abonnenten'. Bemærk, at jeg har indsat en alternativ flertalsform, fordi ud fra hvad jeg har fundet gennem onlinesøgninger, er det en praktisk opsætning at have flere abonnenter.

En 'abonnent' (kan også opfattes som replikadatabasen) opretter et ABONNEMENT på en "kilde"-database (udgiver), der definerer forbindelsesoplysninger og alle publikationer, den abonnerer på.

Det er muligt for en abonnent også at være udgiver ved at oprette sin egen PUBLIKATION, som andre abonnenter kan abonnere på.

Hvad sker der nu?

Eventuelle dataændringer, der sker på udgiveren, sendes til abonnenten. Hvilket ud af æsken er alt, men kan konfigureres eller begrænses til bestemte operationer (f.eks. INDSÆT, OPDATERE eller SLET).

Eksempel på højt niveau:

Antag, at vi opdaterer en række eller flere rækker på en bestemt tabel i udgiveren, disse opdateringer og ændringer replikeres på abonnentens forekomst eller flere abonnenter, hvis den type konfiguration er implementeret.

Her er et par ting at huske, som jeg følte mig værd at nævne:

• Udgiverdatabasens wal_level-konfiguration skal indstilles til logisk.
• Logisk replikering har ingen DDL-kommandoer (Data Definition Language).
• Fra siden Konflikter i dokumentationen:"Logisk replikering opfører sig på samme måde som normale DML-operationer, idet dataene vil blive opdateret, selvom de blev ændret lokalt på abonnentknudepunktet. Hvis indgående data overtræder nogen begrænsninger, stopper replikeringen. Dette omtales som en konflikt. Når du replikerer OPDATERING- eller SLET-operationer, vil manglende data ikke skabe en konflikt, og sådanne handlinger vil simpelthen blive sprunget over."
• Udgivertabeller skal have en måde at identificere sig selv på (kaldet "replikidentitet") for korrekt at replikere DML-operationer (OPDATERE og SLETT) i alle replikaer for de berørte rækker. Hvis tabellen har en primær nøgle, er dette standarden (for mig virker det som lydvalget), men i mangel af en primær nøgle er andre konfigurationsmuligheder tilgængelige. Hele rækken kunne bruges, hvis der ikke findes en anden kandidatnøgle (benævnt "fuld"), selvom dokumentationen nævner, at dette typisk ikke er en effektiv løsning. (Se afsnittet REPLICA IDENTITY i dokumenterne for en beskrivelse på lavere niveau af, hvordan den indstilles)

Begrænsninger

Dokumentationen i afsnit 31.4. Restriktioner har nogle vigtige påmindelser om restriktioner, som jeg vil udviske. Vær sikker på og gennemgå den linkede side ovenfor for nøjagtige ordlyd.

• Databaseskema og eventuelle DDL-kommandoer understøttes ikke i replikeringen. Det foreslås, at pg_dump måske kunne bruges til at begynde med, men alligevel skal du selv opdatere eventuelle yderligere ændringer og fremskridt i skemaet til alle replikaerne.
• Dataene i sekvenskolonner vil blive replikeret. Men selve sekvensen ville kun afspejle startværdien. For læsning er det okay. Men hvis dette er dit valg til failover, skal du selv OPDATERE til den aktuelle værdi. Dokumenterne foreslår pg_dump her.
• Truncate er endnu ikke understøttet.
• Replikering af store objekter understøttes ikke.
• Visninger, materialiserede visninger, partitionsrodtabeller eller udenlandske tabeller understøttes ikke af hverken udgiveren eller abonnenten.

Rapporterede tilfælde af almindelig brug

• Du er kun interesseret i visse data og dataændringer, du faktisk replikerer i forhold til blot at replikere hele databasen.
• Når du har brug for replika(er) til skrivebeskyttede operationer, f.eks. et analysescenarie.
• Tillader brugere eller forskellige undergrupper af brugere begrænset eller overvåget adgang til data.
• Distribuerer data.
• Kompatibilitet med andre PostgreSQL-versioner.

Streamende replikering

Fra at forske, læse og studere streaming replikering, en ting, jeg samler lige på forhånd, er at vælge at konfigurere enten asynkron (standard) eller synkron replikering.

Ah, mere ukendte termer ikke?

Her er min 'højt niveau' definition af begge dele:

Med asynkron replikering, efter at en transaktion er begået på den primære, er der en lille forsinkelse, når den samme transaktion er begået og skrevet på replikaen. Der er potentiale for datatab med denne type konfiguration.

• For det første, antag, at masteren går ned.
• To, replikaerne er så langt bagefter masteren, at de har kasseret nødvendige data og oplysninger, for at replikaerne overhovedet er "aktuelle".

Ved synkron replikering anses ingen transaktion dog for at være fuldført, før den er bekræftet af både master- og replikaserveren(e). Hvilket vil have skrevet en commit til begge servers WAL.

Som jeg forstår, betyder det, at skrivninger på masteren også er blevet bekræftet og skrevet på replikaen.

Her er den officielle forklaring fra afsnit 26.2.8. Synkron replikering i den officielle dokumentation:

"Når der anmodes om synkron replikering, vil hver commit af en skrivetransaktion vente, indtil der modtages bekræftelse på, at commit er blevet skrevet til skrive-ahead-log på disken på både den primære server og standby-serveren. "

En anden passage fra dokumentationen har en fin gennemgang af, hvad der skal være (efter min mening), en kæmpe fordel:"Den eneste mulighed for, at data kan gå tabt, er, hvis både den primære og standbyen lider nedbrud på samme tid."

Selvom intet er umuligt, er det stadig en ret god forsikring om, at du ikke vil stå tilbage uden nogen kopi af dine data.

Okay, vi ved, at vi skal vælge en af ​​disse opsætningskonfigurationer, men hvad er den overordnede kerne?

I en nøddeskal sender og anvender Streaming Replication WAL-filer (Write Ahead Log) fra én databaseserver (masteren eller den primære) til en 'replika' (modtagende database).

Men der er en advarsel her at huske på. Potentielt kan WAL-filerne fra masteren genbruges, før standyen har fået dem. En måde at afbøde dette på er at øge wal_keep_segments-indstillingen til en højere værdi.

Punkter på streamingreplikering

• Som standard er Streaming-replikering asynkron, hvilket betyder, at der er en forsinkelse (måske lille) mellem de forpligtede transaktioner på masteren og deres synlighed på replikaen.
• Replika(r) opretter forbindelse til masteren via en netværksforbindelse.
• Vær opmærksom på godkendelse. Se her fra dokumentationen:"Det er meget vigtigt, at adgangsrettighederne til replikering sættes op, så kun betroede brugere kan læse WAL-strømmen, fordi det er nemt at udtrække privilegeret information fra den"

Hvornår skal du bruge streamingreplikering

• En almindelig brug (især i analyse) giver en "skrivebeskyttet"-replika for at fjerne belastningen af ​​den primære server.
• Du har brug for et miljø med høj tilgængelighed.
• Nyttig opsætning til failover til hot standby-server, hvis den primære går ned.