high availability mysql clustering via mysql replication

[FunzoneQ!]

Ik ben bezig met het ontwerpen van een applicatie dat het single point of failure van MySQL weg gaat halen uit een mysql replication setup.

Nou zullen jullie misschien denken: Maar er is toch mysql cluster? Ja daar heb je helemaal gelijk in, maar mysql cluster heeft een groot nadeel, waardoor het ongeschikt is voor de case die ik heb opgesteld. MySQL cluster heeft namelijk als verplichting dat alle databases en indexes in het geheugen geladen moeten worden. Dat gaat via de volgende formule:
(Size of database * NumberofReplicas * 1.1) / Number of storage nodes

Dat is nog niet zo'n groot probleem wanneer je één database van één gigabyte hebt. Wanneer je echter meer dan 300 databases van in het totaal 50 gigabyte hebt, heb je een groot probleem: De hardware kan nog niet zoveel geheugen aan en het kost klauwen met geld.

Het idee is om een Query Director te maken: een loadbalancer voor mysql. De huidige setup van MySQL is altijd een tier 2 setup: applicatie -> database. Ik ben van plan om hier een tier 3 setup van te maken, namelijk: applicatie -> query director -> database. Dit heeft een aantal voordelen:
- Je kan ' mysql clustering ' toepassen zonder je applicatie aan te passen. (belangerijk voor webhosting)
- De query balancer zorgt voor High Availability.

Het is dus de bedoeling dat de klant naar de query director connect in plaats van naar de database. De query director splitst dan de SELECT-queries van de write-queries (UPDATE, INSERT, DELETE). De select queries worden naar de MySQL replication slaves gestuurd en de write queries naar de master. Alle results worden dan via de query director weer terug naar de klant gebracht. Op deze manier kan je mysql replication toepassen zonder dat de gebruiker er ook maar iets van merkt, of zijn applicatie hoeft aan te passen.

Ik heb een document uitgewerkt waar in detail het probleem word beschreven. Dat kan je vinden op: http://funzoneq.livejournal.com/19503.html. Hier staan ook plaatjes bij om de situaties te verduidelijken.

Ik zou graag van jullie feedback ontvangen over de technische aspecten van zo'n applicatie. Mis ik iets? Zien jullie iets in z'n applicatie? Hoe kan je dit het beste aanpakken?

(ps. Dit topic past ook heel goed in professional networking & servers en programming, dus ik was niet helemaal zeker waar ik het moest plaatsen.)

[Boss]

Op zich is je oplossing niet specifiek voor MySQL maar zou je er iedere database achter kunnen hangen, dus ik zou het iets breder opzetten.

Kan je dan ipv master/salve databases niet gewoon losse databases maken en de update/insert/delete queries daar direct op afvuren? Ik denk dat je oplossing ook wel rekening zou moeten houden met de verhouding select/overige queries.

Op zich een interessante case, maar ik denk dat als je het over high availability en 300 databases hebt dat MySQL misschien niet meer de oplossing is en je iets meer naar de professionele databases en hardware moet gaan. Maargoed, daarom is het een case en geen praktijksituatie neem ik aan?

[Alarmnummer]

FunzoneQ! schreef op donderdag 03 augustus 2006 @ 16:39:
Ik ben bezig met het ontwerpen van een applicatie dat het single point of failure van MySQL weg gaat halen uit een mysql replication setup.

Woehoe... mysql en zijn halfvolwassen cluster oplossingen.

Nou zullen jullie misschien denken: Maar er is toch mysql cluster? Ja daar heb je helemaal gelijk in, maar mysql cluster heeft een groot nadeel, waardoor het ongeschikt is voor de case die ik heb opgesteld. MySQL cluster heeft namelijk als verplichting dat alle databases en indexes in het geheugen geladen moeten worden.

En als extraatje: referentiele integriteit wordt ook niet ondersteund.

Het is dus de bedoeling dat de klant naar de query director connect in plaats van naar de database. De query director splitst dan de SELECT-queries van de write-queries (UPDATE, INSERT, DELETE).

En wat nu als je keuze om een insert of update te doen afhangt van die select...

Je wilt dat replicatie synchroon plaats vind (het moet niet uitmaken welke db je aanspreekt). Verder wil je ook gebruik maken van allerlei locking meuk (eventueel 'isolation' meuk door je isolation level). Daar ga je hier ook dikke issues mee krijgen. Je kunt dus niet zo maar verschillende calls die horen bij een enkele transactie over meerdere machines gaan verdelen.

