🚀 go-pugleaf

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.

Tänud ette,

WK