Fórumok
Van egy gondom, hogy lenny alatt 5.0.5-s mysql adatbázist kellene upgradelni 5.5.32-re.
A gond az, hogy az adatbázis megvan de a rendszer már nincs, s a mysl-be elmentett adatokat kellene átvinni az új rendszer alá. Esetleg valakinek valami ötlete van-e?
Hozzászólások
Én óvatos duhaj vagyok! Nem tudom milyen értéket képvisel és mekkora is ez az adatbázis.
Megbízhatóan, mindig a szöveges "dump" volt jó export/import adat.
"Felcsapni" egy minimális Debian Lenny -t ck 2 óra (ha nincs extra hardwer probléma és van stabil internet kapcsolat) akkor simán tudsz telepíteni egy megfelelő verziójú MySQL -t, ott binárisan beépíteni az adatbázist, és dump - ezzel már biztos megtudod oldani a helyreállítást.
Egy próbát persze a bináris "betöltés" is megér:
Bölcs ha az aktuális adatbázist mented, mielőtt machinálsz.
MySQl leállít, a megfelelő helyre az adatbázis (/var/lib/mysql) bemásol és újra indít mysql - logot jól megnézni!
* Én egy indián vagyok. Minden indián hazudik.
Soha nem is értettem, mire jó a MySQL mappát natívan elmenteni, de legalább értem a kérdező problémája miből ered.
+1 a megoldási javaslatra.
--
PtY - www.onlinedemo.hu
Úgy érted, dump helyett mire jó?
Vagy mire gondolsz?
Dump (ha csak minimálisan hasonlít az oracle exp/imp működésére) nem igazán jó backupnak, mert lassabban lehet belőle helyreállítani az adatbázist, mint a fájlok mentésével.
MySQL-hez úgy tudom, nincs rman jellegű backup megoldás.
-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
Igen, úgy értem, hogy dump helyett mire jó.
Pont ezek a bajaim - a dump nem verziófüggő, a dump visszatöltése újragenerálja az indexeket (indexhibák ellen kitűnő megoldás). Csupán a mappa lementése nem fogja megoldani pl. az inkonzisztecia problémákat, sőt, elő sem fognak jönni, és hamis biztonságérzetet ad.
Ha meg binális logokat használsz (tranzakciós logok), és nem áll a mysql-ed, amikor lemented, még adatvesztésed is lesz. Dump meg mehet online is.
Szóval konkrétan mire jó, ha nem használok dumpot, és lementem a mappákat?
--
PtY - www.onlinedemo.hu
Flush logs és máris nincs gond az adatvesztéssel. Már persze ha nem épp a flush utáni adat kell. Vagy a mentés utáni, ehe.
MySQL-lel nincs sok tapasztalatom, szóval nem mernék szakérteni.
Az biztos, hogy dump-ból helyreállítani egy nagy adatbázist, k. lassú.
A dump normálisan nem a napi backup kiváltására való.
Archiválásra, adatmozgatásra egyik szerverről a másikra igen, kis méretű adatbázisok esetén talán mentés helyett is, de egyébként... A mentés tervezésekor nem árt számolni egy esetleges helyreállítás idejével is.
-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
7*24-ben futó mysql-t lvm-re illik pakolni, flush tables with read lock, lvm snapshot kreálás, unlock tables, aztán a snapshot már menthető, a binlogokat meg szépen rá lehet utána pakolni, ha köll. Ilyen környezetben a visszaállítás időigényét is le kell szorítani, arra meg szerintem pont nem a szöveges dump/restore a legjobb megoldás.
Ma sz@r az index, arra nem hiszem, hogy a DB teljes újraépítése a megoldás :-) El lehet dobni, újra lehet kreálni, akár menet közben is, nem?
Ok, ez valóban mind igaz, de verzióprobléma akkor is fennáll.
Egy olyan helyzetben, mint a threadindító, pont ezt okozza: telepítened kell egy kompatibilis rendszert, azon upgrade-elni, majd átemelni az új környezetbe, vagy azon dumpolni, és az új rendszerben meg importálni. Ilyen esetekben űber nagy szívás. Kis méretű (pl. webes) adatbázisoknál is, nem csak nagyoknál.
Ha meg nincs lvm, akkor snapshotolni sem tudsz.
--
PtY - www.onlinedemo.hu
Verzióprobléma bármilyen mentésnek a frissebb sw-be történő visszalapátolása során adódhat, db esetében persze komolyabb a gond, hiszen nincs olyan tool, ami a bináris db-fájlokat képes lenne átmókolni az egyes verziók között - holott létezhetne. Láttam már jogszabályi kötelezettség miatt megőrzött őskövület hw-eket, amik csak a helyet foglalták, meg a port fogták, de az azokkal feldolgozott adatokat még x évig helyre kell tudni állítani, és ez volt a legegyszerűbb megoldás - itt is ez a helyzet: a régi mentés értelmezéséhez kell egy régi sw.
A topic indítójának a problémáját szerintem az okozza, hogy ugyanolyan formátumban készült a db archiválása, mint a rendszeres mentése, és most egy ilyen archivból kell visszaállni, ami tényleg méretes szívás. Vagy meg kell őrizni az archívok megőrzési idejének megfelelően visszamenőlegesen a sw-környezetet is, vagy formátumfüggetlenül kell archiválni.
Ha nincs lvm, akkor az valóban szívás - másik oldalról viszont a rendszer összerakásánál elkövetett orbitális hiba.
proli like!
(alias +1 ;) )
-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
Az ilyen őskövület rendszereket be kell virtualizálni, a vasat meg kihajítani ténylegesen. A virtuális image-eket meg eltenni X példányban, Y különböző médián.
--
PtY - www.onlinedemo.hu
Kár, hogy a virtualizált környezet nem minden esetben működik.
Ahol törvényi előírások miatt őrizgetnek őskövületeket, ott általában nem a tudatlanság az ok.
-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
Nem biztos, hogy van olyan virtuális környezeted, ahol egy sparkot tudsz virtualizálni, vagy van valami spec hw kulcs, ok. Viszont sok esetben x86-ot őrizgetnek, aminek semmi értelme nem kéne, hogy legyen. Egy windows nt 3.x-et is be lehet virtualizálni.
Megkockáztatnám, hogy egy netware 3.1-est is.
--
PtY - www.onlinedemo.hu
Én speciel VAX-ra emlékeztem, amit még tíz (de lehet, hogy húsz) éves korában is őrizgettünk, mert azon volt az archivum. És a spéci hardver (WORM diszkek) miatt akkor sem lett volna esély virtualizálni, ha történetesen ismertük volna a linuxos VAX emulátort. :)
-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
Igen, extrém esetek mindig vannak, de virtualizálni is leginkább 7-8 éve tudunk, azelőtt még gyerekcipőben volt a dolog.
Ennek ellenére sok esetben a p2v fel sem merül, mint kiváló archiválási módszer még akkor sem, ha semmi akadálya nincsen.
--
PtY - www.onlinedemo.hu
Megkockáztatnám, hogy egy netware 3.1-est is.
Been there, done that. Szopás.
A szopást nem irigylem, de a tény, hogy megcsináltad, elismerésre méltó :)
--
PtY - www.onlinedemo.hu
Oké, virtualizálj be például Alpha procin futó OS-t meg adatbáziskezelőt :-P De mondhatnék olyat, hogy SCO Unix-on fut(ott), és hw-kulcsos alkalmazás... Esetleg AIX 4.2-4.3-on mocorgó SAP, valami 7.x-es Oracle DB-vel maga alatt - olyan helyen, ahol ez az utolsó RISC motyó, csak PC van már hosszú évek óta...
Nem írtam, hogy mindent lehet virtualizálni - épp ellenkezőleg: írtam, hogy nem lehet mindent :)
--
PtY - www.onlinedemo.hu
"Az ilyen őskövület rendszereket be kell virtualizálni" - na pont ezt nem lehet nagyon sok esetben - még x86 (IBM PC) platform esetén sem...
Megfelelő mennyiségű szívást bevállalva x86 alatt szinte bármit lehet.
Nem mondom, speckón fordított kernellel őskövület woody-t nem egyszerű, de az opensource-nak hála, mindenhez lehet találni forrást, csak kell, aki bevállalja.
--
PtY - www.onlinedemo.hu
SCO Unix? Azt azért elég nemtriviális lenne, pláne, ha még az adott hw-hez is kötött a sw, ami futkorászik rajta... Nem csak ópenszósz szoftverek léteznek ugyanis...
Lehet, hogy elkerülte a figyelmed a "szinte" szó.
Tudom, hogy mindent nem lehet, de a többséget igen.
--
PtY - www.onlinedemo.hu
Ami őskövület, az általában nem Linux és más ópenszósz motyó, meg nem x86...
NT3.5 nem őskövület? Virtualizálható. Novell is, mint fentebb írta valaki. Nem egyszerű, de meg lehet vele harcolni.
--
PtY - www.onlinedemo.hu
De, őskövület. Mint ahogy egy Dec Alpha vagy MIPS alapon felépített szerver is az - és ha ez a kettő összeért, akkor hogy a pélóba akarod bevirtualizálni jellemzően x86-os platformra? Márpedig az NT még a 4-es verzióban is futkorászott ilyen vasakon...
Milyen százalékos arányban fordult elő WNT x86-tól eltérő platformon anno, és most?
--
PtY - www.onlinedemo.hu
Voltak. De mint említettem volt, egy szimpla x86-on futó SCO Unix is elég ahhoz, hogy ne legyen igaz a "mindentbevirtuál izélünk oszt' jónapot".
Na, megint visszakanyarodtunk ide: http://hup.hu/node/126747#comment-1640861
Értő olvasás, és nem mások mondandójának félremagyarázása.
--
PtY - www.onlinedemo.hu
Azért keress rá a MySQL online backup kifejezésre! ;)
(bár lehet, hogy az már fizetős, mert mintha clusteres doksiban láttam volna... :( )
Egyébként meg ha jól veszem ki a szavaidból, az üzemeltetéssel lehetnek gondjaid. Az upgrade-ek általában nem úgy történnek, hogy volt egy rendszerem, gyártok egy újat, a régit eldobom, majd az újon próbálom valahogy összehozni az adatbázist az új verzióra.
Az LVM snapshot meg... No arra nem bíznék adatbázist, ha nem feltétlenül muszáj. Ugyan nem látom át teljesen sem a snapshot működését, sem a mysql-ét, de én tartanék némi adatbázis sérüléstől, inkonzisztenciától, ha az adatbázistól független alkatrészekre alapoznám a backupot.
Amíg egy LV-n van a teljes adatbázis, még so so... De ha több helyre van szétszórva?
-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
Ööööö, izé - nem nekem van problémám :)
Esetemben nem tudunk beszélni olyan méretű adatbázisról, ahol 24 óra ne lenne elég egy dumpból való visszatöltésre - hogy ez szerencse-e, vagy átok, azt passzolom.
Én a topikindítóból azt vettem ki, hogy pl. anno a mysql adatbázis külön disken volt a rendszertől, és azt eltették, a rendszer azóta a tűz martaléka lett (akár metaforikusan is). A DB megvan, és életet kell bele lehelni, de ahová visszatennék, az már újabb mysql, és bele kéne integrálni.
Amit fentebb az upgrade-ről írtam, erre a scenariora vonatkozik, így kell érteni.
Upgrade-elni amúgy is tesztkörnyezeten szoktam előbb, ha kell ilyesmit csinálni.
Az LVM kérdésbe nem szólnék bele, nem használok célzottan lvm-et ilyen célra, de a snapshot logikusnak tűnik - bár, ha eddig kell fajulnia a dolognak, akkor VM snapsot, és azt mentjük.
--
PtY - www.onlinedemo.hu
Az LVM-snapshot teljesen jó. Eléggé alaposan gyúrt db, 7*24-ben kell, hogy menjen, ergo aktív-passzív fürt, alkalmazás felváltva olvas a két db-ből, írni csak egy helyre ír (a replika késleltetése belefér, illetve van rá megoldás az alkalmazásban). Slave alatt széthullott a RAID-tömb, vagy "csak" elhasalt/szétcsúszott a replikáció.
Slave-et a replikáció lelövése után az lvm-es snapshotból rsync-kelve, majd a binlogot rátolva tökéletesen ment tovább az élet... Nem, nem egyszer, hanem sajnos egy raid-kontroller kontra ssd összeférhetetlenség miatt jópár alkalommal tesztelve. Úgyhogy az LVM-es snapshot-tól nem kell félni - szerintem...
"dump visszatöltése újragenerálja az indexeket"
Ettol lesz jo lassu.
"Ha meg binális logokat használsz (tranzakciós logok), és nem áll a mysql-ed, amikor lemented, még adatvesztésed is lesz."
Akkor nem, ha egy sessionben 'FLUSH TABLES WITH READ LOCK' -ot tolsz, meg asszem van a binaris logok flusholesere is van parancs. Nyilvan a shell script teljesen alkalmatlan erre a feladatra, de valami masik scriptnyelv, amiben nyitva lehet egy SQL kapcsolatot tartani (PHP, Perl, Python, Ruby) teljesen alkalmas az ilyesmire.
--
Nem (csak) ettől lassú. Újraépíti az egész adatbázist, ha nem tévedek. Magyarán amikor egy dump-ból töltesz vissza, akkor minden egyes sorra kiad egy-egy insertet.
Egyébként nem tudom, mysql-ben tiltható-e az index, ha igen, akkor a dump betöltésének idejére célszerű ezeket letiltani és újragyártani őket a betöltés után.
"Némileg" gyorsabb szokott lenni (oracle és DEC Rdb esetében tesztelve :) )
-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
"minden egyes sorra kiad egy-egy insertet."
Ha nem hasznaltal --extended-insert kapcsolot, akkor igen. Ha hasznaltal, akkor jo nagy adagokban tolja be a sorokat, tobbszaz sort egy-egy inserttel.
Tilthato az index. tiltja is. De a tabla betoltese utan kiadja rogton az index ujrakalkulalasara a parancsot a dump maga.
Egyebkent meg mindegy, mikor lesz kurva lassu a gep. Maga az index ujrageneralas egy 20-30G -s tablanal _nagyon_ sok tud lenni.
--
Nem, nem mindegy.
Ha aktív indexeid vannak és abba szúrsz be új sorokat, az nagyságrendekkel lehet lassúbb, mint ha egy index nélküli táblát írsz és azt indexeled.
(még mindig: én csak Oracle-t és Rdb-t láttam nagy adatbázissal, csak arra alapozva írom)
-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
Persze, hogy attól lassú, meg attól, hogy újra kell allokálnia a disket, nem fájlcache-t használ csupán, emiatt magasabb az io igénybevétel, és még lehetne sorolni, hogy mi mindentől lassabb. Ezen nincs is vita.
--
PtY - www.onlinedemo.hu
"Ha meg binális logokat használsz (tranzakciós logok), és nem áll a mysql-ed, amikor lemented, még adatvesztésed is lesz."
Ezt tudná valaki indokolni?
Mert eddig úgy tudtam, ezek a logok (a'la Oracle RDBMS redo logs) arra valók, hogy megakadályozzák az adatvesztést, illetve, hogy konzisztens maradjon az adatbázis(*).
Őket közvetlenül nem kell (nem szabad/illik) menteni, de épp ezek biztosíthatják, hogy képes legyél online backupot futtatni.
Legalábbis átfutva a mysql doksijának erről szóló részén, nekem ez jött le. Akkor mi itt az igazság?
* - kissé már bizonytalan vagyok, évekkel ezelőtt láttam utoljára éles szervert, k.sokat felejtettem. :(
-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
Ez teljesen így van, és pont ezért van az, hogy az adatfájlok másolása menet közben nem ajánlott addig, amíg ezek a logok nincsenek belegyúrva az adatbázisba, mert az csak ezekkel együtt konzisztens.
A különböző Oracle által támogatott backup toolokat ez a probléma nem érinti.
--
PtY - www.onlinedemo.hu
Oracle esetében ez úgy működik, hogy az épp mentés alatt álló táblateret backup módba teszem, másolom, backup mód kikapcs.
Köv. táblatér, goto 1, míg végig nem értem mindegyiken.
Eközben ezekben a logokban gyűlnek a változások, ha valamelyik megtelik, akkor megy archivumba és keletkezik egy üres.
Szóval oracle alatt ehhez még spec. tool sem kell.
Ezért értetlenkedtem.
-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
Félreértés: a MySQL az Oracle terméke - így értettem az Oracle által támogatott toolt.
Vélhetően működik, amit írsz, csak ha van valami tényleges bug-od, és nem tudod visszatölteni emiatt az adatokat, akkor a support el fog hajtani, mert nem rman-nal mentettél.
--
PtY - www.onlinedemo.hu
Tudom, hogy az oracle tulajdonában van.
Egyébként megtörtént, nem hajtott el.
Csak két hétig szopattam az indiai gyereket, mire rájöttem, hogy én keféltem el valamit. Mert neki nem tűnt fel. :D
-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
Mázli. 1st levelen voltál - gyanítom.
--
PtY - www.onlinedemo.hu
Nem mázli, szívás. Ha elhajtanak, akkor valószínűleg nem várom tőlük a választ, hanem tovább nézegetem, hogy mivel van gond és akkor két héttel hamarabb végeztem volna egy munkával.
A 1st levelt nem igazán tudom értelmezni.
Náunk nem volt, Oracle-nél meg... én a metalinken jeleztem, hogy gáz van, ők válaszoltak, levelezgettünk egy darabig és a végén szóltam, hogy inkább hagyja a fenébe, megoldottam. :D
De hogy különböző szintű supportjuk lett volna, arról nem tudok.
-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
A 1st level support az, ami megoldja a 'known issues' jellegű hibákat. Ha neki nem megy, mert beazonosította, hogy nincs hozzá neki howto, akkor löki tovább a 2nd levelre. És így tovább.
--
PtY - www.onlinedemo.hu
Oracle esetében nem tudok mit kezdeni a 1st level témával. :)
Különösen az említett társalgást követően.
Annyira nem értette, hogy mi van és volt náluk ilyen, hogy 1st, 2nd, 3rd level, akkor miért nem lökte tovább?
-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
Mert csak akkor tehetei, ha megértette a problémát, és biztosan tudja, hogy ő nem segíthet. Ha továbblöki, és kiderül, hogy neki kellett volna megoldani, akkor szétrúgják a zrityóját.
--
PtY - www.onlinedemo.hu
Magyarán már akkor is az "inkább szopjon az ügyfél, ha már hülye ahhoz amit csinál" volt a jelszó? :D
-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
Minden support így csinálja. :(
--
PtY - www.onlinedemo.hu
És addig nem is foglalkozik érdemben a nyomoroddal, amíg azt nem látja, hogy minden patch fent van. Ami production környezetben nem mindig triviális.
Perconat kell hasznalni, ott az xtrabacup meg az innobackupex -> szerintem mennek mariadb alatt is.
MyISAM-ra meg ott a mysqlhotcopy.
--
Az rman azért szerintem többet tud.
Persze - de nem is egy sulycsoportban jatszik a ketto.
--
Sem minőségben, sem teljesítményben, sem árban, sem supportban.
--
PtY - www.onlinedemo.hu
Az elso kettovel kapcsolatban vannak ketelyeim, a masodik kettovel meg egyetertek.
--
Hát ami igaz, az igaz, mióta mindent Indiában fejleszt az Oracle, romlik a minőség, de azért még ott van.
A teljesítmény meg nyilván nem weboldalak, és pármilliós rekordszámú adatbázisok alatt értendő, ahol minden táblára van 1 - max 2 - index.
--
PtY - www.onlinedemo.hu
Igy mar egyetertek.
--
Milyen adatbazis, InnoDB vagy MyISAM?
5.0-s mysqlt tudsz letolteni, az ala be tudod huzni az adatokat (Bemasolod a mysql datadir ala) onnan tudsz csinalni mysqldumppal dumpot, vagy felupgradeled 5.5-re, majd megint atmasolod az adatokat, etc.
http://dev.mysql.com/downloads/mysql/5.0.html
Gentoo mysql upgrade-re van szerintem hasznos step-by-step guide. Persze a gentoo specifikus részeket át kell ugrani. A parancssori paraméterekhez meríthetsz ötleteket. Meg ugye neked csak a fájl-ok vannak meg. Ha azokat bekopizod, akkor szerintem meg lehet csinálni.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
Upgrade-et futó rendszeren lehet csinálni. Ez nem az IMHO.
--
PtY - www.onlinedemo.hu
Atmasolof a mysql datadir-t majd lejetszod az upgrade-soran levo teendoket. Ha mindenigaz nem tobb, mint a mysql_upgrade futtatasa.
tompos
A topik kapcsán belenéztem valami doksiba, ott azt írták, hogy upgrade-kor nem szabad(???) kihagyni a fő verziókat.
Csak az nem volt tiszta, hogy 5.0 -> 5.5 közti három vagy négy verzió "fő"-nek számít-e vagy sem. Mert mintha épp azzal példálództak volna, hogy 5.0-ról előbb 5.1-re stb.
-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
Ennem tudom, csinalja az, ahogy a debian csinalja vay csinalja azt, ahogy a musql official doksi mondja. A lenyeg, h mukoddik, nem kell beszarni tole.
tompos
Csak arra céloztam volna (már amennyire értem, hogy mit írsz :D), hogy ha van egy 5.0-s adatbázis és egy 5.5-ös szerver hozzá, ott elég esélytelen az upgrade, amennyiben valóban meg kell lépni az 5.0->5.1->5.x->5.5 sort.
-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
Akarsz fogadni?
De megegyszer, probalja ki az alapjan, ami van es kiderul...
tompos
Működik nagyobb verzióugrásokkal is. Az 5.5 alá oda kell másolni az 5.0-s adatfájlokat, majd mysql_upgrade. Ez elvégzi a szükséges konverziókat azokon a táblákon, ahol szükséges. Utána kell még egy mysql restart és kész is.
Nem tudom, ezt direkt csináljátok?
Mondom: "amennyiben meg kell lépni a..."!!!
Ahogy előtte azt is említettem, hogy nem teljesen tiszta, mit értettek főverzió alatt x.n-ből az x vagy az n számít "fő"-nek? Ha jól értelek, akkor az x, ahogy az normálisan elvárható.
-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
MySQL 4-rol 5-re volt egy binaris formatum valtas, azert mondjak azt, hogy nem szabad kihagyni a kozbeeso verziokat.
Azota egy dolog tortent, maga a mysql nevu adatbazis bovult ki asszem 3 uj tablaval, a mysql_upgrade gyakorlatilag ezeket a tablakat potolja.
Egyebkent meg van mentes a dologrol, egy probat meger, nem?
--
OFF: Ez is egy nagyon tanulságos és hasznos téma.
Kismillió hozzászólás, egyik bölcsebb mint a másik. Aki viszont feldobta, eltűnt!?
Mi lett a megoldás?
* Én egy indián vagyok. Minden indián hazudik.