jobjob in pain
28 Jan 2009Totul a început săptămâna trecută, când am decis să nu mai folosim [Amazon EC2][1] pentru [crawling][2]…
[1]: http://aws.amazon.com/ec2/ “” [2]: http://en.wikipedia.org/wiki/Web_crawler “”
În prima fază, am mutat crawlingul pe un alt server al nostru, mai aproape de serverul [jobjob][3].
Am dat drumul la replicarea MySQL, care funcționa până la un punct. Acela de a insera datele în slave. Am încercat mai multe abordări, am citit tot ce se putea despre replicare, am urmat instrucțiuni pas-cu-pas, dar ajungeam mereu la același rezultat nefavorabil. Replicarea funcționa OK din dpdv MySQL, toți indicatorii arătau că merge, datele se transmiteau corect prin [binary log][4], ajungeau pe slave în “queue” dar, dintr-un motiv necunoscut până în ziua de azi, nu se executau. Permisiunile & privilegii – OK.
[3]: http://www.jobjob.ro/ “” [4]: http://dev.mysql.com/doc/refman/5.0/en/binary-log.html “”
Pentru că deja site-ul era jos de aproape două zile, iar ziua următoare aveam programat un demo în Londra, am decis să oprim crawlingul și replicarea și să aducem site-ul în stare de funcționare.
După câteva zile de calm, în care site-ul mergea mai rapid ca niciodată (legătura real-time cu Amazon costă 1-2 secunde!), au început să apară niște erori legate de “read-only file system” – pe directorul în care se salvează fișierele de sesiune php. Apoi pe toată partiția principală (root)!
Chiar acum suntem în discuții cu departamentul de suport al [providerului de hosting][5] și facem tot ce putem să-l readucem la viață. Momentan nu răspunde nici la ping.
[5]: http://www.softlayer.com “”
În ultimă instanță, ne uităm la o reinstalare completă de sistem, cu lucrurile făcute bine de la început.
No pain, no gain.
P.S. Suntem foarte mulțumiți de serviciile [SoftLayer][6] și nu avem nevoie de recomandări de alți provideri. Mulțumesc :) .
[6]: http://www.softlayer.com/ “” [7]: /public/images/smilies/icon_smile.gif