Caught in a Web

I tako sinoć negde oko ponoći konačno navatah malo vremena da sredim neke sitne stvarčice na svom Blogu. Videh da je novi WordPress 2.2.1 već tu, a upgrade nisam radio baš dugo (kod mene se još uvek vrti 2.0.4), pa rekoh sebi, hajde da i to odradimo onako u letu. Standardna procedura “skini i baci novi wp preko starog” (iliti wget http://wordpress.org/latest.tar.gz;tar -xzvf latest.tar.gz; cp…), kao i upgrade baze prošli su sasvim glatko. No, Blog više nije radio! Jednostano dobijam neke sulude poruke o MySQL greškama.

Jedan grep na serveru, i otkrio sam da je problem do Gengo plugin-a koji verovatno treba update-ovati. Ok, skinuo latest verziju istog (0.9), instalirao i problem sa MySQL-om je nestao. Nažalost, pojavili su se neki drugi vrlo čudni problemi, ponovo prouzrokovani gengom. Nakon kopanja po sajtu autora, pronašao sam da Gengo 0.9 nije kompatibilan sa poslednjom verzijom WP-a, ali da je nova verzija “na putu”, tj. neka alfa 0.9.1-alpha-3 je vec dostupna preko svn trunk-a. OK, novo cimanje sa gengom, skidanje svih fajlova iz svn-a i upload … samo da bih pronašao novi bug u istom. Probao čak i ručno da “patchujem” fajlove, ali nije išlo. Već je 02am … vreme je da se nekako vratimo na staru verziju i stavimo iza sebe avanturu zvanu “upgrade wordpressa”.

RTFM
Word Press ima odličnu dokumentaciju o instalaciji, koju sam ja sinoć naravno ignorisao, uljuljkan činjenicom da je upgrade uvek do sada prolazio veoma glatko. Jedna od reči koja se mnogo puta pominje u manualu je backup. Sinoć sam naravno bio dovoljno lenj da ne pravim backup, obzirom da sam znao da moj hosting provider Dreamhost redovno generiše isti, a imao sam i neki (doduše ne baš najsvežiji) i na svom kompjuteru. Naravno, nikada nisam bio u prilici da taj “feature” Dreamhosta isprobam i u praksi, no uvek postoji prvi put :)

Prvo prijatno iznenađenje je način na koji DH backupuje vaše fajlove. Kako je opisano na njihovim wiki stranama, jedan od načina na koji oni backupuju vaše fajlove je takozvani automated domain snapshot. Jednostavno, ako pristupate svojim fajlovima iz shella (što ja naravno sa zadovoljstvom činim), u svakom direktorijumu možete pronaći skriveni .snapshot direktorijum unutar koga možete naći 6 vremenskih intervala (hourly.0, hourly.1, nightly.0, nightly.1, weekly.0, weekly.1) u kojima je kreiran backup tekućeg direktorijuma! Naravno, restore se svodi na jednostavno kopiranje fajlova sa backup lokacije na njihovu pravu lokaciju.

File Snapshot sistem

Što se backupa baze tiče, tu je situacija još jednostavnija. Jednostavno se iz admin panela odabere baza koju želite da povratite, kao i način na koji to želite da odradite, i u roku od 5 minuta, vaši podaci su sređeni.

Restore MySQL tabela u admin panelu

Sve u svemu, u roku od 5 minuta vratio sam sistem u pređašnje stanje, za čije bi mi rešavanje bili potrebni sati!

Napominjem da DH spada u red jeftinijih hosting providera, paket koji ja koristim je reda veličine 150 dolara godišnje ali ipak imaju solidan uptime i podršku, kao i par zgodnih feature-a u koje spada i ovaj backup.

Comments(1)

Kako javlja B92 Tehnopolis, od danas Google AdSense podržava i srpski jezik. Ova ekskluzivna informacija još uvek nije potvrđena na zvaničnom sajtu gde se na listi podržanih jezika još uvek ne nalazi srpski, ali u raspravi na DPT-u potvrđeno je da je podrška stigla i da funkcioniše.

Google Adsense postao je izrazito popularan među domaćim Webmasterima nakon što je Google objavio podršku za hrvatski jezik. Kao i kod hrvatskog jezika, da bi cela stvar funkionisala, u Adsense JavaScript kod, potrebno je dodati sledeći “hack”:

google_language = "sr"