Mijn mening over mysql is dat het nog een redelijke hobbybob oplossing is. Leuk als gegevens niet extreem belangrijk is, als het niet uitmaakt als een keer eens een db naar zijn grootje gaat. Maar als je echt wilt schalen, met een echt serieuze en krachtige db dan is imho oracle rac de enige oplossing. Maarja.. daar betaal je dan ook een vette smak geld voor (in ieder geval ca 30.000 per cpu en alle meuk die er nog eens bij komt)

PS:
kijk een naar sequoia.

[ Voor 3% gewijzigd door Alarmnummer op 03-08-2006 20:20 ]

[Verwijderd]

Op zich een erg interessante oplossing. Maar het feit dat je 'doet alsof' alle slave databases altijd gesynchroniseerd zijn met de master database is denk ik het grootste probleem: mijn ervaring is dat 't al lastig is om 1 master en 9 slaves niet meer dan een paar minuten van elkaar af te laten wijken (niet met MySQL replication, maar met een eigen replication engine voor MSSQL, en 2-way replication, en de slaves zijn vaak via ADSL/SDSL/cable gekoppeld met de master).
't Kan wel, maar dan is die replication engine zo druk dat de normale queries daar merkbaar onder lijden.

Maar voor bepaalde types databases/toepassingen kan dit erg goed werken, zoals bv. bij het online boeken van hotelkamers, vliegtuigstoelen of huurauto's.
Online boeken van hotelkamers (via een website als expedia.com of via een reisagent) hebben een 'look to book' verhouding van ruim 1000 op 1. Dus dik 1000 SELECT sessies tegenover 1 INSERT/UPDATE sessie. En die 'look' sessies genereren ook nog 's een veelvoud aan queries dan een 'book' sessie: even kijken of een ander hotel wel beschikbaarheid heeft, even kijken wat de amenities (zwembad, golfbaan in de buurt, dat soort dingen) van dat hotel zijn, etc.

In zo'n geval is 't geen ramp wanneer de slave databases 10 minuten achterlopen, of wanneer bij het plaatsen van de reservering blijkt dat die laatste 2 kamers (volgens de slave database) niet meer beschikbaar blijken te zijn.

Wanneer je in MySQL Replication aan kunt geven welke slaves prioriteit hebben, of per slave hoe vaak gerepliceerd moet worden, is 't misschien een idee om de Query Director niet alleen op read/write te laten kiezen, maar ook op de (main) tabel waarop ge-SELECT wordt. Je 'high priority' slaves voor SELECTs op tabellen die vaak veranderen, en 'low priority' slaves voor tabellen die redelijk constant blijven. Hoe vaak per dag heeft een hotel plotseling wel of geen zwembad, of ligt de golfbaan opeens 10 miles verderop?

Maar dan moet je Query Director niet alleen checken of 'SELECT' voorkomt in de query, maar ook of er in dat geval 'high priority' tabelnamen aanwezig zijn...

[ Voor 10% gewijzigd door Verwijderd op 03-08-2006 22:19 ]

[justmental]

Volgens mij haal je je meer problemen op je hals dan je oplost.
Die DRDB oplossing of iets dergelijks lijkt me nog het beste voor deze situatie.
Je verdeelt je databases over je machines laat ze elkaars backup zijn. Dus machine 1 bedient klant a,b,c,d (+ backup e,f,g,h) en 2 bedient e,f,g,h (+backup a,b,c,d), 3: i,j,k,l (+backup m,n,o,p) etc etc. Zodra er dan eentje uitvalt zijn er een paar klanten die tijdelijk verminderde capaciteit beschikbaar hebben, maar je verspilt dan in de normale situatie iig geen resources.

[kasper_vk]

FunzoneQ! schreef op donderdag 03 augustus 2006 @ 16:39:
[...]
Het idee is om een Query Director te maken: een loadbalancer voor mysql. De huidige setup van MySQL is altijd een tier 2 setup: applicatie -> database. Ik ben van plan om hier een tier 3 setup van te maken, namelijk: applicatie -> query director -> database. Dit heeft een aantal voordelen:
- Je kan ' mysql clustering ' toepassen zonder je applicatie aan te passen. (belangerijk voor webhosting)
- De query balancer zorgt voor High Availability.
[...]

Voor welk platform ga je dit ontwikkelen?

Als het over Java gaat, wil je even wijzen op het bestaan van C-JDBC: Clustered JDBC. Het is DBMS onafhankelijk (zolang er maar een jdbc-driver voor is natuurlijk) en volgens mij doet het in grote lijnen hetzelfde als wat jij wil maken.

[ontmoedig-mode]
Ongeacht wat het platform is/word, vraag ik me af of hier geen bestaande oplossingen voor zijn, maar vooral: of je de hoeveelheid ontwikkeltijd & de complexiteit van zo'n project niet onderschat.
Als je naar een niveau wil waarin je consistentie wilt kunnen waarborgen (goed met concurrency omgaan), zitten er ongetwijfelt veel complexe haken & ogen aan. Als je naar een niveau wilt waarin je zelfs recovery netjes geregeld wil hebben, word 't er zeker niet eenvoudiger op. Check anders de eerst paar hoofdstukken van dit spul eens en houdt daarbij jouw gedistribueerde database in het achterhoofd.
Kortom: als je aan een oplossing denkt die je voor bedrijfskritische toepassingen wil kunnen inzetten zonder ernstig nat te gaan wanneer de nood een keer hoog is, dan zou ik me nog eens zwaar verdiepen in de materie en serieus afvragen of je dit echt wilt (& kunt).
[/ontmoedig-mode]

Natuurlijk niet serieus bedoeld om je te ontmoedigen , maar wel om je er nog eens heel goed in te laten verdiepen voor je veel uren in zo'n (met alle respect) low-level project gaat stoppen.
De keerzijde: je bent natuurlijk wel helemaal 't mannetje als je dit wél goed voor elkaar krijgt

[ Voor 4% gewijzigd door kasper_vk op 04-08-2006 09:44 . Reden: Referentie naar Bernstein over concurrency & recovery toegevoegd. ]

[FunzoneQ!]

Alarmnummer schreef op donderdag 03 augustus 2006 @ 20:19:
[...]

En wat nu als je keuze om een insert of update te doen afhangt van die select...

Dan is het dus een WRITE-query en gaat hij dus naar de MASTER. Die kan namelijk ook selects uitvoeren, dus een subquery is geen probleem.

Op zich een erg interessante oplossing. Maar het feit dat je 'doet alsof' alle slave databases altijd gesynchroniseerd zijn met de master database is denk ik het grootste probleem: mijn ervaring is dat 't al lastig is om 1 master en 9 slaves niet meer dan een paar minuten van elkaar af te laten wijken (niet met MySQL replication, maar met een eigen replication engine voor MSSQL, en 2-way replication, en de slaves zijn vaak via ADSL/SDSL/cable gekoppeld met de master).
't Kan wel, maar dan is die replication engine zo druk dat de normale queries daar merkbaar onder lijden.

Er zijn een paar verschillen: MySQL Replication in mijn setup is maar 1-way replication en MySQL replication is daar vrij snel in. >10 seconde delays komen niet voor, tenzei je te weinig capaciteit hebt. Mijn servers staan in het datacenter verbonden via gbit verbindingen, met hele kleine hops, dus netwerk is waarschijnlijk bij jou het probleem. (of MSSQL-replication?)
Wanneer de slaves meer dan 20 seconde achterlopen worden ze tijdelijk uit de slave pool gehaald, zodat ze kunnen ' bijschrijven '. Weer up to date, worden ze terug gezet in de pool. Gebeurt het te vaak dat ze er uit worden gegooid kunnen er 2 dingen aan de hand zijn: Je hebt te weinig slave capaciteit: plaats meer slaves. Of je hebt te veel writes: Begin een nieuw cluster of upgrade je hardware.

Ongeacht wat het platform is/word, vraag ik me af of hier geen bestaande oplossingen voor zijn, maar vooral: of je de hoeveelheid ontwikkeltijd & de complexiteit van zo'n project niet onderschat.
Als je naar een niveau wil waarin je consistentie wilt kunnen waarborgen (goed met concurrency omgaan), zitten er ongetwijfelt veel complexe haken & ogen aan. Als je naar een niveau wilt waarin je zelfs recovery netjes geregeld wil hebben, word 't er zeker niet eenvoudiger op.

