Ich hatte PG 8.3 und 8.4 auf einem Server laufen. Hier hatte man dann zwei Konfigurationen. Wenn man aber nur einen neuen Cluster anlegt (initdb?), wo legt man dann den zweiten Port fest?
Du kannst 8.3 oder 8.4 mehrfach laufen lassen, mit je einer eigenen Konfig incl. Port. Dafür erstellst Du dann je einen Cluster mit initdb. Dem Cluster ist der Port egal, das regelt der Serverprozess, konfiguriert durch die Konfig-Datei.
okay, cluster konnte ich anlegen. Im Cluster-Pfad habe ich die Konfig-Dateien angepasst.
Werden beim Server-Neustart alle Cluster geladen? (/etc/init.d/post… restart) Die Verbindung zur DB funktioniert noch nicht.
psql: konnte nicht mit dem Server verbinden: Connection refused
Läuft der Server auf dem Host »localhost« und akzeptiert er
TCP/IP-Verbindungen auf Port 5433?
konnte nicht mit dem Server verbinden: Connection refused
Läuft der Server auf dem Host »localhost« und akzeptiert er
TCP/IP-Verbindungen auf Port 5433?
An sich reichen getrennte Zugriffsberechtigungen sowie getrennte Useraccounts.
Ob jemand die falschen Accountdaten oder den falschen Port angibt, läuft letztendlich auf das gleiche heraus.
Für die Konfiguration ist das jedoch ein Unterschied: die Maschine kann den Speicher für alle Datenbanken in einem Cluster nutzen. Wenn du zwei oder mehr Cluster fährst, musst du die vorhandenen Ressourcen jedoch aufteilen.
Ich bin weiterhin dafür, dass du die Geschichte mit zwei Instanzen vergisst und stattdessen passende Zugriffsrechte vergibst.
Zuerst einmal müssen sich die beiden Instanzen die vorhandenen Ressourcen teilen. In einer einzelnen Instanz kümmert sich PG darum ganz allein.
Außerdem siehst du, dass dein Vorgehen keineswegs weniger Probleme beinhaltet sondern du stattdessen nicht weißt, wie genau du jetzt zu welcher Datenbank connecten sollst. Demzufolge ist dein Ziel “Probleme durch falsche Zugriffe vermeiden” in sehr weite Ferne gerückt.
Ich arbeite mit Schematas, die die validierten Daten beinhalten, normale User dürfen dort lesen, nichts ändern. Projektdaten kommen in eigene Schemata
, in den Nutzer auch ggf. Schreibrechte bekommen. In public kommen meist nur Basisdaten, views etc, die für mehrere Projekte oder global zu verwenden sind. Für ganz harte Fälle des Eigenbaus und Testdaten etc hat jeder der will, noch eine eigene Datenbank, in der er tun und lassen kann was er will. Dazu gibt es noch einen webuser für die Kartendienste, der jeweils angepasste Rechte bekommt. Funktioniert bisher gut.
Vorteil: Alles in einem Backup, Datenkonsistenz einfacher händelbar, man muß Änderungen nur an einem Server machen, keine Verwechslungsgefahr.