In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Hervé
> Le Jeudi 20 Janvier 2005 15:24, Christopher Kings-Lynne a écrit :
>> > Is there any solution with PostgreSQL matching these needs ... ?
>> You want: http://www.slony.info/
>> > Do we have to backport our development to MySQL for this kind of problem
>> > ? Is there any other solution than a Cluster for our problem ?
>> Well, Slony does replication which is basically what you want :)
>> Only master->slave though, so you will need to have all inserts go via
>> the master server, but selects can come off any server.
> Sorry but I don't agree with this ... Slony is a replication
> solution ... I don't need replication ... what will I do when my
> database will grow up to 50 Gb ... I'll need more than 50 Gb of RAM
> on each server ??? This solution is not very realistic for me ...
Huh? Why on earth do you imagine that Slony-I requires a lot of
It doesn't. A fairly _large_ Slony-I process is about 10MB. There
will be some demand for memory on the DB servers, but you don't need
an enormous quantity of extra memory to run it.
There is a MySQL "replicating/clustering" system that uses an
in-memory database which means that if your DB is 50GB in size, you
need something like 200GB of RAM. If you're thinking of that, that's
not relevant to PostgreSQL or Slony-I...
> I need a Cluster solution not a replication one or explain me in
> details how I will do for managing the scalabilty of my database ...
I'm not sure you understand clustering if you imagine it doesn't
There are numerous models for clustering, much as there are numerous
But the only sorts of clustering cases where you get to NOT do
replication are the cases where all you're looking for from clustering
is improved speed, and you're willing for any breakage on any host to
potentially destroy your cluster.
Perhaps you need to describe what you _think_ you mean by a "cluster
solution." It may be that it'll take further thought to determine
what you actually need...
output = ("cbbrowne" "@" "gmail.com")
"Not me, guy. I read the Bash man page each day like a Jehovah's
Witness reads the Bible. No wait, the Bash man page IS the bible.
Excuse me..." (More on confusing aliases, taken from
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match