Løsning af PostgreSQL-opgraderingen

PostgreSQL 9.6 er netop blevet frigivet, og de fleste af postgres-brugerne vil begynde at spørge sig selv, hvordan man opgraderer til den nye større version. Dette indlæg har til hensigt at vise forskellige procedurer til at opgradere din PostgreSQL-server.

Opgradering til en ny større version er en opgave, som har et højt forhold mellem forberedelse i forhold til den samlede eksekveringstid. Specifikt når du springer en udgivelse over i midten, for eksempel når du hopper fra version 9.3 til version 9.5.

Punktfrigivelser

På den anden side behøver punktudgivelsesopgraderinger ikke så meget forberedelse. Generelt er det eneste krav, at postgres-tjenesten genstartes. Der er ingen ændringer i den underliggende datastruktur, så der er ingen grund til at dumpe og gendanne. I værste fald skal du muligvis genskabe nogle af dine indekser, efter du er færdig med at opgradere punktudgivelsen.

Det er meget klogt altid at forblive på den seneste punktudgivelse, så du ikke snubler over en kendt (og sandsynligvis rettet) fejl. Det betyder, at når den seneste version er ude, skal du planlægge tid til opgraderingen så hurtigt som muligt.

Større udgivelsesopgradering

Når du udfører komplekse opgaver som denne, er det godt at overveje alle mulige muligheder for at opnå det endelige resultat.

For større udgivelsesopgraderinger er der tre mulige veje, du kan tage:

• Opgrader gendannelse fra en logisk dump
• Fysisk opgradering
• On-line opgradering

Lad mig forklare hver enkelt i detaljer:

1) Opgrader gendannelse fra et logisk dump

Dette er den enkleste af alle mulige måder at opgradere din klynges datastruktur på.

For at gøre det kort, kræver processen her et logisk dump ved hjælp af pg_dump fra den gamle version og pg_restore på en ren klynge oprettet med den nyligt installerede version.

Nøglepunkter til fordel for at bruge denne sti er:

• Det er det mest testede
• Kompatibilitet går tilbage til 7.0-versioner, så du i sidste ende kan opgradere fra 7.x til en af ​​de seneste udgivelser

Grunde til at du bør undgå at bruge denne mulighed:

• Den samlede nedetid på store databaser kan være et problem, da du skal stoppe skriveforbindelser, før du begynder at køre pg_dump;
• Hvis der er mange store objekter i databasen, vil pg_dump være langsom. Også når man gør det parallelt. Gendannelse vil være endnu langsommere end pg_dump, når mange store objekter er gemt i databasen;
• Det kræver dobbelt diskplads eller fjernelse af den gamle klynge før gendannelse;

På servere med flere CPU-kerner er det muligt at køre pg_dump parallelt ved hjælp af mappeformatet. Når det er færdigt, gendan også parallelt ved hjælp af -j-switchen i både pg_dump og pg_restore. Men du kan ikke starte gendannelsesprocessen, før hele dumpen er færdig.

2) Fysisk opgradering

Disse slags opgraderinger har været tilgængelige siden version 9.0 for at udføre in-place opgraderinger fra versioner så gamle som 8.3. De kaldes "på stedet", fordi de udføres over den samme server og helst på den samme datamappe.

Fordele ved denne slags opgraderinger:

• Du behøver ikke plads til endnu en kopi af klyngen.
• Nedetid er meget lavere sammenlignet med at bruge pg_dump.

Der er en del ulemper:

• Når du starter den nye version af PostgreSQL, er der ingen vej tilbage til den gamle version (klyngen fungerer kun med den nye version derfra).
• Statistik er nulstillet efter opgraderingen, så lige efter start af den nye version af PostgreSQL skal der udføres en klyngeomfattende analyse.
• Der er blevet fundet mange fejl i de seneste år vedrørende pg_upgrade, hvilket gør nogle databaseadministratorer tilbageholdende med at bruge denne metode til at opgradere.
• Nogle mennesker har haft problemer med at springe en større udgivelse over, for eksempel ved at gå fra version 9.2 til version 9.4.
• Med store kataloger vil det fungere dårligt (klynger med mange databaser eller databaser med mange tusinde objekter).

Du kan også køre pg_upgrade uden –link-indstillingen (i dette tilfælde vil pg_upgrade generere en anden kopi på disken af ​​din klynge), så du kan gå tilbage til den gamle version. Men du mister begge de fordele, der er nævnt ovenfor.

3) Online-opgradering

Proceduren, der skal følges for denne metode, ville være som denne:

