Temat: Replikacja MySQL nie trywialnie

Panowie mam ciekawe zadanko. Mam N serwerów MySQL (Master), gdzie na każdym serwerze żyje jedna baza transakcyjna (dla uproszczenia). Zadanie polega na tym by w trybie Master-Slave replikować te wszystkie bazy do jednego Slave. W obrębie Slave mogą to być różne bazy. Nie oczekuję gotowej odpowiedzi (jak ustawić - to sam muszę rozwiązać :) ), a raczej czy jest to możliwe i czy komuś się udało.

Z góry dzięki za pomoc.

Temat: Replikacja MySQL nie trywialnie

Da się, udało się.
Nie wiem jak sytuacja wygląda w dniu dzisiejszym ale w dawnych czasach trzeba było robić CHANGE MASTER TO z odpowiednimi parametrami i skakać po slave'ach (należy pamiętać pozycję logów dla każdego z osobna).
Dużo ułatwia jeśli każdy z masterów ma inaczej nazywającą się bazę.

Temat: Replikacja MySQL nie trywialnie

Irek Słonina:
Da się, udało się.
Nie wiem jak sytuacja wygląda w dniu dzisiejszym ale w dawnych czasach trzeba było robić CHANGE MASTER TO z odpowiednimi parametrami i skakać po slave'ach (należy pamiętać pozycję logów dla każdego z osobna).
Dużo ułatwia jeśli każdy z masterów ma inaczej nazywającą się bazę.

Sprawdziłem - dalej trzeba zmieniać mastera ale za to można położyć replikację, przełączyć mastera i wznowić replikację. Pozycja w logu dla poprzedniego mastera jest zapamiętywana i można wrócić do niej w późniejszym czasie.

Dzięki za trafną podpowiedź.

Temat: Replikacja MySQL nie trywialnie

Piotr Rusoł:
Panowie mam ciekawe zadanko. Mam N serwerów MySQL (Master), gdzie na każdym serwerze żyje jedna baza transakcyjna (dla uproszczenia). Zadanie polega na tym by w trybie Master-Slave replikować te wszystkie bazy do jednego Slave. W obrębie Slave mogą to być różne bazy. Nie oczekuję gotowej odpowiedzi (jak ustawić - to sam muszę rozwiązać :) ), a raczej czy jest to możliwe i czy komuś się udało.

Z góry dzięki za pomoc.

Rozwiązanie, które podał Irek powinno zadziałać. Tylko trzeba uważać, aby dobrze zapisywać pozycje na każdym masterze i nie rozwalić replikacji pomiędzy poszczególnymi bazami.

Irek poruszył temat nazw baz na poszczególnych masterach. Ja powiem więcej: na żadnym z masterów nie mogą się znajdować bazy danych o takiej samej nazwie. W twoim przypadku jesteś akurat w dobrej sytuacji, bo na każdym masterze znajduje się jedna baza.
Gdybyś miał konflikt w nazwach, to da się go obejść przez restart slave z odpowiednimi parametrami replicate-* przy każdorazowej zmianie mastera.

Rozwiązanie ze zmianą mastera ma 1 wadę: trzeba w jakiś sposób decydować, kiedy przełączać na kolejnego mastera. Możesz mieć problemy z utrzymaniem lagu replikacji dla poszczególnych baz. Wszystko zależy od tego, ile operacji zapisu będziesz miał na masterach. Pamiętaj, że replikacja w MySQL wykorzystuje tylko 1 wątek do wykonywania query.

Jest jeszcze jedno rozwiązanie, wydaje mi się, że widziałem gdzieś na slajdach, że powinno umożliwić równoczesną replikację z kilku masterów. Nazywa się ono Tungsten Replicator. Pobrać można tutaj: http://sourceforge.net/projects/tungsten/files/.

A teraz zapytam przewrotnie: jaki jest cel twojego działania? Dlaczego potrzebujesz X baz z X masterów na 1 slave?

Pamiętaj, że replikacja, podobnie jak RAID, to nie jest backup.

Temat: Replikacja MySQL nie trywialnie

Mariusz Sucajtys:

Piotr Rusoł:
Panowie mam ciekawe zadanko. Mam N serwerów MySQL (Master), gdzie na każdym serwerze żyje jedna baza transakcyjna (dla uproszczenia). Zadanie polega na tym by w trybie Master-Slave replikować te wszystkie bazy do jednego Slave. W obrębie Slave mogą to być różne bazy. Nie oczekuję gotowej odpowiedzi (jak ustawić - to sam muszę rozwiązać :) ), a raczej czy jest to możliwe i czy komuś się udało.

