Witam...

Może przedstawię problem.

Otóż mam zmodyfikować system. Kopie systemu znajdują się w różnych miejscach w sieci (po jednej kopii na klienta).

System zawiera 2 poziomy danych: globalne i lokalne. Oba typy danych są takie same.

Dane lokalne są tylko i wyłącznie do dyspozycji użytkowników zalogowanych na danej kopii systemu (oni również mogą je modyfikować, dodawać usuwać etc.).
Dane globalne mają być dostępne dla użytkowników korzystających ze wszystkich kopii systemu (klient ma możliwość jedynie używania danych w trybie read-only).

W tej chwili korzystanie z danych globalnych wygląda w ten sposób, że dane są przekopiowywane do każdej kopii systemu za każdym razem gdy następuje ich zmiana. Problem polega na tym, że (na szczęście) klientów (kopii systemu) jest coraz więcej, tak samo jak coraz większa jest liczba danych. A ciągłe kopiowanie danych staje się coraz bardziej uciążliwe i "błędo-genne".

Chcę stworzyć jeden serwer bazy danych (dalej nazwany GDB) w jednej lokalizacji i chcę aby wszystkie wersje systemu komunikowały się z nim w celu pobrania danych globalnych.

Teraz pytania:

1. Czy to jest dobre podejście?
2. Jeśli tak, to jak najlepiej to zrobić? Czy lepiej otworzyć port bazy danych na GDB? Czy może lepiej utworzyć tam jeszcze serwer SOAP i dzięki temu pobierać dane dla klientów.
3. Czy może lepiej utworzyć w jakiś sposób systemy replikacji danych?

Jeśli ktoś miał kiedykolwiek podobny problem proszę o podzielenie się doświadczeniem.

Pozdrawiam.
Cezar708

Skoro nikt inny nie ma nic mądrzejszego do powiedzenia to ja dodam swoją opinię:

Myślę że warto odpowiedzieć sobie na następujące pytania:

Czy system jest systemem krytycznym (tzn jego niedostępność powoduje duże straty)?

Jeżeli tak to replikacja jest konieczna ze względów bezpieczeństwa, ale można ją wykonać w sposób w pełni automatyczny
i przeźroczysty dla systemu. Stosuje się do tego właśnie bazy kopie i bazę główną. Użytkownicy
mogą czytać z którejkolwiek z baz a zapisywać do głównej (odwrotnie niż opisałeś). Baza
główna okresowo wysyła TYLKO zmiany do baz kopii. Dostęp do bazy w takim wypadku odbywa się przez punkt dostępowy i to właśnie punkt dostępowy decyduje która baza obsłuży klienta, a nie sam system. Chyba istnieją gotowe systemy przystosowane do tego celu.

Czy replikacja nie wynika z konieczności szybkiego dostępu (szybkie łącze) do danych?

W takim wypadku prawdopodobnie trzeba pozostać przy wielu bazach i napisać system replikacji.

Zauważ, że najlepiej aby to baza główna obsługiwała zmiany i kopiowała TYLKO zmiany na kopie (gdzie to możliwe to okresowo). Z kolei kopie powinny być read-only. Dlaczego? Ponieważ z reguły zmiany są dużo rzadsze niż wykonywanie operacji odczytu. Poza tym zmiany wymagają dużo mniejszego transferu niż operacje odczytu (odczyt wymaga często zwracania wielu rekordów).
Można również zmieniać jednocześnie główną i aktywną lokalną, co pozwoli na okresowe wprowadzanie zmian w innych bazach lokalnych. Dlaczego? Ponieważ użytkownik wprowadzający zmiany będzie je widział od razu. Z kolei użytkownicy na innych serwerach zobaczą je dopiero po pewnym czasie (tak jakby zmiana została dokonana później. W tym wypadku należy jednak zwrócić uwagę na zachowanie spójności danych - czy i jakie dane mogą być zmieniane okresowo? Co się stanie gdy serwer padnie w stanie gdy bazy danych są inne (zasada: zmiany zawsze najpierw na głównej bazie)

Jeżeli replikacja nie jest potrzebna bo ani nie zależy nam na szybkości, ani na bezpieczeństwie to najlepiej po prostu postawić jeden serwer i mieć spokój.

Dzięki za wyczerpującą odpowiedź.



Czyli pozostaję przy wielu bazach danych i muszę napisać system replikacji.

Używam PostgreSQL, jak wyczytałem w sieci:

(źródło)
Nie jestem pewien czy to jest prawda, choć artykuł jest datowany na 9 stycznia 2008.

Proponuje zewnętrzne rozwiązania:


Czy możecie mi polecić, które rozwiązanie jest lepsze? A może żadne z nich i istnieje jeszcze inny sposób replikacji danych?