Daniel Duvall wrote:
While "clustering" in some circles may be an open-ended buzzword --
mainly the commercial DB marketing crowd -- there are concepts beneath
the bull that are even inherent in the name. However, I understand
your point.
high-availability), and parallel execution (high-performance... sure).
While some consider the implementation of only one of these to qualify
a cluster, others seem to demand that a "true" cluster must
implement both.
What I'm really after is a DB setup that does fail-over and parallel
execution. Your setup sounds like it would gracefully handle the
former, but cannot achieve the latter. Perhaps I'm simply asking too
much of a free software setup.
Thanks for your response.
While "clustering" in some circles may be an open-ended buzzword --
mainly the commercial DB marketing crowd -- there are concepts beneath
the bull that are even inherent in the name. However, I understand
your point.
From what I've researched, the concepts and practices seem to fall
under one of two abstract categorizations: fail-over (ok...high-availability), and parallel execution (high-performance... sure).
While some consider the implementation of only one of these to qualify
a cluster, others seem to demand that a "true" cluster must
implement both.
What I'm really after is a DB setup that does fail-over and parallel
execution. Your setup sounds like it would gracefully handle the
former, but cannot achieve the latter. Perhaps I'm simply asking too
much of a free software setup.
Thanks for your response.
http://archives.postgresql.org/pgsql-admin/2005-06/msg00013.php
With PITR you can have one or more remote machine/s that
continuously replay log from main, and if the main crash
the "mirrors" can come out from their reply and go "on line".
At that time was not possible connect to a "replayng" engine
to perform ( at least ) queries, dunno if this changed in 8.1
BTW, did someone go further with that idea? If not I'd like rewrite
that stuff in C ( I do prefer C++ ).
Regards
Gaetano Mendola
