Het opzetten van replicatie tussen twee databases biedt fouttolerantie tegen onverwachte ongelukken. Het wordt beschouwd als de beste strategie om hoge beschikbaarheid te bereiken bij rampen.<\/p>\n
In dit artikel duiken we in de verschillende strategie\u00ebn die backend ontwikkelaars<\/a> kunnen toepassen voor naadloze PostgreSQL replicatie.<\/p>\n PostgreSQL replicatie kan je defini\u00ebren als het proces van het kopi\u00ebren van gegevens van een PostgreSQL databaseserver<\/a> naar een andere server. De bron-databaseserver wordt ook wel de “primaire” server genoemd, terwijl de databaseserver die de gekopieerde gegevens ontvangt bekend staat als de “replica” server.<\/p>\n De PostgreSQL database volgt een rechtlijnig replicatiemodel, waarbij alle writes naar een primaire node gaan. De primaire node kan deze veranderingen dan toepassen en naar de secundaire nodes versturen.<\/p>\n Failover is een methode om gegevens te herstellen als de primaire server<\/a> het om welke reden dan ook begeeft. Zolang je PostreSQL hebt geconfigureerd om je fysieke streaming replicatie te beheren, zullen jij – en je gebruikers – beschermd zijn tegen downtime als gevolg van een primaire server snafu.<\/p>\n Merk op dat het opzetten en opstarten van het failoverproces enige tijd in beslag kan nemen. Er zijn geen ingebouwde hulpmiddelen om serverfouten in PostgreSQL te monitoren en te scopen, dus je zult creatief moeten zijn.<\/p>\n Gelukkig hoeft je niet afhankelijk te zijn van PostgreSQL voor failover. Er zijn speciale tool die automatische failover en automatisch overschakelen naar de stand-by mogelijk maken, waardoor de downtime van de database<\/a> korter wordt.<\/p>\n Door failover replicatie in te stellen, garandeer je bijna hoge beschikbaarheid door ervoor te zorgen dat stand-by’s beschikbaar zijn als de primaire server ooit instort.<\/p>\n Hier zijn een paar belangrijke voordelen van het gebruik van PostgreSQL replicatie:<\/p>\n Over het algemeen geloven mensen dat wanneer je met een primaire en secundaire architectuur rommelt, er maar \u00e9\u00e9n manier is om backups en replicatie op te zetten<\/a>. PostgreSQL deployments kunnen echter elk van deze drie methoden volgen<\/a>:<\/p>\n PostgreSQL streaming replicatie, ook bekend als WAL replicatie, kan naadloos opgezet worden nadat PostgreSQL op alle servers ge\u00efnstalleerd is. Deze aanpak van replicatie is gebaseerd op het verplaatsen van de WAL bestanden van de primaire naar de doeldatabase.<\/p>\n Je kunt PostgreSQL streaming replicatie implementeren door een primair-secundaire configuratie te gebruiken. De primaire server is de hoofdinstantie die de primaire database en al zijn bewerkingen afhandelt. De secundaire server fungeert als aanvullende instantie en voert alle veranderingen aan de primaire database op zichzelf uit, waarbij hij een identieke kopie genereert. De primaire is de lees\/schrijf-server terwijl de secundaire server alleen-lezen is.<\/p>\n Voor deze methode moet je zowel de primaire node als de standby node configureren. De volgende secties zullen de stappen verduidelijken die nodig zijn om ze gemakkelijk in te stellen.<\/p>\n Je kunt de primaire node instellen voor streaming replicatie door de volgende stappen uit te voeren:<\/p>\n Om de database te initialiseren<\/a>, kun je gebruik maken van het De gebruiker zal een wachtwoord en een gebruikersnaam moeten opgeven voor de gegeven query. Het replicatie keyword wordt gebruikt om de gebruiker de vereiste rechten te geven. Een voorbeeld query zou er ongeveer zo uitzien:<\/p>\n Vervolgens kun je de streaming eigenschappen configureren met het PostgreSQL configuratiebestand (postgresql.conf<\/strong>) dat als volgt gewijzigd kan worden:<\/p>\n Hier volgt wat achtergrondinformatie\u00a0 rond de parameters die in de vorige snippet gebruikt werden:<\/p>\n Nadat je de parameters in het postgresql.conf<\/strong> bestand gewijzigd hebt, kun je met een nieuwe replicatie entry in het pg_hba.conf<\/strong> bestand de servers in staat stellen een verbinding met elkaar op te zetten voor replicatie.<\/p>\n Je vindt dit bestand meestal in de data map van PostgreSQL. Je kunt hiervoor het volgende codefragment gebruiken:<\/p>\n Zodra het codefragment wordt uitgevoerd, staat de primaire server een gebruiker genaamd Om de stand-by node in te stellen voor streaming replicatie, volg je deze stappen:<\/p>\n Om de standby node in te stellen, maak je gebruik van de De parameters die in de bovenstaande syntaxis gebruikt worden zijn als volgt:<\/p>\n Vervolgens moet je controleren of het replicatie configuratiebestand bestaat. Als dat niet zo is, kun je het replicatie configuratiebestand genereren als recovery.conf<\/strong>.<\/p>\n Je moet dit bestand aanmaken in de gegevensmap van de PostgreSQL installatie. Je kunt het automatisch genereren door de Het recovery.conf<\/strong> bestand moet de volgende commando’s bevatten:<\/p>\n De parameters die in de bovengenoemde commando’s gebruikt worden zijn als volgt:<\/p>\n Om een verbinding op te zetten moet je de gebruikersnaam, het IP adres, en het wachtwoord opgeven als waarden voor de parameter primary_conninfo. Bijvoorbeeld:<\/p>\n Tenslotte kun je de secundaire server herstarten om het configuratieproces te voltooien.<\/p>\n Streaming replicatie komt echter met verschillende uitdagingen, zoals:<\/p>\n De replicated block device benadering maakt gebruik van disk mirroring (ook bekend als volumereplicatie). Bij deze aanpak worden veranderingen naar een persistent volume geschreven dat synchroon naar een ander volume gespiegeld wordt.<\/p>\n Het extra voordeel van deze aanpak is de compatibiliteit en de duurzaamheid van de gegevens in cloudomgevingen met alle relationele databases, waaronder PostgreSQL, MySQL, en SQL Server<\/a>, om er een paar te noemen.<\/p>\n De disk-mirroring aanpak van PostgreSQL replicatie vereist echter dat je zowel WAL log- als tabelgegevens repliceert. Omdat elk schrijven naar de database nu synchroon over het netwerk moet gaan, kun je je niet veroorloven ook maar een enkele byte te verliezen, want dat zou je database in een corrupte toestand kunnen achterlaten.<\/p>\n Deze aanpak wordt gewoonlijk toegepast met Azure PostgreSQL en Amazon RDS.<\/p>\n WAL bestaat uit segmentbestanden (standaard 16 MB). Elk segment heeft een of meer records. Een log sequence record (LSN) is een pointer naar een record in WAL, die je de positie\/plaats laat weten waar het record in het logbestand is opgeslagen.<\/p>\n Een stand-by server maakt gebruik van WAL segmenten – in PostgreSQL terminologie ook wel XLOGS genoemd – om voortdurend veranderingen van zijn primaire server te repliceren. Je kunt write-ahead logging gebruiken om duurzaamheid en atomiciteit in een DBMS te verlenen door blokken van byte-array gegevens (elk met een unieke LSN) te serialiseren naar stabiele opslag voordat ze in een database worden toegepast.<\/p>\n Het toepassen van een mutatie op een database kan leiden tot verschillende bewerkingen aan het bestandssysteem. Een vraag die opkomt is hoe een database atomiciteit kan garanderen bij een serverstoring door een stroomstoring terwijl hij midden in een bestandssysteemupdate zat. Als een database opstart, begint hij een startup- of replayproces dat de beschikbare WAL segmenten kan lezen en ze vergelijkt met de LSN die op elke gegevenspagina zijn opgeslagen (elke gegevenspagina is gemarkeerd met de LSN van het laatste WAL record dat op de pagina betrekking heeft).<\/p>\n Streaming replicatie verfijnt het log shipping proces. In plaats van te wachten op de WAL switch, worden de records verzonden terwijl ze worden aangemaakt, waardoor de replicatie vertraging afneemt.<\/p>\n Streaming replicatie overtroeft ook log shipping omdat de standby server over het netwerk met de primaire server in verbinding staat door gebruik te maken van een replicatieprotocol. De primaire server kan dan WAL records direct over deze verbinding versturen zonder afhankelijk te zijn van door de eindgebruiker verstrekte scripts.<\/p>\n Log shipping wordt gedefinieerd als het kopi\u00ebren van logbestanden naar een andere PostgreSQL server om een andere stand-by server te genereren door WAL bestanden opnieuw af te spelen. Deze server is geconfigureerd om in herstelmodus te werken, en zijn enige doel is om eventuele nieuwe WAL bestanden toe te passen als ze opduiken.<\/p>\n Deze secundaire server wordt dan een warme backup van de primaire PostgreSQL server. Hij kan ook ingesteld worden als leesreplica, waarbij hij alleen-lezen queries kan aanbieden, ook wel hot stand-by genoemd.<\/p>\n Het kopi\u00ebren van WAL bestanden terwijl ze gemaakt worden naar een andere plaats dan de Het script kan gebruik maken van het Andere log-gebaseerde configuraties zijn onder andere:<\/p>\n Een proces bekend als WAL receiver, dat op de stand-by server draait, maakt gebruik van de verbindingsgegevens die in de Om streaming replicatie te starten kan het frontend binnen het opstartbericht de replicatie parameter zenden. Een Booleaanse waarde van true, yes, 1, of ON laat de backend<\/a> weten dat hij in fysieke replicatie WAL sender mode moet gaan.<\/p>\n WAL sender is weer een ander proces dat op de primaire server draait en belast is met het verzenden van de WAL records naar de stand-by server als ze gegenereerd worden. De WAL ontvanger bewaart de WAL records in WAL alsof ze door clientactiviteit van lokaal verbonden clients zijn aangemaakt.<\/p>\n Zodra de WAL records de WAL segmentbestanden bereiken, blijft de stand-by server voortdurend de WAL herhalen, zodat primaire en stand-by synchroon lopen.<\/p>\n In dit onderdeel krijg je een dieper inzicht in de veelgebruikte modellen (single-master en multi-master replicatie), typen (fysieke en logische replicatie), en modi (synchroon en asynchroon) van PostgreSQL replicatie.<\/p>\n Schaalbaarheid betekent het toevoegen van meer resources\/hardware aan bestaande nodes om de mogelijkheden van de database te vergroten om meer gegevens op te slaan en te verwerken, wat horizontaal en verticaal kan worden bereikt. PostgreSQL replicatie is een voorbeeld van horizontale schaalbaarheid die veel moeilijker te realiseren is dan verticale schaalbaarheid. We kunnen horizontale schaalbaarheid vooral bereiken door single-master replicatie (SMR) en multi-master replicatie (MMR).<\/p>\n Met single-master replicatie kunnen gegevens alleen op een enkele node gewijzigd worden, en deze wijzigingen worden naar een of meer nodes gerepliceerd. De gerepliceerde tabellen in de replica database mogen geen wijzigingen aannemen, behalve die van de primaire server. Zelfs als ze dat wel doen, worden de wijzigingen niet naar de primaire server gerepliceerd.<\/p>\n Meestal is SMR voldoende voor de toepassing omdat het minder ingewikkeld is om in te stellen en te beheren, met geen kans op conflicten. Single-master replicatie is ook unidirectioneel, omdat de replicatiegegevens hoofdzakelijk in \u00e9\u00e9n richting stromen, van de primaire naar de replica database.<\/p>\n In sommige gevallen kan SMR alleen niet voldoende zijn, en moet je MMR implementeren. MMR staat toe dat meer dan \u00e9\u00e9n node als primaire node fungeert. Veranderingen aan tabelrijen in meer dan \u00e9\u00e9n aangewezen primair gegevensbestand worden gerepliceerd naar hun pendant tabellen in elk ander primair gegevensbestand. In dit model worden vaak conflictresolutieschema’s gebruikt om problemen als dubbele primaire sleutels te vermijden.<\/p>\n Er zijn een paar voordelen aan het gebruik van MMR, namelijk:<\/p>\n Het nadeel van het toepassen van MMR is echter de complexiteit en de moeilijkheid om conflicten op te lossen.<\/p>\n Verschillende takken en toepassingen bieden MMR oplossingen aan omdat PostgreSQL die niet van nature ondersteunt. Deze oplossingen kunnen open-source<\/a>, gratis, of betaald zijn. E\u00e9n zo’n uitbreiding<\/a> is bidirectionele replicatie (BDR) die asynchroon is en gebaseerd is op de PostgreSQL logische decoderingsfunctie.<\/p>\n Omdat de BDR toepassing transacties op andere nodes herhaalt, kan de herhaaloperatie mislukken als er een conflict is tussen de transactie die wordt toegepast en de transactie die op de ontvangende node is vastgelegd.<\/p>\n Er zijn twee soorten PostgreSQL replicatie: logische en fysieke replicatie.<\/p>\n Een eenvoudige logische<\/em> bewerking Fysieke replicatie heeft meestal te maken met bestanden en mappen. Het weet niet wat deze bestanden en mappen voorstellen. Deze methoden worden gebruikt om een volledige kopie van de hele gegevens van een enkele cluster bij te houden, meestal op een andere machine, en gebeuren op het niveau van het bestandssysteem of de schijf en gebruiken exacte blokadressen.<\/p>\n Logische replicatie is een manier om gegevensentiteiten en hun wijzigingen te reproduceren, op basis van hun replicatie-identiteit (meestal een primaire sleutel). In tegenstelling tot fysieke replicatie heeft het te maken met databanken, tabellen, en DML operaties en gebeurt het op het niveau van de databasecluster. Het gebruikt een publish<\/em> en subscribe<\/em> model waarbij een of meer subscribers<\/em> geabonneerd zijn op een of meer publications <\/i>op een publisher<\/em> node.<\/p>\n Het replicatieproces begint met het maken van een momentopname van de gegevens op de publisher database en kopieert die dan naar de subscriber. Subscribers halen gegevens uit de publications waarop ze “geabonneerd” zijn en kunnen gegevens later opnieuw publiceren om cascade replication of complexere configuraties mogelijk te maken. De subscriber past de gegevens toe in dezelfde volgorde als de publisher, zodat transactionele consistentie gegarandeerd is voor publications binnen een enkel “abonnement”, ook bekend als transactionele replicatie.<\/p>\n De typische gebruikssituaties voor logische replicatie zijn:<\/p>\n De subscriber database gedraagt zich op dezelfde manier als elke andere PostgreSQL instantie en kan gebruikt worden als publisher voor andere databases door zijn publicaties te defini\u00ebren.<\/p>\n Als de subscriber door de toepassing als alleen-lezen wordt behandeld, zullen er geen conflicten zijn van een enkele subcriber. Anderzijds kunnen er conflicten ontstaan als er door een toepassing of door andere subcribers andere schrijfbewerkingen op dezelfde set tabellen worden uitgevoerd.<\/p>\n PostgreSQL ondersteunt beide mechanismen gelijktijdig. Logische replicatie maakt uitgebreide controle mogelijk over zowel gegevensreplicatie als beveiliging.<\/p>\n Er zijn hoofdzakelijk twee replicatiewijzen in PostgreSQL: synchroon en asynchroon. Synchrone replicatie staat toe dat gegevens tegelijk naar de primaire en de secundaire server worden geschreven, terwijl asynchrone replicatie ervoor zorgt dat de gegevens eerst naar de host worden geschreven en dan naar de secundaire server worden gekopieerd.<\/p>\n Bij replicatie in synchrone modus worden transacties op de primaire database pas als voltooid beschouwd als die veranderingen naar alle replica’s zijn gerepliceerd. De replicaservers moeten allemaal de hele tijd beschikbaar zijn om de transacties op de primaire te kunnen voltooien. De synchrone replicatiemodus wordt gebruikt in hoogwaardige transactie-omgevingen met onmiddellijke failover eisen.<\/p>\n In de asynchrone modus kunnen transacties op de primaire server voltooid worden verklaard als de veranderingen alleen op de primaire server zijn gedaan. Deze veranderingen worden dan later in de tijd gerepliceerd in de replica’s. De replicaservers kunnen gedurende een bepaalde tijd uit-synchroon blijven, een replicatie-vertraging genoemd. In het geval van een crash kan gegevensverlies optreden, maar de overhead die asynchrone replicatie oplevert is gering, dus in de meeste gevallen aanvaardbaar (de host wordt er niet door overbelast). Fail-over van de primaire database naar de secundaire database duurt langer dan bij synchrone replicatie.<\/p>\n In dit onderdeel laten we zien hoe je het PostgreSQL replicatieproces opzet op een Linux besturingssysteem. In dit geval gebruiken we Ubuntu 18.04 LTS en PostgreSQL 10.<\/p>\nWat is PostgreSQL replicatie?<\/h2>\n
![\"Illustratie](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/PostgreSQL-Replication-Illustration.png\")
Wat is een automatische failover?<\/h3>\n
Voordelen van het gebruik van PostgreSQL replicatie<\/h2>\n
\n
Hoe PostgreSQL replicatie werkt<\/h2>\n
\n
Methode 1: streaming<\/h3>\n
Het instellen van de primaire node<\/h4>\n
Stap 1: Initialiseer de database<\/h5>\n
initdb<\/code> utility commando. Vervolgens kun je een nieuwe gebruiker met replicatiebevoegdheden maken met behulp van de volgende opdracht:<\/p>\nCREATE USER 'example_username' REPLICATION LOGIN ENCRYPTED PASSWORD 'example_password';<\/code><\/pre>\nCREATE USER 'rep_username' REPLICATION LOGIN ENCRYPTED PASSWORD 'rep_password';<\/code><\/pre>\nStap 2: Streaming eigenschappen configureren<\/h5>\n
wal_level = logical\nwal_log_hints = on\nmax_wal_senders = 8\nmax_wal_size = 1GB\nhot_standby = on<\/code><\/pre>\n\n
wal_log_hints<\/code>:<\/strong> Deze parameter is nodig voor de pg_rewind<\/code> capability die van pas komt als de stand-by server niet meer synchroon loopt met de primaire server.<\/li>\nwal_level<\/code>:<\/strong> Je kunt deze parameter gebruiken om PostgreSQL streaming replicatie in te schakelen, met mogelijke waarden als minimal<\/code>, replica<\/code>, of logical<\/code>.<\/li>\nmax_wal_size<\/code>:<\/strong> Hiermee kun je de grootte opgeven van de WAL bestanden die in logbestanden kunnen worden bewaard.<\/li>\nhot_standby<\/code>:<\/strong> Je kunt deze parameter gebruiken voor een read-on verbinding met de secundaire als hij op ON is gezet.<\/li>\nmax_wal_senders<\/code>:<\/strong> Je kunt max_wal_senders<\/code> gebruiken om het maximum aantal gelijktijdige verbindingen op te geven dat met de stand-by servers tot stand kan worden gebracht.<\/li>\n<\/ul>\nStap 3: Maak een nieuwe entry<\/h5>\n
host replication rep_user IPaddress md5<\/code><\/pre>\nrep_user<\/code> toe verbinding te maken en als de stand-by server te fungeren door het opgegeven IP te gebruiken voor replicatie. Bijvoorbeeld:<\/p>\nhost replication rep_user 192.168.0.22\/32 md5<\/code><\/pre>\nStand-by node instellen<\/h4>\n
Stap 1: Maak een backup van de primaire node<\/h5>\n
pg_basebackup<\/code> tool om een backup van de primaire node te genereren. Deze zal dienen als startpunt voor de stand-by node. Je kunt dit hulpprogramma gebruiken met de volgende syntaxis:<\/p>\npg_basebackp -D -h -X stream -c fast -U rep_user -W<\/code><\/pre>\n\n
-h<\/code>:<\/strong> Je kunt dit gebruiken om de primaire host te vermelden.<\/li>\n-D<\/code>:<\/strong> Deze parameter geeft de directory aan waarin je momenteel werkt.<\/li>\n-C<\/code>:<\/strong> Je kunt dit gebruiken om de checkpoints in te stellen.<\/li>\n-X<\/code>:<\/strong> Deze parameter kun je gebruiken om de nodige transactielogbestanden op te nemen.<\/li>\n-W<\/code>:<\/strong> Je kunt deze parameter gebruiken om de gebruiker om een wachtwoord te vragen voordat hij verbinding maakt met de database.<\/li>\n<\/ul>\nStap 2: Replicatie configuratiebestand instellen<\/h5>\n
-R<\/code> optie te gebruiken binnen de tool pg_basebackup<\/code>.<\/p>\nstandby_mode = 'on'\n\n<\/code>primary_conninfo = 'host=<master_host> port=<postgres_port> user=<replication_user> password=<password> application_name=\"host_name\"'\n\n<\/code>recovery_target_timeline = 'latest'<\/code><\/pre>\n\n
primary_conninfo<\/code>:<\/strong> Je kunt dit gebruiken om een verbinding te maken tussen de primaire en secundaire servers door gebruik te maken van een verbindingsstring.<\/li>\nstandby_mode<\/code>:<\/strong> Deze parameter kan ervoor zorgen dat de primaire server als stand-by start als hij ingeschakeld wordt.<\/li>\nrecovery_target_timeline<\/code>:<\/strong> Je kunt dit gebruiken om de hersteltijd in te stellen.<\/li>\n<\/ul>\nprimary_conninfo = 'host=192.168.0.26 port=5432 user=rep_user password=rep_pass'<\/code><\/pre>\nStap 3: Herstart de secundaire server<\/h5>\n
\n
Methode 2: Replicated block device<\/h3>\n
Methode 3: WAL<\/h3>\n
Log shipping-gebaseerde replicatie (blokniveau)<\/h4>\n
Log shipping-gebaseerde replicatie (bestandsniveau)<\/h4>\n
Continu WAL archivering<\/h4>\n
pg_wal<\/code> subdirectory om ze te archiveren wordt WAL archivering genoemd. PostgreSQL zal een door de gebruiker gegeven script aanroepen om te archiveren, telkens als een WAL bestand wordt aangemaakt.<\/p>\nscp<\/code> commando om het bestand te dupliceren naar een of meer plaatsen, zoals een NFS mount. Eenmaal gearchiveerd kunnen de WAL segmentbestanden gebruikt worden om de database op elk willekeurig moment te herstellen.<\/p>\n\n
Gegevens van het WAL streaming protocol<\/h4>\n
primary_conninfo<\/code> parameter van recovery.conf<\/strong> staan en verbindt zich met de primaire server door gebruik te maken van een TCP\/IP verbinding.<\/p>\n![\"WAL](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/WAL-Streaming-Protocol-Details.png\")
Elementen van PostgreSQL replicatie<\/h2>\n
Modellen van PostgreSQL databasereplicatie<\/h3>\n
\n
Soorten PostgreSQL replicatie<\/h3>\n
initdb<\/code> zou de fysische bewerking uitvoeren van het aanmaken van een basismap voor een cluster. Evenzo zou een eenvoudige logische<\/em> bewerking CREATE DATABASE<\/code>\u00a0de fysieke<\/em> bewerking uitvoeren van het maken van een submap in de basismap.<\/p>\n\n
Replicatietypen<\/h3>\n
Hoe PostgreSQL replicatie op te zetten<\/h2>\n