Replikace / redundance na dvou serverech

Jozef Babjak babjak at hilbert.chtf.stuba.sk
Thu Oct 27 06:00:43 CEST 2005


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?

> 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 |
        +---------+

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? :-|

J. 




More information about the Users-l mailing list