Pregătiți și testați mai întâi noul server, copiați datele cu o metodă de consistență acceptată de aplicație, definiți o fereastră de comutare și păstrați mediul vechi. Rollback-ul trebuie să țină cont de scrierile acceptate pe noul server, nu doar de o modificare DNS.
Inventariați serviciul înainte de a muta mașina
O migrare include mai mult decât fișierele aplicației. Enumerați bazele de date, încărcările, sarcinile programate, lucrătorii de coadă, certificatele, domeniile, secretele și integrările de ieșire. Înregistrați versiunile software și ipotezele de operare care contează, cum ar fi permisiunile fișierelor și căile de stocare. Un server dedicat nou poate scoate la iveală o dependență uitată care fusese instalată în liniște cu ani în urmă pe mediul vechi.
Atribuiți un responsabil pentru decizia de comutare și definiți cum arată succesul. Includeți verificări vizibile pentru utilizator, consistența datelor și capacitatea de a recupera accesul. Confirmați că noua configurație este livrată și utilizabilă înainte de a anunța o dată de migrare. O confirmare de comandă sau o specificație de hardware listată nu este același lucru cu o destinație funcțională pregătită să primească date de producție.
Construiți destinația ca mediu separat
Instalați stiva necesară, stabiliți administrarea și configurați firewall-ul dorit. Păstrați secretele private și setați permisiunile serviciilor în mod deliberat. Verificați comportamentul așteptat al numelui de gazdă și al certificatului aplicației înainte de mutarea traficului public. Documentația Apache privind gazdele virtuale ilustrează de ce rutarea numelui de gazdă este o decizie de configurare separată de adresa serverului. O pagină implicită funcțională nu dovedește că gazda corectă a aplicației este configurată.
Folosiți un set de date reprezentativ restaurat pentru exersare, cu e-mailurile de ieșire, plățile și sarcinile programate dezactivate sau redirecționate către sisteme de test sigure. Astfel se evită ca mediul de test să acționeze asupra utilizatorilor reali. Exersați autentificarea, încărcările, activitatea în fundal și restaurarea. Înregistrați procedura și durata acesteia, astfel încât fereastra reală să se bazeze pe un proces observat, nu pe optimism.
Alegeți o limită consecventă a datelor
Utilizați o metodă de backup sau replicare acceptată de baza de date și aplicație. PostgreSQL distinge între dump-urile SQL, backup-urile sistemului de fișiere și arhivarea continuă, fiecare cu propriile ipoteze. Îndrumările sale privind dump-urile notează că dump-urile bazei de date pot fi consecvente intern, în timp ce rolurile la nivel de cluster și alte detalii necesită gestionare separată. Citiți cerințele pentru sistemul exact pe care îl rulați, în loc să copiați fișiere de date deschise fără discriminare.
Planificați modul în care baza de date se raportează la încărcări și la starea cozii. Dacă o înregistrare indică un fișier care a fost copiat la un moment diferit, aplicația restaurată poate fi incompletă chiar dacă ambele copii au reușit individual. Decideți dacă să întrerupeți scrierile scurt, să utilizați o configurație de replicare testată sau să efectuați un export specific aplicației. Păstrați această decizie de consistență explicită în runbook.
| Etapă | Dovezi necesare | Decizie |
|---|---|---|
| Exersare | Aplicația și datele restaurate trec verificările | Destinația poate fi luată în considerare pentru comutare |
| Sincronizare finală | Punct de recuperare consecvent definit | Continuați doar cu modificările rămase înțelese |
| Comutarea traficului | Rutare corectă și comportament corect al certificatului | Monitorizați ambele destinații |
| Rollback | Locația tuturor scrierilor nou acceptate | Reconciliați datele înainte de a readuce traficul |
Pregătiți rutarea traficului fără a promite schimbări instantanee
DNS time-to-live controlează cât timp pot fi stocate în cache înregistrările, după cum se explică în documentația DNS a Cloudflare. Examinați TTL-ul devreme dacă DNS face parte din migrare și lăsați înregistrările existente din cache să expire conform setării lor anterioare. Schimbarea valorii în momentul comutării nu poate scurta retroactiv fiecare răspuns din cache. Diferiți clienți pot ajunge la destinații diferite în timpul tranziției.
Păstrați mediul vechi disponibil cât timp se stabilizează modificările de rutare, cu o politică deliberată privind posibilitatea de a accepta în continuare scrieri. Evitați rularea de consumatori de coadă sau sarcini programate duplicate, cu excepția cazului în care aplicația este proiectată pentru asta. Monitorizați solicitările pe ambele părți și confirmați numele de gazdă vizat, certificatul TLS și versiunea aplicației din clienți independenți.
Definiți rollback-ul după începerea scrierilor
Înainte ca noul sistem să accepte modificări, revenirea traficului poate fi relativ simplă. Ulterior, o singură inversare DNS poate duce la pierderea muncii sau la crearea a două istorice conflictuale. Definiți modul în care înregistrările nou create și încărcările ar fi păstrate sau reconciliate. Dacă aplicația nu le poate fuziona în siguranță, o perioadă de mentenanță controlată poate fi de preferat unei reveniri improvizate la copia veche.
Stabiliți condițiile care impun întreruperea migrării și mențineți persoana responsabilă de decizie accesibilă. Păstrați jurnalele și dovezile utile conform regulilor de retenție ale proiectului. Nu ștergeți vechiul server sau copia sa independentă de recuperare doar pentru că pagina principală s-a încărcat o dată. Perioada de retenție ar trebui să acopere nevoile convenite de verificare și rollback.
Încheiați migrarea cu verificări operaționale
După comutare, verificați backupurile, alertele, reînnoirea certificatelor, lucrările programate și recuperarea accesului. Confirmați că gazda monitorizată este noua destinație și că nu au rămas integrări de test în producție. Examinați erorile aplicației și timpii vizibili pentru utilizatori în condiții de trafic obișnuit. Actualizați inventarul și runbook-ul, astfel încât următorul administrator să nu fie nevoit să deducă ce s-a schimbat.
Familiile dedicate ale SwissOctet oferă configurații fizice diferite, dar activitatea de migrare și asistența gestionată trebuie confirmate pentru serviciul ales. Folosiți catalogul pentru a selecta resursele potrivite, apoi construiți o mutare testată în jurul datelor aplicației dvs. O migrare este completă atunci când serviciul și procesul său de recuperare funcționează la destinație, nu doar atunci când fișierele au fost transferate.
Lista dumneavoastră practică de verificare.
- Inventariați datele, lucrările, secretele și integrările.
- Verificați destinația livrată înainte de programare.
- Exersați cu integrări externe sigure.
- Definiți consistența bazei de date și a încărcărilor.
- Planificați tranziția rutării și prevenirea lucrărilor duplicate.
- Specificați rollback-ul pentru scrierile noi.
- Verificați backupurile și monitorizarea după comutare.
Detaliile care contează.
Pot migra copiind directorul aplicației?+
Numai dacă aceasta capturează tot ce are nevoie serviciul și păstrează consistența. Bazele de date, încărcările, lucrările, secretele și configurația necesită de obicei atenție separată.
Scăderea TTL-ului DNS face comutarea instantanee?+
Nu. Răspunsurile cache-uite anterior pot rămâne până la expirarea duratei lor de viață anterioare, iar clienții se pot actualiza la momente diferite.
Rollback-ul înseamnă doar să îndreptați DNS către vechiul server?+
Nu după ce noul server acceptă scrieri. Trebuie să țineți cont de acele înregistrări și fișiere înainte de a readuce traficul.
Mergeți la sursă.
Aceste referințe susțin conceptele tehnice din acest ghid. Urmați documentația actuală înainte de a modifica un sistem de producție.
- PostgreSQL: Backup și restaurare www.postgresql.org
- PostgreSQL: Consistența și restaurarea dump-ului SQL www.postgresql.org
- Apache: Documentația Virtual Host httpd.apache.org
- Cloudflare DNS: Time to Live developers.cloudflare.com
Îndrumare editorială de SwissOctet. Exemplele sunt ilustrative. Specificațiile serviciilor, opțiunile disponibile și condițiile contractuale trebuie verificate separat.