Multi-Master

[Gość Kamikadze]

Od kilku dni/tygodni rozmyślam nad rozwiązaniem awaryjności mojej aplikacji i udało się wyeliminować 90% problemów.

 

Ale został jeden najgorszy... A mianowicie bazy danych.

 

Co sądzicie o czymś takim: http://jayant7k.blogspot.com/2006/06/multi-master-replication-in-mysql.html

 

z przerobieniem api aby w przypadku awarii korzystała z innego serwera mysql to nie problem, ale dane są gorsze.

 

Sama replikacja by była dobra, ale jak się dane zmienią na bierząco na drugim serwerze a podłączy się spowrotem api do pierwszego bo zaczął działać to dupa bo tamte dane się nie przeniosą.

 

A taka multi replikacja była by chyba ok, tylko muszę ją przetestować na jakichś testowych serwerkach

 

Korzystał ktoś? A może ktoś zna lepsze rozwiązanie?

[tym 205]

Polecam zapoznanie się z http://www.percona.com/software/

[Gość patrys]

Replikacja master aktywny > master aktywny w środowiskach produkcyjnych nie jest dobrym pomysłem.

Oczywiście ma plusy, ale też sporo minusów...

Tu rozwiązaniem lepszym będzie replikacja w trybie master aktywny - > master pasywny.

Gdzie serwer pasywny będzie działał w trybie tylko do odczytu, a będzie go można ręcznie przemianować na mastera aktywnego, na czas naprawy usterki.

 

Polecam zapoznanie się z http://www.percona.com/software/

Jaki to ma związek z tematem ?

[beliq 442]

Replikacja MySQLa, szczególnie w przypadku instalacji działających pod wysokim obciążeniem,nie jest tematem trywialnym.

Jest to wbrew pozorom bardzo skomplikowana procedura o bardzo dużej ilości zależności.

Absolutnie nie można tego postrzegać jako prostą 3 etapowe wdrożenie typu fire&forget;

a) spiąć ze sobą dwie instancje b) dodać rekord na A i sprawdzić czy się pojawił na B c) zostawić i cieszyć się działającym rozwiązaniem.

W sieci jest pełno artykułów, które ilustrują w mniej lub bardziej poprawny sposób jak to szybko wykonać,

ale absolutnie nie radzę iść tą drogą. Bez przeczytania wszystkich dostępnych dokumentacji i dużej ilości treści pochodnych,

bawienie się w replikację zakrawa na hazard.

 

Istnieją działające z powodzeniem instalacje typu master aktywny<->master aktywny,

ale osoby, które je wdrażały naprawdę wiedzą co robią.

Znają bardzo dokładnie architekturę swojej bazy danych, ograniczenia silnika,

a także wszystkie sytuacje kiedy to się może posypać na dobre - co zaakceptowali.

 

Najlepiej poświęć z miesiąc czasu na research i testy. Podejdź do tematu powoli.

[Gość Kamikadze]

Korzystałem kiedyś z replikacji, ale potrzebuję czegoś lepszego.

 

Tzn. dwa automatycznie uzupełniające się serwery.

 

Czyli jak na serwerze A dodam rekord to pojawi się na serwerze B i odwrotnie jak dodam na B to pojawi się na A.

 

 

 

Chcę się uodpornić na awarię serwera A czyli api przechodzi na działanie na serwerze B, a jak serwer A znowu jest sprawny to aktualizuje się z serwera B.

 

Chciałem wiedzieć czy jest coś takiego, albo ktoś coś wymyślił

Sam też kombinuję i myślę ale to niezwykle trudne

[beliq 442]

Jaki to projekt? Ile danych? MyISAM? InnoDB? Proste zapytania? Skomplikowane złączenia?

Ilość operacji na sekundę? Ilość IO/PS? MB/s odczyt/zapis? Jaki masz obecnie sprzęt? Plany wzrostu obciążenia?

Dlaczego w ogóle myślisz o wysokiej dostępności? Serwer się zawiesza? Masz szrota w OVH?

Czy częste awarie prądu?

[Gość Kamikadze]

Praktycznie jedna baza i kilkaset rekordów,

 

