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

From: rudi(at)je-more(dot)de
To: Michael Renner <renner(at)inqnet(dot)at>
Cc: pgsql-de-allgemein(at)postgresql(dot)org
Subject: Re: Tabellen im laufenden Betrieb auf andere Tablespaces verlagern ohne DB-Server Downtime?
Date: 2008-05-21 14:46:28
Message-ID: 1211381188.483435c4d3f54@webmail.konsole-h.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-de-allgemein

Quoting Michael Renner <renner(at)inqnet(dot)at>:

> rudi(at)je-more(dot)de schrieb:
>
> > 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.
>
> Sei mir nicht bös, aber das von dem du da gerade erzählst klingt
> ziemlich nach Wald&Wiesen-Provider mit Fehleinschätzung der Situation :).

Ganz groß kann ja auch "auch" ein Problem sein, weil die ausser
Stangenwahre nichts spezielles machen, das ist eben Massengeschäft.
Zu klein kann jedoch den Nachteil haben schlecht angebunden oder technisch
nicht auf dem hohen Niveau der großen zu sein.

Daher bin ich dort wo ich bin eigentlich recht zufrieden. Ich habe
mittlerweile angrafragt und sie würden mir auf wunsch auch biszu 4 Platten
einbauen, das Problem ist somit vorerst aus der Welt ;d

> Cheap, Fast, Reliable ist nahezu immer (ausser die Housing/Hosting
> Business Unit der Firma ist nicht Gewinnorientiert) ein "pick two out of
> three".
>
>
> [..Storagewahnsinn..]
>
> Mit einzelnen Systemen kannst du bis zu einer gewissen Größe
> Blockdevicemässig wachsen. Dies wird eigentlich nur durch die Diskslots
> im Gehäuse bzw. die SATA/SAS-Ports am Controller beschränkt. Sinnvolle
> RAID-Controller (zB HP Smartarray) können Volumes online extenden bzw.
> erzeugen; obs das darunterliegende OS mit Volume-Manager kann gilt es
> auszuprobieren.

Debian Etch 4.0 64-Bit. Über NFS mache ich einiges, aber LVM
habe ich bisher nicht angerührt, ist für PG wohl aber auch nciht empfohlen,
zumindest laut Performanceguide aus der offiziellen Doku.

> Falls man Gefahr läuft relativ bald ans Limit des Gehäuses/Controllers
> zu kommen, sollte man einen Blick in Richtung SAN werfen, die sind
> meistens noch eine Spur besser online erweiterbar.

Und kosten ein Vermögen ;d Das Geld muss erstmal reinkommen, dann
kann das kommen, vorher erstmal kleine Brötchen backen ohne gegen die Wand
zu fahren. Ich bin überzeug das auch das geht ;d

> Da du wieder Gefahr läufst ins 99,999999% Traumland abzudriften

Kann deine Ansicht diesbezüglich nicht teilen, da ich schon standalone MySQL
Tabellen habe die jenseits von 450 Gybte liegen und permanent anwachsen.
Die gesammt DB knackt bald die 800 GByte Grenze, daher muss das Ablösesystem
mit Postgres 8.3 bald zum Zug kommen. Dabei dürfen aber die alten, schlechten
Attribute wie Downtimes und schlechte skalier und wartbarkeit kein Problem
mehr sein.

>wärs
> langsam wirklich nett wenn du wo ein komplettes Konzept bzw.

Sorry, das ist etwas zu umfangreich ;d

In response to

Responses

Browse pgsql-de-allgemein by date

  From Date Subject
Next Message Michael Renner 2008-05-21 15:09:28 Re: Tabellen im laufenden Betrieb auf andere Tablespaces verlagern ohne DB-Server Downtime?
Previous Message rudi 2008-05-21 14:15:26 Re: Tabellen im laufenden Betrieb auf andere Tablespaces verlagern ohne DB-Server Downtime?