Maxence DUNNEWIND wrote:
I'm working on some zope based cluster. The network schema can be found
at http://people.dunnewind.net/maxence/cluster3.png .
All the database part (the red/pink parts) are managed with postgresql
(with replication).
The relationships between the databases in the diagram are unclear. Let
me take a guess at what it means. There is one logical database but
three database servers. The solid arrows represent synchronous
replication and the dashed arrows represent asynchronous replication.
All commits eventually get reflected throughout the cluster.
If that's right, I don't see how it can actually work correctly with
most ZODB applications (especially Plone and anything that uses ZCatalog
or BTrees). It will produce massive data corruption. OTOH, maybe I
didn't understand the diagram correctly.
Incidentally, I don't think it's wise to push RelStorage beyond simple
slave replication (one master with multiple slaves) at this time. I
think multi-master replication is possible, but would require careful
thought, trade-offs, and site-specific configuration.
My problem is : I would that each zope server uses mainly one pgsql
server (like on the picture). Anyway, if one of the database server
fails, then I would than zope/zodb/relstorage switch to another database
server, and go back to his server when it will be back.
Any idea to make that with zodb/relstorage ?
At the moment, the only idea I have is to use an external check/watchdog
service which change the config file and reload zope in case of database
problem.
You could achieve this with iptables or a load balancer like Linux
Virtual Server, but again, be sure your replication strategy makes sense
before going down this road.
Shane
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
