🚀 go-pugleaf

Gunnar Koppel wrote:
> Terr!
> 
> Selline inetu lugu juhtus, et sai tehtud andmebaasi kasutavates skriptides
> rida muudatusi (�kshaaval, testitud ja kasutusse antud) ja siis ka tehtud
> �hte mysql-i tabelisse selline muudatus:
> 
> alter table xtabel add ms enum('e', 'j') not null default 'e';
> 
> Toodud muudatus oli ettevaatav, st et �kski skript seda ei vajanud, uus
> veerg tabelisse oli vajalik edaspidiseks. Lisaks oli veeru nimi unikaalne
> k�igi kasutatavate andmebaaside piires, st et polnud v�imalik ka tabelite
> lohaka �hendamise korral segadust tekitada.
> 
> P�rast seda muudatust hakkas pihta seletamatu anomaalia: mysql tekitas �ha
> protsesse juurde, load kasvas taevasse ja mysql-iga suhtlemine polnud
> v�imalik, masin ise oli tatine. Kui mysql-ile restart teha, siis m�nda
> aega oli k�ik OK, aga tasapisi (s�ltuvalt kasutamise aktiivsusest) olukord
> taastus. Kuna mysqlis tehtud muudatus oli niiv�rd s��tu, j�i kahtlus ikka
> skriptidele, aga mysqli logidest ei leidnud mingit �hte konkreetset
> skripti, millega h�da kaasneks. K�ll aga j�i silma, et mitmete skriptide
> loodud �hendused j�id p�rast viimast p�ringut pikaks ajaks rippuma ja
> �henduse katkestamine toimus alles palju-palju hiljem. Ja kui ka lihtne
> 'insert' tabelisse (mitte muudetud tabel, isegi teine baas)  
> k�sureakliendi kaudu mysql-i t�itsa tummaks v�ttis, siis hakkas s�venema
> kahtlus, et kuidagi on k�ige taga tabelisse tehtud muudatus.
> 
> Ja k�sk:
> 
> alter table xtabel drop ms;
> 
> l�ikas m�dapaise lahti ja k�ik toimib j�lle ladusalt. Mingit �petlikku
> j�reldust �laltoodust kahjuks teha ei suuda, ka oleks vaja nimetet veerg
> ikkagi tabelisse tekitada. 
> 
> mysql oli alguses 3.23.49 (debiani pakiversioon), jamade k�igus uuendasin
> 4.0.18 peale, mis aga olukorda kuidagi ei muutnud.
> 
> Iga selgitav vihje on teretulnd.
> 

Kas mysql konfis v�i k�sureal oli log-slow-queries parameeter? Serveri enda
logist sa aegan�udvaid p�ringuid ei n�e.
show processlist k�suga t�en�oliselt protsesse juba uurisid aga uuri, kas
rakenduses ei ole p�ringut 'SELECT * FROM xtabel ...' ja mingil p�hjusel
j��b rakendus selle uue v�lja peale andmete t��tlemisel rippu v�i hakkab
uusi p�ringuid genereerima. 
Lihtsa insert lause rippuma j��mine viitab sellele, et tabel oli lukus,
protsessidest peaks n�ha olema, mis selle tabeliga tehakse.
Mina alustaks:
1. Vaataks, mis p�ringud j��vad pikaks ajaks staatusesse 'LOCKED'
2. Vaataks, mida 'slow query' log n�itab
3. Kui kahest eelnevast probleemi p�hjust ei leia, paneks mysql-i k�iki
	p�ringuid logima ja vaataks ega midagi ebatavalist silma ei hakka.
4. Kui targemaks pole saanud, prooviks lisada sama v�lja
	teise nimega ja vaataks, kas siis samuti probleeme tekib(v�imalik, et rakenduse
	jaoks siiski on sellel ms-l mingi eriline t�hendus, ms pole unikaalne ja
	lohaks join teeb pahandust vms.)
5. Kui ikka targemaks ei saa, siis t�staks andmebaasid m�ne teise OS-ga
	masinasse ja vaataks, kuidas mysql ennast seal �lal peab. Kui probleeme
	pole, siis kontrolliks, kas OS-l on ikka viimased lapid peal ja kui on,
	siis prooviks mysql-i ise kokku kompileerida.