postgresql 7.3

[wrobell]

On Tue, Feb 18, 2003 at 12:29:29AM +0100, Jakub Bogusz wrote:
> On Mon, Feb 17, 2003 at 06:30:11PM +0100, wrobell wrote:
> > On Mon, Feb 17, 2003 at 05:09:17PM +0100, Jakub Bogusz wrote:
[...]
> >     initdb -D /var/lib/pgsql
> > 
> >   co mysle, ze nie jest na tyle trudne ani skomplikowane, zeby uzasdnialo
> >   istnienie dodatkowej funkcjonalnosci w postgresql.init
> 
> Skoro można to zrobić małym kosztem, to dlaczego maiłoby nie być.
> Tak jak w mysql.init i squid.init - akcja init przystosowuje pakiet do
> pracy po pierwszej instalacji.
> 
> Akcja init może wyglądać tak:
> 
>     init)
>     	for pgdir in $DB_CLUSTERS; do
>             if [ -f $pgdir/PG_VERSION ]; then
>                 echo "Skipping existing cluster $pgdir"
>     	    else
>     	        echo "Initializing cluster $pgdir"
>                 TMPDIR=/tmp su - postgres -s /bin/sh -c "initdb -D $pgdir"
>             fi
>         done
>         echo "REMEMBER to setup password for user \"postgres\"!"
No niby pryszcz... ale... jest to tylko czubek góry lodowej, bo
zaraz ktoś sobie zażyczy standardowego encodingu, ktoś inny
możliwości przy init określania niektórych standardowych parametrów
konfiguracji... może lepiej stworzyć osobny skrypt pginitcluster?

postgresql.init jest skryptem startowym, jeśli ktoś potrzebuje
łatwiejszego narzędzia niż initdb do tworzenia klastrów to proponuję by
go użył - o ile istnieje (proszę wybaczyć brak przykładów, ale dla mnie
initdb jest narzędziem w pełni wystarczającym).

> > > 2. upgrade
> > > Komunikat "please downgrade" w %pre wygląda niezbyt poważnie.
> > > 
> > > Powinno być co najmniej coś takiego jak w 7.2 (tylko dla wszystkich
> > > klastrów), albo jakaś forma are-you-sure (jeżeli stare binarki będą
> > > kopiowane do innego katalogu) - tylko jak to zrobić nieinteraktywnie?
> > 
> > > Automatyczne dump+restore nie jest możliwe, ale można to ułatwić.
> > > W pakietach z wielu dystrubucji (RH, Mdk, SuSE, Debian) są załączane
> > > skrypty do migracji (w większości takie same, lub z niewielkimi
> > > modyfikacjami) - do uruchomienia po upgrade pakietu (tylko Debian
> > > proponuje uruchomienie podczas upgrade pakietu - ale bez gwarancji
> > > powodzenia).
> > > Skrypt opiera się na przeniesieniu danych i napuszczeniu na ten katalog
> > > starej wersji postgresa (binarki są kopiowane do oddzielnego katalogu
> > > w %pre) uruchomionej na innym porcie.
> > > U nas może być więcej roboty ze względu na wiele klastrów.
> > 
> > IMHO, bym odpuscil robienie jakichkolwiek dodatkowych skryptów.
> > Kazdy administrator powinien sobie zdawac sprawe 
> > o tym, ze musi zrobic dump-a bazy przez upgrade'em do nowszej wersji
> > i robic upgrade _świadomie_.
> 
> Tylko nie każdy administrator systemu jest administratorem baz danych
> - może nie od razu wiedzieć, czym się różni zmiana trzeciej cyfry od
> zmiany drugiej czy pierwszej w numerze wersji postgresa (zapewne "do
> pierwszego golenia").
W to już nie wnikam. Po prostu jak w przypadku innych elementów
dystrybucji, tak tutaj także powinniśmy wymagać pewnej dozy wiedzy
(man initdb - czy to naprawdę takie trudne?) i odpowiedzialności.
 
> > Ma do tego celu stosowne, łatwe
> > w użyciu narzędzia: pg_dump i pg_restore.
> 
> Przy większej liczbie baz raczej męczące, mniej roboty jest z pg_dumpall
Ale pg_dumpall nie może być zawsze wykorzystywane - ze względu
na large objects.

> i psql (chociaż z użyciem tekstowych dumpów proces może trwać dłużej).
Trwa dłużej.

> Przy wielu klastrach nie wystarczy już jedno polecenie przed, jedno po
> upgradzie pakietu - musi być po jednym dla każdego klastra. I to można
> próbować uprościć (np. dostarczyć skrypty wywoływane jako
> "pg_dumpallclusters <katalog>" i "pg_restoreallclusters <katalog>",
> zrzucające wszystkie dane do i odzyskujące z katalogu).
 
> A, jeszcze jedno zauważyłem - dump+restore to nie wszystko. Katalog
> $PGDATA zawiera jeszcze pliki konfiguracyjne...

Proponuję stworzyć nowy projekt, który stworzy odpowiednie skrypty
do wykonywania backup-ów (a może coś takiego juz istnieje?).

IMHO, nie ma sensu dodawać takiej funkcjonalności do postgresql.init
(nie wiem czy to sugerowałeś - piszę tak na wszelki wypadek).
 
> > Co do komunikatu "please downgrade", to może ew. jakieś zabezpieczenie
> > przed automatycznym upgrejdem? Sprawdzać postgresql.sysconfig na obecność
> > PG_DB_CLUSTERS? Jakiekolwiek sugestie mile widziane.
> 
> Czy postgres 7.3.x umieszcza "7.3" w $PGDATA/PG_VERSION?
> Jeśli tak, to można wrzucić do %pre:
> 
> PG_DB_CLUSTERS=""
> if [ -f /etc/sysconfig/postgresql ]; then
> . /etc/sysconfig/postgresql
> fi
> foundold=0
> for pgdir in $PG_DB_CLUSTERS; do
>     if [ -f $pgdir/PG_VERSION ]; then
>         if `cat $pgdir/PG_VERSION` != '7.3' ]; then
> 	    echo "Found database(s) in older, incompatible format in cluster $pgdir."
> 	    foundold=1
> 	fi
>     fi
> done
> if [ "$foundold" = "1" ]; then
>     echo
>     echo "Dump all data from clusters mentioned above (e.g. using pg_dumpall)"
>     echo "and clean (or rename) echo those directories; then upgrade postgresql"
>     echo "and restore all data (e.g. using psql)"
>     exit 1
> fi
Trzeba jeszcze sprawdzić czy istnieje zmienna POSTGRES_DATA_DIR
(z postgresql.sysconfig dla wersji z przed 7.3.x) po zaciągnięciu
/etc/sysconfig/postgresql.

Niewątpliwie, w %pre postgresql.spec powinny się znaleźć zabezpieczenia
przed automatycznym, przypadkowym upgrejdem.

Natomiast co do prostej migracji pomiędzy wersjami i ułatwiania ludziom
życia, to narzędzia oczywiście przydatne, ale nie jest to rola
posgresql.init. Tego typu narzędzia powinny być w /usr/sbin/ a nie
/etc/rc.d/init.d/.

    wrobell <wrobell w ite.pl>
-------------- następna część ---------
Załącznik, który nie był tekstem został usunięty...
Name: nie znany
Type: application/pgp-signature
Size: 189 bytes
Desc: nie znany
Url : /mailman/pipermail/pld-devel-pl/attachments/20040626/6649db80/attachment.bin