Du könntest auch einfach Symlinks im Datenverzeichnis auf die neuen Configdateien zeigen lassen. Das bringt am wenigsten Probleme und ist die Vorgehensweise, die von einigen Distributionen gewählt wird.
Hallo,
beim Versuch PostgreSQL 8.3 die Nutzung der postgresql.conf (und weiterer *.conf) in einem vom PGDATA verschiedenen Verzeichnis unterzubringen scheitere ich.
Problem:
1. wird kein external_pid_file angegeben
wird beim DB Stop das PID File in $PGDATA vermutet obwohl es im data_directory angelegt wurde.
2. wird external_pid_file angegeben
werden die DB prozesse zwar beendet aber der pg_ctl stop timed out.
und das external_pid_file bleibt liegen
Interessant ist vielleicht noch anzumerken, das die DB mit PGDATA=/pg/OSL/data angelegt wurde (initdb), und anschliessend
die Separierung der Config vorgenommen wurde.
Bug or feature ?
Mir stellt sich die Frage wie ich bei einer Trennung von data_directory und Configurations Dateien vorgehen soll ?
Wie macht ihr das, wenn ihr es denn macht ?
----------------------LOG-----------------------------------
USER Environment:
$ env | grep PG
PGPORT=5432
PGDATA=/pg/OSL/etc
1. external_pid_file nicht gesetzt
-----------------------
$ cat /pg/OSL/etc/postgresql.conf
...
data_directory = '/pg/OSL/data'
hba_file = '/pg/OSL/etc/pg_hba.conf'
ident_file = '/pg/OSL/etc/pg_ident.conf'
# If external_pid_file is not explicitly set, no extra PID file is written.
#external_pid_file = '/pg/OSL/etc/postmaster.pid' # write an extra PID file
# (change requires restart)
Ein Start ist erfolgreich und ein postmaster.pid
wird im data_directory angelegt (/pg/OSL/data) !
Beim Stop meint pg_ctl:
$ pg_ctl stop
pg_ctl: PID file "/pg/OSL/etc/postmaster.pid" does not exist
Is server running?
Wieso erwartet er sein PID File im falschen Directory ?
2. external_pid_file gesetzt
-------------------
Wie erwartet werden bei pg_ctl start 2x postmaster.pid Dateien erzeugt.
$ ls -l data/postmaster.pid
-rw------- 1 pgosl postgres 38 Aug 14 11:53 data/postmaster.pid
$ ls -l etc/postmaster.pid
-rw------- 1 pgosl postgres 5 Aug 14 11:53 etc/postmaster.pid
Und der Stop räumt zwar die Prozesse ab aber timed out und beendet sich mit einem Fehler.
$ pg_ctl stop
waiting for server to shut down.............................................. ................. failed
pg_ctl: server does not shut down
Super ein PID File ist noch da !!!
$ ls -l etc/postmaster.pid
-rw------- 1 pgosl postgres 5 Aug 14 11:53 etc/postmaster.pid
$ ls -l data/postmaster.pid
data/postmaster.pid: No such file or directory
MfG
Oliver
Geändert von oha (14.08.2008 um 12:33 Uhr)
Du könntest auch einfach Symlinks im Datenverzeichnis auf die neuen Configdateien zeigen lassen. Das bringt am wenigsten Probleme und ist die Vorgehensweise, die von einigen Distributionen gewählt wird.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
Hallo,
Danke für deinen Ansatz,
aber diese "Lösung" riecht mir zu sehr nach 'nem HACK.
Hallo,
Aus den Äusserungen, und den Hacks welche die Distributionen zu machen scheinen
schließe ich das die PG Entwickler von diesem BUG nichts wissen.
Super klasse finde ich das alle es zu wissen scheinen (einschließlich ads) aber sich an der Situation nichts ändert.
Tolle Community
Tschuldigung aber das kotzt mich an !
Für mich ist das kein Bug.
Ausserdem habe ich dir einen möglichen Weg aufgezeigt, dein Problem zu lösen. Wenn dir das nicht reicht - nicht meine Schuld.
Wenn du weiterhin behaupten möchtest, dass das ein Bug ist:
Wo ist dein Bugreport auf der -hackers Mailingliste?
Du bist ein ganz toller Typ, hier fleißig rummotzen aber selber zu faul sein, einen Bugreport zu schreiben.Tolle Community
Tschuldigung aber das kotzt mich an !
PostgreSQL ist ein Open Source Projekt, solche Projekte leben davon, das die Nutzer Feedback liefern.
Also, bevor du hier das nächste Mal einen künstlichen Aufstand produizierst, schickst du eine Email an die -users oder die -hackers Mailingliste und schaust, was du zu deinem Problem sagen.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
>Wenn du weiterhin behaupten möchtest, dass das ein Bug ist:
>Wo ist dein Bugreport auf der -hackers Mailingliste?
>Du bist ein ganz toller Typ, hier fleißig rummotzen aber selber zu faul sein, einen >Bugreport zu schreiben.
Wer sagt denn das das nicht erledigt wurde ?
>PostgreSQL ist ein Open Source Projekt, solche Projekte leben davon, das die Nutzer >Feedback liefern.
Vielen Dank für deine Belehrungen.
Der ganze KRAM funktioniert nicht wie beschrieben --> ein BUG
Und seit es diese Funktionalität gibt kam zero/nada/null Feedback von der Community.
Was man daran erkennen kann das die Distributionen von dir erwähnte und vorgeschlagene Hacks verwenden. Das ist ein sehr unbefriedigender Zustand, welcher
die PG Community in meinen Augen schlecht aussehen lässt !
Alles klar ?
Nein. Und wenn du weiter bei deinem Ton bleibst, wundern mich ausbleibende Antworten kein bischen.
Zuerst mal vermischt du da mehrere Probleme miteinander. Einmal das nicht funktionierende Stoppen des Dienstes, was mehrere Ursachen haben kann. Zum anderen dein Gemosere über einen Bug, welcher bisher nur bei dir auftritt. Das zwei PID-Files erzeugt werden, ist schon ungewöhnlich genug, der Daemon erzeugt nur ein einzelnes - also wer erzeugt das zweite? In Folge gibt es dabei auch sicher Probleme beim Stoppen des Daemons - welche du gerade beobachten kannst.
Ach und btw, "etc" (auch ohne / am Anfang) ist für Konfigurationsdateien, nicht für temporäre Dateien und zu letzterem gehört das PID-File.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
Weil du hier einen Fehler gemacht hast ...
Dein $PGDATA aus dem Environment zeigt auf:
während das pgdata Verzeichnis aus seiner Config auf:Code:PGDATA=/pg/OSL/etc
zeigt.Code:data_directory = '/pg/OSL/data'
Was denkst du, was das ist, wenn deine Dateien dann nicht gefunden werden.
Ein Bug? Oder ein Fehler vor der Tastatur?
Korrigiere das, versuch es dann noch mal, mäßige deinen Ton und deine Ausdrucksweise und dann schauen wir weiter.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
PostgreSQL Dokumentation
18.2 File Locations
If you wish to keep the configuration files elsewhere than the data directory,
the postgres -D command-line option or PGDATA environment variable must
point to the directory containing the configuration files, and the data_directory
parameter must be set in postgresql.conf (or on the command line) to show
where the data directory is actually located. Notice that data_directory
overrides -D and PGDATA for the location of the data directory, but not for
the location of the configuration files.
In meinem Verständnis bietet
PGDATA=/pg/OSL/etc
sowie ein postgresql.conf mit data_directory
$ cat /pg/OSL/etc/postgresql.conf
data_directory='/pg/OSL/data'
genau das gewünschte.
Mein Ziel ist es nach wie vor, meine postgresql.conf (und weitere *.conf)
nicht im data_directory aufzubewahren. Das heisst
data_directory != PGDATA
/pg/OSL/data != /pg/OSL/etc
Im Fall 1 (siehe oben) legt ein
$ pg_ctl start
sein PID File im data_directory an
während der
$ pg_ctl stop
sein PID File in PGDATA nicht findet und einen Fehler meldet.
Sollte der Fehler vor dem Monitor sitzen, bitte ich um Erleuchtung!
Nun, du musst zumindest pg_ctl und dem Daemon die gleichen Optionen und Daten mitgeben. Nur in einem Fall wird bei dir in "etc" gesucht und im anderen Fall im data Directory. Daher kommen deine Probleme.
Du siehst ja selbst, das einmal pidfiles in jedem Verzeichnis auftauchen und das andererseits dein pg_ctl im falschen Verzeichnis sucht.
Also: ich denke schon, das du das alles richtig hinbekommen kannst, aber dafür ist eine Ecke mehr Arbeit notwendig. Die Distributionen legen nicht ohne Grund Symlinks: nicht weil es ein Bug ist sondern weil es dann in jedem Fall funktioniert (KISS-Prinzip). Auch sind hinterher die (doch sehr wichtigen) Configdateien auch in jedem Backup mit enthalten, was bei dir auch nicht der Fall ist.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
Links: Tobias Bauer - IT- und Funkdienstleistungen - Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen - Funkforum
Lesezeichen