Pred jiz delsi dobou (2-3roky) jsem takto chtel provadet replikaci nekolika mysql databasi na zalozni server. Uz presne nevim na cem to ztroskotalo, ale mam pocit ze replikace mela mnoho omezeni a v pripade ze na masteru se provedla nejaka replikaci nepodporovana operace, tak se replikace rozpadla. Pokud bude mit clanek pokracovani tak bych ocenil informace tykajici se prave omezeni replikace a nejake poznatky z realneho pouzivani.
Clanek je prilis strucny, je to uplne minimum, ktere je potreba nastavit pro rozbehnuti mysql replikace, nepopisuji se tu typy replikace (row type, statement, mixed apod.), rozdily v moznostech nastaveni u jednotlivych verzi MySQL (napr. 5.1 a 5.5) a dalsi detailnejsi a dost podstatne informace. U tohoto typu replikace je cela rada uskali, bylo by dobre asi zminit alespon nektera z nich. Je to asynchronni replikace, velky problemem je konzistence dat, chybi mi tu nastineni moznosti jak to resit. Tento typ replikace ma svoje limita, bylo by dobre uvest, pro jaka data a projekty se tato replikace hodi, kdy radeji sahnout namisto toho po MySQL ndb clusteru (multimaster), Percone (multimaster) nebo treba Postgres, ktera ma daleko lepe vyresenou replikaci master-slave. V potaz beru pouze open-source a jeho derivaty.
Podobne, ale mnohem detailnejsi clanky lze najit na howtoforge. Na zaver dodam, ze autorovy clanky o Redmine byly mnohem kvalitnejsi.
Strucny clanek je slabe slovo, svoje poznamky o nastavovani replik pro mysql mam mnohem delsi.
Skoda ze zde neni alespon zminka o nejakem pokracovani, treba by se hodilo uves i master-master replikaci ktera se od te master-slave resi jen nepatrne.
Dost podstatna informace jak ze Slave udelat Mastra zde take chybi...
ps replikace je opravdu tragedie pravidelne to vyhuci a clovek to pak musi nahazovat znova, prikladem muze byt posledni update na debianu ktery replikaci rozbil pouhym security updatem mysql-5.1 (5.1.61-1)
Než MySQL ndb cluster, tak to radši několikanásobnou Master - Slave replikaci. Osobní zkušenost. Asi měsíc jsem s tím zápasil. Podle mě je tam víc problémů než přínosů. Ano, je to "sakra" rychlé, ale to je tak všechno... Je to asi rok co jsem to zkoušel (nějaká verze 7.1.9). Teď jsou na tom možná lépe.
Co se týče chodu MySQL replikace, tak tu máme v produkčním nasazení (cca 20 databází pro různé účely, velikost pár GB) a spolehlivost dobrá.
Návodů, jak rozjet replikaci na MySQL je na internetu plno a nemyslím, že má smysl psát další. Spíš by pomohlo, kdyby se někdo fundovaný rozepsal o problémech a zejména jejich řešení ohledně replikace na MySQL. Replikace se snadno rozpadá, slave nestíhá, master-master je kvůli tomu dost o data, při replikování jen vybraných databází replikaci shodí jakýkoli alter table, když se explicitně neuvede k tabulkám jméno db atd.
Doporucuji pouzivat Maatkit, pomoci nej jsem resil konzistentnost dat na slavech a v pripade rozbiti replikaci napise konkretni tabulky ktere jsou v nekonzistetnim stavu. Nasledne jsem je uz pres mysqldump za chodu replikace opravil. Da se pouzit primo i utilita na synchronizovani dat. Ja to cele delal pomoci skriptu, ktery checkoval stav replikaci a v pripade problemu odeslal i e-mail s nekonzistenci a naslednym resenim (reseni bylo mysqldump s parametry atd., takze stacilo jen spustit v konzoli a problem vyresen...).
Prave ze da, v to je to vynikajici nastroj. Akorat Maatkit uz neni uplne up-to-date, aktualne pouzivejte Percona Toolkit.
Tento clanek je IMHO zbytecny. Na internetu jsou tisice podobnych tutorialu, ale jen velmi malo jich zminuje uskali, ktere tady v diskuzi lide zminuji. Napriklad pokud pouzijete 5.5 a row-level replikaci, dost pravdepodobne vam pobezi 100krat stabilneji nez statement-level na 5.1, nedejboze 5.0. Za posledniho pul roku na 5.5 jsme meli jediny vypadek replikace a byl zpusobeny chybnou administraci.
BTW, doporucovat v clanku replicate-do-db je blbost. Bude to fungovat, dokud neudelate update databaze.tabulka ...... bez zvolene default DB. Pak budete uz jenom brecet, ze mate jiny data na slave nez na masteru.
Pokud chce nekdo pouzivat replikaci v produkci a nemit z toho boleni hlavy, doporucuju nejakou knizku, treba High Performance MySQL 3rd edition od Percony, nebo MySQL High Availability (O'Reilly).
Ve verzi MySQL 5.6 se konecne administrace replikace zjedodussi, ale stable verze bude az za rok.
U MySQL je fajn, ze ho pouziva dost lidi, ale na druhou stranu 99% clanku na internetu pisou lidi s minimem zkusenosti.
Panove, nebudte takovi drsni :-) Clanek je dobre napsany a obsahuje vse, co by mel. Nevim, jak jste zkuseni Vy, ja mam za sebou jen 15 let jako DBA, a ruku na srdce - MySQL a replikace k sobe nejdou a nepujdou. Ve srovnani s komercnim resenim je to stale lepsi, nez nic, ale Oracle si nebude kalet do vlastniho "hnizda", aby na replikaci MySQL opravdu maknul. Jiz zminena nekonzistence dat je ubijejici, stejne jako neproveditelne SQL query na strane slave; chybi jakakoliv zpetna kontrola, interni master-master na urovni dat, ne binarnich logu. Takze nechtejte prosim po MySQL a potazmo autorovi zazraky a pokud touzite po vice informacich a boji s vetrnymi mlyny, mrknete do oficialni dokumentace, pripadne do "MySQL profesionálně - Optimalizace pro vysoký výkon", kde je replikaci venovano nekolik stranek.
-Ge-
Načasování nemohlo být lepší, nad tímhle přemýšlím už delší dobu a teď mám i český návod, super.
Jen velmi důležitý dotaz - slave nepoběží vždy, je to desktop, takže běží pár hodin denně. Co se bude dít v případě, že slave zrovna nejede? Vzhledem k tomu, že si slave sahá pro data (ne, že je master posílá), tak asi k synchronizaci dojde po spuštění slave PC, je to tak?
Takže když nepotřebuju dělat zálohu po každé změně, ale jen namátkově, tak mi to bde fungovat bez problémů i s vypínáním slave?
(jde o domácí mini server, MySQL databáze obsahuje pro mě důležitá data, ale ztrátu dat za posledních 24 i více hodin, kdy slave neběžel, bych přežil)