Ihanda at subukan muna ang bagong server, kopyahin ang data gamit ang paraan ng consistency na sinusuportahan ng application, tukuyin ang cutover window at panatilihin ang lumang kapaligiran. Ang rollback ay dapat isaalang-alang ang mga writes na tinanggap sa bagong server, hindi lamang pagbabago sa DNS.
I-inventory ang serbisyo bago ilipat ang makina
Ang migration ay may kasamang higit pa sa mga file ng application. Ilista ang mga database, upload, naka-iskedyul na trabaho, queue worker, certificate, domain, secret at outbound integration. Itala ang mga bersyon ng software at ang mahahalagang palagay sa pagpapatakbo, tulad ng mga pahintulot sa file at storage path. Ang bagong dedicated server ay maaaring maglantad ng nakalimutang dependency na tahimik na na-install maraming taon na ang nakalipas sa lumang kapaligiran.
Magtalaga ng may-ari para sa desisyon sa cutover at tukuyin kung ano ang hitsura ng tagumpay. Isama ang mga check na nakikita ng user, consistency ng data at kakayahang mabawi ang access. Kumpirmahin na ang bagong configuration ay naihatid at magagamit bago ipahayag ang petsa ng migration. Ang kumpirmasyon ng order o nakalistang detalye ng hardware ay hindi katulad ng gumaganang destinasyon na handa nang tumanggap ng production data.
Buuin ang destinasyon bilang hiwalay na kapaligiran
I-install ang kinakailangang stack, magtatag ng administration at i-configure ang nilalayong firewall. Itago nang pribado ang mga secret at sadyang itakda ang mga pahintulot ng serbisyo. I-verify ang inaasahang hostname at pag-uugali ng certificate ng application bago lumipat ang pampublikong trapiko. Ang dokumentasyon ng virtual-host ng Apache ay naglalarawan kung bakit ang hostname routing ay hiwalay na desisyon sa configuration mula sa address ng server. Ang gumaganang default page ay hindi nagpapatunay na ang tamang application host ay naka-configure.
Gumamit ng representatibong naibalik na dataset para sa rehearsal, na naka-disable o naka-redirect sa ligtas na test system ang papalabas na email, pagbabayad at naka-iskedyul na trabaho. Pinipigilan nito ang test environment na kumilos sa mga tunay na user. Isagawa ang login, upload, background work at restoration. Itala ang pamamaraan at tagal nito upang ang tunay na window ay nakabatay sa naobserbahang proseso sa halip na optimismo.
Pumili ng pare-parehong hangganan ng data
Gumamit ng backup o replication method na sinusuportahan ng database at application. Tinutukoy ng PostgreSQL ang SQL dump, file-system backup at continuous archiving, bawat isa ay may sariling palagay. Ang gabay nito sa dump ay nagsasaad na ang mga database dump ay maaaring panloob na pare-pareho habang ang cluster-wide roles at iba pang detalye ay nangangailangan ng hiwalay na paghawak. Basahin ang mga kinakailangan para sa eksaktong sistemang pinapatakbo mo sa halip na basta kopyahin ang mga bukas na data file.
Planuhin kung paano nauugnay ang database sa mga upload at queue state. Kung ang isang record ay tumutukoy sa file na kinopya sa ibang oras, ang naibalik na application ay maaaring hindi kumpleto kahit na ang parehong kopya ay nagtagumpay nang isa-isa. Magpasya kung ihinto sandali ang writes, gumamit ng nasubok na replication arrangement o magsagawa ng application-specific export. Panatilihing tahasan ang desisyon sa consistency na iyon sa runbook.
| Yugto | Kinakailangang ebidensya | Desisyon |
|---|---|---|
| Pagsasanay | Pumasa ang application at naibalik na data sa mga check | Maaaring isaalang-alang ang destinasyon para sa cutover |
| Huling synchronisation | Tinukoy na pare-parehong recovery point | Magpatuloy lamang sa mga nauunawaang natitirang pagbabago |
| Paglipat ng trapiko | Tamang routing at pag-uugali ng certificate | Subaybayan ang parehong destinasyon |
| Pagbalik sa dating kalagayan | Lokasyon ng lahat ng bagong tinanggap na writes | I-reconcile ang data bago ibalik ang trapiko |
Ihanda ang routing ng trapiko nang hindi nangangako ng agarang pagbabago
Kinokontrol ng DNS time-to-live kung gaano katagal maaaring i-cache ang mga record, gaya ng ipinaliwanag sa dokumentasyon ng DNS ng Cloudflare. Suriin ang TTL nang maaga kung bahagi ng migration ang DNS, at hayaang mag-expire ang mga kasalukuyang naka-cache na record sa ilalim ng kanilang dating setting. Ang pagbabago ng halaga sa sandali ng cutover ay hindi maaaring retroaktibong paikliin ang bawat naka-cache na sagot. Maaaring maabot ng iba't ibang client ang iba't ibang destinasyon sa panahon ng transition.
Panatilihing magagamit ang lumang kapaligiran habang nag-aayos ang mga pagbabago sa routing, na may sadyang patakaran kung maaari pa itong tumanggap ng writes. Iwasan ang pagpapatakbo ng duplicate na queue consumer o naka-iskedyul na trabaho maliban kung dinisenyo ang application para dito. Subaybayan ang mga request sa magkabilang panig at kumpirmahin ang nilalayong hostname, TLS certificate at bersyon ng application mula sa mga independiyenteng client.
Tukuyin ang rollback pagkatapos magsimula ang writes
Bago tumanggap ng mga pagbabago ang bagong sistema, ang pagbabalik ng trapiko ay maaaring medyo simple. Pagkatapos, ang pagbabalik ng DNS lamang ay maaaring mawalan ng trabaho o lumikha ng dalawang magkasalungat na kasaysayan. Tukuyin kung paano mapapanatili o mai-reconcile ang mga bagong likhang record at upload. Kung hindi ligtas na pagsamahin ng application ang mga ito, ang kontroladong panahon ng maintenance ay maaaring mas mainam kaysa sa improvised na pagbabalik sa lumang kopya.
Itakda ang mga kundisyon na nangangailangan ng paghinto sa migration, at panatilihing maabot ang may-ari ng desisyon. Itago ang mga log at kapaki-pakinabang na ebidensya sa ilalim ng mga patakaran sa retention ng proyekto. Huwag tanggalin ang lumang makina o ang independiyenteng recovery copy nito dahil lamang nag-load nang isang beses ang home page. Ang panahon ng retention ay dapat sumaklaw sa napagkasunduang pangangailangan sa verification at rollback.
Isara ang migration sa mga operational check
Pagkatapos ng cutover, i-verify ang mga backup, alerto, pag-renew ng certificate, naka-iskedyul na trabaho at pagbawi ng access. Kumpirmahin na ang sinusubaybayang host ay ang bagong destinasyon at walang natitirang test integration sa production. Suriin ang mga error ng application at mga timing na nakikita ng user sa ilalim ng ordinaryong trapiko. I-update ang inventory at runbook upang hindi na kailangang hulaan ng susunod na administrator kung ano ang nagbago.
Ang mga dedicated family ng SwissOctet ay nag-aalok ng iba't ibang pisikal na configuration, ngunit ang gawain sa migration at managed assistance ay dapat kumpirmahin para sa napiling serbisyo. Gamitin ang catalogue upang pumili ng angkop na resources, pagkatapos ay bumuo ng nasubok na paglipat para sa data ng iyong application. Kumpleto ang migration kapag gumagana ang serbisyo at ang proseso ng pagbawi nito sa destinasyon, hindi lamang kapag nailipat na ang mga file.
Ang iyong praktikal na checklist.
- I-inventory ang data, trabaho, secret at integration.
- I-verify ang naihatid na destinasyon bago mag-iskedyul.
- Magsanay gamit ang ligtas na external integration.
- Tukuyin ang consistency ng database at upload.
- Planuhin ang transition ng routing at pag-iwas sa duplicate na trabaho.
- Tukuyin ang rollback para sa mga bagong write.
- I-verify ang mga backup at monitoring pagkatapos ng cutover.
Ang mga detalyeng mahalaga.
Maaari ba akong mag-migrate sa pamamagitan ng pagkopya ng application directory?+
Kung nakukuha lamang nito ang lahat ng kailangan ng serbisyo at napapanatili ang consistency. Ang mga database, upload, trabaho, secret at configuration ay karaniwang nangangailangan ng hiwalay na atensyon.
Ginagawang agarang ang cutover kapag ibinaba ang DNS TTL?+
Hindi. Ang mga dating naka-cache na sagot ay maaaring manatili hanggang matapos ang kanilang naunang lifetime, at maaaring mag-update ang mga client sa iba't ibang oras.
Ang rollback ba ay pagturo lamang ng DNS sa lumang server?+
Hindi pagkatapos tumanggap ng writes ang bagong server. Dapat mong isaalang-alang ang mga record at file na iyon bago ibalik ang trapiko.
Pumunta sa pinagmulan.
Sinusuportahan ng mga sangguniang ito ang mga teknikal na konsepto sa gabay na ito. Sundin ang kasalukuyang dokumentasyon bago baguhin ang isang production system.
- PostgreSQL: Backup at Pagpapanumbalik www.postgresql.org
- PostgreSQL: Consistency at restoration ng SQL Dump www.postgresql.org
- Apache: Dokumentasyon ng Virtual Host httpd.apache.org
- Cloudflare DNS: Time to Live developers.cloudflare.com
Editorial guidance ni SwissOctet. Ang mga halimbawa ay ilustratibo. Ang service specifications, available options at contractual conditions ay dapat beripikahin nang hiwalay.