Z góry dzięki za pomoc.

Rozwiązanie, które podał Irek powinno zadziałać. Tylko trzeba uważać, aby dobrze zapisywać pozycje na każdym masterze i nie rozwalić replikacji pomiędzy poszczególnymi bazami.

Irek poruszył temat nazw baz na poszczególnych masterach. Ja powiem więcej: na żadnym z masterów nie mogą się znajdować bazy danych o takiej samej nazwie. W twoim przypadku jesteś akurat w dobrej sytuacji, bo na każdym masterze znajduje się jedna baza.
Gdybyś miał konflikt w nazwach, to da się go obejść przez restart slave z odpowiednimi parametrami replicate-* przy każdorazowej zmianie mastera.

Rozwiązanie ze zmianą mastera ma 1 wadę: trzeba w jakiś sposób decydować, kiedy przełączać na kolejnego mastera. Możesz mieć problemy z utrzymaniem lagu replikacji dla poszczególnych baz. Wszystko zależy od tego, ile operacji zapisu będziesz miał na masterach. Pamiętaj, że replikacja w MySQL wykorzystuje tylko 1 wątek do wykonywania query.

Jest jeszcze jedno rozwiązanie, wydaje mi się, że widziałem gdzieś na slajdach, że powinno umożliwić równoczesną replikację z kilku masterów. Nazywa się ono Tungsten Replicator. Pobrać można tutaj: http://sourceforge.net/projects/tungsten/files/.

A teraz zapytam przewrotnie: jaki jest cel twojego działania? Dlaczego potrzebujesz X baz z X masterów na 1 slave?

Pamiętaj, że replikacja, podobnie jak RAID, to nie jest backup.

Dziękuję pięknie za odpowiedź. Do tego, co napisałeś dodam jeszcze, że ID mastera i slave muszą się zgadzać.

Tak wiem, że replikacja to nie backup wiem też jakie wady, zalety, zagrożenia i zyski się z tym wiążą. :) Po prostu nigdy tego nie robiłem na MySQL i stąd moje pytanie o ograniczenia w przypadku tego konkretnego RDBMS.

Cel jest taki, że jest sobie klient X, który ma kilka(a w niedalekiej przyszłości naście) sklepów internetowych. Wpadł on na genialny pomysł, by dane z tych sklepów były na bieżąco składowane w ACCESS u niego lokalnie i zmiany były propagowane do poszczególnych sklepów.

Tak wiem, pomysł klienta to replikacja multi-master i jest nie do zrealizowania technologicznie przy takich założeniach. Choć by ze względu na ograniczenia wielkości bazy w ACCESS. Oczywiście można by kupić płatną wersję MySQL i mieć ten problem z głowy. Natomiast cena jest poza zasięgiem klienta. Dlatego zacząłem rozważać inne opcje rozwiązania tego problemu wychodząc z założenia, że skoro na tym solidnie nie zarobię to przynajmniej czegoś się nauczę. Replikacja master-slave to jedna ze składowych rozwiązania.

Inne podejście jakie rozważam to głęboka modyfikacja kodu źródłowego oprogramowania sklepu ale tego chcę uniknąć ponieważ nie przepadam za PHP i sam program nie posiada skonsolidowanej dokumentacji.

Parę innych jeszcze ciekawych rozwiązań mi do głowy przyszło ale to temat na inną bajkę.Piotr Rusoł edytował(a) ten post dnia 06.02.11 o godzinie 01:40

Temat: Replikacja MySQL nie trywialnie

Piotr Rusoł:

Dziękuję pięknie za odpowiedź. Do tego, co napisałeś dodam jeszcze, że ID mastera i slave muszą się zgadzać.

W jakich przypadkach muszą się zgadzać? Server ID powinno być unikatowe.
Z http://dev.mysql.com/doc/refman/5.0/en/replication-how...
If the slave server ID is not already set, or the current value conflicts with the value that you have chosen for the master server, you should shut down your slave server and edit the configuration to specify a unique server ID.

Cel jest taki, że jest sobie klient X, który ma kilka(a w niedalekiej przyszłości naście) sklepów internetowych. Wpadł on na genialny pomysł, by dane z tych sklepów były na bieżąco składowane w ACCESS u niego lokalnie i zmiany były propagowane do poszczególnych sklepów.

