Unikając upgrade

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.

Problem

Wykorzystywałem bazę obsługiwaną przez Postgresa 8.3, dodatkowo replikowaną na drugą maszynę, także do 8.3. Aktualizacji do 8.4 nie zrobiłem przed update do Lucida częściowo z braku czasu a częściowo z braku miejsca na dysku - elegancki upgrade (o którym niżej) wymaga podwojenia (stara i nowa baza), a siłowy (via dump) nawet potrojenia (stara baza, backup, nowa baza) wykorzystywanej przestrzeni.

Upgrade do Lucid po prostu skasowało binaria Postgresa 8.3. Oczywiście próbowało przenieść dane, co ... w moim wypadku nie udało się na obu maszynach (na źródle z wspominanego braku miejsca na dysku, na celu ponieważ pg_upgradecluster odmówił obsługi slave Slony-I).

Zostałem zatem z bazami w formacie 8.3, binariami Postgresa 8.4 a przy okazji, oczywiście, nie działającą replikacją.

Nie robiłem oczywiście upgrade dwóch maszyn równocześnie, problem odkryłem przy aktualizacji slave i miałem czas na przemyślenie rozwiązania, dla tej notki nie jest to jednak istotne.

Reaktywacja starych pakietów

Na szczęście Lucid bez problemów pozwala na instalację pakietów z Karmica (nie ma binarnych niezgodności istotnych bibliotek).

Wystarczyło stworzyć plik /etc/apt/sources.list.d/karmic.list o treści:

deb http://archive.ubuntu.com/ubuntu/ karmic main restricted universe
deb-src http://archive.ubuntu.com/ubuntu/ karmic main restricted universe

i zrobić

$ sudo apt-get update

by rozmaite stare pakiety stały się dostępne. W szczególności

$ sudo apt-get install postgresql-8.3

ponownie zainstalowało Postgresa 8.3 i umożliwiło przywrócenie działania baz danych.

Reanimacja Slony-I

Cofanie wersji slony1 byłoby bardziej kłopotliwe - jest to ten sam pakiet i Ubuntu uparcie proponowałoby jego aktualizację do nowszej wersji (apt-pinning nigdy mnie nie pociągał). Na szczęście dobrzy ludzie przygotowali wsparcie dla Postgresa 8.3 w wersji 1.2.20 Slony1 (zgodnej z wersją dystrybuowaną w Lucidzie).

Dodatkową korzyścią z jej użycia jest możliwość zestawienia replikacji z 8.3 do 8.4, wersja Slony się zgadza.

Zatem:

# Instalacja skryptu add-apt-repository
$ sudo apt-get install python-software-properties

# Dołączenie PPA ze Slony 1.2.20 dla Postgresa 8.3
$ sudo add-apt-repository ppa:stub/launchpad2

$ sudo apt-get update

$ sudo apt-get install postgresql-8.3-slony1

(powtórzone na maszynach z obu stron replikacji). A potem normalny upgrade wersji Slony w bazie danych.

Końcowym efektem są bazy 8.3 replikujące się przy pomocy Slony-ego 1.2.20 (tj. nowego) i gotowe do eleganckiego upgrade do 8.4.

Perspektywy upgrade

Elegancki upgrade konfiguracji Slony-I polega na stworzeniu pustej bazy w nowej wersji Postgresa, dołączeniu jej do schematu replikacji jako nowego slave, odczekaniu aż dane się skopiują, a następnie zmigrowaniu mastera, przełączeniu nań klientów bazy danych i późniejszym usunięciu oryginału z replikacji a później z dysku).

W moim scenariuszu (dwie bazy replikowane przez stosunkowo wolne łącze) będę chciał to niezależnie zrobić na obu maszynach (by kopiowanie danych z 8.3 do 8.4 odbywało się lokalnie).