Witam Panowie, podpowiedzcie rozwiązanie. generalnie mam postawionego lmsa z mysql i radiusem na jednej maszynie. chciałbym postawić bratni serwer z tymi samymi usługami i replikowaną bazą. tak by w klientach wpisywać dwa serwery radius i bym mógł w każdej chwili któryś wyłączyć bez odczuwalności dla sesji PPPoE.
dobrze w tym wypadku sprawdziła by się replikacja master-master dla mysql, ale tak zachwalany postgres jest lepszy i szybszy. niestety nie wspiera on takiej replikacji jak mysql, albo jeszcze o tym nie doczytałem. jest to najlepszy moment na przejście na postgresa gdzyż będę stawiał dwie nowe maszynki oddalone od siebie lokacyjnie.
jakie najlepsze rozwiązanie wybrać? mysql czy postres? z gróy dzięki za sugestie i podpowiedzi.
Mysql tez nie wspiera replikacji master-master w ktorej zapis odbywa sie na obu wezlach rownoczesnie. Jak probojesz tak zrobic to wyladujesz z niespojnymi danymi lub zatrzymana replikacja.
Co do replikacji pg to nie wiem jak natywna ale slony porafi zamieniac funkcja master ze slave w locie.
9 wrz 2014 14:19 "Marcin" marcin@nicram.net napisał(a):
Witam Panowie, podpowiedzcie rozwiązanie. generalnie mam postawionego lmsa z mysql i radiusem na jednej maszynie. chciałbym postawić bratni serwer z tymi samymi usługami i replikowaną bazą. tak by w klientach wpisywać dwa serwery radius i bym mógł w każdej chwili któryś wyłączyć bez odczuwalności dla sesji PPPoE.
dobrze w tym wypadku sprawdziła by się replikacja master-master dla mysql, ale tak zachwalany postgres jest lepszy i szybszy. niestety nie wspiera on takiej replikacji jak mysql, albo jeszcze o tym nie doczytałem. jest to najlepszy moment na przejście na postgresa gdzyż będę stawiał dwie nowe maszynki oddalone od siebie lokacyjnie.
jakie najlepsze rozwiązanie wybrać? mysql czy postres? z gróy dzięki za sugestie i podpowiedzi.
-- Pozdrawiam Marcin / nicraM _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 9 września 2014 16:09 użytkownik Rafał Ramocki rafal.ramocki@gmail.com napisał:
Mysql tez nie wspiera replikacji master-master w ktorej zapis odbywa sie na obu wezlach rownoczesnie.
ale odbywa się za pomocą plików binarnych i takie rozwiązanie jest dla mnie wystarczające. nie potrzebuję w danej milisekundzie zapisu na obu jednocześnie, ważne by dane były spójne w możliwie krótkim czasie.
Co do replikacji pg to nie wiem jak natywna ale slony porafi zamieniac funkcja master ze slave w locie.
hmm, chciałbym uniknąć "dodaktowych" daemonów
Witam,
Nie wiem czy takie rozwiazanie Cie zadowala, ale ja mam:
1. MySQL Master 2. MySQL Slave 3. MySQL Slave
We freeradiusie mam podpiete te 3 bazy danych, z ta roznica, ze dla baz slave'owych mam wylaczony accouting (czyli zapisywanie). Accouting odbywa sie tylko do bazy Master, a radiusowe requesty r/o ida do 3 baz. Jak przestaje dzialac master, requesty ida do slave'a bez acc, jak master wraca, radius przepina sie na mastera. :)
W dniu 09.09.2014, 16:13, Marcin pisze:
W dniu 9 września 2014 16:09 użytkownik Rafał Ramocki rafal.ramocki@gmail.com napisał:
Mysql tez nie wspiera replikacji master-master w ktorej zapis odbywa sie na obu wezlach rownoczesnie.
ale odbywa się za pomocą plików binarnych i takie rozwiązanie jest dla mnie wystarczające. nie potrzebuję w danej milisekundzie zapisu na obu jednocześnie, ważne by dane były spójne w możliwie krótkim czasie.
Co do replikacji pg to nie wiem jak natywna ale slony porafi zamieniac funkcja master ze slave w locie.
hmm, chciałbym uniknąć "dodaktowych" daemonów
W dniu 09.09.2014 16:13, Marcin napisał(a):
W dniu 9 września 2014 16:09 użytkownik Rafał Ramocki rafal.ramocki@gmail.com napisał:
Mysql tez nie wspiera replikacji master-master w ktorej zapis odbywa sie na obu wezlach rownoczesnie.
ale odbywa się za pomocą plików binarnych i takie rozwiązanie jest dla mnie wystarczające. nie potrzebuję w danej milisekundzie zapisu na obu jednocześnie, ważne by dane były spójne w możliwie krótkim czasie.
Co do replikacji pg to nie wiem jak natywna ale slony porafi zamieniac funkcja master ze slave w locie.
hmm, chciałbym uniknąć "dodaktowych" daemonów
Jeśli to pod kątem serwera radius te rozważania to totalnie bez sensu zajmować się replikacją baz danych.
W dniu 9 września 2014 16:25 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
Jeśli to pod kątem serwera radius te rozważania to totalnie bez sensu zajmować się replikacją baz danych.
hmm, to co byś proponował? jakieś sprawdzone rozwiązanie w przypadku padu jednej maszyny?
W dniu 09.09.2014 16:27, Marcin napisał(a):
W dniu 9 września 2014 16:25 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
Jeśli to pod kątem serwera radius te rozważania to totalnie bez sensu zajmować się replikacją baz danych.
hmm, to co byś proponował? jakieś sprawdzone rozwiązanie w przypadku padu jednej maszyny?
Przejść we freeradius z rlm_sql na rlm_files. (wielokrotnie szybsze niż rlm_sql i do tego nie generującego zbytecznego obciążenia samym silnikiem sql).
W dniu 9 września 2014 16:34 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
Przejść we freeradius z rlm_sql na rlm_files. (wielokrotnie szybsze niż rlm_sql i do tego nie generującego zbytecznego obciążenia samym silnikiem sql).
z tym, że w moim przypadku login i hasło do pppoe biorę z bazy lms, więc baza mi jest potrzebna. accountig również. wiem, mogę accounting przenieść do plików, ale łatwiej się go przegląda z bazy. na bazę accoutnigu mam osobną bazę, nie trzymam tego w lms. przy przejściu na pliki musiałbym generować pliki konfiguracyjne i za każdym razem przeładowywać radiusa.
Żeby mieć spójne dane w MySQL przy replikacji cyklicznej przy zapisie do obu musisz mieć pewność że wszystkie binlogi znają się na drugim serwerze i po drugie zmiany w nich naniesione na bazę. W zasadzie bezpiecznie jest drugą bazę ustawić w read_only = 1.
Co do postgresa to ze slony1 pracuję od czasu 8.1 i jest stabilny (nawet przy często zmienianych bazach o rozmiarach rzędu setek gigabajtów). Jest sprawny i szybki. W Twoim wypadku wadą byłoby to, że trzeba zrobić plik konfiguracyjny opisujący wszystkie podlegające replikacji tabele i sekwencje.
PS: Jak planujesz skopiować dane z MySQL do PostgreSQL?
W dniu 9 września 2014 16:13 użytkownik Marcin marcin@nicram.net napisał:
W dniu 9 września 2014 16:09 użytkownik Rafał Ramocki rafal.ramocki@gmail.com napisał:
Mysql tez nie wspiera replikacji master-master w ktorej zapis odbywa sie
na
obu wezlach rownoczesnie.
ale odbywa się za pomocą plików binarnych i takie rozwiązanie jest dla mnie wystarczające. nie potrzebuję w danej milisekundzie zapisu na obu jednocześnie, ważne by dane były spójne w możliwie krótkim czasie.
Co do replikacji pg to nie wiem jak natywna ale slony porafi zamieniac funkcja master ze slave w locie.
hmm, chciałbym uniknąć "dodaktowych" daemonów
-- Pozdrawiam Marcin / nicraM _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 9 września 2014 17:18 użytkownik Rafał Ramocki rafal.ramocki@gmail.com napisał:
Co do postgresa to ze slony1 pracuję od czasu 8.1 i jest stabilny (nawet przy często zmienianych bazach o rozmiarach rzędu setek gigabajtów). Jest sprawny i szybki. W Twoim wypadku wadą byłoby to, że trzeba zrobić plik konfiguracyjny opisujący wszystkie podlegające replikacji tabele i sekwencje.
no właśnie, dodatkową konfigurację. widzę, że nowy postgres ma log shiping i wówacza nie trzeba robić dodatkowych konfigów. działa na podobnej zasadzie jak binlogi w mysql
PS: Jak planujesz skopiować dane z MySQL do PostgreSQL?
jakiś czas temu było to wałkowane tu na liście. przeróbka dumpa z mysqla i import do postgresa.
I tak i nie. W PG wg mojej wiedzy replikowane są logi transakcyjne. W MySQL zależnie od wersji i typu replikacji albo zapytania, albo modyfikowane rekordy. Stąd większa zawodność replikacji MySQL pomimo jej dłuższej historii. Gdyby replikacja MySQL miałaby być podobna do MySQL to replikowany musiałby być ib_logfile, a nie binlogi.
Co do dodatkowych configów to Slony ma też zalety. Można z nim robić sztuczki których normalna replikacja PostgreSQL i takie których próżno szukać również w MySQL. - możesz wybierać tabele do replikacji i w ten sposób konstruując odpowiednio konfigurację radiusa/mysql zdecydować że nie potrzbujesz na slave I/O od Accouting-Update. (to MySQL ma) - Możesz replikować część tabel w jedną, a część w drugą stronę - możesz zdecydować, że baza o nazwie 'A' zostanie zreplikowana do bazy o nazwie 'B' (np PG1:accountig -> PG2:accounting_backup i PG2:accouting -> PG1:accouting_backup) - Możesz sobie nawet zażyczyć by baza/tabele były replikowane w ramach tego samego postgresa.
i tak dalej :)
W dniu 9 września 2014 17:23 użytkownik Marcin marcin@nicram.net napisał:
W dniu 9 września 2014 17:18 użytkownik Rafał Ramocki rafal.ramocki@gmail.com napisał:
Co do postgresa to ze slony1 pracuję od czasu 8.1 i jest stabilny (nawet przy często zmienianych bazach o rozmiarach rzędu setek gigabajtów). Jest sprawny i szybki. W Twoim wypadku wadą byłoby to, że trzeba zrobić plik konfiguracyjny opisujący wszystkie podlegające replikacji tabele i sekwencje.
no właśnie, dodatkową konfigurację. widzę, że nowy postgres ma log shiping i wówacza nie trzeba robić dodatkowych konfigów. działa na podobnej zasadzie jak binlogi w mysql
PS: Jak planujesz skopiować dane z MySQL do PostgreSQL?
jakiś czas temu było to wałkowane tu na liście. przeróbka dumpa z mysqla i import do postgresa.
-- Pozdrawiam Marcin / nicraM _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
I tak i nie. W PG wg mojej wiedzy replikowane są logi transakcyjne. W MySQL zależnie od wersji i typu replikacji albo zapytania, albo modyfikowane rekordy. Stąd większa zawodność replikacji MySQL pomimo jej dłuższej historii. Gdyby replikacja MySQL miałaby być podobna do MySQL to replikowany musiałby być ib_logfile, a nie binlogi.
Co jest takiego w tych logach transakcyjnych, że są lepsze od binlogów? W MySQL możesz replikować albo zapytania, albo zmienione dane, albo tryb mieszany - replikacja zapytań, kiedy to możliwe, a jeśli zapytanie za każdym razem może dać inny efekt (np funkcje losowe) to wtedy replikacja danych. Żaden ze mnie DBA, więc nie wiem (i dlatego pytam): jaka jest różnica między replikacją logów transakcji a replikacją zapytań w binlogach? Bo z tego co na szybko znalazłem wynika, że w logu transakcji zapisywane są commitnięte transakcje, czyli (jeśli dobrze myślę) coś, co może za każdym razem dać inny wynik. Tutaj mieszany binlog MySQLa wydaje mi się lepszy. Mógłby to ktoś bliżej wyjaśnić?
- możesz wybierać tabele do replikacji i w ten sposób konstruując odpowiednio konfigurację radiusa/mysql zdecydować że nie potrzbujesz na slave I/O od Accouting-Update. (to MySQL ma)
Nie wiem czy Ciebie dobrze zrozumiałem: chcesz oszczędzić na logowaniu Accouting-Update i logować samo -Start i -Stop? Przecież wtedy w przypadku awarii utracisz spójność/informacje.
W dniu 11.09.2014 21:10, Piotr Piróg napisał(a):
I tak i nie. W PG wg mojej wiedzy replikowane są logi transakcyjne. W MySQL zależnie od wersji i typu replikacji albo zapytania, albo modyfikowane rekordy. Stąd większa zawodność replikacji MySQL pomimo jej dłuższej historii. Gdyby replikacja MySQL miałaby być podobna do MySQL to replikowany musiałby być ib_logfile, a nie binlogi.
Co jest takiego w tych logach transakcyjnych, że są lepsze od binlogów? W MySQL możesz replikować albo zapytania, albo zmienione dane, albo tryb mieszany - replikacja zapytań, kiedy to możliwe, a jeśli zapytanie za każdym razem może dać inny efekt (np funkcje losowe) to wtedy replikacja danych. Żaden ze mnie DBA, więc nie wiem (i dlatego pytam): jaka jest różnica między replikacją logów transakcji a replikacją zapytań w binlogach? Bo z tego co na szybko znalazłem wynika, że w logu transakcji zapisywane są commitnięte transakcje, czyli (jeśli dobrze myślę) coś, co może za każdym razem dać inny wynik. Tutaj mieszany binlog MySQLa wydaje mi się lepszy. Mógłby to ktoś bliżej wyjaśnić?
- możesz wybierać tabele do replikacji i w ten sposób konstruując
odpowiednio konfigurację radiusa/mysql zdecydować że nie potrzbujesz na slave I/O od Accouting-Update. (to MySQL ma)
Nie wiem czy Ciebie dobrze zrozumiałem: chcesz oszczędzić na logowaniu Accouting-Update i logować samo -Start i -Stop? Przecież wtedy w przypadku awarii utracisz spójność/informacje.
Tak to jest jak administratorzy za wszelką cenę tworzą sami sobie problemy. Rozwiązaniem najbardziej stabilnym i wydajnym dla FreeRadius jest użycie do uwierzytelniania rlm_files, zaś do logowania accountingu modułu linelog. Accounting z ładnie sformatowanego pliku tekstowego można co jakiś czas (np. co 5 minut) przeanalizować i umieścić stosowne dane w bazie sql. I nie ma ryzyka utraty jakichś danych przy replikacjach, padzie serwera sql, etc... Do tego skaluje się łatwo do wielu tysięcy klientów.
Już tłumaczę dlaczego log transakcyjny jest lepszy od binloga z MySQL. W bazach ACID ostatnia literka czyli "Durability" jest zapewniona właśnie dzięki logom transakcyjnym. Dane najpierw lądują w logu transakcyjnym, następuje flush wszystkich danych na dysk (fsync/fdatasync), a następnie dane zapisywane są w docelowe miejsce. W wypadku awarii zasilania/systemu/braku miejsca na dysku/oom jest pewność, że to co znalazło się w logach transakcyjnych jest bezpieczne, bo baza sprawdza przy starcie i w razie czego ponawia zapis w docelowe miejsca odtwarzając operacje które znalazły się w logach transakcyjnych.
W wypadku MySQL są dwa miejsca docelowe. Binlog też jest zdaje się domyślnie fsyncowany, ale może się zdarzyć tak, że dane w logu transakcyjnego zostaną skutecznie zapisane na dysk, a dane z binloga nie. Co więcej może się zdarzyć też tak, że w logu transakcyjnym zapisze się cała transakcja, a w binlogu tylko połowa. Po starcie takiej replikacji na slave można otrzymać różne i nie zawsze przewidywalne efekty. Ponad to dodatkowy fsync może też uderzać w wydajność.
Dlatego nawet robiony na wąsach slony do postgresa jest bardziej niezawodny ponieważ nawet u niego dane replikacyjne podlegają tym samym zasadom bezpieczeństwa co dane replikowane. W wypadku binlogów i MySQL tak nie jest. Poziom bezpieczeństwa i spójności danych w binlogach jest bardziej zbliżony do MyISAM niż InnoDB z tą różnicą że metod naprawy bez utraty zmian i ponownego zestawiania replikacji jest jakby trochę mniej.
Co do accountingu mówię jedynie, że możesz (nie musisz) stworzyć taką konfigurację w której w normalnych okolicznościach zapisujesz wszystko, a replikujesz tylko informacje o pełnych sesjach. Ale to tylko przykład zastosowania pasujący do sytuacji w której SLAVE jest wolniejszy/ma inne zadania. Slony ma duże możliwości - między innymi dlatego nadal się rozwija pomimo istnienia replikacji w PG.
Dla przykładu wiem o instytucji w której ważne dane online-owe były synchronizowane pomiędzy aplikacjami właśnie poprzez replikację kilku tabel je zawierających. Dane lądują w trzech tabelach na serwerze A i korzysta z nich aplikacja która ma nie tylko te trzy tabele, z danych korzysta też aplikacja mająca bazę na maszynie B oraz jeszcze inna mająca bazę na maszynie C (master) i D (slave). Bazy C i D zawierają trzy tabele z bazy A (replikowane) baza aplikacja trzyma własne dane w tabelach na C i replikuje część z nich (łącznie z onlineowymi) na D, by na D wykonywać co bardziej kosztowne SELECTy.
W dniu 11 września 2014 21:10 użytkownik Piotr Piróg pirogpiotr@gmail.com napisał:
I tak i nie. W PG wg mojej wiedzy replikowane są logi transakcyjne. W
MySQL
zależnie od wersji i typu replikacji albo zapytania, albo modyfikowane rekordy. Stąd większa zawodność replikacji MySQL pomimo jej dłuższej historii. Gdyby replikacja MySQL miałaby być podobna do MySQL to
replikowany
musiałby być ib_logfile, a nie binlogi.
Co jest takiego w tych logach transakcyjnych, że są lepsze od binlogów? W MySQL możesz replikować albo zapytania, albo zmienione dane, albo tryb mieszany - replikacja zapytań, kiedy to możliwe, a jeśli zapytanie za każdym razem może dać inny efekt (np funkcje losowe) to wtedy replikacja danych. Żaden ze mnie DBA, więc nie wiem (i dlatego pytam): jaka jest różnica między replikacją logów transakcji a replikacją zapytań w binlogach? Bo z tego co na szybko znalazłem wynika, że w logu transakcji zapisywane są commitnięte transakcje, czyli (jeśli dobrze myślę) coś, co może za każdym razem dać inny wynik. Tutaj mieszany binlog MySQLa wydaje mi się lepszy. Mógłby to ktoś bliżej wyjaśnić?
- możesz wybierać tabele do replikacji i w ten sposób konstruując
odpowiednio konfigurację radiusa/mysql zdecydować że nie potrzbujesz na slave I/O od Accouting-Update. (to MySQL ma) Nie wiem czy Ciebie dobrze zrozumiałem: chcesz oszczędzić na logowaniu Accouting-Update i logować samo -Start i -Stop? Przecież wtedy w przypadku awarii utracisz spójność/informacje. _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Podejście trochę z innej beczki. Jeżeli postawimy LMS pod proxmoxem można zrobić klaster z sieciowym raidem. Niema znaczenia postgres czy mysql.
Wtedy w każdej chwili mamy idealne kopie systemu. Tyle że do tego potrzebne są 3 maszynki. Przy 2 jeżeli padnie jedna będzie trzeba się pomęczyć z synchronizacją. Przy 3 maszynkach 2 działające mając większość wymuszą na 3 synchronizację.
Jeżeli wykorzystywane są dokumenty LMS to replikacja bazy nie rozwiązuje problemu awarii.
Dnia 2014-09-09, wto o godzinie 14:19 +0200, Marcin pisze:
Witam Panowie, podpowiedzcie rozwiązanie. generalnie mam postawionego lmsa z mysql i radiusem na jednej maszynie. chciałbym postawić bratni serwer z tymi samymi usługami i replikowaną bazą. tak by w klientach wpisywać dwa serwery radius i bym mógł w każdej chwili któryś wyłączyć bez odczuwalności dla sesji PPPoE.
dobrze w tym wypadku sprawdziła by się replikacja master-master dla mysql, ale tak zachwalany postgres jest lepszy i szybszy. niestety nie wspiera on takiej replikacji jak mysql, albo jeszcze o tym nie doczytałem. jest to najlepszy moment na przejście na postgresa gdzyż będę stawiał dwie nowe maszynki oddalone od siebie lokacyjnie.
jakie najlepsze rozwiązanie wybrać? mysql czy postres? z gróy dzięki za sugestie i podpowiedzi.
Dnia 2014-09-09, wto o godzinie 16:33 +0200, Sylwester Zdanowski pisze:
Podejście trochę z innej beczki. Jeżeli postawimy LMS pod proxmoxem można zrobić klaster z sieciowym raidem. Niema znaczenia postgres czy mysql.
Wtedy w każdej chwili mamy idealne kopie systemu. Tyle że do tego potrzebne są 3 maszynki. Przy 2 jeżeli padnie jedna będzie trzeba się pomęczyć z synchronizacją. Przy 3 maszynkach 2 działające mając większość wymuszą na 3 synchronizację.
Jeżeli wykorzystywane są dokumenty LMS to replikacja bazy nie rozwiązuje problemu awarii.
Dnia 2014-09-09, wto o godzinie 14:19 +0200, Marcin pisze:
Witam Panowie, podpowiedzcie rozwiązanie. generalnie mam postawionego lmsa z mysql i radiusem na jednej maszynie. chciałbym postawić bratni serwer z tymi samymi usługami i replikowaną bazą. tak by w klientach wpisywać dwa serwery radius i bym mógł w każdej chwili któryś wyłączyć bez odczuwalności dla sesji PPPoE.
dobrze w tym wypadku sprawdziła by się replikacja master-master dla mysql, ale tak zachwalany postgres jest lepszy i szybszy. niestety nie wspiera on takiej replikacji jak mysql, albo jeszcze o tym nie doczytałem. jest to najlepszy moment na przejście na postgresa gdzyż będę stawiał dwie nowe maszynki oddalone od siebie lokacyjnie.
jakie najlepsze rozwiązanie wybrać? mysql czy postres? z gróy dzięki za sugestie i podpowiedzi.
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
inne rozwiązanie :
jest serwer (master) z mysql, po drugiej stronie sieci jest slave zrobiony na atomie, sama baza i freeradius
mam skrypcik który co 6h robi dump db (bez statystyk) wysyła go do slave i tam importuje do bazy , wszystko za pomocą połączenia ssh po kluczu i scp,
na Mietkach mam podane dwa adresy do radiusa mastera i slave, tak że jak master będzie miał pad to z drugiej maszyny idzie autoryzacja dla dhcp, pppie i wifi :)
Rozwiązanie nietypowe ale nie martwię się czy replikacja prawidłowo działa
z tym, ze na mietkach możesz zrobić x połączeń na ten sam login i hasło. sprawę załatwia simultaneous-use, z tym, że przy takiej "replikacji" co piszesz, nie ma prawa prawidłowo zadziałać bo nie będzie na slave informacji o obecnych sesjach
W dniu 9 września 2014 16:41 użytkownik Sylwester Kondracki sylwester.kondracki@gmail.com napisał:
Dnia 2014-09-09, wto o godzinie 16:33 +0200, Sylwester Zdanowski pisze:
Podejście trochę z innej beczki. Jeżeli postawimy LMS pod proxmoxem można zrobić klaster z sieciowym raidem. Niema znaczenia postgres czy mysql.
Wtedy w każdej chwili mamy idealne kopie systemu. Tyle że do tego potrzebne są 3 maszynki. Przy 2 jeżeli padnie jedna będzie trzeba się pomęczyć z synchronizacją. Przy 3 maszynkach 2 działające mając większość wymuszą na 3 synchronizację.
Jeżeli wykorzystywane są dokumenty LMS to replikacja bazy nie rozwiązuje problemu awarii.
Dnia 2014-09-09, wto o godzinie 14:19 +0200, Marcin pisze:
Witam Panowie, podpowiedzcie rozwiązanie. generalnie mam postawionego lmsa z mysql i radiusem na jednej maszynie. chciałbym postawić bratni serwer z tymi samymi usługami i replikowaną bazą. tak by w klientach wpisywać dwa serwery radius i bym mógł w każdej chwili któryś wyłączyć bez odczuwalności dla sesji PPPoE.
dobrze w tym wypadku sprawdziła by się replikacja master-master dla mysql, ale tak zachwalany postgres jest lepszy i szybszy. niestety nie wspiera on takiej replikacji jak mysql, albo jeszcze o tym nie doczytałem. jest to najlepszy moment na przejście na postgresa gdzyż będę stawiał dwie nowe maszynki oddalone od siebie lokacyjnie.
jakie najlepsze rozwiązanie wybrać? mysql czy postres? z gróy dzięki za sugestie i podpowiedzi.
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
inne rozwiązanie :
jest serwer (master) z mysql, po drugiej stronie sieci jest slave zrobiony na atomie, sama baza i freeradius
mam skrypcik który co 6h robi dump db (bez statystyk) wysyła go do slave i tam importuje do bazy , wszystko za pomocą połączenia ssh po kluczu i scp,
na Mietkach mam podane dwa adresy do radiusa mastera i slave, tak że jak master będzie miał pad to z drugiej maszyny idzie autoryzacja dla dhcp, pppie i wifi :)
Rozwiązanie nietypowe ale nie martwię się czy replikacja prawidłowo działa --
Pozdrawiam Sylwester Kondracki Tel. 724-680-757 www.pati.net.pl
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Niby fajne rozwiazanie, tylko w MySQLu przy dumpie robione sa locki na tabelach, co uniemozliwia w czasie locka wykonywanie jakiegos Inserta badz update'a na bazie master.
W dniu 09.09.2014, 16:41, Sylwester Kondracki pisze:
Dnia 2014-09-09, wto o godzinie 16:33 +0200, Sylwester Zdanowski pisze:
Podejście trochę z innej beczki. Jeżeli postawimy LMS pod proxmoxem można zrobić klaster z sieciowym raidem. Niema znaczenia postgres czy mysql.
Wtedy w każdej chwili mamy idealne kopie systemu. Tyle że do tego potrzebne są 3 maszynki. Przy 2 jeżeli padnie jedna będzie trzeba się pomęczyć z synchronizacją. Przy 3 maszynkach 2 działające mając większość wymuszą na 3 synchronizację.
Jeżeli wykorzystywane są dokumenty LMS to replikacja bazy nie rozwiązuje problemu awarii.
Dnia 2014-09-09, wto o godzinie 14:19 +0200, Marcin pisze:
Witam Panowie, podpowiedzcie rozwiązanie. generalnie mam postawionego lmsa z mysql i radiusem na jednej maszynie. chciałbym postawić bratni serwer z tymi samymi usługami i replikowaną bazą. tak by w klientach wpisywać dwa serwery radius i bym mógł w każdej chwili któryś wyłączyć bez odczuwalności dla sesji PPPoE.
dobrze w tym wypadku sprawdziła by się replikacja master-master dla mysql, ale tak zachwalany postgres jest lepszy i szybszy. niestety nie wspiera on takiej replikacji jak mysql, albo jeszcze o tym nie doczytałem. jest to najlepszy moment na przejście na postgresa gdzyż będę stawiał dwie nowe maszynki oddalone od siebie lokacyjnie.
jakie najlepsze rozwiązanie wybrać? mysql czy postres? z gróy dzięki za sugestie i podpowiedzi.
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
inne rozwiązanie :
jest serwer (master) z mysql, po drugiej stronie sieci jest slave zrobiony na atomie, sama baza i freeradius
mam skrypcik który co 6h robi dump db (bez statystyk) wysyła go do slave i tam importuje do bazy , wszystko za pomocą połączenia ssh po kluczu i scp,
na Mietkach mam podane dwa adresy do radiusa mastera i slave, tak że jak master będzie miał pad to z drugiej maszyny idzie autoryzacja dla dhcp, pppie i wifi :)
Rozwiązanie nietypowe ale nie martwię się czy replikacja prawidłowo działa
Locki nie muszą być zakładane przy InnoDB.
W dniu 9 września 2014 17:08 użytkownik "Czerepuk, Łukasz (JPK)" < lukasz@jpk.pl> napisał:
Niby fajne rozwiazanie, tylko w MySQLu przy dumpie robione sa locki na tabelach, co uniemozliwia w czasie locka wykonywanie jakiegos Inserta badz update'a na bazie master.
W dniu 09.09.2014, 16:41, Sylwester Kondracki pisze:
Dnia 2014-09-09, wto o godzinie 16:33 +0200, Sylwester Zdanowski pisze:
Podejście trochę z innej beczki. Jeżeli postawimy LMS pod proxmoxem można zrobić klaster z sieciowym raidem. Niema znaczenia postgres czy mysql.
Wtedy w każdej chwili mamy idealne kopie systemu. Tyle że do tego potrzebne są 3 maszynki. Przy 2 jeżeli padnie jedna będzie trzeba się pomęczyć z synchronizacją. Przy 3 maszynkach 2 działające mając większość wymuszą na 3 synchronizację.
Jeżeli wykorzystywane są dokumenty LMS to replikacja bazy nie rozwiązuje problemu awarii.
Dnia 2014-09-09, wto o godzinie 14:19 +0200, Marcin pisze:
Witam Panowie, podpowiedzcie rozwiązanie. generalnie mam postawionego lmsa z mysql i radiusem na jednej maszynie. chciałbym postawić bratni serwer z tymi samymi usługami i replikowaną bazą. tak by w klientach wpisywać dwa serwery radius i bym mógł w każdej chwili któryś wyłączyć bez odczuwalności dla sesji PPPoE.
dobrze w tym wypadku sprawdziła by się replikacja master-master dla mysql, ale tak zachwalany postgres jest lepszy i szybszy. niestety nie wspiera on takiej replikacji jak mysql, albo jeszcze o tym nie doczytałem. jest to najlepszy moment na przejście na postgresa gdzyż będę stawiał dwie nowe maszynki oddalone od siebie lokacyjnie.
jakie najlepsze rozwiązanie wybrać? mysql czy postres? z gróy dzięki za sugestie i podpowiedzi.
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
inne rozwiązanie :
jest serwer (master) z mysql, po drugiej stronie sieci jest slave zrobiony na atomie, sama baza i freeradius
mam skrypcik który co 6h robi dump db (bez statystyk) wysyła go do slave i tam importuje do bazy , wszystko za pomocą połączenia ssh po kluczu i scp,
na Mietkach mam podane dwa adresy do radiusa mastera i slave, tak że jak master będzie miał pad to z drugiej maszyny idzie autoryzacja dla dhcp, pppie i wifi :)
Rozwiązanie nietypowe ale nie martwię się czy replikacja prawidłowo działa
-- Pozdrawiam, Łukasz Czerepuk JPK www.jpk.pl
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
uczestnicy (7)
-
"Czerepuk, Łukasz (JPK)" -
Marcin -
Piotr Piróg -
Rafał Ramocki -
Sylwester Kondracki -
Sylwester Zdanowski -
Tomasz Chiliński