Ik beschouw mezelf een beetje als een ontdekkingsreiziger. In bepaalde dingen wel. Ik bestel meestal altijd hetzelfde eten bij een bekend restaurant, omdat de angst voor teleurstelling zwaarder weegt dan mijn angst om iets nieuws te proberen.
En natuurlijk heeft een hongerig mens de neiging om gewoon goed te eten?
Maar als het op technologie aankomt, met name SQL (PostgreSQL), heb ik de neiging om op volle snelheid (mijn definitie van verkennen) in vaak onbekende gebieden te struikelen, in de hoop te leren. Wat is een betere manier om te leren dan ervaring?
Dus wat heeft dit geklets in hemelsnaam te maken met logische en streaming-replicatie in PostgreSQL?
Ik ben een complete beginner op deze gebieden zonder enige kennis. Ja, ik heb ongeveer evenveel begrip op dit gebied van Postgres als in astrofysica.
Had ik al gezegd dat ik geen kennis had?
Daarom zal ik in deze blogpost proberen de verschillen in dit soort replicatie te verwerken. Zonder praktijkervaring kan ik je de 'Be all end all . niet beloven ' manuscript voor replicatie.
Waarschijnlijk zouden anderen die minder thuis zijn in dit specifieke gebied (zoals ikzelf) baat hebben bij deze blogpost.
Ervaren gebruikers en ontwikkelaars mee voor de rit, ik hoop je te zien in de reacties hieronder.
Een paar basisdefinities
Wat betekent Replicatie in de brede zin van het woord?
Replicatie zoals gedefinieerd in WikiWoordenboek heeft dit te zeggen:
"Proces waarmee een object, persoon, plaats of idee kan worden gekopieerd, nagebootst of gereproduceerd."
Toch is het vijfde vermelde item meer van toepassing op deze blogpost en ik vind dat we daar ook naar moeten kijken:
"(computergebruik) Het proces van frequente elektronische gegevens die een database op de ene computer of server kopiëren naar een database in een andere, zodat alle gebruikers hetzelfde informatieniveau delen. Wordt gebruikt om de fouttolerantie van het systeem te verbeteren."
Nu is er iets waar we ons in kunnen vinden. De vermelding van het kopiëren van gegevens van de ene server of database naar de andere? We zijn nu op bekend terrein...
Dus, toe te voegen aan wat we weten uit die definitie, wat zijn de definities van streaming-replicatie en logische replicatie?
Laten we eens kijken wat de PostgreSQL Wiki te bieden heeft:
Streaming-replicatie:"biedt de mogelijkheid om de WAL XLOG-records continu te verzenden en toe te passen op een aantal standby-servers om ze actueel te houden.
En de PostgreSQL-documentatie heeft deze definitie voor logische replicatie:
"Logische replicatie is een methode voor het repliceren van data-objecten en hun wijzigingen, gebaseerd op hun replicatie-identiteit (meestal een primaire sleutel). We gebruiken de term logisch in tegenstelling tot fysieke replicatie, die exacte blokadressen en byte-by-byte replicatie gebruikt. "
Hoofdstuk 19.6 Replicatie van de officiële documentatie zit ook boordevol goodies, dus zorg ervoor dat je die bron bezoekt.
Hieronder zal ik proberen de verschillen in lekentermen weer te geven. (Vergeet niet dat als ik struikel, ik een beginneling ben.) Dit is een extreem 'high-level' overzicht.
Logische replicatie
Een "bron"-database maakt een PUBLICATION aan met behulp van de opdracht CREATE PUBLICATION. (Ik zie dit in eenvoudige bewoordingen als de 'afzender'.)
De documentatie noemt het de uitgever.
Deze uitgeversdatabase bevat de gegevens die we willen repliceren. Toch moeten we iets hebben om naar te repliceren en dit is waar de tegenhanger(s) van de uitgever om de hoek komen kijken. De 'abonnee'. Merk op dat ik een alternatieve meervoudsvorm heb ingevoerd, want van wat ik heb gevonden via online zoekopdrachten, is het een praktische opzet om meerdere abonnees te hebben.
Een 'abonnee' (kan ook worden gezien als de replicadatabase) maakt een ABONNEMENT op een 'bron'-database (uitgever) die verbindingsinformatie definieert, en alle publicaties waarop hij is geabonneerd.
Het is mogelijk dat een abonnee ook een uitgever is en zijn eigen PUBLICATIE creëert waarop andere abonnees zich kunnen abonneren.
Wat gebeurt er nu?
Alle gegevenswijzigingen die op de uitgever plaatsvinden, worden naar de abonnee verzonden. Wat direct uit de doos alles is, maar kan worden geconfigureerd of beperkt tot bepaalde bewerkingen (bijv. INSERT, UPDATE of DELETE).
Voorbeeld op hoog niveau:
Stel dat we een rij of meerdere rijen bijwerken op een bepaalde tabel in de uitgever, dan worden die updates en wijzigingen gerepliceerd, op het exemplaar van de abonnee of meerdere abonnees als dat type configuratie is geïmplementeerd.
Hier zijn een paar dingen om te onthouden die ik de moeite waard vond om te vermelden:
- De wal_level-configuratie van de uitgeversdatabase moet zijn ingesteld op logisch.
- Logische replicatie heeft geen DDL-opdrachten (Data Definition Language).
- Van de pagina Conflicten in de documentatie:"Logische replicatie gedraagt zich op dezelfde manier als normale DML-bewerkingen, in die zin dat de gegevens worden bijgewerkt, zelfs als deze lokaal op het abonneeknooppunt zijn gewijzigd. Als binnenkomende gegevens enige beperkingen overtreden, stopt de replicatie. Dit wordt een conflict genoemd. Bij het repliceren van UPDATE- of DELETE-bewerkingen zullen ontbrekende gegevens geen conflict veroorzaken en worden dergelijke bewerkingen gewoon overgeslagen."
- Uitgeverstabellen moeten een manier hebben om zichzelf te identificeren ("replica-identiteit" genoemd) om DML-bewerkingen (UPDATE en DELETE) correct te repliceren in replica('s) voor de betreffende rijen. Als de tabel een primaire sleutel heeft, is dit de standaard (lijkt mij de juiste keuze), maar bij afwezigheid van een primaire sleutel zijn er andere configuratie-opties beschikbaar. De hele rij kan worden gebruikt als er geen andere kandidaatsleutel bestaat ('vol' genoemd), hoewel de documentatie vermeldt dat dit doorgaans geen efficiënte oplossing is. (Zie het gedeelte REPLICA IDENTITEIT in de documenten voor een beschrijving op een lager niveau van hoe u dit instelt)
Beperkingen
De documentatie in paragraaf 31.4. Beperkingen heeft enkele belangrijke herinneringen aan beperkingen die ik zal verdoezelen. Zorg ervoor dat en bekijk de gelinkte pagina hierboven voor de exacte woordenschat.
- Databaseschema en eventuele DDL-opdrachten worden niet ondersteund in de replicatie. Er wordt gesuggereerd dat pg_dump in eerste instantie zou kunnen worden gebruikt, maar toch moet u eventuele verdere wijzigingen en verbeteringen in het schema zelf bijwerken naar alle replica's.
- De gegevens in sequentiekolommen worden gerepliceerd. Maar de reeks zelf zou alleen de startwaarde weergeven. Voor leest is dat oké. Maar als dit uw favoriet is voor failover, moet u zelf de huidige waarde UPDATEN. De documenten stellen hier pg_dump voor.
- Truncate wordt nog niet ondersteund.
- Replicatie van grote objecten wordt niet ondersteund.
- Weergaven, gerealiseerde weergaven, partitie-roottabellen of externe tabellen worden niet ondersteund door de uitgever of de abonnee.
Gerapporteerde veelvoorkomende toepassingen
- U bent alleen geïnteresseerd in bepaalde gegevens en gegevenswijzigingen die u daadwerkelijk repliceert, in plaats van alleen de hele database te repliceren.
- Als u replica('s) nodig heeft voor alleen-lezen bewerkingen, zoals een analysescenario.
- Gebruikers of verschillende subsets van gebruikers beperkte of gecontroleerde toegang tot gegevens toestaan.
- Gegevens distribueren.
- Compatibiliteit met andere PostgreSQL-versies.
Streaming-replicatie
Van het onderzoeken, lezen en bestuderen van Streaming Replicatie, één ding dat ik van tevoren heb begrepen, is de keuze om asynchrone (de standaard) of synchrone replicatie in te stellen.
Ah, meer onbekende termen hè?
Hier is mijn 'high-level' definitie van beide:
Bij asynchrone replicatie is er, nadat een transactie op de primaire transactie is doorgevoerd, een kleine vertraging wanneer diezelfde transactie wordt doorgevoerd en op de replica wordt geschreven. Bij dit type configuratie is er kans op gegevensverlies.
- Eén, stel dat de master crasht.
- Twee, de replica('s) lopen zo ver achter op de master, dat de benodigde gegevens en informatie voor de replica('s) zelfs 'actueel' zijn weggegooid.
Bij synchrone replicatie wordt echter geen transactie als voltooid beschouwd, totdat deze is bevestigd door zowel de master- als de replicaserver(s). Wat een commit zal hebben geschreven naar de WAL van beide servers.
In termen die ik begrijp, betekent dit dat schrijfsels op de master ook zijn bevestigd en geschreven op de replica.
Hier is de officiële uitleg van paragraaf 26.2.8. Synchrone replicatie in de officiële documentatie:
“Bij het aanvragen van synchrone replicatie, zal elke commit van een schrijftransactie wachten tot de bevestiging is ontvangen dat de commit is geschreven naar de write-ahead log op schijf van zowel de primaire als de standby-server. “
Een andere passage uit de documentatie geeft een mooi overzicht van wat er moet zijn (naar mijn mening), een enorm voordeel:"De enige mogelijkheid dat gegevens verloren kunnen gaan, is als zowel de primaire als de stand-by gelijktijdig crasht."
Hoewel niets onmogelijk is, is dat nog steeds een goede garantie dat u geen kopie van uw gegevens zult hebben.
Oké, we weten dat we een van deze configuraties moeten kiezen, maar wat is de algemene essentie?
In een notendop, Streaming Replication verzendt en past WAL-bestanden (Write Ahead Log) van één databaseserver (de master of primaire) toe op een 'replica' (ontvangende database).
Maar er is hier een waarschuwing om in gedachten te houden. Mogelijk kunnen de WAL-bestanden van de master worden gerecycled voordat de standy ze heeft gekregen. Een manier om dit te verminderen is door de instelling wal_keep_segments naar een hogere waarde te verhogen.
Punten op streamingreplicatie
Gerelateerde bronnen ClusterControl for PostgreSQL PostgreSQL Streaming Replication - a Deep Dive Een experthandleiding voor Slony-replicatie voor PostgreSQL- Standaard is streaming-replicatie asynchroon, wat betekent dat er een (misschien kleine) vertraging is tussen de vastgelegde transacties op de master en hun zichtbaarheid op de replica.
- Replica('s) maken verbinding met de master via een netwerkverbinding.
- Houd rekening met authenticatie. Zie hier uit de documentatie:"Het is erg belangrijk dat de toegangsrechten voor replicatie zo worden ingesteld dat alleen vertrouwde gebruikers de WAL-stream kunnen lezen, omdat het gemakkelijk is om geprivilegieerde informatie eruit te extraheren"
Wanneer streamingreplicatie gebruiken
- Een algemeen gebruik (vooral bij analyse) biedt een 'alleen-lezen' replica om de primaire server te ontlasten.
- Je hebt een omgeving met hoge beschikbaarheid nodig.
- Nuttige installatie voor failover naar hot standby-server als de primaire uitvalt.