Re: Tabellen im laufenden Betrieb auf andere Tablespaces verlagern ohne DB-Server Downtime?

Quoting Andreas 'ads' Scherbaum <adsmail(at)wars-nicht(dot)de>:

> > Mein Provider hat auf seinem Server eine begrenzte Kapazität was
> > Festplattenspeicher betrifft. Bei wachsender DB
> > möchte ich jedoch Handlungsfähig bleiben, nur wie lässt sich das am
> > besten einrichten?
>
> Indem man einen anderen Provider wählt, der flexibler ist.
> Ausserdem: sprechen wir über Tablespaces auf dem gleichen oder auf
> einem zweiten Server? So recht will sich mir nämlich der Sinn deiner
> Frage nicht erschließen bzw. kann es sein, dass du in die falsche
> Richtung denkst.

Es gibt nicht viele Provider die eine redundante Leitug zum DECIX
haben, ein Rechenzentrum nach den neuesten Standards und Spitzenhardware
zum günstingen Discountpreis sowie unlimited Traffic inkl. Bei einem kleinen
Wald und Wiesen Provider wirds meist teuer und die Leitung von und zum
Inet hin ist lahm und meist muss man noch den Traffic extra bezahlen.

Das Thema habe ich schon in verschiedenen Situation erlebt und würde
es sicherlich nicht noch einmal machen.

> > Das Programm legt ferner in
> >
> > $PGDATA/mydata/mydb/ die Tablespaces
> > ->forums
> > ->messages
> > ->users
> > u.s.w
> >
> > sowie alle Tabellen, Indexe, Trigger und Grants an.
>
> Dein Programm legt hoffentlich hoffentlich unterhalb von $PGDATA
> überhaupt nichts alleine an. Auf $PGDATA greift nur die Datenbank zu,
> wo genau die Daten dann liegen, interessiert dich nicht.

Doch, tut es, weil PG es nicht selber kann.
Es liest beim Start env(PGDATA) aus und erstellt relativ
dazu ein Verzeichnis "mydd_name" und setzt die FS Rechte
und Ownership auf postgres.postres. Danach connected
es sich selbst auf die DB und legt die Tablespaces
mit CREATE TABLESPACE in dem vorher erstellten Verzeichnis
an. Dies ist schon deswegen notwendig, da PG für CREATE
TABLE Spaces nun einmal einen existenten Ordner verlangt.

Danach erstellt es noch die notwendigen User, Schematas
und Tabellen und für Basisbetriesparameter ein.

Damit bin ich relativ schnell in der Lage die AppDB
Struktur auf dem neu in Betrieb zu nehmenden DB-Server
binnen sek zu erstellen.

> Bis dann
> P.S.: Warum kommt es mir so vor, als ob die Anforderung nur lautete
> "muss ohne Downtime funktionieren", ohne sich vorher konkret Gedanken
> über die Aufteilung der Struktur gemacht zu haben? Wenn ich deine
> Tablespaces sehe, könnte ich mir auch sehr gut verteilte Lösungen
> vorstellen, die sich recht einfach realisieren lassen.

Weil es nun mal so ist und ohne Downtime funktionieren muss, ganz
einfach, das ist die Anforderung!

Dabei müssen einzelne Komponenten trotzdem austauschbar und das
Gesammtsystem wartbar und skalierbar bleiben. Ich mache mir sicherlich
nicht die ganze konzeptionelle arbeit, messe und evaluiere so mal
eben zum Spass. Wenn das Ding mal läuft, soll es Gewinne abwerfen und
da muss man eben besser sein als die Konkurenz.

Downtimes und schlechte Performance bei konstanten sowie stark
wachsenden Userzahlen sind ein KO Kriterium und no go das unbedingt
vermieden werden muss und daher ist es Gegenstand der aktuellen Planspiele.

Momentan gilt es eigentlich nur noch das Thema Plattenkapazität erhöhen
im laufenden Betrieb abzuklären. Mein Provider bietet einen service an,
der ungefähr in die Richtung geht, aber eher auf Radundanz abzielt
(also Raid 10 SCSI Controller nachrüsten u.s.w)

ein verteiltes Szenario ist aber ein interessanter Gedanke, nur scheinen
80 GByte Server Festplatte dabei trotzdem zu wenig, gerade wenn eine
Tabelle schon über 450 GByte gross ist und stark weiter wächst.

Mfg