Replikacja niektórych tabel z jednej bazy danych Postgres do drugiej

Mam następującą sytuację: Mam trzy maszyny z bazami danych postgresql. Jeden komputer przechowuje informacje o koncie klienta (zadzwoń na ten komputer C), a pozostałe dwa urządzenia przechowują informacje o logowaniu klienta (nazywaj je L1 i L2). Powodem podziału jest oddzielne ładowanie na wielu komputerach (więc niektórzy klienci wysyłają informacje logowania do L1, inni do L2 ... a może kiedyś L3, L4, ...).

Podczas pobierania informacji o logowaniu zasadniczo chciałbym móc DOŁĄCZYĆ między tabelami rejestrowania na Ln a tabelami kont klienta na C. W rzeczywistości nie mogę wykonywać takich połączeń (a nawet gdybym mógł, chciałbym aby uniknąć ładowania C).

Myślę, że powielę tabele na C na każdym z L1, L2, ... aby móc wykonywać sprzężenia. Jeśli chodzi o tabele z C, C jest master, a L1, L2, ... są niewolnikami. Ale dla innych tabel na L1, L2, ... te maszyny są mistrzami. Nie jest to dokładnie replikacja master-master i czy nie jest to dokładnie master-slave.

Czy można to namówić na replikację postgres (korzystam z wersji 9.1), a jeśli nie, to istnieją inne pakiety, które wykonałyby to zadanie. W ostateczności mogę napisać kod, który okresowo synchronizuje tabele (toleruję pewne opóźnienia), ale byłoby miło, gdyby nie!

Z góry dziękuję.

W PostgreSQL 9.3 można użyć postgres_fdwdo przezroczystego zapytania do obcej tabeli na innym komputerze.

W starszych wersjach dblinkmoże być opcją, o której wspomniał Andrew.

Inną opcją jest użycie narzędzia takiego jak Londiste lub Slony-I do replikacji żądanych tabel. Polecam do tego Londiste, będzie to znacznie prostsze. Tworzy wyzwalacze na stole w celu wykrycia wstawiania / aktualizacji / usuwania i replikuje je przy użyciu własnego klienta / serwera i systemu kolejkowania do innej bazy danych, gdzie wykonuje odpowiednie wstawianie / aktualizację / usuwanie. Używam go w produkcji na kilku stronach klienckich i działa bardzo dobrze.

Przyszłą opcją (mam nadzieję, że w PostgreSQL 9.5) będzie logiczna replikacja strumieniowania dziennika, logiczna ekstrakcja zestawu zmian i replikacja dwukierunkowa, które umożliwią replikację poszczególnych baz danych lub tabel na poziomie SQL. Część pracy w tym zakresie została poświęcona PostgreSQL 9.4, ale niewystarczająca, aby była użyteczna do tego, co chcesz zrobić.

Aby to osiągnąć, powinieneś użyć dblink i zmaterializowanych widoków. Obie funkcje są wbudowane w najnowsze wersje Postgres:

http://www.postgresql.org/docs/9.3/static/rules-materializedviews.html

http://www.postgresql.org/docs/9.3/static/dblink.html

Zasadniczo budujesz Mview na każdej bazie danych L1, L2 ... z danymi wyodrębnionymi z tabel na C, a następnie używasz odświeżania Mview, aby okresowo aktualizować Mviews tak często, jak to konieczne. Dane są przechowywane lokalnie, więc dostęp do nich jest bardzo szybki. Jest to odpowiednie tylko wtedy, gdy dane są względnie statyczne i nie przeszkadza ci, że lokalne bazy danych czasami zawierają nieco nieaktualne informacje. Powinieneś ustawić częstotliwości odświeżania, aby odpowiednio to zarządzać, a jeśli nie jest to do zaakceptowania, powinieneś po prostu użyć łącza do bazy danych i poradzić sobie z wynikową powolnością.

Jeśli potrzebujesz dodatkowej funkcjonalności, projekt migawek zapewnia zaawansowane funkcje, takie jak szybkie odświeżanie i dzienniki migawek:

http://pgfoundry.org/projects/snapshot/

Dzięki temu odświeżenia będą aktualizować tylko te wiersze, które wymagają aktualizacji, co może uczynić je wyjątkowo szybkimi w przypadku dużych, nieelastycznych zestawów danych, minimalizując zakłócenie działania aplikacji. Domyślnie widoki są całkowicie usuwane i ponownie tworzone w Postgres, co z oczywistych powodów może być bardzo złe z powodu wydajności.