I det här blogginlägget dyker vi ner i muttrarna och bultar för att ställa in Streaming Replication (SR) i PostgreSQL. Strömmande replikering är den grundläggande byggstenen för att uppnå hög tillgänglighet i ditt PostgreSQL-värd och framställs genom att köra en master-slave-konfiguration.

Master-Slave-terminologi

Master/Primär Server

• Servern som kan ta skrivningar.
• Även kallad läs-/skrivserver.

Slav-/standbyserver

• En server där data hålls synkroniserade med mastern kontinuerligt.
• Även kallad backupserver eller replika.
• En varm standby-server är en som inte kan anslutas till förrän den har befordrats till att bli en huvudserver.
• Däremot kan en hot standby-server acceptera anslutningar och betjänar skrivskyddade frågor. Under resten av den här diskussionen kommer vi bara att fokusera på heta standby-servrar.

Data skrivs till huvudservern och sprids till slavservrarna. Om det finns ett problem med den befintliga masterservern kommer en av slavservrarna att ta över och fortsätta att ta skrivningar för att säkerställa tillgängligheten av systemet.

WAL fraktbaserad replikering

Vad är WAL?

• WAL står för Write-Ahead Logging.
• Det är en loggfil där alla ändringar av databasen skrivs innan de appliceras/skrivs till datafiler.
• WAL används för återställning efter en databaskrasch, vilket säkerställer dataintegritet.
• WAL används i databassystem för att uppnå atomicitet och hållbarhet.

Hur används WAL för replikering?

Write-ahead-loggposter används för att hålla data synkroniserade mellan databasservrarna. Detta uppnås på två sätt:

Filbaserad loggleverans

• WAL-loggfiler skickas från mastern till standby-servrarna för att hålla data synkroniserade.
• Master kan kopiera loggarna direkt till standby-serverlagring eller kan dela lagring med standby-servrarna.
• En WAL-loggfil kan innehålla upp till 16 MB data.
• WAL-filen skickas först efter att den når det tröskelvärdet.
• Detta kommer att orsaka en fördröjning i replikeringen och även öka risken för att förlora data om mastern kraschar och loggar inte arkiveras

Strömmande WAL-poster

• WAL-postbitar strömmas av databasservrar för att hålla data synkroniserade.
• Vänteservern ansluter till mastern för att ta emot WAL-bitarna.
• WAL-posterna strömmas allt eftersom de genereras.
• Strömningen av WAL-poster behöver inte vänta på att WAL-filen fylls i.
• Detta gör att en standby-server kan hålla sig mer uppdaterad än vad som är möjligt med filbaserad loggsändning.
• Som standard är strömmande replikering asynkron även om den också stöder synkron replikering.

Båda metoderna har sina för- och nackdelar. Att använda filbaserad frakt möjliggör punkt-in-time återställning och kontinuerlig arkivering, medan streaming säkerställer omedelbar datatillgänglighet på standby-servrarna. Du kan dock konfigurera PostgreSQL för att använda båda metoderna samtidigt och dra nytta av fördelarna. I den här bloggen koncentrerar vi oss främst på strömmande replikering för att uppnå PostgreSQL hög tillgänglighet.

Hur ställer man in strömmande replikering?

Att ställa in strömmande replikering i PostgreSQL är mycket enkelt. Förutsatt att PostgreSQL redan är installerat på alla servrar kan du följa dessa steg för att komma igång:

Konfiguration på huvudnoden

• Initiera databasen på huvudnoden med hjälp av verktyget initdb.
• Skapa en roll/användare med replikeringsbehörighet genom att köra kommandot nedan. Efter att du kör kommandot kan du verifiera det genom att köra \du för att lista dem på psql.
  •   SKAPA ANVÄNDARE REPLIKATIONSINLOGGNING KRYPTAT LÖSENORD ’’;
• Konfigurera egenskaper relaterade till strömmande replikering i huvudpostgresql-konfigurationsfilen (postgresql.conf):
  

  # Möjliga värden är replik|minimal|logiska wal_level =replica# krävs för pg_rewind-kapacitet när vänteläget inte är synkroniserat med master wal_log_hints =on# ställer in det maximala antalet samtidiga anslutningar från standby-servrarna. max_wal_senders =3 # Parametern nedan används för att tala om för mastern att behålla det minsta antalet # segment av WAL-loggar så att de inte raderas innan standby förbrukar dem. # varje segment är 16 MB wal_keep_segments =8 # Parametern nedan möjliggör skrivskyddad anslutning på noden när den är i # standby-roll. Detta ignoreras när servern körs som master. hot_standby =på

