Inte för att det är ett svar på frågan.
Men cachar ni de mest besökta/ mest databas- intensiva sidorna ?

Hade det varit bara några få writes och mest reads så hade det ju varit en idé att skala upp med bara en master. Men det är mycket fler writes än så, varför bara writes-delen av anropen behöver skalas om du förstår vad jag menar.

Det är ingen idé att cacha eftersom datan ändras mellan varje sidvisning.

Då kommer replication inte att ge någon bost i performance enligt vad dom själva anger i sin faq utan det kan istället bli tvärtom pga man lägger till en kommunikations overhead. Detta är ju inte särskilt konstigt eftersom alla update alter måste gå ut till alla servrar så det är endast fördelningen ev reads som ger lättnad åt servern och en read kräver sällan mer än en write så lättnaden blir inte så stor. Detta är ju egentligen inte din fråga så ursäkta om det blev för mycket off topic.

Det du borde kolla på är deras cluster lösning som jag inte känner till men som verkar intresant, tror att den redan är släppt eller så kommer den att släppas snart, kanske någon här som vet mer om den?

Huh? Som jag förstår det kräver utförandet av instruktioner i den binära loggen mycket mindre av maskinen och att använda den för att replikera data till övriga servrar är bättre än att utföra SQL-frågorna på var och en av dem?

Om du postar strukturen över databasen kanske någon kan hitta en strukturoptimering. En metod är att dela upp vissa tabeller som innehåller mycket text till två (där texten hamnar i en tabell och resten i en annan). Då kan du ha fixed length på huvudtabellen och sedan med relation hämta den stora texten från den andra tabellen.

Du sa att du redan optimerat alla SQL-queries. Har du kontrollerat hur stor del av frågorna som inte använder sig av index fullt ut? Ses enklast i MySQL Administrator.

Vilken typ av tabeller använder du sig av? MyISAM låser hela tabellen vid skrivning (som någon redan sagt) medans InnoDB klarar av att låsa endast den aktuella posten.

Kanske du kan använda mer heap-tabeller som buffert mellan "den riktiga" taballen. Låt sedan den riktiga tabellen uppdateras av heap-tabellen regelbundet.

Eftersom du har en rätt så slö propp i burken skulle jag gissa på att det är bättre att lägga pengar på snabbare dator än att lägga ner tid på allt som har med replikering att göra. Du ska ju ändå hur som helst skaffa en till burk om du ska köra replikering. Släng på lite extra krut på den burken om möjligt och låt den ersätta den gamla. Nu var det inte en sådan lösning du verkade intresserad av, men det är åtminstonde ett tips.

Som sagt, frågorna är optimerade och tabellerna är normaliserade. Index används alltid. Det är myisam-tabeller men jag har inte vågat byta till InnoDB för att jag inte vet hur de klarar stressen.

Som någon tidigare påpekade så är det maskinvara i db-servern du ska byta ut, inte köpa ny och lägga till.
En server med två cpu:s arbetar mycket snabbare, speciellt när flera kommandon ska köras samtidigt.

Vi körde Silverplanet.se(som hade som mest ~500-600 online) på en cpu med dubbla MP 1600+, scsi och apache&mysql på samma maskin. ett försök att göra samma sak på en dator med bara en processor(även om den var mycket snabbare) gick som förväntat, åt h3v3te. Nåväl, då bråkade mysql med apache så det är ju en del av förklaringen. Men fortf. Dubbla processorer, mer cache och snabba sånna :) så har du nog en lösning som håller sig ett tag in på framtiden iaf.

"Krångla inte till det mer än nödvändigt" som någon vis man sa ^^

Att replikera över flera servrar är mycket billigare än att köpa en superdupermaskin - och mer skalbart. Jag kör bara MySQL på maskinen jag nämnde. Om det är någon som skulle vilja hjälpa till med min ursprungliga fråga så vore jag tacksam, det är mycket prat om annat.

Det är ju det vi gör.. :-) Jag tror liksom så många andra att du ska satsa på en bättre burk i första hand.

Och jag kan inte hålla mig och jag måste påpeka att en normaliserad databas är inte alltid det mest effektiva. Teori och praktik går tyvärr isär här ibland...

Men jag sökte lite snabbt och:
http://dev.mysql.com/books/hpmysql-excerpts/ch07.html
säger bl.a:
"If you attempt to use replication to set up a load-balancing system, you may be disappointed."

Man rekommenderar snarare att man i så fall skall segmentera sitt data och lastbalansera så. dvs, flytta vissa tabeller till en annan DB server och kör frågor mot två olika servrar.

Fråga råd hos dom du har maskinen vad dom tycker och kanske får fram en bra lösning på det.

Amd Opteron maskin med SATA disk rullar nog rätt så bra om du idag kör en vanlig maskin med ide. Scsi är väl alltid bäst men sata ligger nog inte så långt ifrån.