Wstęp

Dotychczasowe wdrożenia replikacji przy użyciu Slony-I przeprowadzaliśmy na systemie Debian 4 (Etch) gdzie dostępny jest Slony-I w wersji 1.2.1-1.

Każda baza danych biorąca udział w replikacji jest określana węzłem replikacji (określenie może być też używane względem serwera na którym ta baza danych działa).

Slony-I zapewnia przeniesienie danych z węzła źródłowego na pozostałe węzły replikacji gdy na wszystkich węzłach istnieją takie same tabele. Przed uruchomieniem replikacji należy przygotować tabele na serwerach na które dane mają być kopiowane, np. odtwarzając na nich zrzut bazy źródłowej. W momencie pierwszej synchronizacji zawartości replikowanej tabeli Slony usunie dane z tabeli docelowej.

Czynności do wykonania na wszystkich węzłach.

Należy zainstalować pakiety Slony-I: # apt-get install slony1-bin postgresql-8.1-slony1

Warto włączyć na serwerach biorących udział w replikacji synchronizację czasu. Może to być synchronizacja z serwerami internetowymi.

Wygodniej będzie zacząć od przykładowych plików konfiguracyjnych. # cd /etc/slony1/ # zcat /usr/share/doc/slony1-bin/examples/slon.conf-sample.gz > slon.conf # zcat /usr/share/doc/slony1-bin/examples/slon_tools.conf-sample.gz > slon_tools.conf

Dobrze jest utworzyć dodatkowego użytkownika w systemie bazodanowym. Niech będzie to użytkownik slony. W tym przykładzie będzie to taki sam użytkownik na każdym systemie (obu dokładniej) z hasłem „Ooh9BooGh1”. # su postgres -c "createuser -sP slony"

Istnieje możliwość uniknięcia zapisywania hasła użytkownika slony w plikach konfiguracyjnych Slony-I i zamiast tego umieścić je raz w pliku /root/.pgpass (jeśli używane jest to rozwiązanie należy upewnić się, że inni użytkownicy nie mają uprawnień do odczytu tego pliku). Wpis powinien wyglądać następująco: *:5432:*:slony:Ooh9BooGh1

Slony będzie zapisywał logi w katalogu który mu wskażemy, niech to będzie /var/log/slony. Trzeba go utworzyć: # mkdir /var/log/slony # chown postgres:postgres /var/log/slony

W pliku /etc/slony1/slon.conf należy ustawić przynajmniej wartości cluster_name, conn_info i archive_dir. Sugeruję następujące wpisy: cluster_name='anakondacluster' conn_info='host=localhost dbname=anakonda user=slony password=Ooh9BooGh1' archive_dir="/var/lib/slony"

Każdy węzeł slony ma przypisany numer. Zazwyczaj numer 1 przypisuje się węzłowi źródłowemu. W tym przykładzie oznaczymy jedyny węzeł docelowy numerem 10.

W pliku /etc/default/slony1 należy wpisać numery węzłów działających na tym serwerze: SLON_TOOLS_START_NODES="1"

Następnym celem jest przygotowanie konfiguracji dla narzędzia slonik które służy do sterowania replikacją. Te pliki konfiguracyjne wystarczy przygotować na węźle źródłowym – tam gdzie będzie używany slonik.

W pliku /etc/slony1/slon_tools.conf ustawiamy następujące opcje: $CLUSTER_NAME = 'anakondacluster'; $LOGDIR = '/var/log/slony'; $MASTERNODE = 1;

Wszystkie węzły muszą być tutaj opisane. Node jest numerem przypisanym węzłowi, parent – numerem węzła z którego ten węzeł ma pobierać dane (normalnie jest to węzeł źródłowy - $MASTERNODE), pozostałe parametry opisują jak połączyć się z bazą danych tego węzła. add_node(node => 1, host => 'serwer', dbname => 'anakonda', port => 5432, user => 'slony', password => 'Ooh9BooGh1');

Jeśli hasło użytkownika slony bazy danych zapisano w ~/.pgpass to w tej konfiguracji można pominąć wpis „password”. Jeśli DNS nie tłumaczy lokalnych adresów IP to warto uzupełnić wpisy w /etc/hosts żeby móc używać nazw serwerów w konfiguracji zamiast ich adresów IP.

