I dette blogindlæg dykker vi ned i møtrikker og bolte ved opsætning af Streaming Replication (SR) i PostgreSQL. Streamingreplikering er den grundlæggende byggesten til at opnå høj tilgængelighed i din PostgreSQL-hosting og produceres ved at køre en master-slave-konfiguration.

Master-Slave-terminologi

Master/Primær server

• Serveren, der kan tage skrivninger.
• Også kaldet læse-/skriveserver.

Slave-/standbyserver

• En server, hvor dataene konstant holdes synkroniseret med masteren.
• Også kaldet backupserver eller replika.
• En varm standby-server er en, der ikke kan oprettes forbindelse til, før den er forfremmet til at blive en masterserver.
• I modsætning hertil kan en hot standby-server acceptere forbindelser og levere skrivebeskyttede forespørgsler. I resten af ​​denne diskussion vil vi kun fokusere på hot standby-servere.

Data skrives til masterserveren og udbredes til slaveserverne. Hvis der er et problem med den eksisterende masterserver, vil en af ​​slaveserverne tage over og fortsætte med at tage skrivninger for at sikre tilgængelighed af systemet.

WAL-forsendelsesbaseret replikering

Hvad er WAL?

• WAL står for Write-Ahead Logging.
• Det er en logfil, hvor alle ændringer til databasen er skrevet, før de anvendes/skrives til datafiler.
• WAL bruges til gendannelse efter et databasenedbrud, hvilket sikrer dataintegritet.
• WAL bruges i databasesystemer for at opnå atomicitet og holdbarhed.

Hvordan bruges WAL til replikering?

Write-ahead log records bruges til at holde dataene synkroniseret mellem databaseserverne. Dette opnås på to måder:

Filbaseret logforsendelse

• WAL-logfiler sendes fra masteren til standby-serverne for at holde data synkroniseret.
• Master kan kopiere logfilerne direkte til standby-serverlager eller kan dele lager med standby-servere.
• Én WAL-logfil kan indeholde op til 16 MB data.
• WAL-filen sendes først, når den når denne grænse.
• Dette vil forårsage en forsinkelse i replikeringen og øger også chancerne for at miste data, hvis masteren går ned og logfilerne ikke arkiveres

Streaming WAL Records

• WAL record chunks streames af databaseservere for at holde data synkroniseret.
• Standby-serveren opretter forbindelse til masteren for at modtage WAL-chunks.
• WAL-posterne streames, efterhånden som de genereres.
• Streamingen af ​​WAL-poster behøver ikke vente på, at WAL-filen er udfyldt.
• Dette gør det muligt for en standby-server at forblive mere opdateret, end det er muligt med filbaseret logforsendelse.
• Som standard er streamingreplikering asynkron, selvom den også understøtter synkron replikering.

Begge metoder har deres fordele og ulemper. Brug af filbaseret forsendelse muliggør punkt-i-tidsgendannelse og kontinuerlig arkivering, mens streaming sikrer den øjeblikkelige datatilgængelighed på standby-serverne. Du kan dog konfigurere PostgreSQL til at bruge begge metoder på samme tid og nyde fordelene. I denne blog koncentrerer vi os hovedsageligt om streaming-replikering for at opnå PostgreSQL høj tilgængelighed.

Hvordan konfigureres streamingreplikering?

Opsætning af streamingreplikering i PostgreSQL er meget enkel. Forudsat at PostgreSQL allerede er installeret på alle serverne, kan du følge disse trin for at komme i gang:

Konfiguration på Master Node

• Initialiser databasen på masternoden ved hjælp af værktøjet initdb.
• Opret en rolle/bruger med replikeringsrettigheder ved at køre nedenstående kommando. Efter at du kører kommandoen, kan du bekræfte den ved at køre \du for at vise dem på psql.
  •   OPRET BRUGER REPLIKATIONSLOGIN KRYPTET ADGANGSORD ’’;
• Konfigurer egenskaber relateret til streamingreplikering i master PostgreSQL-konfigurationsfilen (postgresql.conf):
  

  # Mulige værdier er replika|minimal|logiske wal_niveau =replika# påkrævet for pg_rewind-funktion, når standby går ude af synkronisering med master wal_log_hints =on# indstiller det maksimale antal samtidige forbindelser fra standby-serverne. max_wal_senders =3 # Nedenstående parameter bruges til at fortælle masteren om at beholde det mindste antal # segmenter af WAL-logfiler, så de ikke slettes, før standby bruger dem. # hvert segment er 16 MB wal_keep_segments =8 # Nedenstående parameter muliggør skrivebeskyttet forbindelse på noden, når den er i # standby-rolle. Dette ignoreres, når serveren kører som master. hot_standby =på

• Tilføj replikeringsindgang i filen pg_hba.conf for at tillade replikeringsforbindelser mellem serverne:
  

  # Tillad replikeringsforbindelser fra localhost, # af en bruger med replikeringsprivilegiet. # TYPE    DATABASE    BRUGER    ADRESSE    METODE host    replikering    repl_user    IP-adresse(CIDR)    md5

