Synchronizacja dwóch baz danych

Dzień dobry,
Na wstępie nie używam żadnego orm.
Są 2 bazy danych PostgreSQL + rest api w c#. Powiedzmy, że jest w każdej z nich tableka client z jakimiś tam kolumnami.
Jeśli na jednej bazie danych zrobię insert/update/delete to na drugiej ma się stać to samo.
Jak osiągnąc taką synchornizacje?
Żadne głupie pomysły typu wysyłanie backupu co jakiś czas nie wchodza w grę.
Teoretycznie mógłbym zrobić trigger i po każdym jego wyzwoleniu wysyłać to do api drugiej bazy i nawzajem ale wolę zapytać profesjonalistów.

Jak osiągnąc to najmniejszym wysiłkiem? To był tylko przykład i takich tabelek mam więcej i MUSZĄ być przesyłane w czasie rzeczywistym.
Chodzi mi o sam pomysł na algorytm synchronizacji.
Dodac kolumne z timestamp do każdej tabelki i to porównywać?
To musi synchornizować te bazy w 2 strony i być odporne na potencjalną utratę połączenia tzn. jak tylko się przywróci połączenie to przesłać wzystkie zmiany do drugiej bazy.

Wiem, że na pewno sie z czymś podobnym spotkaliście i możecie mi pomóc.

Naprawić chory design.
Pachnie, jakby BARDZO miało być w filozofii mikroseriwsowej, ze względów np religijnych, bez elementarnych tu obowiązujących zasad.

lepszy jest zdrowy monolit, niż chory system mikoserwisowy

Niczego nie musisz wymyślać, żadnych triggerów itp. Skorzystaj z opcji, które Postgres oferuje w standardzie.
Poczytaj o haśle "replikacja" http://jsystems.pl/blog/artykul.html?id=423 (to jeden z przykładowych linków). W dużym skrócie - dajesz jedną bazę jako główną - master, a inne mają się do niej podłączać jako slave i samodzielnie, w czasie rzeczywistym, synchronizować swoją zawartość.

@cerrato:
To będzie działało gdy master będzie widczony w internecie a slave będzie gdzieś schowany za natem bez publicznego IP?

A kolega słyszał o przekierowywaniu portów oraz DynDNS? :P

cerrato napisał(a):

A kolega słyszał o przekierowywaniu portów oraz DynDNS? :P

Chiałbym tego uniknąć. Nie zawsze jest możliwość przekierowania portów.
Naprawdę nie da się tego zrobić używając asp.net web api albo czegoś inengo np. spring boot i przesyłając dane po http?

Można to zrobić na 100 sposobów, ale tak na chłopski rozum - jakie sa szanse, że Tobie się uda to zrobić lepiej, niż twórcom Postgresa - fachowcom od baz danych? I że Twoje rozwiązanie będzie lepsze, niż dedykowane do tego celu, testowane na setkach tysięcy baz przez wiele lat. No i jeszcze pomyśl, ile czasu na to poświecisz - a możesz skorzystać z gotowej funkcjonalności, którą dostajesz praktycznie natychmiast po zainstalowaniu baz.

cerrato napisał(a):

Można to zrobić na 100 sposobów, ale tak na chłopski rozum - jakie sa szanse, że Tobie się uda to zrobić lepiej, niż twórcom Postgresa - fachowcom od baz danych? I że Twoje rozwiązanie będzie lepsze, niż dedykowane do tego celu, testowane na setkach tysięcy baz przez wiele lat. No i jeszcze pomyśl, ile czasu na to poświecisz - a możesz skorzystać z gotowej funkcjonalności, którą dostajesz praktycznie natychmiast po zainstalowaniu baz.

Jeden szczegół, w przypadku gdy padnie połączenie z internetem aplikacja nie będzie mogła łączyć się z serwerem master a do tych slave nie można zapisywać?
I nie chciałbym wszystkiego replikować, bo po co jednemu klientowi dane drugiego.

