Maxence DUNNEWIND wrote:
I'm working on some zope based cluster. The network schema can be found
at .
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

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.


For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to