Re: how to design mysql clusters with 30,000 clients?
On Wednesday 22 May 2002 18:44, Dave Watkins wrote:
> At 16:02 22/05/2002 +0800, Patrick Hsieh wrote:
> >Hello list,
> >
> >I am expecting to have 30,000 http clients visting my website at the
> >same time. To meet the HA requirement, we use dual firewall, dual
> >Layer-4 switch and multiple web servers in the backend. My problem is,
> >if we use the user-tracking system with apache, php and mysql, it will
> >surely brings a huge amount of database traffic. How can I balance mysql
> >load among multiple mysql server yet assure the data consistency among
> >them? My idea is:
> >
Actually you don't need to do clustering at all, at least not for the systems
doing the actual id tracking. Use Apache's mod_unique (which will generate
unique ids even across a cluster of web servers with no need for them the
communicate) and then each web server can have its own user tracking
database, there will be no danger of id collisions.
If you need to do actual session management where you would have any of the
pool of servers needing to recover per-session data, then you're stuck back
where you were before, though at least you have globally unique ids now.
One way to deal with that issue is to provide some form of session affinity,
so once a given user session hits one particular apache, it always gets
directed there. Layer 4 switching may allow you to do that.
Another idea to throw into the mix is reverse proxying. Most likely you have
a mix of dynamic and static content, and the static stuff really could care
less where it gets served from, so set up your cluster so that each system
has a stripped Apache running on port 80 which can serve static content and
reverse proxy dynamic content handling off to a 2nd instance. Then you can
write your proxy rewrite rules such that they take into account the user's
session state, and you end up with effectively session affinity at the
dynamic server, which is really the only place it would matter. Then you have
no need for clustering at all, you can just replicate for reliability
purposes and munge your data together from each server when you need to do
reports.
--
To UNSUBSCRIBE, email to debian-isp-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: