Normalt sätt klarar du dig väldigt långt på en databas-server. En slav blir som ett första steg väldigt bra för backups (oavsett om du kör throttled backup så ger backup en ordentlig last om den ska ske inom OK tid med hyfsad datamängd). Att sedan ha 2-3 slavar kan vara en effektiv fortsättning. Problemen handlar då i stort bara om att sätta upp och övervaka replikeringen, samt lastbalanseringen på applikationssidan (mysqlnd har en färdig lösning där, men senast jag tittade på den belastade den applikationsservrarna för mycket).
För webbservrarna (eller applikationsservrarna) är det enda problemet man normalt sätt får oavsett vilken lastbalansering du väljer att du inte ska spara någon state lokalt på disk. Vanligaste fallet där det görs i en icke-distribuerad miljö är för att sessions-filer och uppladdade filer. Vissa väljer en lat lösning där; att de alltid ger samma server till samma användare och får en mängd användare som loggas ut om en server dör och måste sedan ändå specialhantera uppladdningar. Alternativen är att använda en distribuerad lösning eller desto enklare, ändra session-handler till en egen som går antingen mot MySQL eller än hellre en lättare key-value-store (aka NoSQL, t ex redis).
Det kanske inte lät så nu, men lastbalansering är inte så svårt att komma igång med skulle ha varit min poäng
