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