|
Sunday 06 November 2005 4:25:37 am
I am trying to set up a secure eZ publish configuration with three servers and MySQL replication and rsync and I was hoping I could get some suggestions. Currently, I have two front-line web servers for serving public requests. A load balancer alternates traffic between the two. The front line servers are set up to use a local MySQL slave database for reads and a non-public administrative server (the MySQL master) for writes. The admin server is the only box with an eZ admin web site, which is not public. The front-line servers are getting constant database updates through MySQL replication. Rsync is set up to push out changes to /design, /var, and a few others, every 10 minutes or so. Cache folders are not set to synchronize. The eZ pages seem to render properly on the front-line servers, but I have the following questions: 1) Do the the front-line display-site-only servers really need to be able to write to the eZ publish database at all? I would prefer not to allow this. 2) Would the display sites ever really need to make changes to /var that would need to get copied over to the other servers? Remember that these servers are never going to run the admin site and I don't intend to use eZ publish for anything more than displaying content (no commerce). It makes sense to me that database access in this case should be read-only. I would rather avoid the eZ clustering solution for rsync if I can (I try to avoid using "beta" versions and I want to keep things as simple as possible). 3) I experimented with setting up an array of MySQL slave databases, but I was disappointed to find that eZ publish appears to randomly choose a slave database for reads. When a MySQL connection attempt fails for whatever reason, it looks the page load simply fails. eZ does not appear to be smart enough to try a different slave server on a connection failure. This seems to defeat the whole purpose of adding MySQL slaves to increase availability. Has anyone else addressed this? Thanks in advance for any replies.
|