Tuesday 25 January 2011 4:46:35 am
While I agree that having smarter management inside of ez of master-slave setups would be nice (especially since this setup is supported with recent versions of postgres and oracle too, so that once it is coded in eZ it should be available to every user at no cost), generally speaking I prefer to push this kind of problems down to the architecture layer. In the ideal world eZ should not even know about a master/slave setup. Oracle rac does it native of course, but it costs a huge amount of money, uses a lot of resources and is a pain to setup. Recent developments in the mysqlnd php driver indicate that we might get transparent load-balancing out of the box in the near future. Not sure about postgres, maybe there are commercial solutions (tungsten ?) doing that today. The reason i say eZ should not care about this is because every complex architecture deployment has different needs in term of backups, availability, failover, polling, monitoring etc... A robust, complete and flexible solution takes a lot of time to develop, test and maintain. And in pur oss style, why reinvent the wheel inside eZ, if it already exists elsewhere?
Principal Consultant International Business
Member of the Community Project Board
|