darksign Posted October 8, 2008 Report Share Posted October 8, 2008 Kā ir ar mysql un kolīzijām, cik bieži saskaraties ar tām utt... Man uz viena servera kolēģim, tik tikko uz mysql 4 versijas (precīzāk nezinu...) notika kolīzija, un datubāzi ne ar repair, ne fix ne tur visādiem citādiem nevar salabot.. jātaisa jauna... Bet uztaisot, vienalga situācija vinjam esot atkārtojusies pie liela apjoma noslodzes. Konkrētajā datubāzē tiek glabātas sesijas id utt... 1) vai ko tādu esat novērojuši vispār, un vai tādas problēmas pastāv arī 5 vai 6 mysql versijā... (lai gan teorētiski tas ir iespējams ļoti maz, taču ja ir iespējams, tad pēc mērfija likuma... gadās arī praktiski :D tapēc programmējot pienjemt to sliktaako variantu) 2) Ja kāds strādā vēl ar 4 versiju, tad ko iesakat lai mazinātu koliiziju iiespeeju? 3) Un kas līdziigs buutu jaadara 5.1 mysql lai jau saakotneeji izvairiitos no koliizijaam projekteejot jaunas db ? 4) hmm interesanti buutu zinaat, ko dara dr**.lv vai kaads cits lielais useru portaals uz mysql kursh straadaa glabaajot sesijas datubaazee.. ? gaidīšu visus viedokļus, gan pēc pieredzes, gan apstrakti teorētiskos :) (nu normas robezhaas, lai neaiziet uz offtopic ;) ) Link to comment Share on other sites More sharing options...
bubu Posted October 8, 2008 Report Share Posted October 8, 2008 Kas vēl par mysql kolīzīju? Es zinu, kas ir hešfunkcijas kolīzija. Bet mysql kolīzija? Link to comment Share on other sites More sharing options...
Aleksejs Posted October 8, 2008 Report Share Posted October 8, 2008 Ja nu vienīgi domāts, kad autonumber stabiņam piešķir RANDOM... Nevis Autoincrement... Tad varētu rasties kolīzijas, bet laikam drīzāk domāta tabulu nobrukšana nevis kolīzijas, vai ne? Link to comment Share on other sites More sharing options...
Roze Posted October 8, 2008 Report Share Posted October 8, 2008 4) hmm interesanti buutu zinaat, ko dara dr**.lv vai kaads cits lielais useru portaals uz mysql kursh straadaa glabaajot sesijas datubaazee.. ? dra.lv neglabā sesijas mysqlā - ir izkliedēta in-memory sesiju storage, kas paļaujas uz PHP "unikalitāti" <g> Link to comment Share on other sites More sharing options...
Klez Posted October 8, 2008 Report Share Posted October 8, 2008 ko mysql logos raksta ? Link to comment Share on other sites More sharing options...
darksign Posted October 8, 2008 Author Report Share Posted October 8, 2008 (edited) Ja nu vienīgi domāts, kad autonumber stabiņam piešķir RANDOM... Nevis Autoincrement... Tad varētu rasties kolīzijas, bet laikam drīzāk domāta tabulu nobrukšana nevis kolīzijas, vai ne? jā.. nobrūk tabulas.. (nezinu kā viņu tur sauc pareizi, tapēc pateicu mysql kolīzija...) Nezinu vai konkrētajā gadījumā lieto random, vai autoincrement, bet pēc tava teiktā saprotu, ka ja lieto autoincrement, tad tas nav iespējams ka nobrūk tabula šādas kolīzijas dēļ, ja? (nu vispār būtu jau loģiski ar... :D ) Mēģināšu noskaidrot kas un kā ir.. vēlāk ziņošu. dra.lv neglabā sesijas mysqlā - ir izkliedēta in-memory sesiju storage, kas paļaujas uz PHP "unikalitāti" Roze, vari pastāstīt kaut ko vairāk? tb. tas ir ka glabā mysql tabulā uz Memory tipa tabulu, vai kaut kas cits? vari iedot linku kur palasiities? :) Un ko domāji ar php "unikalitāti"? Edit: p.s. error ko dod ārā mysql: DB function failed with error number 1016 Can't open file: 'mos_session.MYI'. (errno: 145) SQL=SELECT session_id FROM mos_session WHERE session_id=MD5('70b4f83366d712345bf5892044bc78a') SQL = SELECT session_id FROM mos_session WHERE session_id=MD5('70b4f83366d712345bf5892044bc78a') shitaa te dara viena no mambo versijaam.. man patreiz iskataas ka tur vispaar nav kaut kaads atseviskjs id, bet vienkaarshi sessijas id.. principaa kaut vai viena kolonna tur buutu, bet lieta taada, ka laikam meegjina ierakstiit ar vienaadu id pirms taa error, un tad nezinu kaadaa sakaraa tas laikam izdodas (piem, straadaajot tredos.. abi procesori ir paarliecinaati, ka zin ko dara, un meegjina ierakstiit, ieraksta, un sabojaa faila struktuuru). izlasiiju, ka arii citiem taa meedz gadiities un staav pie 4.2.2 versijas bugiem... bet nu vienalga, nav jautaajums ko dariit peec tam, bet pirms tam, lai taa situaacija taada nebuutu. Jo kad useris ielogojas vieniigais ko par vinju zinam ir sessijas id, un ja uz 2 pc ir vienaads sesijas id, vai kaut vai uz vienu un to pashu pc tiek atveerti vairaaki sql kanaali... nu nezinu vai saprataat manu domu, bet kaut kaa taa... ja dabuushu pieeju mysql logiem, un tabulaam, tad jau buus vairaak info.. un zinaasim vai mans koleegjis, vai mambo salaidis griistee, vai arii tur mysql kljuuda... Edited October 8, 2008 by darksign Link to comment Share on other sites More sharing options...
Roze Posted October 9, 2008 Report Share Posted October 9, 2008 Šādām lietām neizmanto MyISAMi! Vai nu lieto InnoDB vai vēl labāk jau minēto MEMORY tipa engini tabulai. MyISAM ir ātrs tikai uz viena veida kverijiem proti vai nu SELECTiem vai INSERTiem ... Miksētā versijā kāda ir sesiju storage (noklusēti katras skripta sesijas sākumā ieraksts tiek nolasīt / katras sesijas beigās dati tiek wraitoti) MyISAMi nedarbosies visai korekti jo notiek table level locking... t.i. tajā brīdi kad notiek SELECTs nevar notiek INSERTI utt.. Šī nav kolīzija : MySQL error code 145: Table was marked as crashed and should be repaired Proti MyISAM tabula ir noplīsusi .. kas tavā lietotajā 4.0.x MySQL versijā gadijās diezgan bieži... Ieteiktu upgreidoties uz 5.1.x ... Roze, vari pastāstīt kaut ko vairāk? tb. tas ir ka glabā mysql tabulā uz Memory tipa tabulu, vai kaut kas cits? vari iedot linku kur palasiities? :) dra.lv izmanto memcache (kaudzi ar memcache instancēm) sesiju storagei.. Kopš kaut kādas 2.x pecl 'memcached' ekstensijas PHP ir iespēja pieslēgt memcache kā sesiju storage transparenti (t.i. nav jāraksta sesiju handleris ( http://lv.php.net/manual/en/function.sessi...ave-handler.php ) kā iepriekš) Un ko domāji ar php "unikalitāti"? Nu unikālu sesijas ID ģenerēšana paliek PHP ziņā ( session.hash_function ) http://lv.php.net/manual/en/session.configuration.php Link to comment Share on other sites More sharing options...
Recommended Posts