Postgres, potężniejszy z dwóch popularnych w świecie open source silników bazodanowych, nie cieszy się dobrą sławą jeśli chodzi o prostotę instalacji i konfiguracji.

W tym artykule chciałbym rozwiać te obawy, przynajmniej jeśli chodzi o replikację baz danych.

Po co replikacja - nie trzeba chyba wyjaśniać, starczy przywołać takie swojsko brzmiące terminy jak real-time backup, load balancing, czy failover.

Podobnie jak w MySQL, najczęstszym sposobem zestawiania replikacji jest schemat master-slave, czyli jedna baza do której piszemy (R/W) i druga służąca tylko do odczytów (R/O).

W postgresie służy do tego oprogramowanie Slony-I, rozprowadzane jako osobny pakiet.

Dla celów tego artykułu zakładam że używamy Debiana lub pochodnej dystrybucji Linuksa, np. Ubuntu.

Kilka słów o Slony-I

Slony-I to system replikacji asynchronicznej oparty na triggerach. Nas przede wszystkim interesują dwa narzędzia: slon - będący replikatorem odpowiedzialnym za przerzucanie danych między bazami, oraz slonik, służący do konfiguracji klastra.

Środowisko

Czyli zestaw hostów wchodzących w skład systemu.

Zakładam że mamy dwa serwery postgresa, glaurung i smaug.
Replikujemy bazę danych webdev z glaurunga na smauga.

Do tego trzeci host merry z którego uruchamiamy replikatory.

Instalacja

Instalujemy wymagane pakiety:

root@merry:~# apt-get install slony1-bin
root@glaurung:~# apt-get install postgresql-8.2-slony1
root@smaug:~# apt-get install postgresql-8.2-slony1


Konfiguracja baz

Replikacja wymaga osobnego konta w bazie, na które będą logować się slon oraz slonik. Na glaurungu dodajemy do bazy użytkownika slony z prawami superusera (createuser zapyta o hasło, ja podałem "thurin"):

postgres@glaurung:~$ createuser -s -P slony

oraz instalujemy język proceduralny PL/PgSQL w bazie webdev:

postgres@glaurung:~$ createlang plpgsql webdev


Teraz musimy zagwarantować identyczność schematu bazy na obu serwerach. Za pomocą programów pg_dumpall oraz pg_dump zrzucamy schemat bazy do pliku:

postgres@glaurung:~$ pg_dumpall -g > master.dump
postgres@glaurung:~$ pg_dump -s -C webdev >> master.dump


Uzyskany w ten sposób plik przegrywamy na smauga i ładujemy do postgresa:

postgres@smaug:~$ psql < master.dump


Konfiguracja Slony-I

Na hoście merry, który będzie centralnym punktem klastra odpowiedzialnym za replikację, tworzymy konfigurację dla slony1. Znajduje się ona w pliku /etc/slony1/slon_tools.conf. Jest to w istocie kawałek kodu w Perlu zawierający definicję wszystkiego co istotne dla klastra. Narzędzie slonik (a właściwie skrypty perlowe, którymi jest obudowany) korzystają właśnie z tego pliku.

#!/usr/bin/perl
$CLUSTER_NAME = 'webdev';
$LOGDIR = '/var/log/slony1';
$MASTERNODE = 1;
add_node(
    node     => 1,
    host     => 'glaurung',
    dbname   => 'webdev',
    port     => 5432,
    user     => 'slony',
    password => 'thurin'
);
add_node(
    node     => 2,
    host     => 'smaug',
    dbname   => 'webdev',
    port     => 5432,
    user     => 'slony',
    password => 'thurin'
);
$SLONY_SETS = {
    set1 => {
        set_id       => 1,
        table_id     => 1,
        sequence_id  => 1,
        pkeyedtables => [
            'accounts',
            'branches',
            'tellers',
        ],
    },
};
1;

Uwaga: replikować można tylko tabele ze zdefiniowanym kluczem głównym (PRIMARY KEY).

Inicjalizacja klastra

W tym kroku wywołamy skrypty programu slonik, które utworzą w bazie danych tabele systemowe potrzebne do działania replikacji.

postgres@merry:~$ slonik_init_cluster > script && slonik script
script:10: Set up replication nodes
script:13: Next: configure paths for each node/origin
script:16: Replication nodes prepared
script:17: Please start a slon replication daemon for each node
postgres@merry:~$ slonik_create_set set1 > script && slonik script
script:16: Subscription set 1 created
script:17: Adding tables to the subscription set
script:21: Add primary keyed table public.accounts
script:25: Add primary keyed table public.branches
script:29: Add primary keyed table public.tellers
script:32: Adding sequences to the subscription set
script:33: All tables added


Uruchomienie procesów slon

Uruchamiamy demony slon replikujące dane.

postgres@merry:~$ slon_start 1
postgres@merry:~$ slon_start 2

Uwaga: należy zadbać żeby slon'y uruchamiały się przy starcie.

Subskrypcja

Należy poinstruować smauga że ma pobierać dane z glaurunga.

postgres@merry:~$ slonik_subscribe_set set1 2 > script && slonik script
script:10: Subscribed nodes to set 1

W tym momencie rozpocznie się wykonywanie kopii danych ze wskazanych tabel. Po pewnym czasie (zależnym od rozmiaru bazy) kopiowanie się zakończy i dane w obu bazach będą identyczne. A system zadba o to, by kolejne aktualizacje docierały do bazy slave.

I to już właściwie koniec :-)
Zostaje jeszcze...

Monitoring

Najprostszą metodą monitorowania slony1 jest czytanie zawartości widoku sl_status:

postgres@merry:~$ psql webdev -xc 'select * from _webdev.sl_status'
-[ RECORD 1 ]-------------+---------------------------
st_origin                 | 1
st_received               | 2
st_last_event             | 308
st_last_event_ts          | 2008-03-18 04:35:32.981955
st_last_received          | 308
st_last_received_ts       | 2008-03-18 04:34:47.51166
st_last_received_event_ts | 2008-03-18 04:35:32.981955
st_lag_num_events         | 0
st_lag_time               | 00:00:04.027

Jest to podsumowanie z wewnętrznej kolejki zdarzeń systemu Slony-I. Najbardziej interesujące są:

• st_lag_num_events: ilość nieprzetworzonych zdarzeń
• st_lag_time: łączny czas opóźnienia bazy slave w stosunku do bazy master.

Na tym skończę. Zainteresowanych odsyłam na świetną stronę projektu Slony-I:
http://slony.info