Jak replikację zestawiano....

Proste zadanie - zestawić replikację master-slave. Nic trudnego, master i slave w ramach tego samego serwera, bo replikacja ma być jedynie testowa, ale za to wymóg jest taki, że po wdrożeniu na produkcję ma być dostępny failover - czyli wszystkie tabele i sekwencje mają być replikowane. By było prościej mamy RedHat Enterprise Linux 5 i równie starego nierozwijanego od grudnia 2011 roku postgresa 8.2 . Wszystko proste z punktu widzenia deweloperów pewnie na 10 minut. Ustaliliśmy sobie że nie takie 10 minut, że ma ograniczenia i broń borze nie modyfikować struktury bazy danych, bo przy replikacji przepuszcza się to przez slonik_execute_script. Wszystko rozumieją, akceptują. Startujemy no i zaczynamy pasmo problemów.

Ponieważ replikacja ma być master-slave i ponieważ na slave mają być generowane raporty, to oczywistym wydaje się być użycie slony1. Szukamy slony1 w repozytoriach RedHata - brak. No nic okazuje się, że postgres też nie jest z instalowany z repozytoriów ponieważ RHEL 5 ma tylko PG 8.3 i 8.4. Okazuje się, że na http://yum.postgresql.org/ oprócz postgresa są też dodatki do niego w tym i pożądany slony1. Oczywiście jest informacja, że wersje dla PG 8.2 nie są wspierane. Pobieramy, instalujemy - problem w zależnościach. Nie można zainstalować bo brakuje perl(log). Dlaczego jest taka zależność i jak znaleźć tą paczkę oczywiście nie wiadomo. Po googlaniach bez rezultatu, po upewnieniu się że zainstalowane jest wszystko to co pasuje do *perl*log* i braku jakichkolwiek innych możliwości wymuszam instalację slony1. Nie via YUM, bo nie chcę niepotrzebnie aktualizować starego postgresa. Pomyślałem, że nie ma co ściągać na siebie problemów - działa, to nie naprawiaj. Jeden problem z głowy.

Zabieramy się za przygotowanie konfiguracji. Zapytania, szybka weryfikacja tabel... znowu problem. Nie wszystkie tabele nadają się do replikacji. Slony wymaga, by tabele miały albo klucz główny, albo unikalny indeks. Kilka tabel tego nie ma. Pierwszy kontakt z deweloperami by ustalić plan działania - nie ma? to se dodaj. Ale zaraz... ja tylko admin. Po krótkich przepychankach zgodzili się poprawić sami - to ich aplikacja, oni bazę projektowali. Super... mogę przygotowywać konfigurację slony1.

Pora startu i kolejne rozczarowanie. O ile np slony1 dostarczany z Debianem z automatu przewiduje konfigurację odpalenia wielu węzłów na jednej maszynie, o tyle ten z http://yum.postgresql.org takiej możliwości nie ma. Chcesz to zrobić? Musisz sobie sam poprzerabiać skrypty startowe, a właściwie z /etc/init.d/slony1 zrobić dwa lekko przerobione. Eh nic... znowu trochę czasu i kolejny problem rozwiązany.

Pora uruchomienia replikacji. Lecimy ze standardem pg_dump -s, restore, slonik_init_cluster, slonik_create_set, slonik_subcribe_set i... czekamy. Długo czekamy bo baza ma kilkadziesiąt GB. Dokładnie czekamy jakieś siedem godzin i... tadam! Działa, sprawę możemy zamykać - przynajmniej tak mi się wtedy wydawało.

Dwa dni później deweloperzy zgłaszają, że replikacja nie działa. No to patrzymy... okazuje się, że OID tabeli, taki jaki zna slony i taki jaki faktycznie jest w PG się nie zgadza. Znowu komunikacja z deweloperami - szybkie pytanie... czy robiliście drop table po zestawieniu replikacji?
- nie
- okej bo zmienił mi się OID i ktoś musiał usunąć tabelę i dodać ją ponowie
- no my nie
- aplikacja?
- aa faktycznie, ma "DROP TABLE" w jednym miejscu bo to tabela tymczasowa
Potem przeprowadziłem z deweloperami uroczą dyskusję skupiającą się na wyjaśnieniu dlaczego aplikacja nie powinna usuwać tabeli i jak to ma się do slonego - przyjęto do wiadomości. Aplikację poprawiono, można zestawiać ponownie replikację od nowa. Odpalam więc znaną sekwencję pg_dump -s, restore, slonik_init_cluster, slonik_create_set, slonik_init_set, slonik_subscribe_set - siedem godzin... gotowe! Kolejny bohatersko rozwiązany problem za nami.

