Det er på tide.
For omkring et år siden udgav vi PostgreSQL 10 med understøttelse af indbygget logisk replikering. En af anvendelserne af logisk replikering er at tillade lav- eller ingen nedetid opgradering mellem PostgreSQL større versioner. Indtil nu var PostgreSQL 10 den eneste PostgreSQL-udgivelse med indbygget logisk replikering, så der var ikke mange muligheder for at opgradere på denne måde. (Logisk replikering kan også bruges til at flytte data mellem instanser på forskellige operativsystemer eller CPU-arkitekturer eller med forskellige konfigurationsindstillinger på lavt niveau, såsom blokstørrelse eller lokalitet - sidegradering om du vil.) Nu hvor PostgreSQL 11 er tæt på, vil der være flere grunde til at gøre brug af denne funktionalitet.
Lad os først sammenligne de tre vigtigste måder at opgradere en PostgreSQL-installation på:
- pg_dump og gendan
- pg_upgrade
- logisk replikering
Vi kan sammenligne disse metoder med hensyn til robusthed, hastighed, påkrævet nedetid og begrænsninger (og mere, men vi må stoppe et sted for denne artikel).
pg_dump and restore er uden tvivl den mest robuste metode, da den er den mest testede og har været i brug i årtier. Den har også meget få begrænsninger i forhold til, hvad den kan klare. Det er muligt at konstruere databaser, der ikke kan dumpes og gendannes, for det meste involverer særlige objektafhængighedsrelationer, men disse er sjældne og involverer normalt modløs praksis.
Problemet med dump- og gendannelsesmetoden er naturligvis, at den effektivt kræver nedetid i hele den tid, dump- og gendannelsesoperationerne kører. Mens kildedatabasen stadig er læsbar og skrivbar, mens processen kører, vil alle opdateringer til kildedatabasen efter starten af dumpet gå tabt.
pg_upgrade forbedrer pg_dump-processen ved at flytte over datafilerne direkte uden at skulle dumpe dem ud i en logisk tekstform. Bemærk, at pg_upgrade stadig bruger pg_dump internt til at kopiere skemaet, men ikke dataene. Da pg_upgrade var ny, blev der stillet spørgsmålstegn ved dens robusthed, og den opgraderede nogle databaser forkert. Men pg_upgrade er nu ret modent og gennemtestet, så man behøver ikke at tøve med at bruge det af den grund længere. Mens pg_upgrade kører, er databasesystemet nede. Men man kan træffe et valg om, hvor længe pg_upgrade kører. I standardkopieringstilstanden er den samlede køretid sammensat af tiden til at dumpe og gendanne skemaet (som normalt er meget hurtigt, medmindre man har tusindvis af tabeller eller andre objekter) plus tiden til at kopiere datafilerne, hvilket afhænger af hvor stor databasen er (og I/O-systemet, filsystemet osv.).
I den valgfrie link-tilstand er datafilerne i stedet for hard-linket til den nye datamappe, så tiden er blot tiden til at udføre en kort kerneoperation pr. fil i stedet for at kopiere hver byte. Ulempen er, at hvis noget går galt med opgraderingen, eller du har brug for at falde tilbage til den gamle installation, vil denne operation have ødelagt din gamle database. (Jeg arbejder på en bedst af begge verdener-løsning til PostgreSQL 12 ved hjælp af reflinks eller filkloningsoperationer på understøttede filsystemer.)
Logisk replikering er den nyeste af bunken her, så det vil sandsynligvis tage lidt tid at finde ud af knæk. Hvis du ikke har tid til at udforske og undersøge, er dette måske ikke vejen at gå lige nu. (Selvfølgelig har folk brugt andre ikke-kerne logiske replikeringsløsninger såsom Slony, Londiste og pglogical til at opgradere PostgreSQL i mange år, så der er meget erfaring med principperne, hvis ikke med detaljerne.)
Fordelen ved at bruge logisk replikering til at opgradere er, at applikationen kan fortsætte med at køre mod den gamle instans, mens datasynkroniseringen sker. Der skal kun være et lille udfald, mens klientforbindelserne skiftes. Så selvom en opgradering ved hjælp af logisk replikering sandsynligvis er langsommere fra start til slut end at bruge pg_upgrade i kopitilstand (og bestemt langsommere end at bruge hardlink-tilstand), betyder det ikke ret meget, da den faktiske nedetid kan være meget kortere.
Bemærk, at logisk replikering i øjeblikket ikke replikerer skemaændringer. I denne foreslåede opgraderingsprocedure kopieres skemaet stadig via pg_dump, men efterfølgende skemaændringer overføres ikke. Opgradering med logisk replikering har også et par andre begrænsninger. Visse operationer fanges ikke af logisk replikering:store objekter, TRUNCATE, sekvensændringer. Vi vil diskutere løsninger på disse problemer senere.
Hvis du har nogen fysisk standby (og hvis ikke, hvorfor har du ikke?), er der også nogle forskelle at overveje mellem metoderne. Med begge metoder skal du bygge nye fysiske standbys til den opgraderede instans. Med dump og gendannelse såvel som med logisk replikering kan de sættes på plads, før opgraderingen starter, så standbyen for det meste er klar, når den indledende synkronisering af gendannelse eller logisk replikering er fuldført, med forbehold for replikeringsforsinkelse.
Med pg_upgrade skal de nye standbys oprettes, efter at opgraderingen af den primære er fuldført. (Pg_upgrade-dokumentationen beskriver dette mere detaljeret.) Hvis du er afhængig af fysiske standbys for høj tilgængelighed, bør standbys være på plads, før du skifter til den nye instans, så opsætningen af standbys kan påvirke dine overordnede timingberegninger.
Men tilbage til logisk replikation. Sådan kan opgradering med logisk replikering udføres:
0. Den gamle instans skal forberedes til logisk replikering. Dette kræver nogle konfigurationsindstillinger som beskrevet under http://www.postgresql.org/docs/10/static/logical-replication-config.html (hovedsageligt wal_level = logical . Hvis det viser sig, at du skal foretage disse ændringer, vil de kræve en servergenstart. Så tjek dette i god tid. Tjek også at pg_hba.conf på den gamle instans er sat op til at acceptere forbindelser fra den nye instans. (At ændre det kræver kun en genindlæsning.)
1. Installer den nye PostgreSQL-version. Du har som minimum brug for serverpakken og klientpakken, der indeholder pg_dump. Mange emballager tillader nu installation af flere versioner side om side. Hvis du kører virtuelle maskiner eller cloud-instanser, er det værd at overveje at installere den nye instans på en ny vært.
2. Opsæt en ny instans, dvs. kør initdb. Den nye instans kan have andre indstillinger end den gamle, for eksempel lokalitet, WAL-segmentstørrelse eller kontrolsum. (Hvorfor ikke bruge denne mulighed til at slå datakontrolsummer til?)
3. Før du starter den nye instans, skal du muligvis ændre nogle konfigurationsindstillinger. Hvis instansen kører på samme vært som den gamle instans, skal du indstille et andet portnummer. Overfør også alle tilpassede ændringer, du har lavet i postgresql.conf på din gamle instans, såsom hukommelsesindstillinger, max_connections osv. Lav på samme måde pg_hba.conf indstillinger, der passer til dit miljø. Du kan normalt starte med at kopiere pg_hba.conf over fil fra den gamle instans. Hvis du vil bruge SSL, skal du indstille det nu.
4. Start den nye (tomme) instans og tjek, at den virker til din tilfredshed. Hvis du opsætter den nye instans på en ny vært, skal du på dette tidspunkt kontrollere, at du kan oprette en databaseforbindelse (ved hjælp af psql) fra den nye vært til den gamle databaseinstans. Det får vi brug for i de efterfølgende trin.
5. Kopier skemadefinitionerne over med pg_dumpall. (Eller du kan gøre det med pg_dump for hver database separat, men glem så ikke globale objekter såsom roller.)
pg_dumpall -s >schemadump.sql psql -d postgres -f schemadump.sql
Eventuelle skemaændringer efter dette punkt vil ikke blive migreret. Dem skulle du selv klare. I mange tilfælde kan du bare anvende den skiftende DDL på begge værter, men at køre kommandoer, der ændrer tabelstrukturen under en opgradering, er sandsynligvis en udfordring for langt.
6. I hver database i kildeinstansen skal du oprette en publikation, der fanger alle tabeller:
CREATE PUBLICATION p_upgrade FOR ALL TABLES;
Logisk replikering fungerer separat i hver database, så dette skal gentages i hver database. På den anden side behøver du ikke at opgradere alle databaser på én gang, så du kan lave denne ene database ad gangen eller endda ikke opgradere nogle databaser.
7. I hver database i målforekomsten skal du oprette et abonnement, der abonnerer på den netop oprettede publikation. Sørg for at matche kilde- og måldatabaserne korrekt.
CREATE SUBSCRIPTION s_upgrade CONNECTION 'host=oldhost port=oldport dbname=dbname ...' PUBLICATION p_upgrade;
Indstil forbindelsesparametrene efter behov.
8. Nu venter du, indtil abonnementerne er kopieret over de oprindelige data og helt har indhentet udgiveren. Du kan kontrollere den indledende synkroniseringsstatus for hver tabel i et abonnement i systemkataloget pg_subscription_rel (se efter r =klar i kolonne srsubstate ). Replikeringens overordnede status kan kontrolleres i pg_stat_replication på afsendersiden og pg_stat_subscription på den modtagende side.
9. Som nævnt ovenfor replikeres sekvensændringer ikke. En mulig løsning på dette er at kopiere sekvensværdierne ved hjælp af pg_dump. Du kan få et dump af de aktuelle sekvensværdier ved at bruge noget som dette:
pg_dump -d dbname --data-only -t '*_seq' >seq-data.sql
(Dette forudsætter, at sekvensnavnene alle matcher *_seq og ingen tabeller matcher det navn. I mere komplicerede tilfælde kan du også gå vejen til at oprette et fuldt dump og udtrække sekvensdataene fra dumpets indholdsfortegnelse.)
Da sekvenserne muligvis udvikler sig, mens du gør dette, kan du måske bruge seq-data.sql fil for at tilføje en smule slæk til tallene.
Gendan derefter filen til den nye database ved hjælp af psql.
10. Showtime:Skift applikationerne til de nye instanser. Dette kræver en vis omtanke i forvejen. I det enkleste scenarie stopper du dine applikationsprogrammer, ændrer forbindelsesindstillingerne, genstarter. Hvis du bruger en forbindelsesproxy, kan du skifte forbindelsen der. Du kan også skifte klientapplikationer én efter én, måske for at teste tingene lidt eller lette belastningen på det nye system. Dette vil fungere, så længe de programmer, der stadig peger på den gamle server, og dem, der peger på den nye server, ikke skriver modstridende. (I så fald ville du køre et multimaster-system, i det mindste i kort tid, og det er en anden kompleksitetsorden.)
11. Når opgraderingen er fuldført, kan du rive replikeringsopsætningen ned. Kør
i hver database på den nye instansDROP SUBSCRIPTION s_upgrade;
Hvis du allerede har lukket den gamle instans ned, vil dette mislykkes, fordi den ikke vil være i stand til at nå fjernserveren for at droppe replikeringsslottet. Se DROP SUBSCRIPTION-man-siden for, hvordan du fortsætter i denne situation.
Du kan også droppe publikationerne på kildeinstansen, men det er ikke nødvendigt, da en publikation ikke beholder nogen ressourcer.
12. Fjern endelig de gamle forekomster, hvis du ikke har brug for dem længere.
Nogle yderligere kommentarer om løsninger på ting, som logisk replikering ikke understøtter. Hvis du bruger store objekter, kan du flytte dem over ved hjælp af pg_dump, selvfølgelig så længe de ikke ændres under opgraderingsprocessen. Dette er en væsentlig begrænsning, så hvis du er en stor bruger af store genstande, er denne metode muligvis ikke noget for dig. Hvis din applikation udsteder TRUNCATE under opgraderingsprocessen, vil disse handlinger ikke blive replikeret. Måske kan du justere dit program for at forhindre det i at gøre det på tidspunktet for opgraderingen, eller du kan erstatte en DELETE i stedet. PostgreSQL 11 understøtter replikering af TRUNCATE, men det vil kun fungere, hvis både kilde- og destinationsforekomsten er PostgreSQL 11 eller nyere.
Nogle afsluttende kommentarer, der virkelig gælder for alle opgraderingsvirksomheder:
- Applikationer og alle databaseklientprogrammer bør testes mod en ny større PostgreSQL-version, før de sættes i produktion.
- Til det formål bør du også teste opgraderingsproceduren, før du udfører den i produktionsmiljøet.
- Skriv ting ned eller bedre script og automatiser så meget som muligt.
- Sørg for, at din backupopsætning, overvågningssystemer og eventuelle vedligeholdelsesværktøjer og scripts er justeret korrekt under opgraderingsproceduren. Ideelt set bør disse være på plads og verificeret, før overgangen udføres.
Med det i tankerne, held og lykke og del gerne dine erfaringer.