[kullervo]

Jag har väldigt dålig koll på hur MySQL's replikering fungerar och eftersom MySQL är som dom är så har jag svårt att gissa hur det fungerar i MySQL.

Några anledningar att slavarna *borde* kunna gör ändringar effektivare än mastern:
* Slavarna kan göra många ändringar i en om samma transaktion (färre duttar på disk samt färre uppdateringar av index) => stor gain i prestanda.
* De gör uppdateringarna när den har tid över.
* Man behöver inte replikera all data till alla slavar.
* Loggning och annan data som man normalt inte behöver presenteras på webbsajten kan ofta gott ligga på endast mastern eller på endast en av slavarna.

Men visst, har du en snabb master och tröga slavar så kan uppdateringarna på slavarna bli flaskhalsen. Eftersom MySQL's replikering är asynkron kommer det resultera i stor fördröjning i replikeringen vilket iofs webbsajten skulle kunna vara designad för att klara av.

Föresten, nu när jag tänker efter så är väl MySQL's replikering semi-synkron? Dvs. att den anser att transaktionen är avslutat när minst två slavar ack:at?


Edit:
Man kan också dela upp alla SELECTS så att de skickas till olika slavar beroende på vilka tabeller de läser från. Då kan man plocka bort alla index för de tabeller som det inte select:as från => mindre arbete för slavarna vid ändringar av av data.

Edit2:
Sitter bara och spånar lite här. Listan kan säkert göras mycket längre.

[grazzy]

Okey.. men då är det ungefär som jag trodde då i alla fall. Med tanke på att inga garantier lämnas på att skrivningarna faktiskt sker till slavarna inom en viss tidsperiod så har jag lite svårt att se fördelarna med det upplägget helt ärligt. Användare lär bli lite lagom sura om de gör förändringar som inte syns direkt etc. Tror inte att disclaimers i stil med "vänta lite, det är snart klart, kanske" skulle vara så poppis.

[kullervo]

Ja, så blir det ju när uppdateringarna sker asynkront. Att köra synkron medför massor av andra tekniska nackdelar (för att inte tala om ekonomiska vad jag vet). En enkel lösning är att köra alla select mot mastern en viss tid efter att klienten gjort en ändring i databasen. Men visst, det är mycket mer bekvämt att skaffa en feting-feting-burk och bara köra en db-server (jag säger inte att det är rätt). Begagnade fin-maskiner såsom Sun Enterprise/Fire servrar behöver inte kosta mycket. Det har legat en välutrustad Fire 6800 med 20 st. 900MHz CPU:er, 40GiB RAM på Ebay länge för $16k. Det är inte direkt ont om den typen av maskiner på andrahandsmarknaden men ofta är priset mycket högre. Har man en sån "behöver" man inte oroa sig för redundans av hårdvara på samma vis som om man kör PC-servrar som knappt klarar av minsta hårdvarufel.

Flickr.com kör 25k transaktioner per sekund (enligt deras product case på www.mysql.com) men en vanlig MySQL-replikerings-lösning. Jag antar att dom menar antal transaktioner + övriga SQL-frågor per sekund. Iofs har Flickr prestandaproblem, men ändå.

[iXam]

Att köpa begagnad "exotisk" hårdvara och köra affärskritiska databaser på tycker inte jag är en större hit. Vad händer _när_ den går sönder? Kör man däremot replikering och SMART programmering kommer man riktigt långt med vanliga PC-servrar som går att köpa snabbt och billigt.

När man bygger siter som ska klara av att skala lite så är caching ett måste. Cacha i filsystem, cacha i ramminnet (memcached). Hur ofta behöver man egentligen en korrekt siffra på antalet inloggade? Den kan man lätt uppdatera en gång i minuten och ha den som en statisk html-sida i en iframe exempelvis. Varenda SQL-fråga ska köras genom "explain" samt köras med testdata. Om en query tar en sekund så betyder det att det max får utföras en sådan fråga per sekund, annars köas dessa upp till antingen besöksfrekvensen går ner eller mysql börjar klaga på resurssvält.
Databasen ska ha maximalt med minne (så mycket du har råd med) samt ha rappa diskar (förr eller senare måste ju det hämtas data eller flushas data).
64bitars processorer och operativsystem är som gjort för databashanterare.

[grazzy]

Fast flickr lär ha betydligt fler läsningar än skrivningar.. en del av informationen jag hänvisade till kommer från boken "Building scalable websites" som just en av killarna bakom den tekniska lösningen på flickr har skrivit. Och jag tycker inte att han verkar ha något svar på just min fråga . Det förklarar väl kanske saken, heh.