Nastał poniedziałek, sprawdzam kontrolnie czy replikacja działa. Jak nie trudno się domyślić okazało się, że nie działa. Zatrzymała się w niedzielę. Ustalenia z deweloperami czy poprawili w aplikacji funkcjonalność która odpowiadała za usuwanie i tworzenie tabeli - twierdzą że tak. Często kłamią sprawdzam więc czy aby na pewno - oidy się zgadzają. Dzisiaj nie mam czasu na diagnozę, jakieś inserty nie poszły może to archaiczny slony, postgres i system. Zestawmy jeszcze raz - zobaczymy co się stanie. Zaczynam więc standardową śpiewkę  pg_dump -s, restore, slonik_init_cluster, slonik_create_set, slonik_init_set i idziemy do domu, może problem rozwiązany? Miałem jeszcze ochotę skrypt do tego napisać, ale pomyślałem, że może tym razem będzie już wszystko w porządku i nie warto.

Rano pierwsza rzecz jaką sprawdzam to replikacja... nadal się zestawia. Pierwsza myśl, to że to maszyna wirtualna, może coś innego skonsumowało CPU. Ostatnio trwało to w prawdzie siedem godzin, ale może teraz potrzebuje np 14-u. Nic, mam inne rzeczy do zrobienia, poczekam. W połowie dnia się nadal zestawia, coś nie tak, ale nie mam czasu na to więc niech jeszcze popracuje... uporałem się ze sprawami bieżącymi wrócę. Pod koniec dnia nadal się zestawia. Coś nie tak. Weryfikacja logów slony1 okazuje się, że nie może skopiować jednej tabel ze względu na różną ilość kolumn na masterze i slave po czym startuje jeszcze raz licząc pewnie żę tym razem się doliczy brakującej na slave kolumny.  Westchnąłem tylko i uderzam do deweloperów z pytaniem:
- modyfikowaliście schemę
- ja nie
- bo wiesz replikacja się nie zestawiła, bo ktoś dodał kolumnę
- a to? To ja zleciłem a robił X....
Po krótkiej powtórce z ograniczeń slonego i replikacji oraz stwierdzeniu, ze jak jeszcze raz ktoś mi samowolnie schemę zmodyfikuje to łapki pourywam, posadzę i dam się nimi pobawić możemy zaczynać znaną już sekwencję. Wcześniej sprawdzam, czy nie poprawili czegoś w związku z niereplikowanymi tabelami. Okazuje się, że poprawili - wszystkie z wyjątkiem jednej. No nic dodaję do slon_tools.conf i jedziemy ze znaną procedurą pg_dump -s, restore, slonik_init_cluster, slonik_create_set, slonik_init_set i idziemy do domu.

Rano sprawdzamy czy replikacja działa... ku mojemu zaskoczeniu tak. Super, pora poruszyć temat niereplikowanej jeszcze tabeli bez klucza głównego i bez unikalnego indeksu. Deweloperzy znowu twierdzą, ze przecież sam mogę sobie dodać, bo tabela jest prosta, tylko dwie kolumny. Zwykle nie wyręczam deweloperów w takich sprawach, ale to już tyle trwa - sam dodałem ten indeks. Przyglądam się dokładniej - okazuje się, że unikalny indeks jest... hmmm pomylili się? A może ja? Dodaję do konfiguracji slonego seta i dodaję do replikacji. Niestety przy próbie utworzenia seta slony stwierdził, że nie może mi tego zrobić, bo nie ma odpowiedniego indeksu. Szukanie informacji i oczywistym się staje że indeks musi być nie tylko unikaly, ale równeiż "NOT NULL". Po weryfikacji okazuje się, że obie kolumny na których założony jest indeks akceptują NULLe. Konsultacje z deweloperami - to zmień. Niech im będzie - i tak to za długo trwa. Dwa altery później można było dodać tabelę do replikacji - mamy komplet - hura! Czyżby to koniec problemów?

Kilka dni później sprawdzam czy replikacja działa - niestety nie działa, deweloperzy tego jeszcze nie zauważyli. Sprawdzam, Znowu wisimy na insercie do tabeli podczas gdy podobny rekord już jest... co jest nie tak? A no pytanie gdzieś czuje, ze ktoś wykonał TRUNCATE na tabeli. Oczywiście deweloperzy w pierwszym kontakcie mówią, że nie ma w aplikacji komendy TRUNCATE. Jak mówię, że tak jak ostatnio stało się to około siódmej rano to nagle nastało olśnienie, że przecież aplikacja ma rano jakieś zadanie w czasie którego aktualizuje tą tabelę i podczas aktualizacji tej niemałej tabeli jest tabela obcinana. Wiedziałem, że slony nie replikuje TRUNCATE, ale postanowiłem sprawdzić czy się nie mylę. Okazało się, że od postgresa 8.4 można założyć trigger na TRUNCATE. Z racji tego, że slony działa właśnie w oparciu o triggery, to może to jest pora by pozbyć się starego PG 8.2 z poza systemu i zainstalować nowszego, pochodzącego z dystrybucji postgresa 8.4. Proponuję deweloperom - akceptacja. Dziś już nie zdążę, zacznę następnego dnia.

