Guide för uppgradering av egenhostad databas: dumpa, skapa ögonblicksbild, migrera och återställa

Det säkra tillvägagångssättet är att behandla en stegvis uppgradering med inbyggda dumpverktyg, lagringssnapshots, isolerad återställningsrepetition och en tydligt avgränsad återställningspunkt som en sekvens av observerbara kontrollpunkter, inte som ett enda kommando.

I en containeriserad PostgreSQL- eller MariaDB-databas på en hemserver är den praktiska risken att en egenhostad databas behöver versionsuppgraderas utan att logiska objekt går förlorade eller att en fungerande återställningsväg saknas. Dokumentera den aktuella identiteten och återställningspunkten, börja med den minst ingripande kontrollen, tolka godkända och underkända resultat innan du ändrar ytterligare en variabel och avbryt när lagringen blir instabil eller den enda återställningsbara kopian skulle exponeras. Arbetsflödet nedan är inte avslutat förrän den ursprungliga arbetsbelastningen fungerar eller bevisläget når en eskaleringsgräns.

Definiera kompatibilitet och återställning före säkerhetskopieringen

Dokumentera databasmotor och exakt källversion, målversion, applikationsversion, tillägg eller insticksprogram, teckenuppsättning, autentiseringsregler, schemalagda jobb och tillgänglig driftstoppstid. Läs både applikationens uppgraderingsanteckningar och databasens uppgraderingsväg, eftersom en applikationsmigrering kan göra gamla binärer inkompatibla med det nya schemat.

Större versionsuppgraderingar kräver ofta en logisk dump och återställning eller ett stödd migreringsverktyg i stället för att den gamla datakatalogen monteras i en ny avbild. Ett fristående arbetsflöde för större databasuppgradering med Compose går igenom en större PostgreSQL-uppgradering baserad på Compose och visar varför den gamla containern och volymen måste hållas åtskilda från målet.

Skriv ner tidsgränsen för återställning och vad som utlöser den nu: underkända integritetskontroller, saknade roller eller tillägg, applikationsfel eller oacceptabel prestanda. Återställning är endast möjlig tills produktionsskrivningar börjar på målet, såvida inte en omvänd datamigreringsplan har testats.

Skapa två oberoende återställningspunkter

Kör motorns inbyggda logiska säkerhetskopiering med globala objekt där det är tillämpligt och spara sedan kommandot, versionen, avslutningsstatusen, manifestet och kontrollsumman. Kontrollera att användare, behörigheter, tillägg, scheman, schemalagda jobb och stora objekt ingår i stället för att anta att en enda databasedump innehåller alla beroenden på servernivå.

Ta en samordnad snapshot eller en kopia av databasvolymen när databasen har stoppats, efter att du bekräftat att databasen är i ett stödd tillstånd. Den logiska dumpen ger portabilitet och granskning på objektnivå; lagringskopian bevarar en exakt återställningspunkt för den gamla versionen. Ingen av dem ska skriva över den andra.

Använd ZimaSpaces verifieringschecklista för att kontrollera checklistan för fullständighet hos databassäkerhetskopian. Säkerhetskopieringskontrollen är godkänd först när dumpen är läsbar, lagringens återställningspunkt är identifierad och båda finns utanför volymen som ska uppgraderas.

Repetera migreringen i ett isolerat mål

Starta måldatabasen på en separat volym och port, installera nödvändiga tillägg, återställ den logiska säkerhetskopian och spara alla varningar. En genomgång från Percona av uppgraderingsvägen med logisk dump och återställning belyser sekvensen för dump och återställning samt behovet av att använda verktyg som passar den avsedda uppgraderingsvägen för PostgreSQL.

Anslut en kasserbar instans av applikationen till den återställda databasen. Testa inloggning, läsningar, skrivningar, bakgrundsjobb, sökning, bilagor, tidszoner och en omstart. Jämför antal rader och kritiska aggregat i stället för att enbart förlita dig på en lyckad avslutningskod från återställningen.

Fortsätt inte om tillägg saknas, ändringar av kollationering är olösta, migreringar misslyckas eller återställningstiden överskrider underhållsfönstret. Åtgärda repetitionen och skapa en ny dump; produktionen är inte rätt plats att upptäcka inkompatibilitet med målversionen.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Växla skrivningar och håll återställningen ren

Aktivera underhållsläge, stoppa applikationens skrivande processer och jobb, bekräfta att aktiva anslutningar töms och skapa sedan den slutliga dumpen eller den stödda delta-säkerhetskopian. Återställ den till ett rent mål, kör integritets- och objektkontroller, uppdatera applikationens anslutning och starta tjänsterna i beroendeordning.

Övervaka felfrekvenser, lås, körning av jobb, säkerhetskopieringar och verkliga applikationstransaktioner. Håll den gamla databasen stoppad och skrivskyddad med sin ursprungliga volym och avbilds-digest. Låt aldrig båda databaserna ta emot oberoende skrivningar med samma applikationsidentitet.

Förklara uppgraderingen som lyckad först när applikationen, det inbyggda säkerhetskopieringsjobbet, omstarten och en teståterställning från den nya versionen alla är godkända. Om en återställningsutlösare aktiveras före skrivgränsen, pekar du tillbaka appen till den bevarade gamla instansen; efter nya skrivningar ska du stoppa och använda den dokumenterade avstämningsplanen i stället för att låtsas att en enkel omstart återställer data.