No a tak na logike - jak to sobie wyobrażasz? Masz 2 bazy, w obu masz klienta o ID=45.
Pada połączenie z netem i obie bazy zaczynają żyć własnym życiem. W jednej z nich klient o takim ID zostaje skasowany, a w drugiej zmieniają jego imię z Roman na Błażej.
Chwilę późnej net wraca, bazy się ze sobą łączą i starają się synchronizować. I co mają zrobić z tym klientem - na drugiej tak, jak na pierwszej - skasować, czy może na pierwszej go przywrócić i ponadto zmienić imię?

Tak się nie robi. Masz jedną bazę do zapisu, pozostałe się z nią synchronizują i można ewentualnie je udostępnić do odczytu, żeby przyspieszyć odczyt albo odciążyć serwer główny.

Poza tym w pierwszym poście nie było ani słowa o zapisach do kopii, więc mam wrażenie, że trochę zmieniasz wymagania. Może lepiej będzie jak napiszesz co chcesz osiągnąć i po co Ci to jest.

cerrato napisał(a):

Pada połączenie z netem i obie bazy zaczynają żyć własnym życiem. W jednej z nich klient o takim ID zostaje skasowany, a w drugiej zmieniają jego imię z Roman na Błażej.
Chwilę późnej net wraca, bazy się ze sobą łączą i starają się asynchronizować. I co mają zrobic z tym klientem - na drugiej tak, jak był na pierwszej - skasować, czy może na pierwszej go przywrócić i ponadto zmienić imię?

Takie rzeczy to umie tylko Cassandra i to tylko do siedmiu dni (przy domyślnej konfiguracji). Jak? Przez siedem dni jest przechowywany znacznik usunięcia "rekordu". Ale to jest zaimplementowane na poziomie samej bazy

Poza tym w pierwszym poście nie było ani słowa o zapisach do kopii, więc mam wrażenie, że trochę zmieniasz wymagania. Może lepiej będzie jak napiszesz co chcesz osiągnąć i po co Ci to jest.

Przepraszam, zapomniałem napisać, że to ma też działać offline.

Chcę mieć nadzór 24h nad tym co robi klient i jak jemu popsuje się ta baza slave to urządzenia, które się do niej łączyły kontynują prace tylko, że łączą się do centralnego serwera.

Mam cos, nazywa się multi master

nie chciałbym zanadto studzić Twojego entuzjazmu, ale raczej nie tędy droga.

PostgreSQL has built-in single-master replication, but unfortunately, there is no multiple-master replication in mainline PostgreSQL. There are some Multimaster replication solutions available, some of these are in the form applications and some are PostgreSQL forks. These forks have their own small communities and are mostly managed by a single company, but not by the mainline PostgreSQL community.

Zdajesz sobie sprawę, że tym pomysłem z replikacją, trybem offline, synchronizacją w czasie rzeczywistym itd. próbujesz obejść PACELC theorem?

Masz takie dwa dylematy:

• w przypadku gdy np. padnie sieć, pakiety się pogubią itd. albo będziesz musiał powiedzieć "no sorry, sieć padła, nie obsłużę żądania bo dane się rozjadą" albo "no sorry, staraliśmy się zapewnić dostępność usługi, ale przez to bazy się rozsynchronizowały / część danych jest niedostępna / wstaw inne niekorzystne okoliczności"
• w przypadku gdy wszystko śmiga ładnie i działa musisz zdecydować, czy wolisz aby wszystko synchronizowało się na bieżąco i było spójne, czy żeby wszystko działo się "w czasie rzeczywistym". Pamiętaj, że sam akt synchronizacji między dwiema bazami może lekką rączką połknąć paręset milisekund, albo nawet więcej, zależnie od ilości danych. Jeśli chcesz zawsze zapewnić minimalne opóźnienia to robisz to kosztem spójności.

Kolejny wątek, że OP ukrywa pełną treść zagadnienia, ujawnia to po kilkunastu postach w jakiś fragmencikach, a ty publiko produkuj się co wiesz.

Kolejny XY problem, który należało by u samych fundamentów inaczej zaprojektować, w szczególności nie patrzeć "bazą danych" a inną koncepcją (event sourcing, saga, whatever)