PostgreSQL-streaming vs logisk replikering – sammenligning

Replikering af oplysningerne, der er gemt i din database, er afgørende for at distribuere data og sikre, at du har en sikkerhedskopi, der kan bruges til katastrofegendannelse, hvis noget går galt.

PostgreSQL-replikering kommer i to former, og begge har deres nicheanvendelser. At forstå, hvordan man anvender en eller begge af disse datareplikeringsmetoder, kan strømline dine datadistributionsprocesser. Det sidste, du ønsker, er at miste afgørende arbejde, du har udført på en database.

Lad os tage et kig på fordele, ulemper og brugstilfælde af streaming replikering og logisk i PostgreSQL.

Definition af datareplikering i PostgreSQL

Hvis du allerede er bekendt med, hvad datareplikering er, så kan du gå videre og rulle ned til næste afsnit. Men hvis du er ny inden for databaseteknik, vil vi gerne sætte grundlaget rigtig hurtigt.

Som navnet antyder, er replikering processen med hyppigt at kopiere data fra en database på en computerserver til en anden database på en anden server, så alle brugere har adgang til det samme informationsniveau. I computing bruges replikering til at eliminere fejl i et digitalt system.

Replikering eliminerer datasiloer, beskytter værdifuld information og strømliner udvikling.

I PostgreSQL er der to muligheder for replikering:logisk og streaming replikering. Disse metoder er gode til forskellige brugstilfælde, og som udvikler kan du finde dig selv mere tilbøjelig til at bruge den ene frem for den anden. Men det er godt at forstå, hvordan man bruger begge, så du kan beslutte, hvad du vil anvende i forskellige scenarier.

Logisk replikering i PostgreSQL

Streaming-replikering blev introduceret til brug med PostgreSQL v10.0. Logisk replikering fungerer ved at kopiere/replikere dataobjekter og deres ændringer baseret på deres replikeringsidentitet.

I mange tilfælde er dataens identitet en primær nøgle. I PostgreSQL giver det brugerne finmasket kontrol over de replikerede data og informationssikkerhed.

Udtrykket logisk bruges til at skelne det fra fysisk replikering, som gør brug af byte-for-byte replikering og nøjagtige blokadresser. Læs mere i den officielle PostgreSQL-dokumentation her.

Gennem en publicerings- og abonnermodel fungerer den ved at gøre det muligt for en eller flere abonnenter at abonnere på en eller flere publikationer på en udgivernode. Abonnenterne kan trække information fra publikationerne og genudgive dataene til kaskadereplikering eller mere kompleks konfiguration.

Logisk datareplikering kan også tage form af transaktionsreplikering. Hvis teknikeren ønsker at kopiere en tabel, kan de bruge denne replikeringsmetode til at tage et øjebliksbillede af dataene i udgiverens ende og sende dem til abonnentens database.

Efterhånden som abonnenterne foretager ændringer i de originale data, modtager udgiverdatabasen opdateringer i realtid. For at sikre transaktionskonsistens i publikationer med et enkelt abonnement skal abonnenten anvende dataene i samme rækkefølge som udgiveren.

Fordele ved logisk replikering i PostgreSQL

Logisk replikering gør det muligt for brugere at anvende en destinationsserver til skrivninger og giver udviklere mulighed for at have forskellige indekser og sikkerhedsdefinitioner. Dette giver øget fleksibilitet til overførsel af data mellem udgivere og abonnenter.

Support på tværs af versioner

Derudover kommer den med cross-version support og kan indstilles mellem forskellige versioner af PostgreSQL. Det giver også hændelsesbaseret filtrering. Publikationer kan have flere abonnementer, hvilket gør det nemt at dele data på tværs af et bredt netværk.

Minimum serverbelastning

Sammenlignet med trigger-baserede løsninger har den en minimal serverbelastning, mens den giver lagerfleksibilitet gennem replikering af mindre sæt. Som nævnt ovenfor kan logisk datareplikering endda kopiere data indeholdt i grundlæggende partitionerede tabeller.

Det er også vigtigt at nævne, at logisk datareplikering muliggør datatransformation, selv når den sættes op, og tillader parallel streaming på tværs af udgivere.

Udemper ved logisk replikering i PostgreSQL

Logisk replikering vil ikke kopiere sekvenser, store objekter, materialiserede visninger, partitionsrodtabeller og fremmede tabeller.

I PostgreSQL understøttes logisk datareplikering kun af DML-operationer. Udviklere kan ikke bruge DDL eller afkorte, og skemaet skal defineres på forhånd. Derudover understøtter den ikke gensidig (tovejs) replikering.

Hvis brugere støder på konflikter med begrænsninger på replikerede data i en tabel, stopper replikeringen. Den eneste måde, hvorpå replikering kan genoptages, er, hvis årsagen til konflikten er løst.

En utilsigtet konflikt kan standse dit teams momentum, så du er nødt til at forstå, hvordan du løser eventuelle problemer hurtigt.

Hvis konflikten ikke bliver taget hånd om hurtigt, vil replikeringspladsen fryse i sin nuværende tilstand, udgivernoden vil begynde at akkumulere Write-Ahead Logs (WAL'er), og noden vil til sidst løbe tør for diskplads.

Brug cases til logisk replikering i PostgreSQL

Mange ingeniører vil bruge logisk replikering til:

• Distribuering af ændringer inden for en enkelt database eller databaseundersæt til abonnenter i realtid
• Sletning af flere databaser til én central database (ofte til analysebrug)
• Oprettelse af replikationer på tværs af forskellige versioner af PostgreSQL
• Udsættelse af replikationer mellem PostgreSQL-instanser på tværs af forskellige platforme, såsom Linux til Windows
• Deling af replikerede data med andre brugere eller grupper
• Distribuering af et databaseundersæt mellem flere databaser

Streaming af replikering i PostgreSQL

Streaming-replikering blev introduceret til brug med PostgreSQL 9.0. Processen sender og anvender WAL-filer (Writ-Ahead Logging) fra en master- eller primær databaseserver til en replika eller modtagende database. WAL'erne bruges til replikering og til at sikre dataintegritet.

Sådan fungerer streamingreplikering

Streaming-replikering arbejder for at bygge bro mellem dataoverførsler, der er iboende i filbaseret logforsendelse, som venter, indtil en WAL når den maksimale kapacitet til at sende data.

Ved at streame WAL-poster streamer databaseservere WAL-poster i bidder for at synkronisere dataene. Standby-serveren opretter forbindelse til replikaen og modtager WAL-bidderne, efterhånden som de sendes.

Med streamingreplikering skal brugeren beslutte, om der skal opsættes asynkron eller synkron replikering. Når streamingreplikering indledningsvis implementeres, vil den som standard være asynkron replikering.

Dette indikerer, at der er en forsinkelse mellem den første ændring på den primære og afspejlingen af ​​den ændring på replikaen. Asynkronisering åbner døren for potentielt datatab, hvis masteren går ned, før ændringerne er kopieret, eller hvis replikaen er så ude af synkronisering med originalen, at den allerede har kasseret relevante data for at foretage ændringer.

Synkron replikering er en meget sikrere mulighed, fordi den foretager ændringer i realtid. Overførslen fra masteren til replikaen anses for at være ufuldstændig, indtil begge servere bekræfter oplysningerne. Når dataændringerne er bekræftet, registreres overførslen på begge serveres WAL'er.

Uanset om du bruger asynkron eller synkron replikering, skal replikaerne være forbundet til masteren via en netværksforbindelse. Derudover er det vigtigt for brugerne at konfigurere adgangsrettigheder til replikaens WAL-streams, så oplysningerne ikke kompromitteres.

Fordele ved streamingreplikering i PostgreSQL

En af de vigtigste fordele ved at bruge streamingreplikering er, at den eneste måde at miste data på er, hvis både den primære og den modtagende server går ned på samme tid. Hvis du afleverer vigtige oplysninger, garanterer streaming-replikering næsten, at en kopi af dit arbejde bliver gemt.

Brugere kan forbinde mere end én standby-server til den primære, og logfilerne vil blive streamet fra den primære til hver af de tilsluttede standby-servere. Hvis en af ​​replikaerne er forsinket eller bliver afbrudt, vil streamingen fortsætte til de andre replikaer.

Opsætning af log-forsendelse gennem streaming-replikering vil ikke forstyrre noget, som brugeren i øjeblikket kører på den primære database. Hvis den primære dataserver skal lukkes ned, vil den vente, indtil de opdaterede registreringer er blevet sendt til replikaen, før den slukkes.

Udemper ved streamingreplikering i PostgreSQL

Streaming-replikering vil ikke kopiere oplysninger til en anden version eller arkitektur, ændre standby-servernes oplysninger og tilbyder ikke granulær replikering.

Især med asynkron streaming-datareplikering kan ældre WAL-filer, som endnu ikke er kopieret til replikaen, blive genbrugt, når brugeren foretager ændringer i masteren. For at sikre, at vitale filer ikke går tabt, kan brugeren indstille wal_keep_segments til en højere værdi.

Uden brugergodkendelsesoplysninger, der er konfigureret til replika-serverne, kan det være nemt for følsomme data at blive udtrukket. For at der kan ske realtidsopdateringer mellem masteren og replikaen, skal brugeren ændre replikeringsmetoden fra standard asynkron replikering til synkron replikering.

Brugssager til streamingreplikering i PostgreSQL

Mange ingeniører vil bruge streaming replikering til:

• Oprettelse af en sikkerhedskopi til deres primære database i tilfælde af serverfejl eller datatab
• Udvikling af en højtilgængelig løsning med så lille replikeringsforsinkelse som muligt
• Udførelse af store forespørgsler for at lindre noget af stresset på det primære system
• Fordeling af databasearbejdsbelastninger på tværs af flere maskiner, især for skrivebeskyttede formater

Hvad venter der i fremtiden?

PostgreSQL Global Development Group annoncerede udgivelsen af ​​PostgreSQL 14 den 30. september 2021. Den nye version kom fyldt med opgraderinger i både streaming og logiske replikationer gennem platformen.

Til streamingreplikering giver version 14 brugerne mulighed for at:

• Indstil serverparameteren log_recovery_conflict_waits for at rapportere lange ventetider for gendannelseskonflikt automatisk
• Sæt gendannelse på pause på en varm standby-server, når parametrene på en primær server ændres (i stedet for at lukke standbyen ned med det samme)
• Brug funktionen pg_get_wal_replay_pause_state() for at rapportere genoprettelsestilstanden mere detaljeret
• Angiv en skrivebeskyttet serverparameter in_hot_standby
• Turnker hurtigt små tabeller under gendannelse på klynger, der har et stort antal delte buffere
• Tillad filsystemsynkronisering ved begyndelsen af ​​nedbrudsgendannelse via Linux
• Brug funktionen pg_xact_commit_timestamp_origin() på en specificeret transaktion for at returnere commit-tidsstemplet og replikeringsoprindelsen
• Brug funktionen pg_last_committed_xact() for at tilføje replikeringsoriginet på den returnerede post
• Anvend standardfunktionstilladelseskontroller til at ændre replikeringsoprindelsesfunktioner (standarden begrænser stadig adgangen til superbrugerne)

Til logisk replikering giver version 14 brugere mulighed for at:

• Stream lange igangværende transaktioner til abonnenter med den logiske replikerings-API
• Tillad flere transaktioner under tabelreplikeringer
• Generer øjeblikkelige WAL-log-undertransaktioner og XID-tilknytninger på øverste niveau
• Brug funktionen pg_create_logical_replication_slot() for at forbedre logiske afkodnings-API'er for to-fasede commits
• Tilføj cache-invalideringsmeddelelser til WAL'en under kommandoafslutning for at tillade logisk streaming af igangværende transaktioner
• Kontroller, hvilke logiske afkodningsmeddelelser der sendes til replikeringsstrømmen
• Brug binær overførselstilstand for hurtigere replikationer
• Filterafkodning efter XID

PostgreSQL arbejder allerede hen imod version 15, som er indstillet til at blive frigivet i tredje kvartal af 2022. Et af problemerne vedrørende replikering, der skal løses i den nyeste version, omfatter at forhindre brugen af ​​variable, der er nedarvet fra servermiljøet i streamingreplikering. Men efterhånden som flere brugere tilpasser sig version 14, vil PostgreSQL sandsynligvis tilføje flere opgaver til forbedring af replikeringsfunktioner.

En hurtig PostgreSQL-replikeringssammenligning:logisk vs. streamingreplikering

Konklusion

Vi håber, at denne vejledning kommer til nytte, når du opsætter dine replikeringsfunktioner. Hvis du har spørgsmål, eller der er andet, du gerne vil vide om, hvordan ScaleGrid kan hjælpe dig med dine PostgreSQL-implementeringer, så kontakt en af ​​vores mange databaseeksperter.