Handleiding voor een upgrade van een zelfgehoste database: dump maken, snapshot maken, migreren en terugrollen

De veilige aanpak is om een gefaseerde upgrade met native dumps, opslagmomentopnamen, geïsoleerde hersteltests en een duidelijk afgebakend terugvalpunt te behandelen als een reeks observeerbare controlepunten, niet als één opdracht.

Bij een gecontaineriseerde PostgreSQL- of MariaDB-database op een homeserver is het praktische risico dat een zelfgehoste database een versie-upgrade nodig heeft zonder logische objecten of een bruikbaar terugvalpad te verliezen. Leg de huidige identiteit en het herstelpunt vast, begin met de minst ingrijpende onderscheidende test, interpreteer geslaagde en mislukte resultaten voordat je een andere variabele wijzigt, en stop wanneer de opslag instabiel wordt of de enige herstelbare kopie blootgesteld zou worden. De onderstaande workflow eindigt pas nadat de oorspronkelijke workload succesvol is uitgevoerd of het bewijs een escalatiegrens bereikt.

Definieer compatibiliteit en terugdraaien vóór de back-up

Leg de database-engine en exacte bronversie, doelversie, applicatieversie, extensies of plug-ins, tekenset, authenticatieregels, geplande taken en beschikbare downtime vast. Lees zowel de upgradenotities van de applicatie als het databasepad, omdat een applicatiemigratie oude binaries incompatibel kan maken met het nieuwe schema.

Voor grote upgrades zijn vaak een logische dump en herstel of een ondersteunde migratietool nodig, in plaats van de oude gegevensdirectory in een nieuwe image te koppelen. Een onafhankelijke workflow voor een upgrade tussen database-hoofdversies met Compose behandelt een PostgreSQL-upgrade tussen hoofdversies op basis van Compose en laat zien waarom de oude container en het oude volume gescheiden moeten blijven van het doel.

Leg nu de deadline en trigger voor terugdraaien vast: mislukte integriteitscontroles, ontbrekende rollen of extensies, applicatiefouten of onaanvaardbare prestaties. Terugdraaien blijft alleen mogelijk totdat er productieschrijfbewerkingen op het doel beginnen, tenzij een getest plan voor omgekeerde datamigratie bestaat.

Maak twee onafhankelijke herstelpunten

Voer de logische back-up uit die eigen is aan de engine, inclusief globale objecten waar van toepassing, en bewaar vervolgens de opdracht, versie, afsluitstatus, manifest en checksum. Controleer of gebruikers, rechten, extensies, schema's, geplande taken en grote objecten zijn opgenomen, in plaats van aan te nemen dat één database-dump alle afhankelijkheden op serverniveau bevat.

Maak een gecoördineerde momentopname of een kopie van het gestopte databasevolume nadat je hebt bevestigd dat de database zich in een ondersteunde toestand bevindt. De logische dump biedt overdraagbaarheid en inspectie op objectniveau; de opslagkopie bewaart een exact terugvalpunt voor de oude versie. Geen van beide mag de andere overschrijven.

Gebruik de verificatiechecklist van ZimaSpace voor de vraag of de checklist voor de volledigheid van een databaseback-up is gevolgd. Het back-upcontrolepunt is pas geslaagd wanneer de dump leesbaar is, het opslagherstelpunt is geïdentificeerd en beide buiten het te upgraden volume zijn opgeslagen.

Oefen de migratie uit in een geïsoleerd doel

Start de doeldatabase op een afzonderlijk volume en een afzonderlijke poort, installeer de vereiste extensies, herstel de logische back-up en sla elke waarschuwing op. Een Percona-uitleg over het upgradepad met logische dump en herstel benadrukt de dump-en-herstelvolgorde en de noodzaak om tools te gebruiken die passen bij het beoogde PostgreSQL-upgradepad.

Verbind een wegwerpapplicatie-instantie met de herstelde database. Test het inloggen, lezen, schrijven, achtergrondtaken, zoeken, bijlagen, tijdzones en een herstart. Vergelijk aantallen rijen en kritieke aggregaten in plaats van alleen te vertrouwen op een geslaagde afsluitcode van het herstel.

Ga niet verder als extensies niet beschikbaar zijn, wijzigingen in collations niet zijn opgelost, migraties mislukken of de hersteltijd de onderhoudsperiode overschrijdt. Los de oefening op en maak een nieuwe dump; productie is niet de plaats om incompatibiliteit met de doelversie te ontdekken.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Schakel schrijfbewerkingen over en houd terugdraaien schoon

Schakel de onderhoudsmodus in, stop schrijvers en taken van de applicatie, controleer of actieve verbindingen zijn beëindigd en maak vervolgens de definitieve dump of ondersteunde delta. Herstel die naar een schoon doel, voer integriteits- en objectcontroles uit, werk de applicatieverbinding bij en start de services in volgorde van afhankelijkheid.

Observeer foutpercentages, locks, taakuitvoering, back-ups en echte applicatietransacties. Houd de oude database gestopt en alleen-lezen met het oorspronkelijke volume en de oorspronkelijke image-digest. Laat nooit beide databases onafhankelijke schrijfbewerkingen accepteren onder dezelfde applicatie-identiteit.

Verklaar de upgrade pas geslaagd nadat de applicatie, de native back-uptaak, de herstart en een testherstel vanuit de nieuwe versie allemaal slagen. Als vóór de schrijfdrempel een trigger voor terugdraaien afgaat, stuur de app terug naar de bewaarde oude instantie; stop na nieuwe schrijfbewerkingen en gebruik het gedocumenteerde reconciliatieplan in plaats van te doen alsof een eenvoudige herstart de gegevens terugdraait.