Nažalost trenutno su prihodi od adsense-a na sajtovima na srpkom jeziku značajno manji nego kod sajtova na engleskom, zato što je vrednost PPC-a (pay per click) značajno manja kod srpskih sajtova.

Comments(2)

From php.net

[13-Jul-2007]

Today it is exactly three years ago since PHP 5 has been released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable & production-ready and as PHP 6 is on the way, PHP 4 will be discontinued.

The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5.

For documentation on migration for PHP 4 to PHP 5, we would like to point you to our migration guide. There is additional information available in the PHP 5.0 to PHP 5.1 and PHP 5.1 to PHP 5.2 migration guides as well.

Amen to that. Finally this will move the rest of people to PHP5, so we can finally start using all those great PHP5 features without worrying that such code cannot be used on most of client servers. Looking forward to PHP6 now :)

Comments(0)

If you ever dealt with backup of MySQL tables, you probably used mysqldump utility, which allows you to dump all data into some mytables.sql file, which you can backup somewhere, import to other MySQL server etc. I used this procedure for a thousands times so far, and generally it goes as follows:

export:

mysqldump -udinke -pmojpass -hhostname.of.server1 dbname table1 table2 tableN > dump_file.sql

mysql -udinke -pmojpass -hhostname.of.server2 dbname  < dump_file.sql

Sometimes there is a problem when you move data from new version of MySQL to old, and in that case you have to specify proper compability flag when running mysql dump (--compatible=name where name can be mysql323, mysql40, postgresql, oracle etc.).

Anyway, few days ago in order to move data from one MySQL to another, I had to dump some ... let say big mysql tables (about 10 tables, where each contained about 10 millions of records). After long lasted procedure (dump to file, gzip, scp to other server) I finally started import. However, after 3 hours (yes, three hours) instead of Linux prompt I got this:

[dinke@um-917 ~/public_html]$ mysql -udinke -p325ewfwt23rasf
keyword_discovery < es_miner_data.sql
ERROR 1582 (23000) at line 163833: Duplicate entry '1167548' for key
'PRIMARY'

WTF? I moved data from old server to new, which means import should run without compability problems. It could be indexes on old table were damaged, but instead to wait like 2 more hours in order to complete check & repair procedure, I've decided to create dump file, this time with ignore option, so all insert queries in dump file are "insert ignore", so in case of error like previous one, errors will be ignored. Not very smart, but those data are not really high sensitive, and I can afford to lose few records but can't afford to lose 10 hours for import!

So, dump, gzip, scp, import again ... which lasted long... loooooong .... so fucking long that after 3 hours after I started import I started to think about other solutions. And solution was dumb but effective. We simple moved all MySQL data files (*.MYI, *.MYD i *.frm) from one server to another, and then we run myisamchk in order to fix those tables because ... we didn't shutdown MySQL server during copy procedure which generally could cause some problems with data.

All in all, this procedure went very fast (the longest was actual copy from one host to another), and in less than half hour I got everything settled down.

At the end I came with conclusion that in case of really big tables, using tool like mysqldump is unaccepted as backup solution because it takes literally hours to complete. One of solution to that problem can be to copy MySQL data files like I did. That shouldn't be a problem, because tables are "platform safe" meaning, binary file created on one platform (ie *.MYI file on Linux) will work without problem when moved to other problem (ie. on Windows). The only one real problem is that if you copy data wihout MySQL shutdown, table files there are in some kind of "state of flux" which can be a problem, especialy if they are highly used in moment when you do copy. That's why you need to do myisamchk on it.

Comments(1)

Što će reći, kiša gotovo svakodnevno, Federer ponovo tuče Nadala u finalu, a Venus diže pehar po n-ti put (ko sme da se kladi da neće biti ovako :). Dobro, nešto je ipak drugačije nego pre… naši ovaj put 3 polufinala (Ana, Nole, Zimonjić), JJ doduše malo razočarala, Tipsarević konačno onaj pravi.

Novakov današnji meč protiv Bagdatisa gotovo je oborio sve rekorde po trajanju (4 sata i 59 minuta). No, osim što je u stanju da igra 5 sati, Nole je i sjajan šouman. Nakon pevanja u Rolland Garrosu, prešao je na travnate terene gde je pokazao i svoje glumačke kvalitete. Na videu su redom Rodick, Hewit, Nadal i Šarapova :)

Nadam se da Nadal ovo nije video, jer se u protivnom Noletu crno piše u sutrašnjem polufinalu.

Comments(0)