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