Replikace / redundance na dvou serverech

Miroslav Lachman 000.fbsd at quip.cz
Thu Oct 27 11:03:19 CEST 2005


Jozef Babjak wrote:

> Zdravim!
> 
> 
>>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?
> 
> 
>   ^-- Navrh 1: Tlacit aj tie uploadovane obrazky do DB. Navrhovo to bude
> cistejsie, synchronizacia sa urobi sama. Navrh 2: rsync; ten vsak funguje
> nad ssh, t.j. udaje sifruje, moze robit porovnania na zaklade MD4
> kontrolnych suctov, a teda je celkom dost narocny na CPU, co na serveroch
> zatazenych uz aj tak normalnou prevadzkou nemusi byt ziaduce. A nakoniec
> Navrh 0: Co tu vlastne riesite, ked udaje budu na *zdielanom* SCSI
> diskovom poli? Zapisom jedneho zo serverov na diskove pole sa tento stane 
> okamzite viditelny na tom druhom. Alebo som nieco nepochopil?

Hlavni problem je to, ze aplikace (redakcni system) je uz napsana a
nepripadaji v uvahu zadne zmeny, alespon ne ted, kvuli predpokladanemu
terminu spusteni 1.11. (ano, to neni vtip, to je realny pozadavek
klienta o kterem jsem mu uz pred tydnem rikal, ze je nesmyslny). Je
udajne ocekavano pro zacatek cca 20 000 UIP denne, takze obrazky v DB by
asi byly znacnou zatezi.

Na diskovem poli maji byt pouze soubory pro download, ne data redakcniho
systemu, nebo databaze.

>>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?
> 
> 
>   ^-- Cely navrh mi pride divny; je to "netradicne" riesenie. Zvycajny 
> scenar je takyto:
> 
>      +---------------+
>      | Load Balancer |
>      +---------------+
>        /           \
> +-----------+ +-----------+
> | Aplikacia | | Aplikacia |
> +-----------+ +-----------+
>        \           /
>    +-------------------+
>    |  D a t a b a z a  |
>    +-------------------+
>              |
>         +---------+
>         | Storage |
>         +---------+

Ano, tohle naprosto chapu, bohuzel v tomto projektu jsou v podstate 4
strany a outsourcing. Jedna strana neco chce, vyhradi na to urcity HW a
zaplati za to druhe strane, druha strana zaplati treti stranu za
programovani redakcniho systemu a ctvrtou stranu za administraci
serveru, sama druha strana pak zajistuje pouze obsah do redakcniho
systemu. Takze vybojovat jakekoliv zmeny v HW zkratka nelze.

> Ak potrebujete hot-zalohovanu prevadzku DB, tak treba uvazovat, ci je 
> MySQL to prave orechove. Co tak Oracle RAC? Ale to bude asi dost mimo 
> planovany rozpocet, vsakze? :-|
> 

Jak jsem uvadel vyse - webaplikace je jiz napsana a otestovana pouze s
MySQL 4.1, takze si nemohu ani dovolit pokusy s MySQL 5.x.

I tak dekuji za rady!

Miroslav Lachman



More information about the Users-l mailing list