• Lägg till replikeringspost i filen pg_hba.conf för att tillåta replikeringsanslutningar mellan servrarna:
  

  # Tillåt replikeringsanslutningar från localhost, # av en användare med replikeringsbehörighet. # TYPE    DATABAS    ANVÄNDARE    ADRESS    METOD värd    replikering    repl_user    IPaddress(CIDR)    md5

• Starta om PostgreSQL-tjänsten på huvudnoden för att ändringarna ska träda i kraft.

Konfiguration på standbynod(er)

• Skapa bassäkerhetskopian för huvudnoden med hjälp av verktyget pg_basebackup och använd det som utgångspunkt för vänteläget.
  

  # Förklarar några alternativ som används för verktyget pg_basebackup alternativet # -X används för att inkludera de nödvändiga transaktionsloggfilerna (WAL-filer) i #-säkerhetskopian. När du anger ström kommer detta att öppna en andra anslutning till servern # och börja streama transaktionsloggen samtidigt som säkerhetskopieringen körs. # -c är kontrollpunktsalternativet. Om du ställer in den på snabb tvingas kontrollpunkten skapas # snart. # -W tvingar pg_basebackup att fråga efter ett lösenord innan du ansluter # till en databas. pg_basebackup -D  -h -X stream -c fast -U repl_user -W

• Skapa replikeringskonfigurationsfilen om den inte finns (den skapas automatiskt om -R-alternativet finns i pg_basebackup):
  

  # Anger om servern ska startas som ett standbyläge. I strömreplikering, # måste denna parameter vara inställd på. standby_mode ='on'# Anger en anslutningssträng som används för att standby-servern ska ansluta # med den primära/mastern. primary_conninfo =‘host= port= user= password= application_name=”host_name”’# Anger återställning till en viss tidslinje. Standard är att återställa längs # samma tidslinje som var aktuell när bassäkerhetskopian togs. # Att ställa in detta på senaste återställning till den senaste tidslinjen som hittades # i arkivet, vilket är användbar i en standby-server. recovery_target_timeline ='senaste'

• Starta vänteläget.

Standby-konfigurationen måste göras på alla standby-servrar. När konfigurationen är klar och ett standbyläge har startat kommer den att ansluta till mastern och starta strömmande loggar. Detta kommer att ställa in replikeringen och kan verifieras genom att köra SQL-satsen "SELECT * FROM pg_stat_replication; “.

Som standard är strömmande replikering asynkron. Om du vill göra det synkront kan du konfigurera det med följande parametrar:

Synchronous_commit måste vara på för synkron replikering och detta är standard. PostgreSQL ger mycket flexibla alternativ för synkron commit och kan konfigureras på användar-/databasnivåer. Giltiga värden är följande:

• Av – Transaktionsbekräftelse bekräftas för klienten redan innan transaktionsposten faktiskt rensas till WAL-loggfilen på den noden.
• Lokalt –  Transaktionsbekräftelse bekräftas för klienten först efter att transaktionsposten har tömts in i WAL-loggfilen på den noden.
• Remote_write – Transaktionsbekräftelse bekräftas till klienten först efter att servern/servrarna som specificeras av synchronous_standby_names bekräftar att transaktionsposten skrevs till diskcachen, men inte nödvändigtvis efter att ha tömts till WAL-loggfilen.
• På – Transaktionsbekräftelse bekräftas för klienten först efter att servern/servrarna som specificeras av synchronous_standby_names bekräftar att transaktionsposten rensas till WAL-loggfilen.
• Remote_apply – Transaktionsbekräftelse bekräftas för klienten först efter att servern/servrarna som specificeras av synchronous_standby_names bekräftar att transaktionsposten rensas till WAL-loggfilen och den appliceras på databasen.

Om du ställer in synchronous_commit till av eller lokal i synkront replikeringsläge kommer det att fungera som asynkront, och kan hjälpa dig att uppnå bättre skrivprestanda. Detta kommer dock att medföra högre risk för dataförlust och läsförseningar på standby-servrar. Om den är inställd på remote_apply kommer den att säkerställa omedelbar datatillgänglighet på standby-servrar, men skrivprestandan kan försämras eftersom den bör tillämpas på alla/nämnda standby-servrar.

Du kan aktivera arkiveringsläget om du planerar att använda kontinuerlig arkivering och punkt-i-tidsåterställning. Även om det inte är obligatoriskt för strömmande replikering, har det extra fördelar att aktivera arkivläge. Om arkivläget inte är aktiverat måste vi använda replikeringsplatserna funktion eller se till att wal_keep_segments värdet är tillräckligt högt baserat på belastning.

Se den här utmärkta presentationen för att gå in på mer information om hög tillgänglighet i PostgreSQL. I vårt nästa blogginlägg kommer vi att introducera dig till världen av verktyg som används för att hantera hög tillgänglighet för PostgreSQL med hjälp av strömmande replikering.