Förra veckan var jag på Nordic PGDay 2018 och jag hade en hel del samtal om verktyget som jag skrev, nämligen pglupgrade , för att automatisera PostgreSQL större versionsuppgraderingar i en replikeringsklusterinstallation. Jag var ganska glad över att det har hörts och att några andra människor i olika samhällen håller föredrag vid möten och andra konferenser om uppgraderingar av nästan noll driftstopp med logisk replikering. Med tanke på att det finns ett föredrag som jag höll på PGDAY'17 Ryssland, PGConf.EU 2017 i Warszawa och sist på FOSDEM PGDay 2018 i Bryssel, tänkte jag att det är bättre att skapa ett blogginlägg för att hålla denna presentation tillgänglig för folk som kunde inte komma till någon av konferenserna ovan. Om du vill gå direkt och hoppa över att läsa detta blogginlägg här är din länk:Near-Zero Downtime Automated Upgrades of PostgreSQL Clusters in Cloud
Den främsta motivationen bakom utvecklingen av detta verktyg var att föreslå en lösning för att minimera stilleståndstiden under större versionsuppgraderingar som tyvärr påverkar nästan alla som använder PostgreSQL. För närvarande har vi inte ett verktyg som tillåter PostgreSQL-användare att uppgradera sina databaser utan driftstopp och det är helt klart en smärtpunkt för många användare, särskilt företag. Och om vi ska lösa uppgraderingsproblemet bör vi tänka på mer än en server (kommer att kallas ett kluster från och med nu), helt enkelt för att det inte är många som använder bara en databasserver längre. Det vanligaste scenariot är att konfigurera fysisk strömmande replikering antingen för högtillgänglighetsändamål eller skala läsfrågorna.
Databasuppgraderingar
Innan vi dyker in i lösningen, låt oss diskutera lite om hur databasuppgraderingar fungerar i allmänhet. Det finns fyra huvudsakliga möjliga tillvägagångssätt för databasuppgraderingar:
- Det första tillvägagångssättet skulle vara att databaser behåller sitt lagringsformat samma eller åtminstone kompatibla över olika versioner. Detta är dock svårt att garantera långsiktigt eftersom nya funktioner kan kräva ändringar i hur data lagras eller lägga till mer metadatainformation för att fungera korrekt. Dessutom förbättras ofta prestandan genom att optimera datastrukturerna.
- Den andra metoden är att göra en logisk kopia (dump) av den gamla servern och ladda den till den nya servern. Detta är det mest traditionella tillvägagångssättet som kräver att den gamla servern inte får några uppdateringar under processen och resulterar i förlängda driftstopp timmar eller till och med dagar i stora databaser.
- Det tredje alternativet är att konvertera data från gammalt format till nytt. Detta kan antingen göras i farten medan det nya systemet körs, men medför prestationsstraff som är svårt att förutsäga eftersom det beror på dataåtkomstmönster, eller så kan det göras offline medan servrarna är nere, vilket återigen medför förlängd tid stilleståndstider (även om ofta kortare än den andra metoden).
- Den fjärde metoden är att använda logisk dump för att spara och återställa databasen samtidigt som ändringarna som sker under tiden registreras och logiskt replikera dem till den nya databasen när den initiala återställningen är klar. Den här metoden kräver orkestrering av flera komponenter men minskar också den tid som databasen inte kan svara på frågor.
Uppgraderingsmetoder i PostgreSQL
PostgreSQL-uppgraderingar kan matchas med de fyra metoderna som anges ovan. Till exempel, PostgreSQL mindre utgåvor, som inte innehåller nya funktioner utan bara fixar, ändrar inte det befintliga dataformatet och passar det första tillvägagångssättet. För det andra tillvägagångssättet tillhandahåller PostgreSQL verktyg som kallas pg_dump och pg_restore som gör den logiska säkerhetskopieringen och återställningen. Det finns också pg_upgrade-verktyg (det var en bidragsmodul och flyttades till huvudträdet i PostgreSQL 9.5) som gör offline-omvandling (servrarna körs inte) av den gamla datakatalogen till den nya, som kan passa in i det tredje alternativet. För det fjärde tillvägagångssättet finns det triggerbaserade tredjepartslösningar som Slony för uppgradering, men de har några varningar som vi kommer att täcka senare.
Traditionella metoder för uppgradering kan bara uppgradera den primära servern medan replikservrarna måste byggas om efteråt (offlinekonvertering) . Detta leder till ytterligare problem med både klustertillgänglighet och kapacitet, vilket effektivt ökar den upplevda stilleståndstiden av databasen från både applikationer och användare. Logisk replikering tillåter replikering medan systemet är igång och testarbete kan hanteras under tiden (onlinekonvertering) .
Det finns olika uppgraderingsmetoder för olika miljöer. Till exempel pg_dump tillåter uppgradering från mycket gamla versioner (dvs. 7.0) till de senaste utgåvorna, så om du kör en antik version av PostgreSQL är den bästa metoden att använda pg_dump/restore (och bättre att göra det nu!). Om din PostgreSQL version är 8.4 och senare du kan använda pg_upgrade . Om du råkar använda PostgreSQL 9.4 och senare detta betyder att du har in-core "Logisk avkodning" och du kan använda pglogical förlängning som ett sätt att uppgradera. Slutligen, om du använder PostgreSQL 10 , kommer du att ha en chans att uppgradera din databas till PostgreSQL 11 och senare (när de är tillgängliga) genom att använda ”Logisk replikering” i kärnan (yay!).
Logisk replikering för uppgraderingar
Var är idén med att uppgradera PostgreSQL genom att använda logisk replikering kommer från? Klart, pglogical hävdar inte uppgraderingssyftet öppet som pg_upgrade gör (detta var ett argument mot pglogical på konferensfesten ), men det betyder inte att vi inte kan använda verktyget för uppgraderingar. Faktum är att när pglogical designades, ansågs utvecklarna av tillägget att uppgraderingar av driftstopp var nästan noll som ett av de förväntade användningsfallen.
Till skillnad från fysisk replikering, som fångar ändringar av rådata på disken, fångar den logiska replikeringen de logiska ändringarna av de individuella posterna i databasen och replikerar dessa. De logiska uppgifterna fungerar över stora utgåvor , därför kan logisk replikering användas för att uppgradera från en utgåva till en annan. Idén med att använda logisk replikering som ett sätt att uppgradera versionen är långt ifrån nytt, triggade baserade replikeringsverktyg har gjort uppgraderingar på ett logiskt sätt genom att fånga och skicka ändringarna via triggers (eftersom utlösare kan fungera oavsett databasversioner också! ).
Om du kan använda triggerbaserade replikeringslösningar för minimala uppgraderingar av driftstopp, varför skulle du istället föredra logisk replikering? I en triggerbaserad mekanism fångas alla ändringar med hjälp av triggers och skrivs in i kötabeller. Denna procedur fördubblar skrivoperationerna, fördubblar loggfiler och saktar ner systemet eftersom alla ändringar måste skrivas två gånger; vilket resulterar i mer disk I/O och belastning på källservern. Däremot byggs in-core logisk replikering (samma gäller för pglogical extension) ovanpå logisk avkodning. Logisk avkodning är en mekanism som extraherar information från WAL-filer till logiska ändringar (INSERT/UPDATE/DELETE). Eftersom data från WAL-mekanismen används för att avkoda transaktionsloggarna, finns det ingen skrivförstärkning som i fallet med triggerbaserade replikeringslösningar, därför presterar denna metod bättre . Som ett resultat har logisk avkodningsbaserade lösningar helt enkelt en lägre inverkan på systemet än triggerbaserade lösningar.
Slutsats
I det här inledande inlägget ville jag ge en idé om varför vi bör överväga att använda logisk replikering för att uppnå minimal driftstopp under större versionsuppgraderingar. Vi kommer att fortsätta med detaljerna om arkitekturen och implementeringen av verktyget i det kommande inlägget.