To zadam inne pytanie: czy i jakie przeszkody są ku temu, aby zebrać bazy z różnych instancji sklepów na jednego mastera? Czy klient ma aż tak duży ruch, że jedna instancja nie obsłuży kilku sklepów? Ale jeżeli ma taki ruch, to jeden slave prawdopodobnie nie da rady uciągnąć replikacji. Zależy to tylko od tego, jaki jest stosunek select do insert/update/delete. Jeżeli przeważają selecty (tak z 80%), to jest spora szansa, że slave da radę.

Jeden master z wieloma bazami po prostu znacznie upraszcza nie tylko replikację, ale również zarządzanie całym tym ustrojstwem. Stawiając dedykowany serwer na DB z odpowiednią mocą można go odpowiednio dostroić i powinno się dać z niego wyciągnąć naprawdę dużo.

Napisałeś, że wolałbyś uniknąć modyfikacji w kodzie php. Dodanie readonly slaves z przekierowaniem zapisów do master prawdopodobnie więc nie wchodzi w grę. Wszystko zależy od tego, jak jest zbudowany kod aplikacji. Może wcale nie trzeba tak wielu modyfikacji.

Wracając do zbierania danych z wielu master na jednego slave. Pomysł nie różni się wiele od równoległej replikacji i tego, co potrafi wspomniany przeze mnie Tungsten: http://scale-out-blog.blogspot.com/2010/10/parallel-re....

Klient chce wszystko do Accessa zbierać. To już robi się coś na kształt BI. Ale dane do hurtowni ładowane są zazwyczaj wsadowo jako zadania ETL. Z takiej hurtowni dane można już spokojnie do Access'a pociągnąć.
Czy dane do "slave" muszą spływać w czasie rzeczywistym? Czy akceptowalne jest okresowe zaciąganie danych? Można oskrytpować mk-table-checksum oraz mk-table-sync z Maatkit.

Temat: Replikacja MySQL nie trywialnie

Mariusz Sucajtys:

Piotr Rusoł:

Dziękuję pięknie za odpowiedź. Do tego, co napisałeś dodam jeszcze, że ID mastera i slave muszą się zgadzać.

W jakich przypadkach muszą się zgadzać? Server ID powinno być unikatowe.
Z http://dev.mysql.com/doc/refman/5.0/en/replication-how...
If the slave server ID is not already set, or the current value conflicts with the value that you have chosen for the master server, you should shut down your slave server and edit the configuration to specify a unique server ID.

Cel jest taki, że jest sobie klient X, który ma kilka(a w niedalekiej przyszłości naście) sklepów internetowych. Wpadł on na genialny pomysł, by dane z tych sklepów były na bieżąco składowane w ACCESS u niego lokalnie i zmiany były propagowane do poszczególnych sklepów.

To zadam inne pytanie: czy i jakie przeszkody są ku temu, aby zebrać bazy z różnych instancji sklepów na jednego mastera? Czy klient ma aż tak duży ruch, że jedna instancja nie obsłuży kilku sklepów? Ale jeżeli ma taki ruch, to jeden slave prawdopodobnie nie da rady uciągnąć replikacji. Zależy to tylko od tego, jaki jest stosunek select do insert/update/delete. Jeżeli przeważają selecty (tak z 80%), to jest spora szansa, że slave da radę.

>

Jeden master z wieloma bazami po prostu znacznie upraszcza nie tylko replikację, ale również zarządzanie całym tym ustrojstwem. Stawiając dedykowany serwer na DB z odpowiednią mocą można go odpowiednio dostroić i powinno się dać z niego wyciągnąć naprawdę dużo.

Właśnie podałeś właśnie jedno z rozwiązań ćwiczenia. Według mnie najlepsze z możliwych. Tylko przekonać klienta, że takie rozwiązanie jest najlepsze. ;)

Napisałeś, że wolałbyś uniknąć modyfikacji w kodzie php. Dodanie readonly slaves z przekierowaniem zapisów do master prawdopodobnie więc nie wchodzi w grę. Wszystko zależy od tego, jak jest zbudowany kod aplikacji. Może wcale nie trzeba tak wielu modyfikacji.

Napisałem, że chciał bym uniknąć głębokiej modyfikacji kodu :) Miałem na myśli takie przerobienie aplikacji aby obsługiwała jednocześnie więcej niż jedną instancję sklepu (bazy). Z kodem się już zapoznałem i nie jest on zbyt przyjazny choć by ze względu na brak dokumentacji.

