Slony-I jest fajną techniką replikacji danych między bazami PostgreSQL. W przeciwieństwie do techniki warm standby, która efektywnie polega na utrzymywaniu zapasowej bazy w stanie ciągłego odtwarzania inkrementalnego backupu bazy głównej, Slony-I potrafi replikować wybrane tabele i schematy (a nie wyłącznie całą bazę), docelowa baza może być cały czas używana (nawet replikowane tabele - w wariancie tylko do odczytu), a przede wszystkim możliwa jest replikacja między różnymi wersjami PostgreSQL (np. między bazą 8.1 a 8.3) i różnymi architekturami (i386 i amd64 to różne architektury, plików WAL między nimi nie przeniesiemy). Można zresztą replikować do bazy realizującej normalną obsługę innych tabel.

Dokumentacja Slony-I jest dość rozbudowana i obejmuje wiele trudnych przypadków, poniżej prosta recepta na replikację master-slave w konfiguracji dwumaszynowej.

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?

Upgrade jednak czasem bolą...

Debian, a za nim Ubuntu, stosują sympatyczną metodę radzenia sobie z wyborem wersji niektórych programów, po prostu pozwalając na instalację kilku różnych wersji równocześnie. Przykładowo, od dość dawna miałem zainstalowane python2.4, python2.5, python2.6 i python3.1 (które zgodnie koegzystowały), podobnie nie przeszkadzały sobie postgresql-8.3 i postgresql-8.4.

Niestety w Ubuntu Lucid wiele z tych starszych wersji usunięto (prawdopodobnie chcąc uniknąć konieczności ich utrzymywania przez kolejne lata). Mnie dotknęło usunięcie Postgresa 8.3 i ustawienie dlań wymuszonego upgrade do 8.4.