Temat: replikacja

Witam

Chcemy zastosować dla naszego oprogramowania replikacje bazy danych jedną lokalną znajdująca się w ramach tej samej serwerowni oraz drugą replikacje w serwerowni w innej lokalizacji.

Czy ktoś ma doświadczenie z tego typu rozwiązaniami i podpowie jak to najlepiej zrealizować?

Czy opóźnienia w komunikacji z inna serwerownią nie wpływają na stabilność i wydajność lokalnej części systemu?

Temat: replikacja

Marcin Adamowicz:
Witam

Chcemy zastosować dla naszego oprogramowania replikacje bazy danych jedną lokalną znajdująca się w ramach tej samej serwerowni oraz drugą replikacje w serwerowni w innej lokalizacji.

Czy ktoś ma doświadczenie z tego typu rozwiązaniami i podpowie jak to najlepiej zrealizować?

Czy opóźnienia w komunikacji z inna serwerownią nie wpływają na stabilność i wydajność lokalnej części systemu?

Ale po co ta replikacja, co chcecie uzyskać? Zapis do obu baz, czy kopia ma być tylko do odczytu, czy tylko do szybkiego zastąpienia głównego serwera, gdy coś stanie, czy jako backup, czy coś innego?

Chcecie replikować cały klaster, czy może kilka wybranych baz, czy może tylko kilka wybranych tabel?

No i podstawowe pytanie: która wersja bazy?

A rozwiązania to tak na szybko: log shipping (co jest wbudowane w najnowsze wersje bazy), Slony i Bucardo.Szymon G. edytował(a) ten post dnia 29.10.12 o godzinie 18:29

Temat: replikacja

Na replikacji lokalnej chcemy uzyskać szybkość i stabilność
Na replikacji na inną serwerownie chcemy uzyskać większą stabilność całego systemu w przypadku np ataku dos oraz awarii większej w serwerowni. Klient wymaga dużej niezawodności i jako jedno z wytycznych jest przechowywanie danych w dwóch geograficznie różnych serwerowniach. Czyli trzeba replikować dane i bazę.

A jakieś doświadczenie z tą wbudowaną nową replikacją? dobrze stabilnie to działa ?

Temat: replikacja

Marcin Adamowicz:
Na replikacji lokalnej chcemy uzyskać szybkość i stabilność
Na replikacji na inną serwerownie chcemy uzyskać większą stabilność całego systemu w przypadku np ataku dos oraz awarii większej w serwerowni. Klient wymaga dużej niezawodności i jako jedno z wytycznych jest przechowywanie danych w dwóch geograficznie różnych serwerowniach. Czyli trzeba replikować dane i bazę.

A jakieś doświadczenie z tą wbudowaną nową replikacją? dobrze stabilnie to działa ?

Skoro klient chce, to rozumiem, że replikujecie raczej cały klaster… a skoro tak, to proponuję replikować najprościej, czyli log shipping. W skrócie działa to tak, że Postgres i tak zapisuje pewne pliki na dysku zanim zapisze te same dane w plikach z danymi. To pozwala na nietracenie danych podczas padnięcia maszyny czy Postgresa.

Te logi są używane do naprawiania danych po padzie systemu. Potem ktoś wpadł na pomysł, żeby użyć ich do skopiowania na inną maszynę i odtwarzania tam zmian w bazie z tych logów.

W najnowszej wersji bazy, jeśli dobrze pamiętam, można kaskadowo robić tę replikację, a przede wszystkim: baza master jest oczywiście do zapisu, a pozostałe bazy slave są do odczytu.

Działa to stabilnie, wszystko zależy od łącza pomiędzy bazami i sprzętu.

Więcej informacji jest tutaj: http://www.postgresql.org/docs/9.2/static/warm-standby...Szymon G. edytował(a) ten post dnia 29.10.12 o godzinie 20:20

Temat: replikacja

