Re: Slony geeignet?

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Christian Voelker <C(dot)Voelker(at)gmx(dot)net>
Cc: pgsql-de-allgemein(at)postgresql(dot)org
Subject: Re: Slony geeignet?
Date: 2007-09-19 09:05:09
Message-ID: 46F0E645.80808@kaltenbrunner.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-de-allgemein

Christian Voelker wrote:
> Hallo,
>
> ich habe gerade diesen relativ aktuellen Vergleich
> (Februar 2007) zu verschiedenen Möglichkeiten des
> Postgres Clusterings gelesen und frage mich, ob
> die miserable Bewertung von Slony zutreffend ist.
> Eine richtige Version History konnte ich auf der
> Slony Seite nicht finden.
>
> <http://wiki.dspace.org/index.php/HOWTO_Clustering#PostgreSQL>
> <http://slony.info/>
>
> Gruß, Christian
>
> Zitat:
>
> PostgreSQL
>
> Slony-I
>
> Slony-I is a "master to multiple slaves" replication system.
> Unfortunately, it lacks support for many key features I would
> consider necessary for clustering:

"clustering" ist ein sehr relativer begriff und jeder versteht darunter
etwas anders

>
> * No automatic failover or node promotion

korrekt und das ist ein Designaspekt. failover (im vergleich zu
switchover) ist ein businesskritischer Aspekt(Slony ist asyncron und ein
failover heisst unter umständen Datenverlust ob das akzeptabel ist hängt
absolut vom jeweiligen Einsatzgebiet ab).
Das treffen einer derartig massiven entscheidung sollte nicht einer
einzelnen Applikation oblieben sondern einem übergeordneten System
(Netzwerkmanagementsystem, Clustermanager, Operating,...) vorallem da ja
meist noch ganz andere Dinge auch geändert werden müssten
(Konfigurationen, IPaddresse, ...)

> * Trigger-based update propogation means that (eg)
> schema changes cannot be automatically propogated
> across nodes, and it is unable to replicate large
> objects

das ist insofern korrekt als das Schemaänderungen nicht automatisch
durchgeführt werden sondern mittels slonik (dem commandline tool)
durchgeführt werden müssen(das ist mehr ein problem des
changemanagements und dem development->QA->live prozess).
LOBs können nicht repliziert werden (keine trigger) - sehr wohl aber bytea.

> * It is unable to detect node failure

siehe erster punkt (und slony weiss schon das ein node nicht erreichbar
oder "hinten" ist deswegen spooled es ja die daten am Master)

> * No support for a multi-master replication topology
> (ie: there will always be a single point of failure)

korrekt

> * No support for connection brokering

das erledigt ma besser mit externen tools
(pgpoolI,pgpoolII,pgbouncer,appserver,..)

>
> All of these things combined mean that I will not be looking
> into using Slony-I. If anyone has any positive experiences
> with using it, please update this section.

slony ist sehr robust und auch sehr mächtig für eine reihe von
anwendungsfällen - es ist als ein Baustein in einer HA lösung gedacht
aber versucht sich auf das zu konzentrieren was es machen soll -> "daten
zu replizieren". Für andere Dinge sollte man spezialistierte Tools
verwenden.

Stefan

In response to

Responses

Browse pgsql-de-allgemein by date

  From Date Subject
Next Message Peter Eisentraut 2007-09-19 09:23:11 Re: Slony geeignet?
Previous Message Christian Voelker 2007-09-19 08:53:49 Slony geeignet?