Emanuel Salagean wrote:
Trebuie sa inveti sa tratezi astfel de cereri(frateee, sa nu pierd
vreun mail, sau vreun vizitator) functie de client.
Daca se muta, se muta din unul din doua motive: e nemultumit de
serviciile actuale, pt ca-i pica in draci, si atunci alea 2 ore date
de tine sunt un kkt fata de ce probleme are acum. Daca se muta pt ca
e mai ieftin, desi ii merge bine unde e, nu are ceva atat de
important incit sa nu suporte 2 ore de downtime (ipotetic, pentru ca
nu va exista downtime).
Mda, stiu ca e simplu asa.
Problema apare la unele situri care au baze de date, forum, etc. Acolo
trebuie sa tratez un pic diferit problema, daca fac doar transfer si
modificare ns-ului, vor aparea inconsistente in baza de date, unii vor
vedea veche versiune, altii noua. ( O solutie ar fi sa copiez baza de
date pe noul server si sa modific php-ul sa se conecteze la noua baza
de date, asa, daca unii intra pe noul/vechiul server, baza de date e
comuna, dar si acolo pot aparea inconsistente).
pai:
* replicare la bazele de date (treaba mai mult sau mai putin banala in
functie de server)
* TTL redus la minim (5/10 minute)
* copiat conturi et al pe serverul nou, configurat ala vechi sa ruteze
mailurile spre al nou, pus e amandoua ca mx, ala nou cu prioritate mai mare
* eventual anuntati clientii sa se abtina de la schimbari pt o vreme,
sau daca nu se poate, exportat directoarele cu conturi pe nfs sau ceva
asemanator catre serverul vechi
* cand merge tot, schimbat IP-urile in DNS, sters mx vechi, asteptat sa
se propage (motoarele de cautare se prind mai greu cateodata, btw)
* scos server vechi din priza si trimis la copiii flamanzi din uganda
P.S. s-a mai discutat de nspe ori pe lista
P.S. 2 utfg://seamless site migration -microsoft
_______________________________________________
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug