Pokrocila replikace v MySQL

12.11.2007 12:16 | Přečteno: 2208× | PC / IT

Tak jsem se take musel ponorit do taju databazoveho systemu MySQL, abych se pokusil vyresit nasledujici problem.

V soucasne dobe pouzivam 2 servery, jeden jako master, druhy jako slave. Kazdy zaznam na master server se replikuje na slave, proste klasicka replikace.

Jenze data pribyvaji, cca 3-10 zaznamu za minutu na master server, to vse replikovano na slave (celkem asi 35 milionu zaznamu v ruznych databazich a tabulkach). Po diskusi typu "vsechna data jsou dulezita, nektera vsak jeste dulezitejsi" se doslo k zaveru, ze data starsi nez rok nejsou tak dulezita, presto jejich odstraneni nepripada v uvahu. Proto bych chtel dojit k nasledujicimu reseni:

Pridat treti server, na ktery by se opet replikovaly vsechny zaznamy (data or roku 2004, kazda tabulka obsahuje sloupec timestamp). Na master serveru nastavit, aby se kazdy den (napr. v pulnoci) smazaly data starsi nez jeden rok (ve vsech databazich, ve vsech tabulkach). Potom bych mel nejdulezitejsi data na master i slave serveru vzdy do stari jednoho roku, na tretim serveru pak vsechny, vcetne tech nejaktualnejsich.

Bohuzel nejsem v MySQL tak zbehly, tak jsem se chtel zeptat, zda uz nekdo podobny pripad neresil, popripadne me nakopnul spravnym smerem. Problem replikace je, ze replikuje opravdu vsechno, tedy nevim, jak nastavit presouvani dat na treti server, a jak resit automaticke mazani starsich dat nez jeden rok (nejspis pomoci nejake stored procedure?)...

Nebo lze tento problem resit uplne jinak?

       

Komentáře

[Filip Jirsák]

a master serveru nastavit, aby se kazdy den smazaly data starsi nez jeden rok.

Pokud nemáte problém s místem, nedělal bych archivaci každý den. Zbytečně budete fragmentovat databázi a nutit jí stavět nové indexy (nebo naopak bude používat zastaralé indexy). Perioda jednou za měsíc by podle mne mohla stačit.

[Jakub Suchy]

A z ceho vyplyva potreba mazat starsi data? Moc velke tabulky, ktere jsou pak pomale, nebo nedostatek mista na disku?

To druhe se da vyresit i jinak, nez mazanim a to prvni, to bych vyresil treba tak, ze bych vytvoril vzdy neco jako "old" tabulku, ktera by mela identickou strukturu jako hlavni, ale odlejvala by se do ni data starsi nez rok. Vse na jednom serveru, ale v jine tabulce, tudiz nezpomaluje pri SELECTech...

[Michal Čihař]

Nebo odvážně nainstalovat MySQL 5.1 a udělat to přes oddíly. Vliv na výkon to má stejný, jenom člověk nemusí myslet na to, ve které tabulce zrovna tyhle data jsou.

[RapMan]

Mazani starych dat chci realizovat kvuli velikosti tabulek, potom trva zaloha neprimerene dlouho, stejne tak jeji obnova. To prelevani dat do stare tabulky by slo vyresit pomoci stored procedure?

[xkucf03]

bych vytvoril vzdy neco jako "old" tabulku, ktera by mela identickou strukturu jako hlavni, ale odlejvala by se do ni data starsi nez rok

Nebo použít partyšny v Oraclu

[RapMan]

Co jsem tak studoval, tak reseni s old tabulkami by bylo asi nejpruchodnejsi, s tim, ze by na master serveru byly typu federated a smerovaly by na treti server, na druhy server by byla nastavena full replikace, na treti server pak replikace bez *old tabulek.

[CET]

No, pokud to dobre chapu, jedna se ti o omezeni replikace na treti slave server tak, aby provadel pouze INSERT a UPDATE, ale zadny DELETE. Kouknul jsem zbezne do helpu, ale nasel jsem jenom ignorovani celych tabulek.

Mozna by bylo lepsi resit tvuj problem zalozenim ruznych tabulek pro ruzne roky (pokud je to samozrejme mozne s ohledem na provazanost dat). Samozrejme se mi tohle reseni taky nelibi, ale jinak asi tu replikaci delat nebudes moct.

[RapMan]

Presne tak, ze by se na ten treti server nereplikoval prikaz DELETE. Ale to asi z hlediska principu replikace neni mozne... Zalozeni tabulek pro ruzne roky se mi nelibi, rad bych zachoval stavajici strukturu.

[CET]

Hele, prece jenom se mi podarilo neco vygooglit. Je to presne stejnej dotaz, jako mas ty:

http://forums.mysql.com/read.php?12,2505,2505#msg-2505

Prvni odpoved navrhuje reseni, ktery me taky napadlo trosku jinak. Pro replikaci na slave udelat ucet, kterej bude mit jenom pravo select, insert a update, ale ne pravo DROP a DELETE - jenze bohuzel slave SQL se pripojuje na master a taha si zmeny sam a ty pak provadi jako super user, takze tam ho moc neomezis. V prizpevku navrhuje delat replikaci vlastni silou, ze pri kazde zmene se pripoji aplikace na oba servery a provede SQL. A protoze na slave nebude mit prava na drop a delete, tak se nic nesmaze. Ale to neni klasicka replikace.

Druha odpoved ale ukazuje nevyhodu, tak nevim, jestli by to opravdu slo nebo ne ... Musis to promyslet z pohledu cely funkce DB, jestli je mozny, abys nejaky mazal nejaky stary zaznam a vytvarel novy, ktery muze mit v nejakem unikatnim poli stejnou hodnotu jako stary smazany zaznam - pak by totiz replikace na slave selhala z duvodu, ze stary zaznam nebyl na 3.slave smazan.

Celkove mas asi smulu a budes muset zustat u kompletni replikace a nebo delat dumpy s podminkou roku.

[vlasta neubauer]

možná by pomohlo, kdyby tabulky na trojce byly typy ARCHIVE. uz název k tomu docela vybízí..

tam určitě nejde mazat, ale s updatem si nejsem jist. nebo třetí server vynechat úplně a využít jenom ARCHIVE tabulek