MySQL replication

[Mark]

Gebruiken jullie nu eigenlijk ook MySQL replication ? Zo ja, werkt het inmiddels beter als voorheen ?

[Onno]

http://www.tweakers.net/zooi.dsp?Action=Stats

Replication slave: Running

Doet de indruk wekken dat MySQL met replication draait.

[Mark]

Op woensdag 04 juli 2001 00:34 schreef Onno het volgende:
http://www.tweakers.net/zooi.dsp?Action=Stats
[..]

Doet de indruk wekken dat MySQL met replication draait.

Tjah, dat konden voorgaande Mysql versies ook (ongeveer 10 minuten lang )

[Wouter Tinus]

Het draait nu geloof ik vrij stabiel

[Femme]

Apollo doet sinds ongeveer 2 weken replication voor alle databases op Artemis excl. de fokforum database. Gotforum staat op Apollo en wordt nog niet gerepliceerd. Door een probleem met de search tabellen van Topix wil het nog niet lukken om replication voor het forum te doen (volgens mij heeft het iets te maken met temporary tables voor de search waar MySQL replication niet al te snugger mee om gaat). Er is volgens mij wel een workaroudn voor te verzinnen door die tabellen buiten de got/fokforum database te zetten zodat de tabellen die de problemen veroorzaken genegeerd door replication master genegeerd kunnen worden.

Replication blijkt tot nu toe best aardig te werken. Er zijn soms nog wel vat vage probleempjes waardoor de replication slave stopt. Soms zijn de problemen vrij simpel te fixen, in andere gevallen moet er een heel nieuw snapshot van de master database op de slave gezet worden. Het tarren van de database directories kost ongeveer 5-10 minuten en kan daardoor alleen s'nachts gedaan worden. Eén van de problemen die ik ben tegengekomen (de slave komt terecht op een niet bestaande positie in de binlog) is al onder de aandacht van de MySQL developers. Hopelijk komt er een fix in 3.23.40.

Zoals je in de stats ziet loopt replication nu al 6 dagen en 16 uur (uptime van de master) zonder grote problemen. Da's best wel ok. Replication is in ieder geval bruikbaar voor de t.net database en hopelijk binnenkort ook voor de forums. De meest praktische oplossing lijkt me twee MySQL daemons per sever, waarbij één daemon als slave fungeert van de master daemon op de andere server. In dat geval hoeven niet alle databases op een server down als een snapshot gemaakt of gekopieerd moet worden.

De tweakers.net database wordt momenteel in een verhouding van 70/30 geloadbalanced over Artemis en Apollo. In het geval van een connectie op Apollo wordt automatisch gecheckt of de slave nog een draaiende replictation heeft. Als Artemis down is worden alle pagina's die alleen select queries doen (of onbelangrijke inserts zoals de pricewatch stats) overgenomen door Apollo. Pagina's die schrijven in de database (met name de popups) mogen alleen connecten op Artemis. Voor de connecties op Apollo is er een aparte mysql user die alleen mag schrijven in de stats database op Apollo (ivm stats logging), maar geen rechten heeft voor inserts/updates op andere databases. Inserts en updates op Apollo (zoals de pricewatch stats) worden dus simpelweg genegeerd. Dit scheelt weer veel aanpassingen in scripts en is de simpelste manier om te voorkomen dat er per ongeluk toch inserts worden gedaan (één simpele onschuldige insert op de slave in een tabel met auto_increments kan de hele replication om zeep helpen).

[Verwijderd]

Op woensdag 04 juli 2001 01:10 schreef Femme het volgende:
Apollo doet sinds ongeveer 2 weken replication voor alle databases op Artemis excl. de fokforum database. Gotforum staat op Apollo en wordt nog niet gerepliceerd. Door een probleem met de search tabellen van Topix wil het nog niet lukken om replication voor het forum te doen (volgens mij heeft het iets te maken met temporary tables voor de search waar MySQL replication niet al te snugger mee om gaat). Er is volgens mij wel een workaroudn voor te verzinnen door die tabellen buiten de got/fokforum database te zetten zodat de tabellen die de problemen veroorzaken genegeerd door replication master genegeerd kunnen worden.

Replication blijkt tot nu toe best aardig te werken. Er zijn soms nog wel vat vage probleempjes waardoor de replication slave stopt. Soms zijn de problemen vrij simpel te fixen, in andere gevallen moet er een heel nieuw snapshot van de master database op de slave gezet worden. Het tarren van de database directories kost ongeveer 5-10 minuten en kan daardoor alleen s'nachts gedaan worden. Eén van de problemen die ik ben tegengekomen (de slave komt terecht op een niet bestaande positie in de binlog) is al onder de aandacht van de MySQL developers. Hopelijk komt er een fix in 3.23.40.

Zoals je in de stats ziet loopt replication nu al 6 dagen en 16 uur (uptime van de master) zonder grote problemen. Da's best wel ok. Replication is in ieder geval bruikbaar voor de t.net database en hopelijk binnenkort ook voor de forums. De meest praktische oplossing lijkt me twee MySQL daemons per sever, waarbij één daemon als slave fungeert van de master daemon op de andere server. In dat geval hoeven niet alle databases op een server down als een snapshot gemaakt of gekopieerd moet worden.

De tweakers.net database wordt momenteel in een verhouding van 70/30 geloadbalanced over Artemis en Apollo. In het geval van een connectie op Apollo wordt automatisch gecheckt of de slave nog een draaiende replictation heeft. Als Artemis down is worden alle pagina's die alleen select queries doen (of onbelangrijke inserts zoals de pricewatch stats) overgenomen door Apollo. Pagina's die schrijven in de database (met name de popups) mogen alleen connecten op Artemis. Voor de connecties op Apollo is er een aparte mysql user die alleen mag schrijven in de stats database op Apollo (ivm stats logging), maar geen rechten heeft voor inserts/updates op andere databases. Inserts en updates op Apollo (zoals de pricewatch stats) worden dus simpelweg genegeerd. Dit scheelt weer veel aanpassingen in scripts en is de simpelste manier om te voorkomen dat er per ongeluk toch inserts worden gedaan (één simpele onschuldige insert op de slave in een tabel met auto_increments kan de hele replication om zeep helpen).

Je haalt me de woorden uit de mond ! !!!

[Onno]

Op woensdag 04 juli 2001 01:10 schreef Femme een te lange lap tekst om te quoten

Voor replication beide kanten op is het dus nog niet echt geschikt? Dus als artemis down is heb je alsnog maar een half functionerende site?

[Femme]

Het kan in principe wel. Er zijn mensen die werkende circulaire replication hebben met 2 of nog meer servers, maar je kunt dan iig geen gebruik maken van auto increments.

Failsafe replication (dwz slave kan taak van master overnemen als master dood is) staat wel op de todo voor MySQL 4.0.x.

[raptorix]

Hoe waterdicht is eigenlijk die replication? Ik heb zelf geen ervaring met MySql maar ik kan me zo voorstellen dat er nogal eens wat mis kan gaan als je een db gebruikt die niet via transcactions werkt. Is het misschien niet verstandig om met een soort van queing mechanisme te werken?

[Femme]

De replicaton kan een keiharde kill van de MySQL daemon overleven zonder dat er duplicate entries of andere fouten ontstaan. Het is dus redelijke solide, ondanks het feit dat MyISAM tabellen geen transactions ondersteunen. Ik weet niet hoeverre het gebruik van InnoDB en BerkeleyDB tables (die wel transactions ondersteunen) gevolgen heeft voor de consistentie van de binlog waarin de veranderingen in de databases op de master worden gelogd.

[RvdH]

Op woensdag 04 juli 2001 01:10 schreef Femme het volgende:
Zoals je in de stats ziet loopt replication nu al 6 dagen en 16 uur (uptime van de master) zonder grote problemen. Da's best wel ok.

Je moet niet naar de master kijken, die hoeft alleen maar naar een bestandje te loggen wat er gebeurd. De slave moet dat spul echt lezen en inserten enzo, vandaar dat ie daar dan ook redelijk snel failed (met dubbele entries bv). En die is dus 4 uur 51 min up.

[Femme]

Als replication stuk gaat moet de master down om een nieuw snapshot te maken. De uptime van de master is dus ook de tijd dat de replication heel is gebleven.

Apollo is vannacht gerestart ivm wijzigingen in my.cnf.

[RvdH]

Op woensdag 04 juli 2001 21:10 schreef Femme het volgende:
Als replication stuk gaat moet de master down om een nieuw snapshot te maken.

Heerlijk he, MySQL

De uptime van de master is dus ook de tijd dat de replication heel is gebleven.
Apollo is vannacht gerestart ivm wijzigingen in my.cnf.

Achso.

[Femme]

Online een dump maken werkt nl niet goed. De server platleggen en alle data tarren werkt veel beter.

[Mark]

Hmmzz, lastig dat je geen autoincement meer kunt gebruiken hiermee.

Ook lastig dat als het fout gaat de master down moet voor een nieuw snapshot.

Ik denk dat ik dus nog maar een paar versies afwacht voordat ik het ga gebruiken op deze manier.

[Femme]

Hoe lastig het is hangt af van de grootte van de databases en de prioriteit van het maken van wijzigingen in de updates. De selects kunnen naar de slave gestuurd worden als de master down is. De gebruiker van je website of applicatie hoeft daar niets van te merken zolang-ie niet in de database moet schrijven. Een snapshot maken om 6 uur 's ochtends geeft dan nauwelijks overlast.

Het wordt anders als je een hele grote database van tientallen gigabytes moet tarren.

[Martin Sturm]

Op zich wel cool dit. Nu is het iig al niet meer mogelijk dat door een hd crash, alle t.net nieuwspostings weg zijn

[Verwijderd]

Op donderdag 05 juli 2001 12:39 schreef msturm10 het volgende:
Op zich wel cool dit. Nu is het iig al niet meer mogelijk dat door een hd crash, alle t.net nieuwspostings weg zijn

*kuch* dat kan ook door een goede raid config te gebruiken, maar idd; 't is een goede oplossing *kuch*

[Femme]

Kees doet wel goede RAID configuraties bouwen en backups maken.

[Mark]

Op vrijdag 06 juli 2001 00:09 schreef Femme het volgende:
Kees doet wel goede RAID configuraties bouwen en backups maken.

Backups maken is 1 ding, controlleren is een tweede

[Rense Klinkenberg]

Op vrijdag 06 juli 2001 01:48 schreef RedRoon het volgende:

[..]

Backups maken is 1 ding, controlleren is een tweede

*zuch* goh, ik lach me nogsteeds kapot hoor *zuch*