I sidste uge var jeg til Nordic PGDay 2018 og jeg havde en del samtaler om det værktøj, jeg skrev, nemlig pglupgrade , for at automatisere PostgreSQL større versionsopgraderinger i en replikeringsklyngeopsætning. Jeg var ret glad for, at det er blevet hørt, og at nogle andre mennesker i forskellige samfund holdt foredrag ved møder og andre konferencer om næsten-nul nedetidsopgraderinger ved hjælp af logisk replikering. I betragtning af at der er et foredrag, som jeg holdt på PGDAY'17 Rusland, PGConf.EU 2017 i Warszawa og til sidst på FOSDEM PGDay 2018 i Bruxelles, tænkte jeg, at det er bedre at oprette et blogindlæg for at holde denne præsentation tilgængelig for de folk, der kunne ikke komme til nogen af de førnævnte konferencer. Hvis du gerne vil tage direkte snak og springe over at læse dette blogindlæg, er her dit link:Near-Zero Downtime Automated Upgrades of PostgreSQL Clusters in Cloud
Hovedmotivationen bag udviklingen af dette værktøj var at foreslå en løsning for at minimere nedetiden under større versionsopgraderinger, som desværre påvirker næsten alle, der bruger PostgreSQL. I øjeblikket har vi ikke et værktøj, der giver PostgreSQL-brugere mulighed for at opgradere deres databaser uden nedetid, og det er klart et smertepunkt for mange brugere, især virksomheder. Og hvis vi skal løse opgraderingsproblemet, bør vi tænke på mere end én server (vil blive omtalt som en klynge fra nu af), simpelthen fordi der ikke er mange mennesker, der kun bruger én databaseserver længere. Det mest almindelige scenarie er at have fysisk streaming-replikeringsopsætning enten med henblik på høj tilgængelighed eller skalering af læseforespørgsler.
Databaseopgraderinger
Før vi dykker ned i løsningen, lad os diskutere lidt om, hvordan databaseopgraderinger fungerer generelt. Der er fire hoved mulige tilgange til databaseopgraderinger:
- Den første tilgang ville være, at databaser holder deres lagringsformat det samme eller i det mindste kompatible på tværs af versioner. Dette er dog svært at garantere langsigtet, da nye funktioner kan kræve ændringer i, hvordan data gemmes eller tilføje flere metadataoplysninger for at fungere korrekt. Ydeevnen forbedres også ofte ved at optimere datastrukturerne.
- Den anden tilgang er at lave en logisk kopi (dump) af den gamle server og indlæse den på den nye server. Dette er den mest traditionelle tilgang, som kræver, at den gamle server ikke modtager nogen opdateringer under processen og resulterer i længere nedetider timer eller endda dage på store databaser.
- Den tredje mulighed er at konvertere data fra gammelt format til nyt. Dette kan enten gøres på farten, mens det nye system kører, men det medfører en præstationsstraf, som er svært at forudsige, da det afhænger af dataadgangsmønstre, eller det kan gøres offline, mens serverne er nede, hvilket igen medfører langvarig nedetider (selvom ofte kortere end den anden metode).
- Den fjerde metode er at bruge logisk dump til at gemme og gendanne databasen mens de ændringer, der sker i mellemtiden, registreres og logisk replikere dem til den nye database, når den indledende gendannelse er afsluttet. Denne metode kræver orkestrering af flere komponenter, men reducerer også den tid, databasen ikke kan svare på forespørgsler.
Opgraderingsmetoder i PostgreSQL
PostgreSQL-opgraderinger kan matches med de fire metoder, der er anført ovenfor. For eksempel ændrer PostgreSQL mindre udgivelser, som ikke indeholder nye funktioner, men kun rettelser, ikke det eksisterende dataformat og passer til den første tilgang. Til den anden tilgang giver PostgreSQL værktøjer kaldet pg_dump og pg_restore, som udfører den logiske backup og gendannelse. Der er også pg_upgrade-værktøj (det var et bidragsmodul og flyttet til hovedtræet i PostgreSQL 9.5), som gør offline (serverne kører ikke) konvertering af det gamle databibliotek til det nye, som kan passe ind i den tredje mulighed. For den fjerde tilgang er der tredjeparts trigger-baserede løsninger såsom Slony til opgradering, men de har nogle forbehold, som vi vil dække senere.
Traditionelle metoder til opgradering kan kun opgrader den primære server, mens replikaserverne skal genopbygges bagefter (offlinekonvertering) . Dette fører til yderligere problemer med både klyngens tilgængelighed og kapacitet, hvilket øger den opfattede nedetid effektivt. af databasen fra både applikationer og brugere. Logisk replikering tillader replikering mens systemet er oppe og køre og testindsats kan håndteres i mellemtiden (onlinekonvertering) .
Der er forskellige opgraderingsmetoder, der kan anvendes til forskellige miljøer. For eksempel pg_dump tillader opgradering fra meget gamle versioner (dvs. 7.0) til de seneste udgivelser, så hvis du kører en antik version af PostgreSQL, er den bedste metode at bruge pg_dump/restore (og bedre at gøre det nu!). Hvis din PostgreSQL version er 8.4 og nyere du kan bruge pg_upgrade . Hvis du tilfældigvis bruger PostgreSQL 9.4 og nyere det betyder, at du har in-core "Logisk afkodning" og du kan bruge pglogical udvidelse som middel til opgradering. Endelig, hvis du bruger PostgreSQL 10 , vil du have en chance for at opgradere din database til PostgreSQL 11 og nyere (når de er tilgængelige) ved at bruge in-core "Logisk replikering" (yay!).
Logisk replikering til opgraderinger
Hvor er ideen med at opgradere PostgreSQL ved at bruge logisk replikering kommer fra?Det er klart pglogisk hævder ikke opgraderingsformålet åbenlyst som pg_upgrade gør (dette var et argument imod pglogical ved konferencefesten ), men det betyder ikke, at vi ikke kan bruge værktøjet til opgraderinger. Faktisk, da pglogical blev designet, blev opgraderinger med næsten nul nedetid betragtet som en af de forventede use-cases af udviklerne af udvidelsen.
I modsætning til fysisk replikering, som fanger ændringer til rådata på disken, fanger den logiske replikering de logiske ændringer til de individuelle poster i databasen og replikerer dem. De logiske optegnelser fungerer på tværs af større udgivelser , derfor kan logisk replikering bruges til at opgradere fra en udgivelse til en anden. Ideen med at bruge logisk replikering som middel til versionsopgradering er langt fra at være ny, triggede-baserede replikeringsværktøjer har lavet opgraderinger på en logisk måde ved at fange og sende ændringerne via triggere (fordi triggere også kan fungere uanset databaseversioner! ).
Hvis du kan bruge trigger-baserede replikeringsløsninger til minimale nedetidsopgraderinger, hvorfor skulle du foretrække logisk replikering i stedet? I en trigger-baseret mekanisme fanges alle ændringerne ved at bruge triggere og skrives ind i køtabeller. Denne procedure fordobler skriveoperationerne, fordobler logfiler og sænker systemet, da alle ændringer skal skrives to gange; hvilket resulterer i mere disk I/O og belastning på kildeserveren. I modsætning hertil er in-core logisk replikering (det samme gælder for pglogical extension) bygget oven på logisk afkodning. Logisk afkodning er en mekanisme, der udtrækker information fra WAL-filer til logiske ændringer (INSERT/UPDATE/DELETE). Da dataene fra WAL-mekanismen bruges til at afkode transaktionsloggene, er der ingen skriveforstærkning som i tilfældet med trigger-baserede replikeringsløsninger, derfor yder denne metode bedre . Som et resultat har logisk afkodningsbaserede løsninger ganske enkelt en mindre indvirkning på systemet end triggerbaserede løsninger.
Konklusion
I dette indledende indlæg ville jeg give en idé om, hvorfor vi bør overveje at bruge logisk replikering for at opnå minimal nedetid under større versionsopgraderinger. Vi vil fortsætte med detaljerne om arkitekturen og implementeringen af værktøjet i det kommende indlæg.