Forskellen mellem Stream Replication og logisk replikering

TL;DR :Logisk replikering sender række-for-række-ændringer, fysisk replikering sender diskblokændringer. Logisk replikering er bedre for nogle opgaver, fysisk replikering for andre.

Bemærk, at i PostgreSQL 12 (aktuelt på tidspunktet for opdatering) er logisk replikering stabil og pålidelig, men ret begrænset. Brug fysisk replikering, hvis du stiller dette spørgsmål.

Streaming replikering kan være logisk replikation. Det hele er lidt kompliceret.

WAL-forsendelse vs. streaming

Der er to hovedmåder at sende data fra master til replika i PostgreSQL:

WAL-forsendelse eller kontinuerlig arkivering , hvor individuelle write-ahead-log filer kopieres fra pg_xlog ved hjælp af archive_command kører på masteren til et andet sted. En restore_command konfigureret i replikaens recovery.conf kører på replikaen for at hente arkiverne, så replikaen kan afspille WAL'en igen.

Det er det, der bruges til tidspunkt-replikering (PITR), som bruges som en metode til kontinuerlig backup.

Der kræves ingen direkte netværksforbindelse til masterserveren. Replikering kan have lange forsinkelser, især uden en archive_timeout sæt. WAL-forsendelse kan ikke bruges til synkron replikering.
streaming replikering , hvor hver ændring sendes til en eller flere replika-servere direkte over en TCP/IP-forbindelse, efterhånden som den sker. Replikaerne skal have en direkte netværksforbindelse, som masteren har konfigureret i deres recovery.conf s primary_conninfo mulighed.

Streaming replikering har ringe eller ingen forsinkelse, så længe replikaen er hurtig nok til at følge med. Den kan bruges til synkron replikering . Du kan ikke bruge streamingreplikering til PITR, så det er ikke meget brugbart til kontinuerlig backup. Hvis du taber et bord på masteren, ups, det er også faldet på replikaerne.

De to metoder har således forskellige formål.

Asynkron vs synkron streaming

Oven i det er der synkron og asynkron streaming replikering:

I asynkron streaming-replikering replika(erne) får lov til at falde bagud mesteren i tide, når masteren er hurtigere/travlere. Hvis masteren går ned, kan du miste data, der endnu ikke er replikeret.

Hvis den asynkrone replika falder for langt bag masteren, kan masteren smide oplysninger væk, som replikaen har brug for, hvis max_wal_size (blev tidligere kaldt wal_keep_segments) is too low and no slot is used, meaning you have to re-create the replica from scratch. Or the master's pg_wal(was pg_xlog) kan fylde op og stoppe masteren i at arbejde, indtil der er frigivet diskplads, hvis max_wal_size er for høj, eller der er brugt et slot.
I synkron replikering masteren afslutter ikke forpligtelsen, før en replika har bekræftet, at den har modtaget transaktionen. Du mister aldrig data, hvis masteren går ned, og du skal fejle over til en replika. Masteren vil aldrig smide data væk, som replikaen har brug for, eller fylde sin xlog op og løbe tør for diskplads på grund af replikaforsinkelser. Til gengæld kan det få masteren til at sænke farten eller endda holde op med at virke, hvis replikaer har problemer, og det har altid en præstationsindvirkning på masteren på grund af netværksforsinkelse.

Når der er flere replikaer, er kun én synkron ad gangen. Se synchronous_standby_names .

Du kan ikke have synkron logforsendelse.

Du kan faktisk kombinere logforsendelse og asynkron replikering for at beskytte mod at skulle genskabe en replika, hvis den falder for langt bagud, uden at risikere at påvirke masteren. Dette er en ideel konfiguration til mange implementeringer, kombineret med overvågning af, hvor langt replikaen er bag masteren for at sikre, at den er inden for acceptable katastrofegendannelsesgrænser.

Logisk vs fysisk

Oven i det vi har logiske vs fysisk streaming replikering, som introduceret i PostgreSQL 9.4:

I fysisk streaming-replikering ændringer sendes på næsten diskblokniveau, som "ved offset 14 på disk side 18 i relation 12311, skrev tuple med hex-værdi 0x2342beef1222...".

