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