Replicatie naar de slaves worden automatisch gedaan door MySQL. Ik hoef dus echt alleen maar queries te checken en te redirecten. Dus de complexiteit valt best mee, omdat je gebruik maakt van bestaande techniek.

[Alarmnummer]

FunzoneQ! schreef op vrijdag 04 augustus 2006 @ 12:52:
Dan is het dus een WRITE-query en gaat hij dus naar de MASTER. Die kan namelijk ook selects uitvoeren, dus een subquery is geen probleem.

Je snapt het neit. Als jij de load gaat verdelen op basis van reads en writes, en je replicatie is niet synchroon (dus een alle nodes zijn nog niet up te date), dan zou je een beslissing kunnen nemen op basis van een eigenschap die al niet meer geld.

Eigen clusteroplossing opzetten moet je niet doen omdat je niet weet waar je aan begint. Er zijn al genoeg projecten gaande, en die zijn in mijn ogen allemaal nog behelpen. Zie Sequoia (cjdbc is trouwens gerelateerd aan sequoia).

Replicatie naar de slaves worden automatisch gedaan door MySQL. Ik hoef dus echt alleen maar queries te checken en te redirecten. Dus de complexiteit valt best mee, omdat je gebruik maakt van bestaande techniek.

uhhh.... mysql is imho niet geschikt voor critical data, bv voor betalingen. Doordat je geen enkele garantie met replicatie krijgt, kan het voorkomen dat een client in de veronderstelling is dat een transactie is afgerond, maar voordat de wijzigingen naar een slave zijn gecopieerd gaat de oude db op zijn gat. Het gevolg is dat je ACID nu een D mist. (als je niet weet wat ik bedoel, dan moet je zeker niet gaan beginnen aan hetgeen jij wilt doen).

[Gomez12]

FunzoneQ! schreef op vrijdag 04 augustus 2006 @ 12:52:
[...]


Dan is het dus een WRITE-query en gaat hij dus naar de MASTER. Die kan namelijk ook selects uitvoeren, dus een subquery is geen probleem.

Er zijn meer dingen dan subquery's hoor. Sommige dingen moeten echt in de bussiness layer dbaafgehandeld worden. En hier kan dan best een verschil tussen update en write ontstaan door een veel eerder uitgevoerde select...

Heel simpel gezegd, je komt in de knoei met ingewikkeldere apps.

Ik zie niet op wie je het richt, want qua implementatie lijk je het te richten op simpele dbases, maar deze hebben bijna nooit meerdere dbases nodig.
Wil je het richten op complexe apps, dan moet je ook gewoon alles kunnen aanbieden alsof er 1 server staat ( dus niet met 10 sec vertraging, dit is in een bussiness app onaanvaardbaard ) ipv dat als ik 300 selects afstuur op de query director in 1 sec dat ik dan meerdere antwoorden kan krijgen afhankelijk van de replicatie status... ( even van jouw situatie uitgaan van 300 dbases )

Op zich is het een leuk idee, maar ik vraag me af wanneer het nodig is zonder dat je er de nadelen van ondervind.

Btw je beseft wel dat met jouw plan je nog steeds niet bussiness verantwoord een dbase-structuur met 300 dbases kunt bouwen ( want wat als je query director uitvalt, wat als je master server uitvalt )

[MrBarBarian]

FunzoneQ! schreef op donderdag 03 augustus 2006 @ 16:39:
Dat is nog niet zo'n groot probleem wanneer je één database van één gigabyte hebt. Wanneer je echter meer dan 300 databases van in het totaal 50 gigabyte hebt, heb je een groot probleem: De hardware kan nog niet zoveel geheugen aan en het kost klauwen met geld.

Dat valt wel mee... Er is meer dan genoeg hardware te vinden die dit geen enkel probleem vind.. kost wat, maar ik schat dat jouw oplossing ook niet kosteloos zal zijn...

Maar waarom cluster je op database niveau en niet op OS niveau?

[FunzoneQ!]

Alarmnummer schreef op vrijdag 04 augustus 2006 @ 18:53:
[...]

Je snapt het neit. Als jij de load gaat verdelen op basis van reads en writes, en je replicatie is niet synchroon (dus een alle nodes zijn nog niet up te date), dan zou je een beslissing kunnen nemen op basis van een eigenschap die al niet meer geld.

Eigen clusteroplossing opzetten moet je niet doen omdat je niet weet waar je aan begint. Er zijn al genoeg projecten gaande, en die zijn in mijn ogen allemaal nog behelpen. Zie Sequoia (cjdbc is trouwens gerelateerd aan sequoia).

Je moet single direction en multiple direction synchronisation niet door elkaar halen. Ik gebruik alleen maar SINGLE direction synchonisation. De master is dus _altijd_ synchroon. Alleen de slaves kunnen een x seconden achterlopen, maar dat is hoogst uitzonderlijk.

Als jij een SELECT max(id) FROM tabel; doet, is je applicatie ontwerp zoiezo al verkeerd, omdat je het ID door de database af moet laten handelen en daarna moet opvragen (mysql_insert_id()).

Alarmnummer schreef op vrijdag 04 augustus 2006 @ 18:53:
uhhh.... mysql is imho niet geschikt voor critical data, bv voor betalingen. Doordat je geen enkele garantie met replicatie krijgt, kan het voorkomen dat een client in de veronderstelling is dat een transactie is afgerond, maar voordat de wijzigingen naar een slave zijn gecopieerd gaat de oude db op zijn gat. Het gevolg is dat je ACID nu een D mist. (als je niet weet wat ik bedoel, dan moet je zeker niet gaan beginnen aan hetgeen jij wilt doen).

Overigens weet ik wel waar ik aan begin. Ik werk al jaren met MySQL replication en ik wil dat nu toepassen op een low-end-aimed webhosting cluster. Probleem is dat ik niet wil dat de gebruikers merken dat ze een mysql replication environment gebruiken. Dat wil ik omdat ik niet alle applicaties wil aanpassen om rekening te houden met mysql replication. Dat heb ik ook uitgelegd in mijn artikel (zie OP). Sequoia ziet er uit alsof het aan mijn vereisten voldoet. Bedankt voor de tip.

[FunzoneQ!]

MrBarBarian schreef op vrijdag 04 augustus 2006 @ 19:29:
[...]

Dat valt wel mee... Er is meer dan genoeg hardware te vinden die dit geen enkel probleem vind.. kost wat, maar ik schat dat jouw oplossing ook niet kosteloos zal zijn...

Maar waarom cluster je op database niveau en niet op OS niveau?

Het gaat om clustered webhosting. MySQL is een vereistte anders werken de scripts niet meer. De eerste clustered solutions beginnen rond de 30.000 euro. Het door mij zelf ontwikkelen van software kost absoluut minder.

Clusteren op OS niveau lukt niet omdat je in de problemen komt met de write locks van mysql.

[FunzoneQ!]

Gomez12 schreef op vrijdag 04 augustus 2006 @ 19:23:

Btw je beseft wel dat met jouw plan je nog steeds niet bussiness verantwoord een dbase-structuur met 300 dbases kunt bouwen ( want wat als je query director uitvalt, wat als je master server uitvalt )

Als je het artikel in de OP had gelezen, had je kunnen zien dat de query director redundant is uitgevoerd. Verder negotiate de query director automatisch een nieuwe master, of gaat over op read-only databases.

[MrBarBarian]

FunzoneQ! schreef op vrijdag 04 augustus 2006 @ 20:19:
Clusteren op OS niveau lukt niet omdat je in de problemen komt met de write locks van mysql.

In je openingpost heb je het over high-availebility... Dus het altijd aanwezig zijn van de database (en dus geen performance clustering).. volgens mij zijn writelocks dan geen issue, aangezien de database toch maar op een van de nodes draait.

Mocht performance wel een issue zijn dan is het misschien verstandig om een te kijken of je niet je databases kan verspreiden over meerdere machines (lijkt me nl stug dat alle databases afhankelijk van elkaar zijn).

[Alarmnummer]

FunzoneQ! schreef op vrijdag 04 augustus 2006 @ 20:17:
[...]


Je moet single direction en multiple direction synchronisation niet door elkaar halen. Ik gebruik alleen maar SINGLE direction synchonisation. De master is dus _altijd_ synchroon. Alleen de slaves kunnen een x seconden achterlopen, maar dat is hoogst uitzonderlijk.

En daar zit het probleem. Als de master eruit knalt en niet alle transacties zijn naar de slaves gerepliceerd (die garantie krijg je dus niet) dan loop je de kans dat er data verloren gaat. Dat is het grote probleem met mysql replicatie (en iedere andere vorm van asynchrone replicatie). Daarom is het ook totaal ongeschikt voor business critical data (imho).

Als jij een SELECT max(id) FROM tabel; doet, is je applicatie ontwerp zoiezo al verkeerd, omdat je het ID door de database af moet laten handelen en daarna moet opvragen (mysql_insert_id()).

Wat heeft dat er mee te maken??

Overigens weet ik wel waar ik aan begin. Ik werk al jaren met MySQL replication en ik wil dat nu toepassen op een low-end-aimed webhosting cluster. Probleem is dat ik niet wil dat de gebruikers merken dat ze een mysql replication environment gebruiken.

Als jij al jaren met mysql werkt, dan had je moeten weten dat je replicatie volledig transparant kan toevoegen.

[FunzoneQ!]

Alarmnummer schreef op zaterdag 05 augustus 2006 @ 07:35:
En daar zit het probleem. Als de master eruit knalt en niet alle transacties zijn naar de slaves gerepliceerd (die garantie krijg je dus niet) dan loop je de kans dat er data verloren gaat. Dat is het grote probleem met mysql replicatie (en iedere andere vorm van asynchrone replicatie). Daarom is het ook totaal ongeschikt voor business critical data (imho).

Daar heb je helemaal gelijk in, echter heb ik geen business critical data. Het gaat om clustered webhosting. Wanneer de master plat gaat, gaat de database op read-only, totdat wij de master hebben gereanimeerd.

Alarmnummer schreef op zaterdag 05 augustus 2006 @ 07:35:
Als jij al jaren met mysql werkt, dan had je moeten weten dat je replicatie volledig transparant kan toevoegen.

Dat is dus niet zo. Met transpirant bedoel ik: zonder ook maar iets aan je applicatie te hoeven veranderen. Dat kan niet zonder een extra tussenlaag die de selects balanced, want je applicatie connect alleen maar standaard naar 1 mysql-server: de master. En de applicatie is niet ontwikkeld om om te kunnen gaan met replication slaves. Dus niet transpirant zonder extra tussenlaag.

Nog bedankt voor de referentie naar Sequoia, dat is de open-source backend achter m/cluster, dat 30.000 euro kost om op te (laten) zetten

[Verwijderd]

Alarmnummer schreef op vrijdag 04 augustus 2006 @ 18:53:
Het gevolg is dat je ACID nu een D mist. (als je niet weet wat ik bedoel, dan moet je zeker niet gaan beginnen aan hetgeen jij wilt doen).

Mag ik dat een tikkie arrogant noemen? Je hoeft echt niet te weten wat ACID is (Atomicity, Consistency, Isolation, Durability) om op een goede manier met databases om te gaan.
De beste vertaling voor ACID is denk ik "gezond verstand".

[Alarmnummer]

Verwijderd schreef op zondag 06 augustus 2006 @ 22:38:
[...]
Mag ik dat een tikkie arrogant noemen?

Nee. Iemand die dit wil doen, moet zeker weten wat ACID is. En verder staat het ook uitvoerig op het internet beschreven (en uiteraard in alle zichzelf respecterende db boeken, ook mysql met innodb).

Je hoeft echt niet te weten wat ACID is (Atomicity, Consistency, Isolation, Durability) om op een goede manier met databases om te gaan.

Iemand die het niet weet, die hoort imho niet op professioneel niveau met databases bezig te zijn.

Iemand die clusterfunctionaliteit wil maken en die het niet weet, die weet absoluut niet waar hij mee bezig is.

De beste vertaling voor ACID is denk ik "gezond verstand".

ACID beheersen noem ik gezond verstand. A is meestal vrij eenvoudig, kwestie van je transacties om de goeie punten zetten. D is meestal niet jouw verantwoordelijkheid als developer. C tja.. dat gaat meestal ook goed. I... niemand kijkt naar I.. I is het ondergeschoven kindje in ACID. Zorgen dat je data goed isolated is, zorgt ervoor dat je minder race problemen krijgt zoals:
dirty reads, unrepeatable reads, phantom reads en lost updates.

Gezond verstand alleen is niet voldoende omdat er te veel adders on het gras zijn. (Zelfs nog veel db specifieke adders ivm isolation).