Wracając do zbierania danych z wielu master na jednego slave. Pomysł nie różni się wiele od równoległej replikacji i tego, co potrafi wspomniany przeze mnie Tungsten: http://scale-out-blog.blogspot.com/2010/10/parallel-re....

Nie patrzyłem jeszcze na Tungsten ale na 100% się z nim zapoznam.

Klient chce wszystko do Accessa zbierać. To już robi się coś na kształt BI. Ale dane do hurtowni ładowane są zazwyczaj wsadowo jako zadania ETL. Z takiej hurtowni dane można już spokojnie do Access'a pociągnąć.
Czy dane do "slave" muszą spływać w czasie rzeczywistym? Czy akceptowalne jest okresowe zaciąganie danych? Można oskrytpować mk-table-checksum oraz mk-table-sync z Maatkit.

Właśnie o to chodzi, że klient myśli, że da się dane na bieżąco zbierać do ACCESS i z niego wysyłać zmiany do poszczególnych baz. Teoretycznie jest to wykonalne. Wystarczy tylko dodać do każdej tabeli, która miała by się replikować dwie kolumny - Nazwę systemu (cokolwiek by to nie było) i ostatni czas modyfikacji. Reszta to już banał. Z tym, że pociąga to za sobą głęboką modyfikację w kodzie i przeprowadzenie porządnej analizy czy na przykład wszystkie użyte typy danych w MySQL mają swoje literalne odpowiedniki w ACCESS a jeżeli nie to opracować zasady przekodowania. Itd. itp.

Temat: Replikacja MySQL nie trywialnie

Dziękuję Panowie za wszystkie wypowiedzi i pomoc ale klient chyba zmiękł jak usłyszał cenę startową. Według mnie całkiem niską biorąc pod uwagę typ zadania ale widać jeszcze do niej nie dorósł. Może w przyszłości ...

Temat: Replikacja MySQL nie trywialnie

nie kumam problemu z tym Access-em,

ten program nie powinien być użytkowany w charakterze hurtowni, bo się do tego nie nadaje, może być za to świetnym frontendem z formularzami do pracy z dowolną bazą danych

access może pracować wprost na MySQL za pomocą podlinkowanych tabel

niczego nie importujesz i nie eksportujesz, pracujesz tak jak na lokalnych tabelach Access-a, musisz mieć tylko wgrany sterownik ODBC do MySQL

modyfikacja wykonana z poziomu Access-a jest odrazu widoczna z poziomu PHP i vice-wers-a

Temat: Replikacja MySQL nie trywialnie

Przemysław R.:
nie kumam problemu z tym Access-em,

ten program nie powinien być użytkowany w charakterze hurtowni, bo się do tego nie nadaje, może być za to świetnym frontendem z formularzami do pracy z dowolną bazą danych

Przemek ja to wiem, Ty to wiesz klient nie koniecznie ;)

access może pracować wprost na MySQL za pomocą podlinkowanych tabel

O widzisz tego nie wiedziałem - z ACCESS'em i ODBC mam niewiele wspólnego ... Masz plusa (szkoda, że nie mogę więcej dać).

A powiedz mi jeszcze jak jest z obsługą typów, wyzwalaczy i wywoływaniem procedur składowych? Zakładam, że ACCESS nie rozumie pojęcia SERIAL i paru innych rzeczy.

Temat: Replikacja MySQL nie trywialnie

Piotr Rusoł:

A powiedz mi jeszcze jak jest z obsługą typów, wyzwalaczy i wywoływaniem procedur składowych? Zakładam, że ACCESS nie rozumie pojęcia SERIAL i paru innych rzeczy.

takimi gadżetami zajmuje się klient ODBC, w zasadzie nie masz tylko rzutowania do jakiś dziwnych typów danych np. geograficzne, ale to folklor

procedury, triggery są po stronie bazy i de fakto access nie dotyka tego tematu, z punktu widzenia access-a interesujące są tabele i widoki + wywołanie zapytania SQL za pomocą kwerendy przekazującej -> w dialekcie MySQL-a ale za pomocą mechanizmu ODBC wprost w Access-e, procedury również można wywołać wprost na serwerze za pomocą kwerendy przekazującej np.:

call jakas_procedura ('parm1','parm2');

, wynik zostanie zwrócony w postaci standardowej tabelki, bądź też nie (jest taki ptaszek we właściwościach kwerendy żeby nie zwracała wyniku)

Temat: Replikacja MySQL nie trywialnie

No to sprawa pozamiatana - jeszcze raz dziękuję za pomoc.