• Genstart PostgreSQL-tjenesten på masternoden for at ændringerne træder i kraft.

Konfiguration på standby node(r)

• Opret basis-backup af masterknude ved hjælp af pg_basebackup-værktøjet og brug det som udgangspunkt for standby.
  

  # Forklaring af nogle få muligheder, der bruges til pg_basebackup-værktøj # -X-indstillingen bruges til at inkludere de nødvendige transaktionslogfiler (WAL-filer) i # backup. Når du angiver stream, vil dette åbne en anden forbindelse til serveren # og begynde at streame transaktionsloggen samtidig med at sikkerhedskopien køres. # -c er kontrolpunktet. Indstilling til hurtig vil tvinge kontrolpunktet til at blive # oprettet snart. # -W tvinger pg_basebackup til at bede om en adgangskode, før der oprettes forbindelse # til en database. pg_basebackup -D  -h -X stream -c fast -U repl_user -W

• Opret replikeringskonfigurationsfilen, hvis den ikke er til stede (den oprettes automatisk, hvis -R-indstillingen er angivet i pg_basebackup):
  

  # Angiver, om serveren skal startes som en standby. I streamingreplikering, # skal denne parameter indstilles til on. standby_mode ='on'# Angiver en forbindelsesstreng, som bruges til at standby-serveren forbinder # med den primære/master. primær_konninfo =‘host= port= user= password= application_name=”host_name”’# Specificerer gendannelse til en bestemt tidslinje. Standardindstillingen er at gendanne langs den # samme tidslinje, som var aktuel, da den grundlæggende sikkerhedskopiering blev taget. # Indstilling af dette til seneste gendannelse til den seneste tidslinje fundet # i arkivet, som er nyttig i en standby-server. recovery_target_timeline ='seneste'

• Start standby.

Standby-konfigurationen skal udføres på alle standby-servere. Når konfigurationen er udført, og en standby er startet, vil den oprette forbindelse til master og starte streaming af logfiler. Dette vil opsætte replikeringen og kan verificeres ved at køre SQL-sætningen "SELECT * FROM pg_stat_replikation; “.

Som standard er streamingreplikering asynkron. Hvis du ønsker at gøre det synkront, kan du konfigurere det ved hjælp af følgende parametre:

Synchronous_commit skal være slået til for synkron replikering, og dette er standard. PostgreSQL giver meget fleksible muligheder for synkron commit og kan konfigureres på bruger-/databaseniveau. Gyldige værdier er som følger:

• Fra – Transaktionsforpligtelse bekræftes over for klienten, selv før denne transaktionspost rent faktisk tømmes til WAL-logfilen på den node.
• Lokal –  Transaktionsforpligtelse anerkendes først til klienten, efter at transaktionsposten er tømt ind i WAL-logfilen på den node.
• Remote_write – Transaktionsbekræftelse bekræftes først til klienten, efter at serveren(e) specificeret af synchronous_standby_names bekræfter, at transaktionsposten blev skrevet til diskcachen, men ikke nødvendigvis efter at være blevet tømt til WAL-logfilen.
• Til – Transaktionsbekræftelse anerkendes først til klienten, efter at serveren/serverne specificeret af synchronous_standby_names bekræfter, at transaktionsposten er tømt til WAL-logfilen.
• Remote_apply – Transaktionsbekræftelse anerkendes først til klienten, efter at serveren(e) specificeret af synchronous_standby_names bekræfter, at transaktionsposten er tømt til WAL-logfilen, og den er anvendt på databasen.

Hvis du indstiller synchronous_commit til off eller local i synkron replikeringstilstand, vil det få det til at fungere som asynkront, og kan hjælpe dig med at opnå bedre skriveydeevne. Dette vil dog have højere risiko for datatab og læseforsinkelser på standby-servere. Hvis den er indstillet til remote_apply, vil den sikre øjeblikkelig datatilgængelighed på standby-servere, men skriveydeevnen kan forringes, da den bør anvendes på alle/nævnte standby-servere.

Du kan aktivere arkiveringstilstanden, hvis du planlægger at bruge kontinuerlig arkivering og punkt-i-tidsgendannelse. Selvom det ikke er obligatorisk for streamingreplikering, har aktivering af arkivtilstand ekstra fordele. Hvis arkivtilstand ikke er aktiveret, skal vi bruge replikeringspladserne funktion eller sørg for, at wal_keep_segments værdien er sat højt nok baseret på belastning.

Se denne fremragende præsentation for at gå ind i flere detaljer om høj tilgængelighed i PostgreSQL. I vores næste blogindlæg vil vi introducere dig til en verden af ​​værktøjer, der bruges til at administrere høj tilgængelighed for PostgreSQL ved hjælp af streamingreplikering.