MySQL Replication Configuration

Next topic

Author	Message
Ted Prosser	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.
Ted Prosser	Friday 11 November 2005 5:56:03 am Looks like eZ publish has to have write access to a MySQL database no matter what you are doing with the front-end. The ezsession table gets updated constantly. We've also noted temp tables get created and dropped. So much for that.

Author

Message

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.

Ted Prosser

Friday 11 November 2005 5:56:03 am

Looks like eZ publish has to have write access to a MySQL database no matter what you are doing with the front-end. The ezsession table gets updated constantly. We've also noted temp tables get created and dropped. So much for that.