[ Voor 24% gewijzigd door Alarmnummer op 07-08-2006 12:56 ]

[Alarmnummer]

FunzoneQ! schreef op zaterdag 05 augustus 2006 @ 23:29:
Dat is dus niet zo. Met transpirant bedoel ik: zonder ook maar iets aan je applicatie te hoeven veranderen. Dat kan niet zonder een extra tussenlaag die de selects balanced, want je applicatie connect alleen maar standaard naar 1 mysql-server: de master.

Via Sequoia kan dit dus via de 'dbdriver' Afgezien van 1 configuratie issue kan je het transparant toevoegen. Verder kun je replicatie ook transparant toevoegen, maar je failover is minder transparant.

[Yo-han]

Al eens gekeken naar m/Cluster van continuent? Heb hier in het verleden eens een maand mee getest en moet zeggen dat het op alle gewenste vlakken van clustering hoog scoorde. Was volgens mij ook niet al te duur.
Replicatie vind bijna tot helemaal realtime plaats en de high availability is zeker 99,999%. Verder doet hij ook loadbalancing en quick failover.

[Verwijderd]

Alarmnummer schreef op maandag 07 augustus 2006 @ 12:29:
Iemand die het niet weet, die hoort imho niet op professioneel niveau met databases bezig te zijn.

Dat was een reactie op mijn opmerking:

Je hoeft echt niet te weten wat ACID is (Atomicity, Consistency, Isolation, Durability) om op een goede manier met databases om te gaan.

Dan heb ik niet duidelijk genoeg gezegd wat ik bedoelde. De term ACID hoef je niet te kennen om goed met databases om te gaan. Die term bestaat "pas" 14 jaar, is denk ik pas een jaar of 7 (ruwe schatting) gemeengoed.
De principes van ACID bestaan al vanaf het moment dat multi-user databases en replication bestaan. OK, Isolation is altijd al een ondergeschoven kindje geweest, en werd/wordt vaak ad-hoc aangepakt wanneer je met lastige race conditions te maken kreeg. En wanneer je 1 keer een te ruim opgezette transactie hebt gebruikt die uiteindelijk bleef hangen en na 8 uur een rollback deed met als gevolg dat een klant de mutaties van een hele dag kwijt was, ga je er ook wel voor zorgen dat je transacties zo Atomic mogelijk zijn...

"Gezond verstand" dus, aangevuld met en gevoed door ervaring. Ik werk al dik 20 jaar professioneel met databases, en 5 jaar geleden kende ik de term ACID nog niet.

Iemand die clusterfunctionaliteit wil maken en die het niet weet, die weet absoluut niet waar hij mee bezig is.

Zie hierboven.

[Alarmnummer]

dayoman schreef op dinsdag 08 augustus 2006 @ 14:02:
Al eens gekeken naar m/Cluster van continuent? Heb hier in het verleden eens een maand mee getest en moet zeggen dat het op alle gewenste vlakken van clustering hoog scoorde. Was volgens mij ook niet al te duur.
Replicatie vind bijna tot helemaal realtime plaats en de high availability is zeker 99,999%. Verder doet hij ook loadbalancing en quick failover.

Seqoia, mcluster, cjdbc.. allemaal dezelfde club.

[Verwijderd]

Alarmnummer schreef op dinsdag 08 augustus 2006 @ 22:13:
[...]

Seqoia, mcluster, cjdbc.. allemaal dezelfde club.

Inderdaad, eigenlijk is Sequoia gewoon de naamsverandering van CJDBC. Die naam mocht niet verder gebruikt worden vanwege copyrights die sun op JDBC heeft. Beetje flauw. Wel raar dat ze die oude site laten staan en doen alsof het een nieuw project is gebasseerd op CJDBC.

Anyway, ook ik wil de TS niet ontmoedigen (denk je eens in wat er gebeurd was als men Linus destijds had ontmoedigd omdat een OS schrijven minimaal een jaar of 20 zou gaan duren), maar Sequoia is dus ook al lang bezig. Hier zitten meer mensen aan en deze zijn ook zeker niet de domste personen.

Toch is Sequoia nog steeds niet perfect. Wij doen ongeveer elke drie kwart jaar een test of het 'al werkt', en tot op heden blijven er telkens kleine dingetjes die toch weer fout gaan.

Zo makkelijk is het dus inderdaad niet...