wg. phpmyadmin zapytania (ogólnie ale 99% do tej jednej

bazy)

 

Sumarycznie - 17M

ø na godzinę - 29,30k

ø na minutę - 488,32

ø na sekundę - 8,14

 

 

MyISAM

 

 

W planach mam wzrost z 200 do około 500-1000 rekordów

 

Wszystko proste jak budowa cepa

 

Serwer się nie zawiesza, jest bardzo dobry, ale chciałem wyeliminować problem "niedostępności" - wiadomo pady się zdarzają, awarie łączy itp.

 

Odpukać awarii nie ma, ale lepiej później nie płakac

Edytowano Wrzesień 1, 2012 przez Kamikadze (zobacz historię edycji)

[Gość patrys]

Baza mikro, ilość zapytań również..

Na początek zmień jeżeli nie masz MySQL na wersje 5.5, ustaw go pod InnoDB i zamień MyISAM na InnoDB.

 

Na pewno nikt na forum nie wklei Ci gotowej my.cnf dla dwóch masterów i poda komendy "change master to..."

Sama replikacja aktywny-aktywny jest dość skomplikowana i tak jak pisał kolega wyżej jest dla ludzi którzy dobrze znają temat.

Pamiętaj, że nawet jak już replikacja będzie działała dość sprawnie to zostaje Ci kwestia rozłożenia ruchu na serwery i wykrywania usterek.

Dużo bardziej polecana jest replikacja master aktywny - > master pasywny, oczywiście tam gdzie można ją zastosować.

Można spokojnie korzystać z jednego master'a i automagicznie albo ręcznie przełączyć ruch na drugiego który jest w trybie ro.

Teraz albo naprawiać głównego i korzystać tylko z dobrodziejstwa odczytu danych, albo przemianować pasywnego na aktywnego co jest bardzo proste ( oczywiście jeżeli nie ma jeszcze serwerów podrzędnych, ale to już niewielki problem ).

 

Masz szrota w OVH?

No musiał ^^

[Gość Kamikadze]

Ok dzięki za info

 

Postawię sobie kilka serwerów mysql testowych i potestuję różne rozwiązania.

[beliq 442]

Serwer się nie zawiesza, jest bardzo dobry, ale chciałem wyeliminować problem "niedostępności" - wiadomo pady się zdarzają, awarie łączy itp.

Jakie awarie łączy w sieci LAN? Jeśli nie jesteś w stanie zagwarantować poprawnego

połączenia pomiędzy serwerami MySQL żadna forma HA nie wchodzi w grę.

Przy założeniu, że masz jakiś serwer RACK, dyski w RAID, dwa zasilacze,

to przy obciążeniach jakie generujesz, serwer MySQL mógłby pracować i nawet 10 lat non-stop.

Ile miałeś awarii/niedostępności MySQLa w tym roku i czym one były spowodowane?

[Gość Kamikadze]

Trochę nie zrozumiałeś

 

Mam serwer w lokalizacji X i lokalizacji Y i chciałbym aby one między sobą wymieniały dane.

 

Awarii nie miałem żadnej jeszcze ani łącza, ani zasilania nic zero odpukać.

[kafi 2425]

To, co chcesz zrobić, to niestety, ale cała teoria systemów rozproszonych.

Na dobry początek proponuję przejrzeć (bo czytanie od deski do deski to raczej chyba niewykonalne i bezsensowne) dwie cegiełki:

 

A. S. Tanenbaum, M. van Steen, Systemy rozproszone, zasady i paradygmaty, WNT 2005.
G. Coulouris, Systemy rozproszone, podstawy i projektowanie, WNT 1999

 

W trakcie musisz się zastanowić, jak to napisać APLIKACJĘ w sposób skalowalny, a nie jak tu wydziwniać z mechanizmami replikacyjnymi master-slave. Bo one służą raczej, jak to bellerofont napisał, zabezpieczeniu się przed failoverem SZBD, a nie jakąś awarią sieciową.

 

 

IMO rozwiązanie tego może być w sposób taki, że każdy satelita zbiera (pomiary?) do wewnętrznej bazy danych, a jakiś nadrzędny serwer je raz na jakiś czas zasysa (ale czy push, pull, czy może i to i to?).