Forbered og test den nye serveren først, kopier data med en applikasjonsstøttet konsistensmetode, definer et overgangsvindu og bevar det gamle miljøet. Tilbakerulling må ta høyde for skrivinger som godtas på den nye serveren, ikke bare en DNS-endring.
Kartlegg tjenesten før du flytter maskinen
En migrering omfatter mer enn applikasjonsfilene. List opp databaser, opplastinger, planlagte jobber, køarbeidere, sertifikater, domener, hemmeligheter og utgående integrasjoner. Registrer programvareversjoner og de driftsforutsetningene som betyr noe, som filrettigheter og lagringsbaner. En ny dedikert server kan avdekke en glemt avhengighet som ble stille installert for flere år siden i det gamle miljøet.
Tildel en eier for overgangsbeslutningen og definer hvordan suksess ser ut. Inkluder brukersynlige kontroller, datakonsistens og evnen til å gjenopprette tilgang. Bekreft at den nye konfigurasjonen er levert og brukbar før du kunngjør en migreringsdato. En ordrebekreftelse eller en oppført maskinvarespesifikasjon er ikke det samme som en fungerende destinasjon klar til å motta produksjonsdata.
Bygg destinasjonen som et separat miljø
Installer den nødvendige stakken, etabler administrasjon og konfigurer den tiltenkte brannmuren. Hold hemmeligheter private og sett tjenestetillatelser bevisst. Verifiser applikasjonens forventede vertsnavn og sertifikatadferd før offentlig trafikk flyttes. Apaches dokumentasjon for virtuelle verter illustrerer hvorfor vertsnavnruting er en separat konfigurasjonsbeslutning fra serverens adresse. En fungerende standardside beviser ikke at riktig applikasjonsvert er konfigurert.
Bruk et representativt gjenopprettet datasett til øving, med utgående e-post, betalinger og planlagte jobber deaktivert eller omdirigert til sikre testsystemer. Dette hindrer at testmiljøet handler på vegne av reelle brukere. Øv på innlogging, opplastinger, bakgrunnsarbeid og gjenoppretting. Registrer prosedyren og varigheten, slik at det reelle vinduet bygger på en observert prosess i stedet for optimisme.
Velg en konsistent datagrense
Bruk en sikkerhetskopi- eller replikasjonsmetode som støttes av databasen og applikasjonen. PostgreSQL skiller mellom SQL-dumper, filsystemssikkerhetskopier og kontinuerlig arkivering, hver med sine egne forutsetninger. Veiledningen for dumper bemerker at databasedumper kan være internt konsistente mens klyngenomfattende roller og andre detaljer krever separat håndtering. Les kravene for det nøyaktige systemet du kjører, i stedet for å kopiere åpne datafiler vilkårlig.
Planlegg hvordan databasen forholder seg til opplastinger og køtilstand. Hvis en post peker på en fil som ble kopiert på et annet tidspunkt, kan den gjenopprettede applikasjonen være ufullstendig selv om begge kopiene lyktes hver for seg. Bestem om du skal pause skrivinger kort, bruke en testet replikasjonsordning eller utføre en applikasjonsspesifikk eksport. Hold den konsistensbeslutningen eksplisitt i runbooken.
| Trinn | Nødvendig bevis | Beslutning |
|---|---|---|
| Øving | Applikasjon og gjenopprettede data består kontroller | Destinasjonen kan vurderes for overgang |
| Endelig synkronisering | Definert konsistent gjenopprettingspunkt | Fortsett bare med forståtte gjenstående endringer |
| Trafikkbryter | Korrekt ruting og sertifikatadferd | Overvåk begge destinasjoner |
| Tilbakerulling | Plassering av alle nylig godtatte skrivinger | Avstem data før trafikken returneres |
Forbered trafikkruting uten å love umiddelbare endringer
DNS time-to-live styrer hvor lenge poster kan hurtigbufres, som forklart i Cloudflares DNS-dokumentasjon. Gjennomgå TTL tidlig hvis DNS er en del av migreringen, og la eksisterende hurtigbufrede poster eldes under sin tidligere innstilling. Å endre verdien i overgangsøyeblikket kan ikke i ettertid forkorte alle hurtigbufrede svar. Ulike klienter kan nå ulike destinasjoner i overgangen.
Hold det gamle miljøet tilgjengelig mens rutingendringene får sette seg, med en bevisst policy for om det fortsatt kan godta skrivinger. Unngå å kjøre dupliserte køforbrukere eller planlagte jobber med mindre applikasjonen er laget for det. Overvåk forespørsler på begge sider og bekreft det tiltenkte vertsnavnet, TLS-sertifikatet og applikasjonsversjonen fra uavhengige klienter.
Definer tilbakerulling etter at skrivinger begynner
Før det nye systemet godtar endringer, kan tilbakeføring av trafikk være relativt enkelt. Etterpå kan en DNS-reversering alene miste arbeid eller skape to motstridende historikker. Definer hvordan nyopprettede poster og opplastinger skal bevares eller avstemmes. Hvis applikasjonen ikke trygt kan slå dem sammen, kan en kontrollert vedlikeholdsperiode være å foretrekke fremfor en improvisert retur til den gamle kopien.
Sett betingelsene som krever at migreringen pauses, og hold beslutningseieren tilgjengelig. Bevar logger og nyttige bevis i henhold til prosjektets oppbevaringsregler. Ikke slett den gamle maskinen eller dens uavhengige gjenopprettingskopi bare fordi hjemmesiden lastet én gang. Oppbevaringsperioden bør dekke de avtalte verifiserings- og tilbakerullingsbehovene.
Avslutt migreringen med operasjonelle kontroller
Etter overgangen, verifiser sikkerhetskopier, varsler, sertifikatfornyelse, planlagt arbeid og gjenoppretting av tilgang. Bekreft at den overvåkede verten er den nye destinasjonen, og at ingen testintegrasjoner er igjen i produksjon. Gjennomgå applikasjonsfeil og brukersynlige tider under vanlig trafikk. Oppdater inventaret og runbooken slik at neste administrator ikke må utlede hva som ble endret.
SwissOctets dedikerte familier tilbyr forskjellige fysiske konfigurasjoner, men migreringsarbeid og administrert assistanse må bekreftes for den valgte tjenesten. Bruk katalogen til å velge passende ressurser, og bygg deretter en testet flytting rundt applikasjonens data. En migrering er fullført når tjenesten og gjenopprettingsprosessen fungerer på destinasjonen, ikke bare når filene er overført.
Din praktiske sjekkliste.
- Kartlegg data, jobber, hemmeligheter og integrasjoner.
- Verifiser den leverte destinasjonen før planlegging.
- Øv med sikre eksterne integrasjoner.
- Definer konsistens for database og opplastinger.
- Planlegg rutingovergang og forebygging av dupliserte jobber.
- Spesifiser tilbakerulling for nye skrivinger.
- Verifiser sikkerhetskopier og overvåking etter overgangen.
Detaljene som betyr noe.
Kan jeg migrere ved å kopiere applikasjonskatalogen?+
Bare hvis det fanger opp alt tjenesten trenger og bevarer konsistensen. Databaser, opplastinger, jobber, hemmeligheter og konfigurasjon krever vanligvis separat oppmerksomhet.
Gjør lavere DNS TTL overgangen umiddelbar?+
Nei. Tidligere hurtigbufrede svar kan bestå til deres tidligere levetid utløper, og klienter kan oppdatere til ulike tider.
Er tilbakerulling bare å peke DNS mot den gamle serveren?+
Ikke etter at den nye serveren godtar skrivinger. Du må ta høyde for disse postene og filene før trafikken returneres.
Gå til kilden.
Disse referansene støtter de tekniske konseptene i denne veiledningen. Følg gjeldende dokumentasjon før du endrer et produksjonssystem.
- PostgreSQL: Sikkerhetskopiering og gjenoppretting www.postgresql.org
- PostgreSQL: SQL-dumpkonsistens og gjenoppretting www.postgresql.org
- Apache: Dokumentasjon for virtuelle verter httpd.apache.org
- Cloudflare DNS: Time to Live developers.cloudflare.com
Redaksjonell veiledning av SwissOctet. Eksempler er illustrerende. Tjenestespesifikasjoner, tilgjengelige alternativer og kontraktsvilkår må verifiseres separat.