Hi Philip, thanks for the reply.
Single master + many read only slaves would only solve the problem of
handling many many concurrent read accesses, by distributing the load
across all slaves.
However, I guess the real problem, is that the writes would still need
to be performed across ALL databases, and the DB would be HUGE, would it
not?
Lets say I host 100 forums, with 100k posts each, every write would need
to be replicated to as many slaves as I have.
Thanks!
Jay
Philip Hallstrom wrote:
Hi there,
I am in the midst of creating a forums hosting site.
1. It has to be highly scalable, so I doubt a single MYSQL db with
TONS of "subforums that simulate full forums" would do.
2. Also regarding scalablity, I hope to "Add capacity" as and when
its needed. So i'll have one server running initially, and when it
gets too crowded, i'll get two servers etc.
3. I will be providing a user with a "dashboard" that allows him to
view all his subscribed posts across ALL forums. So lets say a user
is a member of 25 forums, this dashboard view will allow the user to
view all his posts across all the forums.
Does anyone have advice that could point me in the right direction?
I have solved the scalability issue WITHIN a forum (code can handle
million + posts easy), but I havent solved the issue of scaling
MULTIPLE separate forums.
What about having a single write master with many read-only slaves?
Then modify your code so that posts go to the master and everything
else happens on the slaves?
Also, does there exist any php package that helps ease the process of
"deciding which Server/database to connect to"?
For example, someone accesses FORUM A, so the script would
automatically know to direct all queries to the DB in SERVER 1 etc,
and if i try to access FORUM J, it would connect to SERVER 2 etc. I
could easily hard code this, but I was thinking "what if internal IP
addresses change, or I decide to migrate a busy forum to a server of
its own etc", so perhaps there is a better available packaged
solution designed for this task.
Create a table on a "central" server that contains this mapping. This
server could also hold the login tables as well...
Just a thought.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
