To, czego naprawdę potrzebujesz, to logiczne dekodowanie PostgreSQL 9.4 wsparcie, które pozwala wyodrębnić strumień zmian z serwera. Aby z niego skorzystać, potrzebujesz logicznej wtyczki dekodującej, która zamienia strumień zmian na serwerze w coś, co może wykorzystać Twoja aplikacja. Kilka jest w fazie rozwoju, ale wciąż jest dość wcześnie.
Ponieważ zauważyłeś w komentarzu, że używasz AWS RDS, w tej chwili nie masz szczęścia, ponieważ RDS w momencie pisania tego tekstu nie oferuje żadnych wtyczek dekodujących i do ich zainstalowania potrzebne są uprawnienia superużytkownika.
Nie możesz użyć xmin i xmax do pełnego przyrostowego kopiowania, ponieważ nie możesz wykonywać brudnych odczytów w PostgreSQL, więc nie możesz zobaczyć, czy krotka została DELETE d. Aby użyć identyfikatorów transakcji, musisz zapobiec VACUUM od usuwania „martwych” wierszy, czyli wierszy, których żadna bieżąca transakcja nie musi jeszcze wykonać poprawnie. Musisz także umieć robić brudne odczyty. Żadne z nich nie ma łatwych rozwiązań w PostgreSQL.
Jeśli masz tabele tylko do wstawiania (lub robisz wstawki i aktualizacje, nigdy nie usuwasz i nigdy nie zmieniasz klucza podstawowego wiersza), możesz ewentualnie użyć transakcji xmin. Będziesz musiał poradzić sobie z zawijaniem identyfikatora transakcji
sprawdzając pg_database.datfrozenxid i pg_class.relfrozenxid dla relacji zainteresowania. Zobacz kod źródłowy i komentarze w kodzie, aby uzyskać szczegółowe informacje. VACUUM a brak brudnych odczytów nie stanowi problemu, jeśli nigdy nie usuniesz wpisu, ponieważ nie musisz widzieć „zaginionych” wierszy.
Jeśli to możliwe, użyj dekodowania logicznego w wersji 9.4+. W przypadku starszych wersji, jeśli potrzebujesz pełnej replikacji, musisz zgromadzić kolejkę zmian z wyzwalaczami.
Jeśli możesz całkowicie zabronić usuwania i zmiany klucza podstawowego, możesz użyć xmin aby znaleźć zmienione wiersze, o ile zadbasz o to, aby nie było delete s uruchomić lub jakakolwiek update s zmieniające primary key s.
