Re: 64 Bit auf WebServer

Alvar Freude <alvar(at)a-blast.org> wrote:
> Oliver Fromme <olli(at)lurza.secnetix.de> wrote:
>
> > > sinnvoll waere es dennoch diese files weiterhin zu splitten, da sie
> > > sonst nicht rueckwaerts-kompatibel sind.
> >
> > Korrekt. Oder kompatibel zwischen derselben PostgresSQL-
> > Version auf verschiedenen Plattformen, was extrem nützlich
> > sein kann, wenn man z.B. eine Datenbank von einem i386-
> > Rechner auf einen amd64-Rechner umziehen will (oder umge-
> > kehrt).
>
> ich weiß jetzt nicht ob die Dateien kompatibel sind, auch was
> Little-Endian/Big-Endian anbelangt;

i386 und amd64 sind beide Little-Endian, und die Dateien
sind formatkompatibel, soviel ich weiß.

> aber das übliche um eine DB vom
> einen System auf das andere zu transferieren ist ein pg_dumpall;

Das kommt ganz drauf an, wie die betreffende Serverfarm
aufgesetzt ist. Es ist z.B. durchaus nicht unüblich, daß
die Daten von einem Netzwerk-Massenspeicher kommen (sei es
per NFS, iSCSI oder sonstwas). In so einem Fall muß man
gar nichts transferieren, sondern läßt den neuen Server
einfach auf die bestehenden Daten zugreifen. Hat den Vor-
teil, daß die Ausfallzeit nahezu Null ist. Ähnlich verhält
es sich bei Konzepten mit Wechselfestplatten (habe ich auch
schon gesehen): Platte aus altem Server rausziehen, in
neuen Server reinstecken, Dienst wieder starten.

Mit pg_dumpall wird man eher nicht so glücklich, wenn die
Datenbank größer ist als nur ein paar Gbyte. Man will ja
nicht ein paar Stunden warten müssen. Vor allem wollen das
die meisten Kunden nicht. ;-)

Klar, es gibt work-arounds, z.B. das pg_dumpall ausreichend
lange vorher laufen lassen, in die neue Datenbank reinfüt-
tern, dann die WAL-Journals seit dem Anlegen der Dumps in
der neuen Datenbank nachspielen ... Damit minimiert man
die Ausfallzeit auch, aber es ist »fummlig« und aufwendig,
nach dem Motto: Wieso einfach, wenn's auch komplizert geht?

> das
> braucht man (leider) auch bei größeren Versionssprüngen, das nervt

Da stimme ich Dir leider zu. Immerhin kann man so ein Up-
date im voraus planen und entsprechende Vorbereitungen
treffen (siehe oben). Aber wenn man unvorhergesehen ge-
zwungen ist, die Datenbank auf einen anderen Rechner zu
migrieren (z.B. Hardware-Schaden), sieht die Sache anders
aus.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
Perl is worse than Python because people wanted it worse.
        -- Larry Wall
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message