In deze blogpost gaan we dieper in op het instellen van Streaming Replication (SR) in PostgreSQL. Streaming-replicatie is de fundamentele bouwsteen voor het bereiken van hoge beschikbaarheid in uw PostgreSQL-hosting en wordt geproduceerd door een master-slave-configuratie uit te voeren.

Master-Slave-terminologie

Hoofd/Primaire Server

• De server die schrijfbewerkingen kan verwerken.
• Ook wel lees-/schrijfserver genoemd.

Slaaf/Standby-server

• Een server waar de gegevens continu gesynchroniseerd worden gehouden met de master.
• Ook wel back-upserver of replica genoemd.
• Een warme standby-server is er een waar geen verbinding mee kan worden gemaakt totdat deze is gepromoveerd tot masterserver.
• Daarentegen kan een hot standby-server verbindingen accepteren en alleen-lezen-query's uitvoeren. Voor de rest van deze discussie zullen we ons alleen concentreren op hot standby-servers.

Gegevens worden naar de masterserver geschreven en naar de slaveservers gepropageerd. In het geval dat er een probleem is met de bestaande masterserver, zal een van de slaveservers het overnemen en de schrijfbewerkingen blijven uitvoeren om de beschikbaarheid van het systeem te garanderen.

WAL Shipping-Based Replicatie

Wat is WAL?

• WAL staat voor Write-Ahead Logging.
• Het is een logbestand waarin alle wijzigingen in de database worden geschreven voordat ze worden toegepast/geschreven in gegevensbestanden.
• WAL wordt gebruikt voor herstel na een databasecrash, waardoor de gegevensintegriteit wordt gewaarborgd.
• WAL wordt gebruikt in databasesystemen om atomiciteit en duurzaamheid te bereiken.

Hoe wordt WAL gebruikt voor replicatie?

Write-ahead log-records worden gebruikt om de gegevens gesynchroniseerd te houden tussen de databaseservers. Dit wordt op twee manieren bereikt:

Bestandsgebaseerde verzending van logbestanden

• WAL-logbestanden worden van de master naar de standby-servers verzonden om de gegevens gesynchroniseerd te houden.
• Master kan de logs rechtstreeks kopiëren naar de standby-serveropslag of kan de opslag delen met de standby-servers.
• Eén WAL-logbestand kan maximaal 16 MB aan gegevens bevatten.
• Het WAL-bestand wordt pas verzonden nadat het die drempel heeft bereikt.
• Dit veroorzaakt een vertraging in de replicatie en vergroot ook de kans op gegevensverlies als de master crasht en logbestanden niet worden gearchiveerd

WAL-records streamen

• Brokken WAL-records worden gestreamd door databaseservers om de gegevens gesynchroniseerd te houden.
• De standby-server maakt verbinding met de master om de WAL-chunks te ontvangen.
• De WAL-records worden gestreamd terwijl ze worden gegenereerd.
• Het streamen van WAL-records hoeft niet te wachten tot het WAL-bestand is gevuld.
• Hierdoor kan een standby-server up-to-date blijven dan mogelijk is met op bestanden gebaseerde logverzending.
• Standaard is streaming-replicatie asynchroon, hoewel het ook synchrone replicatie ondersteunt.

Beide methoden hebben hun voor- en nadelen. Het gebruik van op bestanden gebaseerde verzending maakt herstel op een bepaald tijdstip en continue archivering mogelijk, terwijl streaming zorgt voor de onmiddellijke beschikbaarheid van gegevens op de standby-servers. U kunt PostgreSQL echter configureren om beide methoden tegelijkertijd te gebruiken en van de voordelen te genieten. In deze blog concentreren we ons voornamelijk op streamingreplicatie om PostgreSQL hoge beschikbaarheid te bereiken.

Hoe stel ik streaming-replicatie in?

Het instellen van streaming-replicatie in PostgreSQL is heel eenvoudig. Ervan uitgaande dat PostgreSQL al op alle servers is geïnstalleerd, kunt u deze stappen volgen om aan de slag te gaan:

Configuratie op hoofdknooppunt

• Initialiseer de database op het hoofdknooppunt met het hulpprogramma initdb.
• Maak een rol/gebruiker met replicatierechten door de onderstaande opdracht uit te voeren. Nadat u het commando hebt uitgevoerd, kunt u het verifiëren door \du uit te voeren om ze op psql te vermelden.
  •   GEBRUIKER MAKEN REPLICATIE LOGIN VERSLEUTELD WACHTWOORD ’’;
• Configureer eigenschappen met betrekking tot streamingreplicatie in het hoofd PostgreSQL-configuratiebestand (postgresql.conf):
  

  # Mogelijke waarden zijn replica|minimal|logical wal_level =replica# vereist voor pg_rewind-mogelijkheid wanneer stand-by niet synchroon loopt met master wal_log_hints =on# stelt het maximum aantal gelijktijdige verbindingen van de standby-servers in. max_wal_senders =3 # De onderstaande parameter wordt gebruikt om de master te vertellen het minimumaantal # segmenten van WAL-logboeken te behouden, zodat ze niet worden verwijderd voordat ze in stand-by worden gebruikt. # elk segment is 16 MB wal_keep_segments =8 # De onderstaande parameter maakt alleen-lezen verbinding mogelijk op het knooppunt wanneer het zich in # standby-rol bevindt. Dit wordt genegeerd wanneer de server als master draait. hot_standby =aan

