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.