Replikacja Slony-I - scenariusz upgrade

Dopisek do artykułu o konfiguracji replikacji baz PostgreSQL przy pomocy Slony-I: co się dzieje przy upgrade.

W kontekście replikacji znaczenie mają wersje następujących elementów:

• programu slon
• zapisanych w bazie danych triggerów i procedur składowanych Slony-I,
• binarnej biblioteki pomocniczej należącej do Slony-I (używanej przez powyższe i dolinkowywanej dynamicznie do bazy danych),
• samej bazy danych (tj. PostgreSQL).

Aby Slony-I działało, między każdymi z nich musi być zgodność wersji, tj.:

• program slon musi mieć tą samą (dokładnie!) wersję co triggery we wszystkich bazach, z którymi się komunikuje - także zdalnych,
• biblioteka pomocnicza musi być binarnie zgodna z triggerami
• biblioteka pomocnicza musi być binarnie zgodna z bazą danych (tj. skompilowana z jej nagłówkami i bibliotekami).

Same bazy mogą mieć różne wersje (na różnych węzłach) ale pod warunkiem przykrycia taką samą wersją Slony-I (tj. możemy mieć PostgreSQL 8.1 na maszynie A i PostgreSQL 8.3 na maszynie B, ale musimy mieć na obu bibliotekę pomocniczą, program slon i kod SQL w bazie z - powiedzmy - Slony-I 1.2.13).

Jak to wygląda przy normalnym, pakietowym systemie dystrybucji?

Dystrybucja poszczególnych elementów

Przynajmniej na Debianie i Ubuntu powyższe elementy są dystrybuowane następująco:

• program slon należy do pakietu slony1-bin, także w tym pakiecie mamy skrypty SQLowe którymi można założyć obiekty bazodanowe Slony-I, skrypt slonik itp.
• triggery/procedury składowane nie podlegają schematowi pakietowania, zakładamy je sami uruchamiając odpowiednie skrypty slonik (patrz poprzedni artykuł)
• biblioteka pomocnicza to pakiet postgresql-8.3-slony1
• sama baza danych to pakiet postgresql-8.3

Schematy zależności między pakietami zapewniają zgodność między wersjami programu slon, biblioteki pomocniczej i bazy danych. Nie mają jednak wpływu na struktury bazodanowe (ani, oczywiście, na zdalne maszyny).

Co się dzieje w trakcie upgrade

Z powyższego łatwo zauważyć, że upgrade pakietów prowadzi do wstrzymania działania replikacji. Na przykład przy upgrade Ubuntu z 8.04 na 8.10 program opisane wyżej pakiety zmieniły wersję Slony-I z 1.2.13 na 1.2.14.

Efekt? Ponieważ w bazach (tak lokalnej, jak zdalnej) zostały dawne schematy, po zakończeniu upgrade program slon odmówił uruchomienia się, wypisując w logu (/var/log/slony1/slon-mojschemat.log) informację:

ERROR  Slony-I schema version is 1.2.13
ERROR  please upgrade Slony-I schema to version 1.2.14
FATAL  main: Node has wrong Slony-I schema or module version loaded

Co ważne: nic fatalnego się tu nie stało. Bazodanowe triggery dalej działają i rejestrują zmiany do odegrania, ale sama replikacja jest wstrzymana (gdy zsynchronizujemy powtórnie wersje, zaległe zmiany zostaną odegrane).

Powtórna synchronizacja wersji

Zaczynamy od uzgodnienia wersji binarnych komponentów Slony-I na wszystkich maszynach. Najprostszym rozwiązaniem jest instalacja zgodnych pakietów (np. skoro na jednej maszynie przeszedłem na Ubuntu 8.10, to przechodzę na nie także na pozostałych).

Jeśli z jakichś względów jest to niemożliwe, można ręcznie skompilować odpowiednie Slony-I. Na przykład, jeśli na jednym z serwerów musi pozostać Ubuntu 8.04, instalujemy tam postgresql-server-dev-8.3 (a także make, gcc, flex i inne elementy potrzebne do kompilacji), ściągamy tam źródła Slony-I 1.2.14 i kompilujemy ręcznie (./configure, make, make install). Kompilacja wyprodukuje zarówno binarną bibliotekę, jak program slon.

Wszystkie programy slon do tego czasu już się raczej zatrzymały ale dla pewności robimy wszędzie:

/etc/init.d/slony1 stop

Teraz czas na upgrade schematów (czyli triggerów/procedur bazodanowych). W tym celu piszemy skrypcik upgrade.slonik o następującej treści:

include <preamble.slonik>
update functions (id = @node_mydb_master);
update functions (id = @node_mydb_slave);

gdzie wiersz update functions wpisujemy dla każdej z maszyn z konfiguracji replikacji.

Sprawdzamy, czy na maszynie z której uruchomimy powyższy skrypt (stacji roboczej) mamy właściwą wersję Slony-I (pakietu slony1-bin). Jeśli nie, także tu aktualizujemy go jedną z powyższych metod. Zapewni nam to właściwą wersję skryptu slonik i skryptów SQLowych przezeń używanych.

Wreszcie, uruchamiamy:

$ slonik upgrade.slonik

Powyższy skrypt połączy się po kolei do każdej z baz i zaaktualizuje w niej wersje triggerów i procedur Slony-I.

Na koniec startujemy demony slon na wszystkich maszynach. Replikacja powinna ponownie działać (bezpośrednio po uruchomieniu będziemy mieć moment zwiększonego obciążenia związanego z odgrywaniem zaległości).