Se pare că este dificil să transferăm site-ul pe alt server? Probabil că mulți dintre noi am copiat primele pagini de pornire de la găzduire la găzduire în căutarea celor mai bune, în timp ce încă mai studiem la școală sau la primul an universitar. Sau suspendat la urechi de taitei pentru management, a explicat că această sarcină nu este rezolvată instantaneu și site-ul nu va funcționa timp de 24 de ore, deoarece DNS este un astfel de lucru ...
- Copiați fișierele
- Pentru a crea o bază de date
- Extindeți pe un nou server
- Pe vechiul server, înlocuiți toate conexiunile cu noua bază de date
- Configurați DNS
- ...
Cât timp va dura? Cât de multe minute prețioase va funcționa site-ul \ nu va funcționa corect?
Din anumite motive, nu am găsit nici un articol despre hubr, așa că am decis să scriu câteva trucuri, cum pot transfera un proiect stângace sau doar câteva astfel încât șeful să fie mulțumit de funcționarea stabilă a site-ului.
Toate acestea sunt mai relevante pentru site-urile scrise în PHP, pentru administratorii care au întâlnit proiecte care nu au folosit cadre, cms și cap atunci când scriu codul.
1. Transferarea fișierelor
Cea mai bună cale este prin intermediul ssh folosind rsync:
Deci, rsync sincronizeaza dosare treptat, adică, numai exemplare - ceea ce lipsește, și nu ar atinge ceva nou. De exemplu, ai putea scrie un script bash mic, care se va sincroniza toate folderele de pe serverul vechi la noul DNS în momentul actualizării, dar încă cea mai bună opțiune ar fi câteva zile pentru a sincroniza dosarul cu -n cheie (-dry-run) doar pentru a vedea diferența. Cred că documentația pentru rsync găsi soluții la probleme în sincronizarea fișierelor. Programul trebuie să fie instalat pe ambele servere.
Cu FTP, rsync nu poate funcționa, apoi folosiți lftp:
2. Transfer de baze de date folosind MySQL ca exemplu
Pe ambele mașini, deschideți portul de server MySQL în lume:
Voi scrie un exemplu de modul în care fac backup-uri în fiecare zi, tăind logrotate.d:
De ce nu clasic "mysqldump -u root -p bază de date> dump.sql"? Apoi procedurile de vizualizare și stocare nu vor fi salvate. Spre deosebire de MySQL Workbench, de acolo am luat această comandă.
Apoi, în variabila $ CMD, adăugați -h ip_your_server și modificați linia $ CMD $ i | gzip -c> /srv/dumps/$i/$i.sql.gz la:
Desigur, trebuie să creați mai întâi toate bazele de date:
3. Redirecționați toate conexiunile la localhost: 3306 - server vechi pe un server nou
Destul de simplu, folosim tunelul ssh (care anterior a oprit mysql):
Și ssh este necesar doar pe mașina locală. Verificăm:
Obținem serverul MySQL la distanță pe mașina locală. Totul ar fi bine, dar clientul MySQL, dacă vede că conexiunea se duce la localhost care se conectează la server prin socketul local și nu există setări pentru a face acest lucru nu se poate dezactiva. Ie
Sau ca de obicei scriem în scripturi:
Nu va funcționa, pentru că o astfel de conexiune va fi de asemenea gestionată prin conectorul local. Desigur, puteți trece peste toate conexiunile site-ului și puteți înlocui localhost cu 127.0.0.1 sau un server IP extern, acesta va funcționa deja, dar există o cale mai bună.
Găsiți singura potrivire în text localhost și înlocuiți-o cu altceva, ca lacalhost, în ambele fișiere. După ce conexiunile locale vor funcționa prin TCP / IP! Singura MySQL nu permite utilizatorilor ale căror gazde de la distanță pot fi doar localhost în privilegii. Aceasta trebuie să fie fixată la% în timpul transferului.
Trecem peste setările serverului web, pe această temă este plină de materiale.
Ca rezultat, avem două mașini de lucru cu un server de bază de date. Calmați resetarea DNS și du-te la culcare!
P.S. De asemenea, a venit ideea de a interogări proxy de la vechiul server la cel nou prin intermediul nginx. A făcut cineva asta?
Trimiteți-le prietenilor: