MySQL (4.1) clusteren

[Snow_King]

Beste Tweakers,

Ik weet dat hier al meerdere topics over zijn geweest.

Tot nu toe heb ik nog geen cluster mogelijkheid gevonden voor MySQL die voldoet aan mijn wensen en ik begin me ook wel af te vragen óf deze bestaat.

MySQL kent de volgende mogelijkheden:
- Replication (eigenlijk niet echt clustering te noemen)
- MaxDB met NBcluster (dit mist echter iets)

Wat wil ik?
Een MySQL cluster waarbij je geen rekening te houden hoeft met welk type tabellen je aanmaakt, kort door de bocht. Ik wil mijn MyReact forum kunnen installeren en deze zijn MyISAM en InnoDB tabellen laten aanmaken en dan moet dit gelijk gebeuren op meerdere servers.

Waarom replication niet?
Werkt met master-slave en op slave kan je alleen lezen, daar heb ik als hoster echter geen invloed op. Bij uitval van een node, is het lastig weer op gang te brengen.

Waarom geen NBcluster?
Hiermee moet je persé tabellen aanmaken met als type nbcluster, doe je dit niet, dan worden ze ook niet opgenomen in het cluster.

Dus als iemand dan zijn MyReact installeert maakt dit vrolijk MyISAM en InnoDB tabellen aan, maar in het cluster wordt niet opgenomen.

Nu zoek ik dus een manier om MySQL gewoon te laten functioneren op de manier waarop het gewoon functioneert, maar alle operaties (SELECT, INSERT, enz) moeten op alle servers uitgevoerd kunnen worden en direct met elkaar worden bijgewerkt.

Ik begin echter wel sterk te twijfelen óf het uberhaupt mogelijk is.

Ik wil niet alleen een fail-over opstelling, maar ook loadbalancing over meerdere SQL servers gaan opzetten.

Iemand ervaring hier mee?

[ Voor 7% gewijzigd door Snow_King op 02-12-2005 11:57 ]

[Verwijderd]

Je zou een cluster filesystem moeten proberen zoals ocfs (oracle filesystem) en dan op alle nodes mysql draaien met dezelfde datafiles.

[Snow_King]

Verwijderd schreef op vrijdag 02 december 2005 @ 22:18:
Je zou een cluster filesystem moeten proberen zoals ocfs (oracle filesystem) en dan op alle nodes mysql draaien met dezelfde datafiles.

Je krijgt dan geen problemen met tabellen die gelocked worden?

Of zou een AoE (Ata over Ethernet) hier volstaan (soort NAS dus)

Bij AoE denkt de server dat het een lokale disk is, de I/O loopt namelijk gewoon direct zonder tussenkomst van een extra laag.

[ Voor 25% gewijzigd door Snow_King op 02-12-2005 22:41 ]

[Hans]

Meerdere MySQL servers op dezelfde datafiles gaat echt resulteren in complete chaos en datacorruptie.

Helaas is het met MySQL nog niet echt betrouwbaar mogelijk om een master<->master replication setup te maken oid. Je kan wel iets vergelijkbaars bereiken door je read-only slave te instrueren om master te gaan spelen zodra je master down gaat. Ik kan de TS aanraden de MySQL replication FAQ eens door te nemen, en dan met name het kopje "How can I use replication to provide redundancy/high availability?". Zie http://dev.mysql.com/doc/refman/5.0/en/replication-faq.html

[ Voor 29% gewijzigd door Hans op 03-12-2005 20:31 ]

[Snow_King]

Ik wil meer loadbalancen dan alleen fail-over.

Ik heb nu al een Dual Core Dual Opteron machine in de running voor deze taak en die zal er ook eens problemen mee gaan krijgen.

Ik heb een cluster met 10 webservers die nu allemaal verbinding maken met de host "database"

In /etc/hosts heb ik die verwezen naar een IP-adres.

Nu wil ik op de eerste 5 servers het naar ip x laten verwijzen op op de andere 5 naar ip y.

Zo wil ik dus de load verdelen, echter moeten ze samen onderling syncen.

Ik was al bang dat MySQL hier geen goede betrouwbare oplossing voor bood.

[Hans]

Nee helaas nog niet echt. Je hebt zoals je zelf al aanhaalde wel mysql cluster sinds kort maar dat heeft ook de nodige beperkingen wat het totaal oninteressant maakt, bijvoorbeeld alleen al het feit dat het alleen RAM-based is.

Wij (Parse) zullen zelf ooit ook tegen een bepaald plafond aanlopen met MySQL voor onze React based sites en apps, maar met die dual opteron kan je wel even vooruit hoor We hebben zelf vier database servers waarvan eentje de databases verzocht voor een aantal grote en drukbezochte React-based sites, en die doet dat tot op heden met twee vingers in z'n neus (is ook een dual opteron machine btw, met 6GB mem en SCSI RAID-10)

[Snow_King]

Ik heb helaas niet al te veel invloed op de queries die op die bak op worden afgevuurd (hoster), dus daarom moet ik een oplossing gaan vinden om MySQL te clusteren.

[froggie]

Snow_King, ik heb hetzelfde probleem (zie ook mijn topic "Ervaringen advanced network filesystems" voor een situatie schets) als jij beschrijft maar helaas hebben wij nog geen (betaalbare) oplossing gevonden.
Ik vrees dat we zullen moeten wachten tot het MySQL devteam een betrouwbare master <-> master replicatie methode implementeerd voordat failover/loadbalancing goed te implementeren is.

[Renegade]

Froggie schreef op maandag 05 december 2005 @ 14:00:
Ik vrees dat we zullen moeten wachten tot het MySQL devteam een betrouwbare master <-> master replicatie methode implementeerd voordat failover/loadbalancing goed te implementeren is.

De DB is daar geloof ik zelfs het kleinere probleem. Ik weet niet over wat voor een datahoeveelheden je praat, maar hou rekening met toch nog redelijk wat overhead die je hebt door de data replicatie. Verder is fatsoenlijke clustering onder de verschillende linux distros imho zowiezo nog een groot probleem, vaak kom je dan aan de oplossingen als een Veritas cluster server of een EMC autostart. Op het moment zul je denk ik niet ontkomen aan het repliceren van je logs na een transactie en verder het monitoren van je dienst op de master server.

[Snow_King]

Wij hebben +/- 17GB aan data staan per SQL server en deze doen zo'n 700 a 800 queries per seconde.

Dan is het helaas wachten tot MySQL met een oplossing komt.

[jvhaarst]

Ik heb er geen ervaring mee, maar is m/cluster niet een optie ?
Van de site :

Continuent™ m/cluster is the leading middleware high availability and scalability solution for use with MySQL. m/cluster supports all the most popular MySQL storage engine types: MyISAM, InnoDB and memory (heap). m/cluster delivers the robustness that you can rely on to build mission-critical applications using the world’s leading open source database, MySQL.

The product provides high availability services by ensuring any number of MySQL database servers are fully in-synch at all times. Fast and automatic failover ensures that any server can transparently handle the queries from a failed or out-of-service node. Load balancing ensures performance scalability. New nodes can be added on-the-fly allowing you to add capacity without taking the system out of service.

m/cluster creates a single virtual database view of multiple MySQL databases and is designed to integrate seamlessly with your MySQL-based application.

The architecture of m/cluster is designed to use commodity hardware and does not require any special hardware devices like storage area networks or load balancers.

[The Eagle]

Mja, als ik dat zo lees wil je toch wel een behoorlijk snelle redundante verbinding tussen je DB servers..als je 800 queries per sec af moet vangen over een trage verbinding...dat wil je echt niet

[Paul]

Je zegt dat je hoster bent... Kun je dan niet gewoon klant a..m op server 1 en klant n..z op server 2 kwijt?

Klant X hoeft toch niet bij de data van klant I? Dus waarom zou de server waar klant X tegen praat perse de data van klant I moeten hebben?

[CrashOne]

Paul Nieuwkamp schreef op maandag 05 december 2005 @ 23:10:
Je zegt dat je hoster bent... Kun je dan niet gewoon klant a..m op server 1 en klant n..z op server 2 kwijt?

Klant X hoeft toch niet bij de data van klant I? Dus waarom zou de server waar klant X tegen praat perse de data van klant I moeten hebben?

Ik denk niet dat er bij (virtual hosting) 1 mySql server per klant is, dat zou het geheel erg kostbaar maken.

[Snow_King]

Paul Nieuwkamp schreef op maandag 05 december 2005 @ 23:10:
Je zegt dat je hoster bent... Kun je dan niet gewoon klant a..m op server 1 en klant n..z op server 2 kwijt?

Klant X hoeft toch niet bij de data van klant I? Dus waarom zou de server waar klant X tegen praat perse de data van klant I moeten hebben?

Klopt.

Wij bouwen echter clusters.

Op dit moment is iedere keer MySQL onze beperkende factor in de grootte van een cluster, hierdoor moeten we uitwijken naar nieuwe clusters.

We willen ook de MySQL gaan clusteren en zo op een gegeven moment een cluster maken van +/- 40 webservers, flink wat storage servers, aantal database servers.

De onderlinge link tussen de databaseservers is 1Gbit, ze hangen boven elkaar in het rack.

Glas is zelfs ook een optie.

Ik ga iig even de boven genoemde optie doornemen.

[Paul]

Hij heeft 10 webservers en 800 queries per seconde. Ik heb nergens beweerd dat hij 5.000 sql-servers neer moet zetten...

De webservers staan ook in cluster zie ik... Hoeveel werk is het om dat ene cluster van 10 servers om te bouwen naar 2 clusters van 5 servers? Allebei de helft van de users, allebei een eigen SQL-server, en de load op je sql-server halveerd.

Ik weet niet hoe klanten precies connecten naar je db-server (op ip, op hostname, via een door de hoster aangeboden include, echt totaal geen ervaring mee) maar je zou waarschijnlijk ook zonder je cluster te splitsen je klanten over meerdere sql-servers kunnen verdelen.

[Snow_King]

Dat snap ik ook volledig, echter zijn er bepaalde redenen waarom we het bij 1 cluster willen houden.

Dat doet dus verder ook niet ter zake aangaande mijn topicstart, de vraag blijft, hoe een goed MySQL cluster te bouwen?

Sowieso bedankt voor je meedenken

[Snow_King]

Ik heb geïnformeerd naar dat m/cluster, maar dat liegt er niet om.

3 Dual CPU nodes, kost $3500 per node, dus meer dan $10.000 voor een cluster van 3 MySQL servers.

[jvhaarst]

Heb je mysql zelf al je vraag voorgelegd ?
Toen ik de clustering whitepaper had aangevraagd kreeg ik vervolgens een net mailtje van MySQL met daarin de aanbieding voor consultancy en support op MySQL cluster.

[igmar]

Snow_King schreef op vrijdag 02 december 2005 @ 11:56:
Waarom geen NBcluster?
Hiermee moet je persé tabellen aanmaken met als type nbcluster, doe je dit niet, dan worden ze ook niet opgenomen in het cluster.

Dus als iemand dan zijn MyReact installeert maakt dit vrolijk MyISAM en InnoDB tabellen aan, maar in het cluster wordt niet opgenomen.

Nu zoek ik dus een manier om MySQL gewoon te laten functioneren op de manier waarop het gewoon functioneert, maar alle operaties (SELECT, INSERT, enz) moeten op alle servers uitgevoerd kunnen worden en direct met elkaar worden bijgewerkt.

Ik zie zelf 2 mogelijke oplossingen :

1) eens in de zoveel tijd kijken of alle tabellen het doen, en indien nodig converteren
2) Alle storage engines uitschakelen behalve nbcluster

Goed, je krijgt dan wel een dikke error als je een tabel fout aanmaakt, maar da's IMHO altijd beter dan niks doen...

[Snow_King]

jvhaarst schreef op donderdag 08 december 2005 @ 09:04:
Heb je mysql zelf al je vraag voorgelegd ?
Toen ik de clustering whitepaper had aangevraagd kreeg ik vervolgens een net mailtje van MySQL met daarin de aanbieding voor consultancy en support op MySQL cluster.

Dat ga ik even doen, tnx

[jvhaarst]

En heb je al antwoord ?

[Snow_King]

jvhaarst schreef op dinsdag 13 december 2005 @ 14:39:
En heb je al antwoord ?

Ik heb gebeld door MySQL, echter was ik er toen niet. Ze zouden me gisteren terug bellen, helaas niets gehoord.

[froggie]

Ik heb ook de betreffende whitepaper aangevraagd. Ben benieuwd of hier iets leuks uit komt. m/cluster lijkt een leuk product, maar is idd vanwege het kostenplaatje niet echt interessant meer. Beetje jammer dat er toch zo overdreven veel geld gevraagd wordt voor dit soort oplossingen.

[Hans]

Zoals ik al eerder zei is MySQL cluster een leuk begin van de mysql devvers, maar het heeft nog een huge nadeel, en dat is dat tablespace RAM-bound is. Dus als je een het hebt over 17 GB aan data en het geheel ook nog een beetje op de groei wil kopen zal je dus moeten beginnen met 5 dataservers met minstens 4GB RAM vrij voor mysql cluster. daarnaast heb je nog de servers nodig die daar voor komen te hangen, die de dataservers gaan querieen, plus een monitoring&management station. Zit je al aan iets van 9 a 10 flinke dozen. Loopt aardig in de centen dus.

[ Voor 25% gewijzigd door Hans op 14-12-2005 23:05 ]

[Aike]

Hans schreef op woensdag 14 december 2005 @ 23:04:
Zoals ik al eerder zei is MySQL cluster een leuk begin van de mysql devvers, maar het heeft nog een huge nadeel, en dat is dat tablespace RAM-bound is. Dus als je een het hebt over 17 GB aan data en het geheel ook nog een beetje op de groei wil kopen zal je dus moeten beginnen met 5 dataservers met minstens 4GB RAM vrij voor mysql cluster. daarnaast heb je nog de servers nodig die daar voor komen te hangen, die de dataservers gaan querieen, plus een monitoring&management station. Zit je al aan iets van 9 a 10 flinke dozen. Loopt aardig in de centen dus.

Mja, dat is allemaal te compenseren met geld. Lastiger is dat mysql-cluser in sommige gevallen, per query, trager is dan een standalone mysql server. Tenminste dat is mijn ervaring. Met een database van 200kb deden sommige select queries er meer dan 3 seconden over.

Die whitepaper stelt niet veel voor trouwens, gewoon info over wat alles is en doet.

[Snow_King]

Froggie schreef op woensdag 14 december 2005 @ 22:56:
Ik heb ook de betreffende whitepaper aangevraagd. Ben benieuwd of hier iets leuks uit komt. m/cluster lijkt een leuk product, maar is idd vanwege het kostenplaatje niet echt interessant meer. Beetje jammer dat er toch zo overdreven veel geld gevraagd wordt voor dit soort oplossingen.

Ik denk vanwege de kleine afzet

Hans, bedankt voor je info.

MySQL heeft alsnog niet terug gebeld.

[froggie]

Ik heb naar aanleiding van het aanvragen van een whitepaper een korte email conversatie met iemand van MySQL NL gehad. MySQL 5.1 gaat disk-based clustering ondersteunen:

Hallo Arjen,

Wat dacht je van disk-based clustering?
Versie 5.1 heeft de beperking niet meer dat de gehele database in memory
moet.

Biedt dat mogelijkheden?

Groet,
Gérard

-----Original Message-----
From: Arjen Roodselaar [mailto:[e-mail]]
Sent: 22 December 2005 11:01
To: Gérard Ringenaldus
Subject: Re: MySQL

>Beste Gérard,
>
>Wij zijn op dit moment een web(tomcat)/db cluster aan het bouwen voor een
>klant. Instresse in de cluster mogelijkheden van MySQL is er zeer zeker,
>helaas hebben we op dit moment al temaken met een totale grote van de db's
>van +- 3GB. De verwachting is dat deze hoeveelheid data na op gebruikname
>van het nieuwe platform flink gaat groeien. In memory db tabellen wordt dus op
>een gegeven moment een dure aangelegenheid.
>Helaas levert MySQL (bij mijn weten) geen andere cluster mogelijkheden biedt
>zullen we waarschijnlijk genoodzaakt zijn om het bij replicatie en hot
>standby te houden.
>We hebben reeds gekeken naar m/cluster, maar dit product is vanwege de prijs
>per node nog niet interessant.
>Mochten er toch andere mogelijkheden zijn om onze setup robuster en
>schaalbaarder te maken dan hoor ik dit graag.
>
>Mvg,
>Arjen Roodselaar

>On Wednesday 21 December 2005 23:48, you wrote:
>> Hallo Arjen,
>>
>> MySQL is recentelijk gestart met een vestiging in Nederland om zo onze
>> klanten, partners en belangstellenden optimaal te helpen.
>> In het overzicht van Nederlandse bezoekers aan onze website, zag ik dat
>> jij interesse had in MySQL Cluster: is die interesse er nog?
>>
>> Met vriendelijke groet,
>>
>> MySQL Benelux

@ Snow_King: leuk blog! Ik twijfel nog steeds of ik niet toch nog een keer de keuring voor officier zal doorlopen.

[Snow_King]

Ik heb de zelfde mail van Gérard gehad, ben op dit moment ook met hem aan het mailen.


OT: Tnx, ik heb een leuke tijd daar gehad. Officier is pittig, reken daar wel op.