Rozwiązań jest parę - wspomniany przez Szymona log shipping. Można też replikować konkretne zmiany np. Slony. W najnowszej wersji może być multi - master. Wszystko zależy od konkretnych warunków. Pod spodem to wygląda tak, że jak masz logi - musisz je przesłać. Między takimi przesłaniami - slave ma poślizg. Slony robi tak, że na masterze zakładane są tabele, w których odkładane są zmiany, slave się rejestruje na zmiany i na bieżąco je wykonuje na swojej bazie. To rozwiązanie oznacza, że narzut na transakcyjność jest jeszcze większy. Z grubsza można powiedzieć, że jak zmian jest bardzo dużo, log shipping wypada lepiej. Jak zmian jest mało - Slony daje radę, a nie trzeba kopiować plików z logami. Z drugiej strony - utrzymywanie struktury bazy replikowanej slonym bywa upierdliwe. Ostatnio trochę zarobiony jestem i nie bardzo mam czas, żeby grupy czytać - mailem chyba będzie najszybciej...

Temat: replikacja

Michał Z.:
Rozwiązań jest parę - wspomniany przez Szymona log shipping. Można też replikować konkretne zmiany np. Slony. W najnowszej wersji może być multi - master. Wszystko zależy od konkretnych warunków. Pod spodem to wygląda tak, że jak masz logi - musisz je przesłać. Między takimi przesłaniami - slave ma poślizg. Slony robi tak, że na masterze zakładane są tabele, w których odkładane są zmiany, slave się rejestruje na zmiany i na bieżąco je wykonuje na swojej bazie. To rozwiązanie oznacza, że narzut na transakcyjność jest jeszcze większy. Z grubsza można powiedzieć, że jak zmian jest bardzo dużo, log shipping wypada lepiej. Jak zmian jest mało - Slony daje radę, a nie trzeba kopiować plików z logami. Z drugiej strony - utrzymywanie struktury bazy replikowanej slonym bywa upierdliwe. Ostatnio trochę zarobiony jestem i nie bardzo mam czas, żeby grupy czytać - mailem chyba będzie najszybciej...

Mała uwaga: Slony nie replikuje DDLi i trzeba je robić specjalnie, co utrudnia zabawę. Log shipping replikuje wszystko i nie trzeba go informować o niczym.

Temat: replikacja

Szymon G.:

Michał Z.:
Rozwiązań jest parę - wspomniany przez Szymona log shipping. Można też replikować konkretne zmiany np. Slony. W najnowszej wersji może być multi - master. Wszystko zależy od konkretnych warunków. Pod spodem to wygląda tak, że jak masz logi - musisz je przesłać. Między takimi przesłaniami - slave ma poślizg. Slony robi tak, że na masterze zakładane są tabele, w których odkładane są zmiany, slave się rejestruje na zmiany i na bieżąco je wykonuje na swojej bazie. To rozwiązanie oznacza, że narzut na transakcyjność jest jeszcze większy. Z grubsza można powiedzieć, że jak zmian jest bardzo dużo, log shipping wypada lepiej. Jak zmian jest mało - Slony daje radę, a nie trzeba kopiować plików z logami. Z drugiej strony - utrzymywanie struktury bazy replikowanej slonym bywa upierdliwe. Ostatnio trochę zarobiony jestem i nie bardzo mam czas, żeby grupy czytać - mailem chyba będzie najszybciej...

Mała uwaga: Slony nie replikuje DDLi i trzeba je robić specjalnie, co utrudnia zabawę. Log shipping replikuje wszystko i nie trzeba go informować o niczym.

Generalnie - każde rozwiązanie ma swoje plusy i minusy. W Slonym trzeba pamiętać od DDLach, bo inaczej replikacja pada. Z drugiej strony - zakładanie indeksu i replikowanie zmian? Bywa to dość kosztowne. Czasem taniej jest replikować operacje, a czasem zmiany w danych. Pewnie, w kolejnych wersjach to też ogarną. Skoro w MySQLu się dało, to tu też powinno się udać. Jak by jeszcze zrobili multi master na tym... :) Póki co - trzeba mieć świadomość z ograniczeń każdego z rozwiązań i chyba tyle.

Temat: replikacja

To odświeżę temat.

Potrzebuje zrobić replikację na Postgres 9.2.3. Gdzie jeden z serwerów jest tylko do odczytu. Dane nie muszą być aktualizowane na bieżąco tylko np. raz w nocy. Co byście polecili. Chce replikować dwie bazy. Dzięki za wszystkie sugestie.