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