Instanz, Cluster oder Tablespace ?

Um laufende Projekte nicht ausversehen zu bearbeiten sollen diese “ausgelagert” werden.

Alle “heißen” Projekte sollen unter einem anderen Port laufen.

Was muss dazu erstellt werden? Eine Instanz, Cluster oder ein Tablespace? Bei den Begrifflichkeiten kommen man etwas durcheinander…

Gruß
Karl

Auf einem anderen Port? Okay, dann muß da ein eigenständiger PostgreSQL-Server seinen Dienst verrichten. Das nennt man dann eher Instanz oder Cluster.

Andreas

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?

Doku findet man dazu leider icht zu viel

Edit:
-p port, –port port

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.

Andreas

Wie erfährt man den speicherort eines clusters?

http://www.pg-forum.de/allgemeines/1116-datenbank-speicherort.html

show data_directory;

Andreas

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.

Hier ist die zweite Instanz erstellt worden:

 /var/lib/postgresql/8.4/database

Darin befinden sich auch die Konfigurationsdateien. (pg_hba.conf, postgres.conf, pg_ident.conf)

Ein Auszug aus der postgres.conf:

listen_addresses = '*'          
port = 5433                             
max_connections = 100



data_directory = '/var/lib/postgresql/8.4/database'             
hba_file = '/var/lib/postgresql/8.4/database/pg_hba.conf'       
ident_file = '/var/lib/postgresql/8.4/database/pg_ident.conf


Damit verbinde ich mich dann mit der Instanz:

 psql -U postgres -h localhost -p 5433 -d postgres

Nun klammere ich alle Einträge in der pg_hba.conf aus. (Im Verzeichnis der neuen Instanz)

Warum kann ich mich weiterhin zur Instanz auf Port 5433 verbinden?

Edit: Es funktionieren alle User, welche “eigentlich” nur unter der Main-Instanz von Port 5432 laufen.

Ich arbeite auf jeden Fall in der neuen Instanz. Hier wurde auch eine Test-DB angelegt.

Datei pg_database im global-Verzeichnis

"template1" 1 1663 648
"template0" 11563 1663 648
"postgres" 11564 1663 648
"test" 16387 1663 648

Edit: Es funktionieren alle User, welche “eigentlich” nur unter der Main-Instanz von Port 5432 laufen.

Das stimmt natürlich nicht. Drop ich einen USER unter 5433, dann kommt man nicht mehr auf diese DB.


Das Problem ist aber einfach, dass die Zugangsbeschränkung von der pg_hba.conf in keinster Weise berücksichtigt wird. Das macht mich sehr stutzig.

Ist das normal?

Karl

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.

Okay, überredet. Ich lass die Instanzen. Ich werd dann aber wohl einen zweiten v-Server aufsetzten. VM lebe hoch.

Oh man …

Hast du irgendeines meiner Argumente gelesen und verstanden? :wink:

+1 :wink:

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.

Gruß Uwe