Nastał nowy dzionek. Lecimy z aktualizacją postgresa. Dump bazy. Przesuwam profilaktycznie katalog data na bok. Usuwam postgresa 8.2, instaluję 8.4. Migruję ustawienia z 8.2 do 8.4 - pomiędzy tymi wersjami kilka dyrektyw się zmieniło, część zniknęła a część zmieniła format - nie tak łatwo, ale do przejścia. Po dostosowaniu konfiguracji startujemy i wgrywamy dumpa. Z racji czasochłonności tego procesu to by było na tyle jeżeli chodzi o to zadanie w tym dniu. W zasadzie problem TRUNCATE mam już rozwiązany, ale zobaczymy jutro.

Następnego dnia okazało się, że dump się skończył, ale część tabel jest pusta. O co chodzi? Oczywiście firewall klienta jest na tyle sprytny, że po pewnym czasie zrywa połączenia, a ja na tyle niesprytny, że zapomniałem o screenie. No to lecimy jeszcze raz z odtworzeniem bazy danych. W momencie gdy kończyłem pracę nadal się odtwarzało więc, znowu dzień w plecy, ale problem zasadniczo rozwiązany.

Przychodzę do pracy master dump się wgrał. Fajnie, pytanie czy aplikacja działa, ale może uruchomię jeszcze proces zestawiania replikacji. Znana bajeczka...  pg_dump -s, restore, slonik_init_cluster... i dupa, nieznane symbole bibliotece slonego ładowanej do postgresa. O co chodzi? A no o to, że po aktualizacji slonego nie zaktualizowałem slonika, ale by dojść do tego potrzebna znowu była godzina czytania - nie lubię ani redhata, ani paczek z http://yum.postgresql.org. Debianowcy radzą sobie z tym lepiej. Tak czy siak wymiana slony1 na slony1-II i lecimy dalej z bajeczką: slonik_create_set, slonik_init_set, slonik_subscribe_set  i czekamy. Do końca dnia zestawiać się nie skończyła, więc zobaczymy jutro, ale przecież dużo problemów już nie może być przede mną.

Nastał nowy piękny dzień. Deweloperzy testują i... trafiają na problem. Kilka zapytań raportowych się nie wykonuje. Okazuje się, że postgres pluje błędem informującym, że nie może porównać typu "text" z "int". Znowu szybkie ustalenia za deweloperów i okazuje, się że w postgresie 8.3 usunięto "implicit casts". Miało to na celu poprawę wydajności postgresa. Okazało się też, że można ponownie dodać tą funkcjonalność dodając odpowiednie rzutowania typów za pomocą tego, gotowego zestawu komend: http://wiki.postgresql.org/wiki/File:Pg83-implicit-casts.sql Proponuje deweloperom takie rozwiązanie, ale Ci stwierdzają, że już w aplikacji zamienili ten TRUNCATE na DELETE i chcą powrotu do wersji 8.2. Ech, odpisuję na maila upewniając się, że chcą się wycofać w tym momencie.... oby nie.

Następnego dnia otrzymuję potwierdzenie. Cofamy się do poprzedniej wersji postgresa. No nic, dobrze że przynajmniej zachowałem sobie stary katalog data z postgresa 8.2. Odinstalowuję wersję 8.4 i slonego, instaluję postgresa 8.2, instaluję slonego. Uruchamiam... działa. Czy to koniec? Okazuje się, że nie. Przez przypadek usunąłem bibliotekę potrzebną przez httpd, a z nim cały httpd. No nic, instalujemy jeszcze raz - przecież to 5 minut. Okazuje się, że jednak nie, bo te 40MB (aktualizacja danych o repo + sam apache) idzie jak krew z nosa. Nie wiem co się dzieje ale zaczęły już mi się przypominać czasy modemowe. No dobra, po 40-u minutach mamy httpd,

Czy aplikacja jest dostępna? Nie, było by za łatwo, dostaję 404. Znowu ustalenia, i okazuje się, żę brakuje mod_jk. Nic prostrzego yum search i.... nie ma. W RHEL nie ma mod_jk - bo po co ułatwiać zadania. Na szczęście. Ten kto przygotowywał system w /root/ zostawił źródła. Pewnie ze źródeł było instalowane. Wg dokumentacji configure i... nie ma axps. No dobra, to nie problem doinstalujemy. yum instal i modem. Bajty przeciskają się przez miedź niczym klej przez słomkę. Zrobiło się na prawdę nostalgicznie. Mam czas, tyle to już trwa, potrwa jeszcze te trzydzieści minut. Jest, no to znowu configure, make, make install. Aplikacja jest dostępna. Informacja w stronę deweloperów. Potwierdzają jest OK! Sukces! No prawie... replikacja niby prosta, a wyszło zadanie na dwa tygodnie z kawłkiem.

Czy życie nie może być proste...