[David]

Har en massa trevliga community-funktioner på Sockerdricka men de kräver en sjujäkla massa av databasservern så nu när det är lite över 500 samtidigt inloggade användare så kämpar den för sitt liv den stackaren. Jag tänkte då naturligtvis replikera databasen och enklast vore att ha flera masters eftersom varje sidvisning kräver ett antal SELECT och kör minst en UPDATE och/eller INSERT.

Allt var frid och fröjd och jag skulle just beställa ytterligare en maskin när jag kom att tänka på att jag i alla tabeller använder mig av auto-increment-kolumner för primärnycklar. Om en master gör en INSERT i messages-tabellen till exempel och den andra gör det samtidigt så kommer det finnas två meddelanden med samma PK och båda servrarna kommer att kasta BAD_PRIMARY_KEY när de exekverar den andras INSERT.

Är det någon som löst det här problemet? Jag har boken High Performance MySQL och författarna föreslår ett antal sätt att lösa problemet men de kräver alla ett oerhört jobb i att ändra hur skripten använder primärnycklar.

[SkyNet]

Jag vet inte hur replikeringen ser ut i senare versioner (säg 4.1 här), men du borde bara ha två saker att välja mellan. Antingen ha en master som tar hand om alla inserts och en massa slavar, då slipper du problemen med autoincrement. Det är när du ska ha INSERT och UPDATEs spridda på flera servrar som det strular till sig. Då är det ett måste att ha någon slags funktion som håller reda på högsta id oavsett vilken server som vill sätta in raden i tabellen.

Om det är någon som vet mer så dela gärna med er, är intresserad av sådan lösning också. Har aldrig hittat något vettigt på nätet angående detta.

[grazzy]

Om ni har en handler för alla sql-frågor så borde det inte vara en alltför avancerad historia att tex köra ett regexp på frågorna för att ta reda på vad som är en INSERT/UPDATE och köra dom mot en server medans andra frågor går mot en annan server (och då kan ni juh redan där ha någon slags round-robin för att sprida frågorna mellan olika select-servrar).

[kullervo]

Vad har du för hårdvara nu? 500 inloggade samtidigt låter inte så farligt. Jag känner till ett community som också kör MySQL och har 5000 samtidigt inloggade och klarar sig med dual opteron. Visst, det är en krallig burk men nu har den siten 10 gånger fler samtidigt aktiva besökare och efter en snabb titt på Sockerdricka så ser den inte så farligt tung ut heller.

Edit: Helt utan erfarenhet av replikerade databaser kommer jag och tänka på en lösning. Låt den ena mastern insert:a jämna auto increment-värden och den andra ojämna. Jag tror inte det finns inställning för att göra det automatiskt i MySQL dock, så du måste kontrollera detta manuelt vilket iofs kan bli tungt...

En annan lösning vore att skapa en till primary key av typen bool. Defautlvärdet får vara 0 på ena servern och 1 på andra. Efter lite snabbt grubblande låter det hyssat fungerande i mitt huvud. Förmodligen en dum idé ändå =)

[kullervo]

Originally posted by grazzy@Nov 30 2004, 22:25
Om ni har en handler för alla sql-frågor så borde det inte vara en alltför avancerad historia att tex köra ett regexp på frågorna för att ta reda på vad som är en INSERT/UPDATE och köra dom mot en server medans andra frågor går mot en annan server (och då kan ni juh redan där ha någon slags round-robin för att sprida frågorna mellan olika select-servrar).

Finns inte det redan inbyggd i MySQL? Då är det master-servern som får ta hand om alla insert och slave-servern kan hantera selects.

[eg0master]

Jag håller med om att 500 samtidigt inloggade användare inte låter speciellt mycket. För de 500 lär ju knappast accessa databasen exakt samtidigt.

Innan jag viftade med lastbalanseringsplakatet skulle jag nog:
1) KOlla över att all DB access (select, insert, delete, update) är optimerad. Finns de rätta indexen etc.
2) Sedan handlar det om att kika på vad som görs. Låses tabeller när det inte behövs osv. Går det att göra de "slöa" sakerna på ett bättre sätt.

Du kanske redan gjort detta och kommit fram till att visst koden är dålig ut prestandasynpunkt och det kostar för mycket at skriva om saker så de är snällare mot databasen. Och även om vi tittar på ett mer generellt fall så är det ju så att förr eller senare vill man ju kanske lastbalansera. Fast då kanske inte MySql bör vara ett förstahandsval.

[SkyNet]

Originally posted by grazzy@Nov 30 2004, 22:25
... (och då kan ni juh redan där ha någon slags round-robin för att sprida frågorna mellan olika select-servrar).

När jag en gång i tiden körde två mindre servrar så hade jag en liten snutt kod som uppdaterade belastningen för varje server i en tabell och sedan skickade användaren till den minst belastade servern...

[SkyNet]

Originally posted by eg0master@Dec 1 2004, 10:13
Jag håller med om att 500 samtidigt inloggade användare inte låter speciellt mycket. För de 500 lär ju knappast accessa databasen exakt samtidigt.

Frågan är ju bara hur man definierar antal samtidigt inloggade användare?

[David]

Originally posted by grazzy@Nov 30 2004, 22:25
och köra dom mot en server medans andra frågor går mot en annan server

Som sagt, det är ingen större idé att ha en master och många slavar eftersom varje sidanrop innebär ett antal av varje. Jag vill därför ha två eller fler masters som potentiellt har vardera en eller fler webservrar mot sig.

snabb titt på Sockerdricka så ser den inte så farligt tung ut heller

Det ser inte så tungt ut men all information på varje sida måste komma någonstansifrån och den kommer från databasen.

Innan jag viftade med lastbalanseringsplakatet skulle jag nog:
1) KOlla över att all DB access (select, insert, delete, update) är optimerad. Finns de rätta indexen etc.
2) Sedan handlar det om att kika på vad som görs. Låses tabeller när det inte behövs osv. Går det att göra de "slöa" sakerna på ett bättre sätt.

Tack, det är gjort för länge sedan.

Vad har du för hårdvara nu?

Db-servern är AMD Sempron 2600+ med 1,5GB RAM och 3 x 80 GB hårddiskar i RAID5.

Jag skulle mycket uppskatta hjälp med problemet jag har, dvs att replikera över flera masters men ändå använda auto_increment.

[Edvard]

Detta är ett välldigt intressant ämne men även komplicerat tyvär.
Är själv intresserad av replication men inte pga performance utan vill istället ha hög availability och det är ju inget direkt problem om man jämför med ditt. Har läst http://dev.mysql.com/doc/mysql/en/Replication_FAQ.html och har inte hittat något som svarar på din fråga men hittada detta.

MySQL replication is most beneficial for a system with frequent reads and infrequent writes. In theory, by using a single-master/multiple-slave setup, you can scale the system by adding more slaves until you either run out of network bandwidth, or your update load grows to the point that the master cannot handle it.

Det ser ju inte direkt bra ut för dig, dom skriver även om förhållandet mellan read/write så hur månge writes har du per read?