On Wed, Jul 07, 2004 at 12:39:34PM +0200, Yannick Lecaillez wrote:
> Thanks a lot for all people which answer.
>
> I have this "clustering on SAN" problem today and i think it could be
> less harder to implement this today than it was for Oracle in 1993
You want to do clustering for failover/reliability reasons, for
performance/scalability reasons, or for both?
For some stuff to read, see the dozen or so links I posted here:
http://openacs.org/forums/message-view?message_id=128060
E.g., the Lustre cluster file system claims full POSIX file system
semantics (locking, etc.), so you should certainly be able to run
PostgreSQL on it. No idea how well that works, but it should
certainly let you do fail over.
Perhaps you could even somehow, eventually, get multiple PostgreSQL
instances on different machines to all cooperate with read/write
access to the same database files over the network. (And without
using super-expensive SCI hardware the way Clusgres does.) That might
get you a true cluster RDBMS, if it worked well.
Another thing I've been wondering about, but haven't been able to find
any discussion of:
Just how closely tied is PostgreSQL to its use of shared memory? At
least in principle, could all direct use of shared memory be replaced
with MPI? Could that even work at all? And in the degenerate case
where the MPI implementation is itself actually using shared memory
underneath (rather than sending messages across the network), would
performance still suck?
In other words, if MPI is unsuitable for PostgreSQL, is it because the
SEMANTICS of MPI are inherently unsuitable, or is it just
implementation or performance issues?
What about PostgreSQL specifically makes message passing no good, and
is the same also true for ALL RDBMSs? What about systems like
Backplane, which claims to be "the only open-source, transactional,
truly distributed database."?
http://www.backplane.com/
--
Andrew Piskorski <atp@piskorski.com>
http://www.piskorski.com/