1. Installer begge versioner, så du kan få dem til at arbejde parallelt. Dette kan gøres på den samme server eller ved at bruge to fysiske servere.
2. Opret en indledende kopi, og repliker ændringerne fra det øjeblik, du startede kopien på kildenoden (dette ville ligne en indledende pg_dump).
3. Fortsæt med at replikere logisk ændringerne, indtil forsinkelsen er tæt på nul.
4. Genpeg forbindelsesoplysningerne fra applikationsserveren for at oprette forbindelse til den nye server.

Denne type opgradering har været tilgængelig, siden de første triggerbaserede replikeringsløsninger fandtes. Med andre ord, siden Slony-I var omkring.

Triggerbaserede replikeringsløsninger er ligeglade med, hvilken version du har på den ene eller den anden side, da den kopierer ændringerne ved hjælp af understøttede SQL-kommandoer.

De triggerbaserede replikeringsværktøjer, der anbefales, i den rækkefølge, de vises, er:

1. skytools:PgQ + londiste
2. Slony-I

Dette bør være den foretrukne måde at opgradere på. Lad os se fordelene ved at bruge denne metode:

• Nul nedetid!
• Fantastisk også til opgradering til nyere hardware.
• On-line test af klyngen med den nye version (skrivebeskyttede forespørgsler, ellers kan du ende med konflikter).
• Reducerer drastisk alle tabel- og indeksbloats.

Der er nogle ulemper:

• Den har brug for dobbelt lagerplads, da den skal gemme en anden kopi af dine data.
• Da det er baseret på triggere, skal systemet skrive hver ændring to gange, hvilket betyder, at der vil være mere disk I/O på kildeserveren (gamle version af klyngen).
• Alle tabeller skal have en primær nøgle, så replikeringsværktøjet kan individualisere de tupler, der opdateres eller slettes
• Den replikerer ikke katalogtabeller, så den replikerer ikke store objekter.
• Grundlæggende brug dækker ikke skemaændringer. Det kan gøres, men ikke gennemsigtigt.

En ny grænse med pglogical

Siden PostgreSQL 9.4 har vi logisk afkodning af transaktionsloggene. Det betyder, at vi nu kan afkode transaktionerne fra WAL og manipulere outputtet.

En helt ny verden af ​​muligheder dukkede op i replikationsfeltet. Triggere er ikke længere nødvendige for at udføre logisk replikering!

Dette betyder dybest set, at du ikke længere behøver at gemme en separat kopi af alle indsættelser, opdateringer og sletninger ved hjælp af triggere. Du kan bare få disse datamanipulationsoperationer fra transaktionsloggene ved at afkode dem. Så er det værktøjet du bruger, der skal manipulere outputtet og sende det over til den abonnerede downstream-knude. I dette tilfælde er værktøjet pglogisk.

Så hvad betyder det hele?

Nå, hvis du har en version 9.4 eller 9.5 af PostgreSQL, og du vil opgradere til 9.6, kan du udføre en online opgradering som den, der er beskrevet ovenfor, men ved at bruge pglogical i stedet for en af ​​de triggerbaserede replikeringsløsninger.

Jeg vil ikke gå yderligere i detaljer, da der er andre blogs om dette særlige emne, som denne skrevet af Petr Jelinek:PGLogical 1.1-pakker til PostgreSQL 9.6beta1

Konklusioner

Afhængigt af skemaet for din database, datastørrelsen, det mulige nedetidsvindue, versionen af ​​den aktuelle PostgreSQL-installation kan du vælge en mulighed frem for en anden eller hvad der passer bedst.

• Hvis din database er lille, og der er et passende vedligeholdelsesvindue, du kan bruge, kan du vælge at køre en pg_dump og pg_restore. Afhængigt af størrelsen af ​​datasættet er der et punkt, hvor muligheden ikke længere er mulig.
• Hvis du har en stor database (adskillige hundrede GB eller endda TB data), bliver du nødt til at kigge efter andre muligheder, såsom en lokal opgradering med pg_upgrade eller en online opgradering.
  • Hvis du opgraderer fra version 8.3 eller nyere til en 9.x-version, kan du bruge pg_upgrade.
  • For versioner, der er ældre end 8.3, bliver du nødt til at vælge en af ​​de logiske replikeringsløsninger som londiste eller slony.
  • Hvis du er på en 9.4- eller 9.5-database, er du bedre stillet med pglogical.

Husk altid, at for logisk replikering skal tabellerne have en Primary Key.

Med pglogical er den regel ikke så streng:Du kan replikere indsættelsestabeller. Men for opdatering og sletninger er det stadig obligatorisk at have en primær nøgle eller en REPLICA IDENTITET på bordet.

Hvis du har brug for hjælp til at opgradere din PostgreSQL-database, kan du tjekke
2ndQuadrant Upgrade-tjenesterne.