postgresql 7.3

Jakub Bogusz qboosh w pld.org.pl
Wto, 18 Lut 2003, 11:31:55 CET


On Tue, Feb 18, 2003 at 11:01:54AM +0100, wrobell wrote:
> 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?

Jak ktoś chce więcej, to raczej będzie wiedział jak użyć initdb :)

> > > 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.

Z drugiej strony - tam gdzie się da, jest automatyka typu chkconfig,
restartowanie demonów, konfiguracja crona, logrotate itp.

> > > 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.

Hm, faktycznie coś takiego napisane. Ciekawe co redhatowe/debianowe
skrypty na to.

> > 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).

Bynajmniej - chodzi mi o oddzielne skrypty do samodzielnego
uruchomienia.

> > > 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
if [ -z "$PG_DB_CLUSTERS" -a -n "$POSTGRES_DATA_DIR" ]; then
    PG_DB_CLUSTERS="$POSTGRES_DATA_DIR"
fi
> > 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.

Fakt. Uwzględnione powyżej.

> 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/.

To już nie było w kontekście postgresql.init.


-- 
Jakub Bogusz    http://www.cs.net.pl/~qboosh/



Więcej informacji o liście dyskusyjnej pld-devel-pl