Replikace / redundance na dvou serverech

Martin Hudec corwin at aeternal.net
Thu Oct 27 08:18:19 CEST 2005


Ahoj Miroslav,


On Wed, Oct 26, 2005 at 10:22:29PM +0200 or thereabouts, Miroslav Lachman wrote:
> Pred par dny jsem se tu ptal na to, jakou verzi nasadit na
> dvouprocesorovy stroj, zminoval jsem se i o tom, ze k tomu bude
> pripojene externi SCSI pole se soubory pro download.
> 
> Nyni vystoupily na svetlo nove skutecnosti a tak jsem tu zase s prosbou
> o radu / inspiraci. Klient si vymyslel, ze to nebude jeden server a
> jedno externi pole, ale dva servery a jedno pole. Na serveru bude
> Apache2 + PHP4 + MySQL 4.1 a na tom "redakcni system". Vse za normalnich
> podminek ma bezet z jednoho serveru, ale v pripade, ze dojde k jeho
> vypadku, ma se to (prostrednictvim nejakeho Cisco loadbalanceru)
> prepnout na druhy stroj a tam pokracovat v plne funkcnosti.
> 
> Co jsem koukal do manualu, nemel by byt problem nastavit MySQL tak, aby
> hlavni stroj byl Master a vsechny SQL queries se budou replikovat na
> druhy stroj, ktery bude jako Slave. Po tud je to vsechno OK.

  Preco chces MySQL riesit replikovanim, ked od verzie 4.1 mas k
  dispozicii clustering (ndb engine). Mozno by som ale vzhladom na
  obmedzenia niektore v 4.1 clusteringu zvolil nasadenie uz MySQL 5.0,
  je vo verzii 5.0.15 a je to GA, cize generally available. Patkovu radu
  mam nasadenu na serveri, kde sa nachadza databaza s cache pre nas CMS
  system (load je tam cca 10 tisic queries/minuta v peakoch, priemerny
  load je tam 6.5 tisica queries/minuta).

  Info o clusteringu:
  http://dev.mysql.com/doc/refman/4.1/en/mysql-cluster-overview.html
  
  Obmedzenia clusteringu v 4.1.x:
  http://dev.mysql.com/doc/refman/4.1/en/mysql-cluster-limitations-in-4-1.html

  FAQ:
  http://dev.mysql.com/doc/refman/4.1/en/mysql-cluster-faq.html

> 1] na server se budou uploadovat nejaka data (naprikald obrazky k
> clankum atd.), to je potreba nejakym zpusobem synchronizovat i na druhy
> server. Tohle asi nepujde nijak realtime, ale to neni zas takovy
> problem, bude IMHO stacit, pokud se to bude provadet z cronu, ale jaky
> nastroj by na tohle byl nejvhodnejsi?

  Sam pises, ze tam bude externe pole pre subory, cize pravdepodobne
  budes riesit neaky NFS sharing na oba aplikacne servery.

> 2] o neco vetsi starosti mi dela externi SCSI pole, jelikoz jsem do ted
> neobdrzel zadne detailni informace o HW, tak nemam nejmensi tuseni, jak
> bude pripojene k serveru a hlavni starost mi dela to, jak ho pripojit ke
> dvoum serverum zaroven, tak, aby na nej mohl zapisovat "master" (a
> samozrejme cist) a v pripade vypadku masteru, aby bez fyzickeho zasahu
> (prepojeni nejakych kabelu) mohl zacit plne fungovat slave.

  Bolo by fajn nahanat dodavatela pola, ci uz osobne, alebo
  prostrednictvom klienta, aby dodal informacie, ved predsa len to
  diskove pole je dolezitou castou celej implementacie. Ale ako vravim,
  NFS export by to mohlo/malo vediet. 

> 3] a ted asi to nejpodstatnejsi - pokud master nekolik dni nepojede a
> budou se veskere zmeny v DB i filesystemu dit na slave serveru, jak je
> pak zase dostat na puvodni master a opet z nej udelat master se vsim
> vsudy? Pokud je mi znamo, tak MySQL 4.1 tohle vubec neresi a replikace
> tam vzdy probiha jen jednim smerem. Lze tedy aspon pak nejakym scriptem,
> nebo rucne provest obracenou synchronizaci a opet presunout vsechnu
> funkcionalitu na master a slave mit zase jen jako zalozni stroj pro
> pripad vypadku?

  Vid vyssie, co pisem ohladne clusteringu. S replikaciou nemam ziadne
  skusenosti, pouzivali sme ju v minulosti iba ako kvazi backup system,
  ale ziaden failover nic.


-- 
martin hudec


   * 421 907 303 393
   * corwin at aeternal.net
   * https://aeternal.net

"Nothing travels faster than the speed of light with the possible 
exception of bad news, which obeys its own special laws."

   Douglas Adams, "The Hitchhiker's Guide to the Galaxy"



More information about the Users-l mailing list