OT: Divoke chovani MySQL

[Jaroslav Lukesh]

Skotské přísloví: nespravuj, co není rozbitý

neboli nevrtej do toho, co funguje.

Když mám něco co mi funguje, začnu křečkovat identický hw na kterém to jede. 
A protože jsem nebyl sám :-D tak se u nás všecko zvirtualizovalo. S tím jsou 
zase jiné problémy u databází (nejen relačních) a tím jsou časové řezy 
přidělené strojům. Prostě po lanu dorazí požadavek ve stejný čas - ten stroj 
si to myslí a jsou problémy s transakcema, že měly stejný timestamp (problém 
podobný starým US ústřednám, viz kolaps tel. sítě koncem 80.). Tak to bylo 
pod vmarem, mezitím nějaké věci byly poupraveny (rozuměj zpomaleny), aby k 
těmto problémům nedocházelo (během roku průměrně jednou za měsíc ale stejně 
dojde k nakopnutí databáze, je to ale pravděpodobnější v době extrémních 
špiček 2x do roka viz dále). Teď to jede na Xenu a ikdyž jsem to trápil tak, 
že na vmwaru by šly blbě hodiny, tak xen (citrixí) šlape tak nějak plynuleji 
a ani problém s hodinama zatím nebyl objeven.

Tak to zkuste taky virtualizovat a budete mít po problémech s hw a novými 
OS.

----- Původní zpráva ----- 
Od: "Jan 'yanek' Bortl" <yanek na ya.bofh.cz>


On 4.7.2011 19:55, HW CNCnet.info wrote:
> Pretahnul jsem binarky, ale to jsem pocital, ze muze byt spatne - proto
> jsem provedl kopii do nove struktury pres:
>
>  insert into ... select ...
>
> cekal jsem ze tohle by to melo eliminovat
>
Udelejte spis mysqldump > soubor; pote smazat vsechna data a pak zpet: mysql
< soubor.

Jinak jestli vas to (ne)uklidni, tak drasticke zhorseni vykonu mezi
5.0.koliksi a 5.1.koliksi jsem zaznamenal rovnez, bohuzel se to projevuje
nesmyslnyma zamkama (jeden select lockne tabulku(!) na par minut az
nekonecne minus ma trpelivost).