• Voeg replicatie-item toe aan het bestand pg_hba.conf om replicatieverbindingen tussen de servers toe te staan:
  

  # Sta replicatieverbindingen toe vanaf localhost, # door een gebruiker met het replicatierecht. # TYPE    DATABASE    GEBRUIKER    ADRES    METHODE host    replicatie    repl_user    IPaddress(CIDR)    md5

• Start de PostgreSQL-service opnieuw op het hoofdknooppunt om de wijzigingen door te voeren.

Configuratie op Standby Node(s)

• Maak de basisback-up van het hoofdknooppunt met behulp van het hulpprogramma pg_basebackup en gebruik het als startpunt voor de stand-by.
  

  # Een paar opties uitleggen die worden gebruikt voor het hulpprogramma pg_basebackup # -X optie wordt gebruikt om de vereiste transactielogbestanden (WAL-bestanden) op te nemen in de # back-up. Als je stream specificeert, wordt er een tweede verbinding met de server geopend # en wordt het transactielogboek gestreamd terwijl de back-up wordt uitgevoerd. # -c is de checkpoint-optie. Als u dit op snel zet, wordt het # binnenkort aangemaakt. # -W dwingt pg_basebackup om een ​​wachtwoord te vragen voordat # verbinding maakt met een database. pg_basebackup -D  -h -X stream -c fast -U repl_user -W

• Maak het configuratiebestand voor replicatie indien niet aanwezig (het wordt automatisch gemaakt als de optie -R is opgegeven in pg_basebackup):
  

  # Specificeert of de server moet worden gestart als een stand-by. Bij streamingreplicatie # moet deze parameter zijn ingesteld op on. standby_mode ='on'# Specificeert een verbindingsreeks die wordt gebruikt voor de standby-server om # te verbinden met de primaire/master. primary_conninfo =‘host= port= user= password= application_name=”host_name”’# Specificeert het herstellen naar een bepaalde tijdlijn. De standaardinstelling is om te herstellen langs de # dezelfde tijdlijn die actueel was toen de basisback-up werd gemaakt. # Dit instellen op de laatste herstelbewerkingen naar de laatst gevonden tijdlijn # in het archief, dat is handig in een standby-server. recovery_target_timeline ='nieuwste'

• Start de stand-by.

De standby-configuratie moet op alle standby-servers worden uitgevoerd. Zodra de configuratie is voltooid en een stand-by is gestart, zal deze verbinding maken met de master en beginnen met het streamen van logs. Dit zal de replicatie instellen en kan worden geverifieerd door de SQL-instructie "SELECT * FROM pg_stat_replication; uit te voeren. “.

Standaard is streaming-replicatie asynchroon. Als u het synchroon wilt maken, kunt u het configureren met de volgende parameters:

Synchroon_commit moet zijn ingeschakeld voor synchrone replicatie en dit is de standaardinstelling. PostgreSQL biedt zeer flexibele opties voor synchrone vastlegging en kan worden geconfigureerd op gebruikers-/databaseniveau. Geldige waarden zijn als volgt:

• Uit – Transactie-commit wordt aan de klant bevestigd, zelfs voordat dat transactierecord daadwerkelijk wordt gewist naar het WAL-logbestand op dat knooppunt.
• Lokaal –  De vastlegging van een transactie wordt pas aan de klant bevestigd nadat die transactierecord is gewist in het WAL-logbestand op dat knooppunt.
• Remote_write – De vastlegging van een transactie wordt pas aan de client bevestigd nadat de server(s) gespecificeerd door synchronous_standby_names bevestigt dat de transactierecord naar de schijfcache is geschreven, maar niet noodzakelijkerwijs nadat deze naar het WAL-logbestand is gewist.
• Aan – De vastlegging van een transactie wordt pas aan de client bevestigd nadat de server(s) gespecificeerd door synchronous_standby_names heeft bevestigd dat de transactierecord is gewist naar het WAL-logbestand.
• Remote_apply – De vastlegging van een transactie wordt pas aan de client bevestigd nadat de server(s) die zijn gespecificeerd door synchronous_standby_names heeft bevestigd dat het transactierecord is gewist naar het WAL-logbestand en is toegepast op de database.

Als u synchronous_commit instelt op uit of lokaal in de synchrone replicatiemodus, werkt het asynchroon en kunt u betere schrijfprestaties behalen. Dit heeft echter een groter risico op gegevensverlies en leesvertragingen op standby-servers. Indien ingesteld op remote_apply, zorgt dit voor onmiddellijke beschikbaarheid van gegevens op standby-servers, maar de schrijfprestaties kunnen afnemen omdat het moet worden toegepast op alle/vermelde standby-servers.

Je kunt de archiefmodus inschakelen als je van plan bent continu archiveren en point-in-time herstel te gebruiken. Hoewel het niet verplicht is voor streamingreplicatie, heeft het inschakelen van de archiefmodus extra voordelen. Als de archiefmodus niet is ingeschakeld, moeten we de replicatieslots . gebruiken functie of zorg ervoor dat wal_keep_segments waarde is hoog genoeg ingesteld op basis van belasting.

Raadpleeg deze uitstekende presentatie voor meer details over hoge beschikbaarheid in PostgreSQL. In onze volgende blogpost laten we u kennismaken met de wereld van tools die worden gebruikt om hoge beschikbaarheid voor PostgreSQL te beheren met behulp van streamingreplicatie.