Fysisk replikation sender alt :indholdet af hver database i PostgreSQL-installationen, alle tabeller i hver database. Den sender indeksposter, den sender de helt nye tabeldata, når du VACUUM FULL , den sender data for transaktioner, der er rullet tilbage osv. Så den genererer en masse "støj" og sender en masse overskydende data. Det kræver også, at replikaen er fuldstændig identisk, så du kan ikke gøre noget, der ville kræve en transaktion, som at oprette midlertidige eller uloggede tabeller. Forespørgsel efter replikaen forsinker replikationen, så lange forespørgsler på replikaen skal annulleres.

Til gengæld er det enkelt og effektivt at anvende ændringerne på replikaen, og replikaen er pålideligt nøjagtig den samme som masteren. DDL replikeres gennemsigtigt, ligesom alt andet, så det kræver ingen særlig håndtering. Det kan også streame store transaktioner, efterhånden som de sker, så der er lidt forsinkelse mellem commit på masteren og commit på replikaen, selv for store ændringer.

Fysisk replikation er moden, velafprøvet og bredt udbredt.

logisk streamingreplikering , nyt i 9.4, sender ændringer på et højere niveau og meget mere selektivt.

Det replikerer kun én database ad gangen. Den sender kun rækkeændringer og kun for forpligtede transaktioner, og den behøver ikke at sende vakuumdata, indeksændringer osv. Den kan selektivt kun sende data for nogle tabeller i en database. Dette gør logisk replikering meget mere båndbreddeeffektiv.

At operere på et højere niveau betyder også, at du kan foretage transaktioner på replika-databaserne. Du kan oprette midlertidige og uloggede tabeller. Selv normale borde, hvis du vil. Du kan bruge udenlandske dataindpakninger, visninger, oprette funktioner, hvad du vil. Der er heller ingen grund til at annullere forespørgsler, hvis de kører for længe.

Logisk replikering kan også bruges til at bygge multi-master replikering i PostgreSQL, hvilket ikke er muligt ved brug af fysisk replikering.

Til gengæld kan den dog (i øjeblikket) ikke streame store transaktioner, mens de sker. Det må vente, indtil de forpligter sig. Så der kan være en lang forsinkelse mellem en stor transaktion, der begås på masteren, og den bliver anvendt på replikaen.

Den afspiller transaktioner strengt i commit rækkefølge, så små hurtige transaktioner kan sidde fast bag en stor transaktion og blive forsinket et stykke tid.

DDL håndteres ikke automatisk. Du skal selv holde tabeldefinitionerne synkroniseret mellem master og replika, eller applikationen, der bruger logisk replikering, skal have sine egne faciliteter til at gøre dette. Det kan være kompliceret at få dette rigtigt.

Selve ansøgningsprocessen er mere kompliceret end at "skrive nogle bytes, hvor jeg bliver bedt om det". Det kræver også flere ressourcer på replikaen, end fysisk replikering gør.

Nuværende logiske replikeringsimplementeringer er ikke modne eller almindeligt anvendte, eller særligt nemme at bruge.

For mange muligheder, fortæl mig, hvad jeg skal gøre

Pyha. Kompliceret, hva'? Og jeg er ikke engang kommet ind på detaljerne om forsinket replikering, slots, max_wal_size , tidslinjer, hvordan promovering fungerer, Postgres-XL, BDR og multimaster osv.

Så hvad skal du gøre ?

Der er ikke et enkelt rigtigt svar. Ellers ville PostgreSQL kun understøtte den ene måde. Men der er et par almindelige tilfælde:

Til sikkerhedskopiering og katastrofegendannelse brug pgbarman at lave grundlæggende sikkerhedskopier og beholde WAL for dig, hvilket giver nem at administrere kontinuerlig backup. Du bør stadig tage periodisk pg_dump backups som ekstra forsikring.

For høj tilgængelighed uden risiko for datatab bruge streaming synkron replikering.

For høj tilgængelighed med lav risiko for datatab og bedre ydeevne du bør bruge asynkron streaming replikering. Enten har WAL-arkivering aktiveret til fallback, eller brug en replikeringsplads. Overvåg, hvor langt replikaen er bag masteren ved hjælp af eksterne værktøjer som Icinga.

Forskellen mellem Stream Replication og logisk replikering

WAL-forsendelse vs. streaming

Asynkron vs synkron streaming

Logisk vs fysisk

For mange muligheder, fortæl mig, hvad jeg skal gøre

Referencer