A colleague and I are having a discussion about the best way to handle
high traffic sites. For example, take a social networking site with 1
million users.

I think it would be better to have multiple web servers with multiple
database servers in a master/slave scenario with replication.

My colleague supports the idea of clustering, with MySQL running on the
same box as the web server.

From a MySQL standpoint, are there any best practices for building high
traffic sites with a MySQL back end? Neither my colleague nor I are
DBA's, nor are we sys admin experts.

Any thoughts are most welcome.

-Erich-

I highly recommend you hire a consultant or a freelance DBA to try to work
this out.

You are talking about something pretty extensive. I would recommend
replication across quite a few high-end servers (all 64 bit of course with
plenty of RAM). Clustering can be a pretty big headache. A lot of this is
going to depend on what you see the most of (reads/writes? etc.). You are
correct in your thoughts, though, about having multiple database servers....

A project like this will most likely require much more initial information
and evaluations to find out a solution suitable to your needs.

On 10/22/07, Erich C. Beyrent <erich.beyrent@beyrent.net> wrote:
>
> A colleague and I are having a discussion about the best way to handle
> high traffic sites. For example, take a social networking site with 1
> million users.
>
> I think it would be better to have multiple web servers with multiple
> database servers in a master/slave scenario with replication.
>
> My colleague supports the idea of clustering, with MySQL running on the
> same box as the web server.
>
> From a MySQL standpoint, are there any best practices for building high
> traffic sites with a MySQL back end? Neither my colleague nor I are
> DBA's, nor are we sys admin experts.
>
> Any thoughts are most welcome.
>
> -Erich-
>
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:
> http://lists.mysql.com/mysql?unsub=c...tler@gmail.com
>
>

Craig,

Thank you for your insight. Having never worked with clustering
solutions, what kinds of headaches might one see with that solution?

Does anyone know of any white papers that might shed some light into the
pros and cons of each solution?

-Erich-

Craig Huffstetler wrote:
> I highly recommend you hire a consultant or a freelance DBA to try to work
> this out.
>
> You are talking about something pretty extensive. I would recommend
> replication across quite a few high-end servers (all 64 bit of course with
> plenty of RAM). Clustering can be a pretty big headache. A lot of this is
> going to depend on what you see the most of (reads/writes? etc.). You are
> correct in your thoughts, though, about having multiple database servers....
>
> A project like this will most likely require much more initial information
> and evaluations to find out a solution suitable to your needs.
>
> On 10/22/07, Erich C. Beyrent <erich.beyrent@beyrent.net> wrote:
>> A colleague and I are having a discussion about the best way to handle
>> high traffic sites. For example, take a social networking site with 1
>> million users.
>>
>> I think it would be better to have multiple web servers with multiple
>> database servers in a master/slave scenario with replication.
>>
>> My colleague supports the idea of clustering, with MySQL running on the
>> same box as the web server.
>>
>> From a MySQL standpoint, are there any best practices for building high
>> traffic sites with a MySQL back end? Neither my colleague nor I are
>> DBA's, nor are we sys admin experts.
>>
>> Any thoughts are most welcome.
>>
>> -Erich-
>>
>>
>> --
>> MySQL General Mailing List
>> For list archives: http://lists.mysql.com/mysql
>> To unsubscribe:
>> http://lists.mysql.com/mysql?unsub=c...tler@gmail.com
>>
>>
>

Hi,

There are a lot of clustering you techniques you can use. Read on
livejournal attack on this problem. You need to start from the schema
poorly constructed schema will kill your hardware.

Go to Mysql Site search for whitepapers and friendster (I'm not
saying it the best implementation but it will give you an idea.)

Hth,

-----Original Message-----
From: Erich C. Beyrent [mailto:erich.beyrent@beyrent.net]
Sent: Monday, October 22, 2007 10:10 AM
To: MySQL General
Subject: Re: High Traffic Sites

Craig,

Thank you for your insight. Having never worked with clustering
solutions, what kinds of headaches might one see with that solution?

Does anyone know of any white papers that might shed some light into the

pros and cons of each solution?

-Erich-

Craig Huffstetler wrote:
> I highly recommend you hire a consultant or a freelance DBA to try to
work
> this out.
>
> You are talking about something pretty extensive. I would recommend
> replication across quite a few high-end servers (all 64 bit of course
with
> plenty of RAM). Clustering can be a pretty big headache. A lot of this
is
> going to depend on what you see the most of (reads/writes? etc.). You
are
> correct in your thoughts, though, about having multiple database
servers....
>
> A project like this will most likely require much more initial
information
> and evaluations to find out a solution suitable to your needs.
>
> On 10/22/07, Erich C. Beyrent <erich.beyrent@beyrent.net> wrote:
>> A colleague and I are having a discussion about the best way to
handle
>> high traffic sites. For example, take a social networking site with
1
>> million users.
>>
>> I think it would be better to have multiple web servers with multiple
>> database servers in a master/slave scenario with replication.
>>
>> My colleague supports the idea of clustering, with MySQL running on
the
>> same box as the web server.
>>
>> From a MySQL standpoint, are there any best practices for building
high
>> traffic sites with a MySQL back end? Neither my colleague nor I are
>> DBA's, nor are we sys admin experts.
>>
>> Any thoughts are most welcome.
>>
>> -Erich-
>>
>>
>> --
>> MySQL General Mailing List
>> For list archives: http://lists.mysql.com/mysql
>> To unsubscribe:
>> http://lists.mysql.com/mysql?unsub=c...tler@gmail.com
>>
>>
>

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:
http://lists.mysql.com/mysql?unsub=jmacaranas@fxdd.com


--------------------------------------------------------------------------------------------------------
This message and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom it is
addressed. It may contain sensitive and private proprietary or legally
privileged information. No confidentiality or privilege is waived or
lost by any mistransmission. If you are not the intended recipient,
please immediately delete it and all copies of it from your system,
destroy any hard copies of it and notify the sender. You must not,
directly or indirectly, use, disclose, distribute, print, or copy any
part of this message if you are not the intended recipient.
FXDirectDealer, LLC reserves the right to monitor all e-mail
communications through its networks. Any views expressed in this
message are those of the individual sender, except where the
message states otherwise and the sender is authorized to state them.

Unless otherwise stated, any pricing information given in this message
is indicative only, is subject to change and does not constitute an
offer to deal at any price quoted. Any reference to the terms of
executed transactions should be treated as preliminary only and subject
to our formal confirmation. FXDirectDealer, LLC is not responsible for any
recommendation, solicitation, offer or agreement or any information
about any transaction, customer account or account activity contained in
this communication.

Erich C. Beyrent wrote:
> Craig,
>
> Thank you for your insight. Having never worked with clustering
> solutions, what kinds of headaches might one see with that solution?
>
> Does anyone know of any white papers that might shed some light into the
> pros and cons of each solution?

You *did* look at the mysql website right?

under white papers

http://mysql.com/why-mysql/white-pap...ailability.php

Dave