PostgreSQL-streaming versus logische replicatie - vergelijking

Het repliceren van de informatie die in uw database is opgeslagen, is essentieel voor het distribueren van gegevens en om ervoor te zorgen dat u een back-up hebt die kan worden gebruikt voor noodherstel, voor het geval er iets misgaat.

PostgreSQL-replicatie is er in twee vormen en beide hebben hun nichegebruik. Als u begrijpt hoe u een of beide methoden voor gegevensreplicatie kunt toepassen, kunt u uw gegevensdistributieprocessen stroomlijnen. Het laatste dat u wilt, is het cruciale werk dat u in een database hebt gedaan, kwijtraken.

Laten we eens kijken naar de voor- en nadelen en gebruiksscenario's van streaming-replicatie en logisch in PostgreSQL.

Gegevensreplicatie definiëren in PostgreSQL

Als u al bekend bent met wat gegevensreplicatie is, kunt u doorgaan en naar het volgende gedeelte scrollen. Maar als database-engineering nieuw voor u is, willen we de basis heel snel leggen.

Zoals de naam al doet vermoeden, is replicatie het proces waarbij gegevens vaak worden gekopieerd van de ene database op een computerserver naar een andere database op een andere server, zodat alle gebruikers toegang hebben tot hetzelfde informatieniveau. Bij computergebruik wordt replicatie gebruikt om fouten in een digitaal systeem te elimineren.

Replicatie elimineert datasilo's, beschermt waardevolle informatie en stroomlijnt ontwikkeling.

In PostgreSQL zijn er twee opties voor replicatie:logische en streaming-replicatie. Deze methoden zijn geweldig voor verschillende gebruiksscenario's en als ontwikkelaar ben je misschien meer geneigd om de ene boven de andere te gebruiken. Maar het is goed om te begrijpen hoe u beide kunt gebruiken, zodat u kunt beslissen welke u in verschillende scenario's wilt toepassen.

Logische replicatie in PostgreSQL

Streaming-replicatie is geïntroduceerd voor gebruik met PostgreSQL v10.0. Logische replicatie werkt door het kopiëren/repliceren van gegevensobjecten en hun wijzigingen op basis van hun replicatie-identiteit.

In veel gevallen is de identiteit van de gegevens een primaire sleutel. In PostgreSQL geeft het gebruikers fijnmazige controle over de gerepliceerde gegevens- en informatiebeveiliging.

De term logisch wordt gebruikt om het te onderscheiden van fysieke replicatie, die gebruik maakt van byte-by-byte replicatie en exacte blokadressen. Lees hier meer in de officiële PostgreSQL-documentatie.

Via een publicatie- en abonnementsmodel werkt het door een of meer abonnees in staat te stellen zich te abonneren op een of meer publicaties op een uitgeversknooppunt. De abonnees kunnen informatie uit de publicaties halen en de gegevens opnieuw publiceren voor trapsgewijze replicatie of complexere configuratie.

Logische gegevensreplicatie kan ook de vorm aannemen van transactionele replicatie. Als de engineer een tabel wil kopiëren, kan hij deze replicatiemethode gebruiken om een ​​momentopname te maken van de gegevens aan de kant van de uitgever en deze naar de database van de abonnee te sturen.

Terwijl de abonnees wijzigingen aanbrengen in de oorspronkelijke gegevens, ontvangt de uitgeversdatabase updates in realtime. Om transactieconsistentie in publicaties met één abonnement te garanderen, moet de abonnee de gegevens in dezelfde volgorde toepassen als de uitgever.

Voordelen van logische replicatie in PostgreSQL

Logische replicatie stelt gebruikers in staat om een ​​doelserver te gebruiken voor schrijfbewerkingen en stelt ontwikkelaars in staat om verschillende indexen en beveiligingsdefinities te hebben. Dit biedt meer flexibiliteit voor de overdracht van gegevens tussen uitgevers en abonnees.

Ondersteuning voor meerdere versies

Bovendien wordt het geleverd met ondersteuning voor meerdere versies en kan het worden ingesteld tussen verschillende versies van PostgreSQL. Het biedt ook op gebeurtenissen gebaseerde filtering. Publicaties kunnen verschillende abonnementen hebben, waardoor het gemakkelijk is om gegevens over een breed netwerk te delen.

Minimale serverbelasting

Vergeleken met op triggers gebaseerde oplossingen, heeft het een minimale serverbelasting en biedt het opslagflexibiliteit door kleinere sets te repliceren. Zoals hierboven vermeld, kan logische gegevensreplicatie zelfs gegevens kopiëren die zijn opgenomen in standaard gepartitioneerde tabellen.

Het is ook essentieel om te vermelden dat logische gegevensreplicatie gegevenstransformatie mogelijk maakt, zelfs wanneer deze wordt ingesteld, en parallelle streaming tussen uitgevers mogelijk maakt.

Nadelen van logische replicatie in PostgreSQL

Logische replicatie kopieert geen sequenties, grote objecten, gematerialiseerde views, partitie-roottabellen en vreemde tabellen.

In PostgreSQL wordt logische gegevensreplicatie alleen ondersteund door DML-bewerkingen. Ontwikkelaars kunnen geen DDL gebruiken of afkappen, en het schema moet vooraf worden gedefinieerd. Bovendien ondersteunt het geen wederzijdse (bidirectionele) replicatie.

Als gebruikers conflicten tegenkomen met beperkingen op gerepliceerde gegevens in een tabel, stopt de replicatie. De enige manier om de replicatie te hervatten, is als de oorzaak van het conflict is opgelost.

Een onbedoeld conflict kan het momentum van uw team stoppen, dus u moet begrijpen hoe u eventuele problemen snel kunt oplossen.

Als het conflict niet snel wordt verholpen, bevriest de replicatiesleuf in de huidige staat, begint de publisher-node Write-Ahead Logs (WAL's) te verzamelen en heeft de node uiteindelijk geen schijfruimte meer.

Gebruik cases voor logische replicatie in PostgreSQL

Veel technici zullen logische replicatie gebruiken voor:

• Wijzigingen binnen een enkele database of database-subset in realtime distribueren naar abonnees
• Meerdere databases samenvoegen tot één centrale database (vaak voor analytisch gebruik)
• Replicaties maken voor verschillende versies van PostgreSQL
• Replicaties implementeren tussen PostgreSQL-instanties op verschillende platforms, zoals Linux naar Windows
• Gerepliceerde gegevens delen met andere gebruikers of groepen
• Een database-subset verdelen over meerdere databases

Streaming-replicatie in PostgreSQL

Streaming-replicatie is geïntroduceerd voor gebruik met PostgreSQL 9.0. Het proces verzendt en past Write-Ahead Logging (WAL)-bestanden van een hoofd- of primaire databaseserver toe op een replica of ontvangende database. De WAL's worden gebruikt voor replicatie en om de gegevensintegriteit te waarborgen.

Hoe streaming replicatie werkt

Streamingreplicatie werkt om de kloof te overbruggen tussen gegevensoverdrachten die inherent zijn aan op bestanden gebaseerde verzending van logbestanden, die wacht tot een WAL de maximale capaciteit bereikt om gegevens te verzenden.

Door WAL-records te streamen, streamen databaseservers WAL-records in brokken om de gegevens te synchroniseren. De standby-server maakt verbinding met de replica en ontvangt de WAL-chunks wanneer ze worden verzonden.

Bij streamingreplicatie moet de gebruiker beslissen of hij asynchrone of synchrone replicatie wil instellen. Wanneer streaming-replicatie in eerste instantie wordt geïmplementeerd, wordt standaard asynchrone replicatie gebruikt.

Dit geeft aan dat er een vertraging is tussen de eerste wijziging op de primaire en de weerspiegeling van die wijziging op de replica. Asynchronisatie opent de deur voor mogelijk gegevensverlies als de master crasht voordat wijzigingen worden gekopieerd of als de replica zo niet synchroon loopt met het origineel dat relevante gegevens al zijn weggegooid om wijzigingen aan te brengen.

Synchrone replicatie is een veel veiligere optie omdat het wijzigingen in realtime aanbrengt. De overdracht van de master naar de replica wordt als onvolledig beschouwd totdat beide servers de informatie verifiëren. Zodra de gegevenswijzigingen zijn bevestigd, wordt de overdracht geregistreerd op de WAL's van beide servers.

Of u nu asynchrone of synchrone replicatie gebruikt, de replica's moeten via een netwerkverbinding met de master worden verbonden. Bovendien is het essentieel dat de gebruikers toegangsrechten instellen voor de WAL-streams van de replica, zodat de informatie niet wordt aangetast.

Voordelen van streamingreplicatie in PostgreSQL

Een van de belangrijkste voordelen van het gebruik van streamingreplicatie is dat de enige manier om gegevens te verliezen is als zowel de primaire als de ontvangende server tegelijkertijd crashen. Als u belangrijke informatie overhandigt, garandeert streaming-replicatie vrijwel zeker dat een kopie van uw werk wordt opgeslagen.

Gebruikers kunnen meer dan één standby-server verbinden met de primaire, en de logboeken worden gestreamd van de primaire naar elk van de verbonden standbys. Als een van de replica's vertraging oploopt of de verbinding wordt verbroken, gaat het streamen door naar de andere replica's.

Het instellen van logverzending via streamingreplicatie heeft geen invloed op alles wat de gebruiker momenteel op de primaire database uitvoert. Als de primaire gegevensserver moet worden afgesloten, wacht deze totdat de bijgewerkte records naar de replica zijn verzonden voordat deze wordt uitgeschakeld.

Nadelen van streamingreplicatie in PostgreSQL

Streaming-replicatie kopieert geen informatie naar een andere versie of architectuur, verandert de informatie van de standby-servers en biedt geen gedetailleerde replicatie.

Vooral bij asynchrone replicatie van streaminggegevens kunnen oudere WAL-bestanden die nog niet naar de replica zijn gekopieerd, worden gerecycled wanneer de gebruiker wijzigingen aanbrengt in de master. Om ervoor te zorgen dat vitale bestanden niet verloren gaan, kan de gebruiker de wal_keep_segments op een hogere waarde instellen.

Zonder gebruikersverificatiegegevens die zijn ingesteld voor de replicaservers, kunnen gevoelige gegevens gemakkelijk worden geëxtraheerd. Om realtime updates tussen de master en de replica te laten plaatsvinden, moet de gebruiker de replicatiemethode wijzigen van de standaard asynchrone replicatie naar synchrone replicatie.

Gebruiksvoorbeelden voor streamingreplicatie in PostgreSQL

Veel technici zullen streaming-replicatie gebruiken voor:

• Een back-up maken voor hun primaire database in geval van serverstoring of gegevensverlies
• Een oplossing met hoge beschikbaarheid bevorderen met zo min mogelijk replicatievertraging
• Grote vragen afhandelen om een ​​deel van de stress op het primaire systeem te verlichten
• Het verdelen van database-workloads over verschillende machines, vooral voor alleen-lezen formaten

Wat staat er in de toekomst te wachten?

De PostgreSQL Global Development Group kondigde de release van PostgreSQL 14 aan op 30 september 2021. De nieuwe versie kwam vol met upgrades in zowel streaming als logische replicaties via het platform.

Voor streaming-replicatie stelt versie 14 gebruikers in staat om:

• Stel de serverparameter log_recovery_conflict_waits in om lange wachttijden voor herstelconflicten automatisch te melden
• Herstel op een actieve stand-by-server onderbreken bij het wijzigen van de parameters op een primaire server (in plaats van de stand-by onmiddellijk af te sluiten)
• Gebruik functie pg_get_wal_replay_pause_state() om de herstelstatus in meer detail te rapporteren
• Geef een alleen-lezen serverparameter in_hot_standby
• Snel kleine tabellen afkappen tijdens herstel op clusters met een groot aantal gedeelde buffers
• Sta bestandssysteemsynchronisatie toe aan het begin van crashherstel via Linux
• Gebruik functie pg_xact_commit_timestamp_origin() op een gespecificeerde transactie om de commit-tijdstempel en replicatieoorsprong te retourneren
• Gebruik functie pg_last_committed_xact() om de replicatieoorsprong toe te voegen aan het geretourneerde record
• Gebruik standaard functies voor machtigingen om de oorsprongsfuncties van replicatie te wijzigen (de standaard beperkt de toegang tot de superusers nog steeds)

Voor logische replicatie stelt versie 14 gebruikers in staat om:

• Stream lange lopende transacties naar abonnees met de logische replicatie-API
• Meerdere transacties toestaan ​​tijdens tabelreplicaties
• Onmiddellijke WAL-log-subtransacties en XID-associaties op het hoogste niveau genereren
• Gebruik functie pg_create_logical_replication_slot() om logische decoderings-API's te verbeteren voor commits in twee fasen
• Voeg cache-invalidatieberichten toe aan de WAL tijdens het voltooien van de opdracht om logische streaming van lopende transacties mogelijk te maken
• Bepaal welke logische decoderingsberichten naar de replicatiestroom worden verzonden
• Gebruik de binaire overdrachtsmodus voor snellere replicaties
• Decodering filteren op XID

PostgreSQL werkt al aan versie 15, die naar verwachting in het derde kwartaal van 2022 wordt uitgebracht. Een van de problemen met betrekking tot replicatie die in de nieuwste versie moet worden aangepakt, is onder meer het voorkomen van het gebruik van variabelen die zijn overgenomen van de serveromgeving bij streamingreplicatie. Maar naarmate meer gebruikers zich aanpassen aan versie 14, zal PostgreSQL waarschijnlijk meer taken toevoegen om de replicatiefuncties te verbeteren.

Een snelle vergelijking van PostgreSQL-replicatie:logische versus streaming-replicatie

Conclusie

We hopen dat deze handleiding van pas komt bij het instellen van uw replicatiefuncties. Als je vragen hebt of iets anders wilt weten over hoe ScaleGrid je kan helpen met je PostgreSQL-implementaties, neem dan contact op met een van onze vele database-experts.