Edit: ja, jag gjorde det ruggigt dumma valet att stoppa sata-diskar i min dual opteron.. jag kan säga att det är en riiiiktigt stor flaskhals just nu. Load ligger på runt 3 under högtryck och då är det nästan alltid 80-90% iowait. Som tur är så är det ju inget jätteingrepp att stoppa in en scsi-raid i efterhand eftersom det är en tower.. men det var ett dumt ställe att snåla på såhär i efterhand, helt klart.

[iXam]

Originally posted by grazzy@Sep 15 2006, 19:25
Edit: ja, jag gjorde det ruggigt dumma valet att stoppa sata-diskar i min dual opteron.. jag kan säga att det är en riiiiktigt stor flaskhals just nu. Load ligger på runt 3 under högtryck och då är det nästan alltid 80-90% iowait. Som tur är så är det ju inget jätteingrepp att stoppa in en scsi-raid i efterhand eftersom det är en tower.. men det var ett dumt ställe att snåla på såhär i efterhand, helt klart.

Vad har du stoppat i databasen?
Har du gett dig in i my.cnf och tunat?
Har du joinar som skapar temporära tabeller på disk?
Kör du "order by" på en kolumn som kanske inte är indexerad?
Kör du selects på stora blobbar som inte används igen inom minuten? Då är det kanske onödigt att lägga MySQL-query cache på det och att man kan skippa cachning av dessa frågor?
Och SATA anser jag inte nödvändigtvis behöver vara ett aber. Man får se till att man har bra diskar,kontrollerkort och drivisar. Kanske tom en raidsetup med SATA-300.
80-90% iowait låter som skapning av temporära tabeller vid joins i mina öron.
Som sann teknikgalning jag är skulle det vara skoj med lite info om tabeller,rader,index och querys.
Ännu roligare vore att släppas in (ssh typ) och spana läget lite och se om det går att göra nått snabbt och enkelt.

[kullervo]

Originally posted by iXam@Sep 15 2006, 18:24
Att köpa begagnad "exotisk" hårdvara och köra affärskritiska databaser på tycker inte jag är en större hit. Vad händer _när_ den går sönder? Kör man däremot replikering och SMART programmering kommer man riktigt långt med vanliga PC-servrar som går att köpa snabbt och billigt.

OT

Vad snackar du om? Vad är det för exotiskt med en Sun Fire-burkar? Jag har egentligen noll erfarenhet av Sun-maskiner, men jag kan upplysa dig lite lätt om hur servrar av bättre sort (Alpha, Sparc, PPC, HP-PA, Itanium etc.) hanterar trasig hårdvara. Kan inte lova att följande gäller för alla nämda arkitekturer. Om det blir för mycket fel i en minnesmodul offline:as den. Om en CPU-pajar så offlineas den. Om någon IO-enhet pajar så behöver inte det vara hela världen (till skillnad mot en kernel panic á la Linux). Om någon t.ex. kortsluter en PCI-buss så är det nog inte heller hela världen. Vill man stoppa i minne, byta ut eller lägga till CPU:er osv så är det bara att offlina det aktuella magasinet och byta ut eller stoppa i ett nytt. Har man dessutom schysst garanti och eventuellt supportavtal så blir biffen fixad snabbt och smidigt vid fel. För övrigt är datorer med högra kvallitét byggda med ECC på de flesta bussar och minnen osv. just för att de ska vara driftsäkra. Man köper inte en burk för kanske flera miljoner om den är så opålitlig att man måste ha en till bredvid som redundans.

Visst håller jag med dig om att det ofta är bättre att bygga en infrastruktur med många mindre burkar där tjänsterna som burkarna kör enkelt kan flyttas runt (gärna med automatik för failover). Det har jag inte sagt något om. Att det alltid är bra med billiga PC-servrar kan jag direkt sätta mig emot. Ibland har man högre krav på OS:et än vad som finns tillgängligt för PC. Ibland har man höga krav på kvalitéten på burkarna och ibland är det billigt som gäller. Sånt varierar ju faktiskt.

[iXam]

Exotiskt i jämförelse med mindre x86-servrar (och dess 64-bitars kusiner).
Det enda jag var lite emot var att köpa ett begagnat system från exempelvis ebay.
Troligtvis utan garanti så när en ickefeltolerant komponent skiter sig så står systemet nere medans man försöker klura ut vad det egentligen är som behövs bytas ut.
Hade det dock varit en "normal" PC-server i ett databaskluster hade snabbaste och billigaste lösningen varit att ha en hot stand by alternativt springa och köpa en ny medans systemet får svettas lite extra under tiden.

Men jag har själv byggt system med sunburkar. r420 och r440 (om jag inte mins fel) samt en D1000 till en R440 som agerade NFS-server till ett linuxkluster som i sin tur hade en quad xeon med SCSI-RAID 5 som databasmaskin. 5 * webserver.
Men då var allt köpt nytt och vi hade support från Dimension utifall nått sket sig. Men det var innan IT-krachen.