Konfiguracja PostgreSQL musi pozwalać na połączenia między węzłami (w obie strony) wg parametrów jakie tu są opisane.

Replikowane elementy bazy danych – zbiór danych

Sugeruję opis zestawów danych umieścić w oddzielnym pliku. W tym celu cały blok $SLONY_SETS w pliku /etc/slony1/slon_tools.conf trzeba usunąć lub wykomentować i dopisać w jego miejscu linijkę: require "/etc/slony1/anakonda-dataset.pl";

Plik /etc/slony1/anakonda-dataset.pl ma zawierać listę elementów bazy danych które mają być replikowane (tj. tabele i sekwencje) w następującej formie: $SLONY_SETS = { "anakonda-dataset" => { "set_id" => 1, # "origin" => 1, # foldCase => 0, "table_id" => 1, "sequence_id" => 1,

"pkeyedtables" => [ "rs_konta_analityczne", "rs_raporty_generatora_pola", "rs_regiony", "rs_tabele_generatora", "rs_receptury_pozycje", [...] "rs_typy_zamowien",

], "keyedtables" => { "rs_obroty_magazynowe" => "rsi_obroty_magazynowe_obrot", }, "serialtables" => [ "rs_config", ], "sequences" => [ "rs_operatorzy_id", "rs_wiadomosci_id", [...] "rs_gr_operacje_seria_seq", ], }, };

W praktyce należy wymienić na tej liście wszystkie tabele bazy danych poza tabelami z danymi archiwalnymi (o nazwach zaczynających się od rsa_) i tabel generatora raportów (nazwy zaczynające się od rs_gr_). Można też pominąć stałe słowniki. Informacja o replikowanych tabelach jest wykorzystywana przez polecenie slonik_create_set i wystarczy, że będzie umieszczona na serwerze na którym to polecenie zostanie wywołane.

Uruchomienie replikacji

Mając tą konfigurację można przystąpić do przygotowania bazy danych do replikacji. Poniższe polecenia należy wykonać raz, np. na serwerze źródłowym. # slonik_init_cluster | slonik

Należy już włączyć daemona Slony-I dla wszystkich węzłów, np. na dla węzła 1: # invoke-rc.d slony1 start

Bywa, że slonik_init_cluster nie ustawia ścieżek przesyłu danych, można to uzupełnić: # slonik_store_node 10 | grep -v 'store node' | slonik

Poniższe polecenie zleca replikację tabel wg opisu zestawu danych # slonik_create_set | slonik

Pozostaje jeszcze polecić zastosować powiązanie między węzłami 1 i 10. # slonik_subscribe_set 1 10 | slonik

Po tym, slony przystąpi do przepisywania zawartości tabel ze zbioru danych z węzła źródłowego na pozostałe. Postęp można obserwować w logach slony dla węzła docelowego.

Gdyby na którymś z tych etapów wystąpił błąd to po usunięciu jego przyczyn można próbować ponowić krok lub rozpocząć od nowa po wyczyszczeniu bazy z danych systemu replikacji: # slonik_uninstall_nodes | slonik

Uwagi

Sugeruję monitorować replikację. Ze strony projektu Slony-I można ściągnąć takie skrypty jak test_slony_state-dbi.pl który wyświetla status replikacji i może powiadamiać mailem jeśli węzły pozostają niezsynchronizowane ponad 30 minut. W przypadku wystąpienia błędu warto sprawdzić zawartość logu w katalogu /var/log/slony/. Po ustawieniu replikacji Slony nie pozwala na zmianę zawartości replikowanych tabel na węzłach innych niż węzeł źródłowy. W ten sposób zapewnia zgodność danych na węzłach, ale węzeł z kopią danych nie nadaje się do normalnej pracy. W przypadku awarii serwera źródłowego używa się polecenie slonik_failover 1 10, aby odrzucić węzeł 1 jako martwy i przypisać węzłowi 10 rolę węzła źródłowego.

Test przełączenia pracy na serwer zapasowy