Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door Femme Taken

Architect

MySQL replication bevindingen

12-07-2001 • 08:54

39 Linkedin Google+

Trouwe .plan freaks zullen gemerkt hebben dat er al enkele weken geen .plannetjes zijn geweest omtrent ons server park. Vaak betekent geen nieuws goed nieuws, zo ook in dit geval. Sinds de laatste werkzaamheden aan het serverpark zijn er namelijk nauwelijks meer problemen geweest, waardoor er weinig nieuws was te melden. Toch zijn er wat ontwikkelingen gaande waarover ik jullie wil informeren en die met name interessant zijn voor de tweakers die zelf gebruik maken van MySQL als database server.

* MySQL replication

MySQL beschikt sinds versie 3.23.15 over ondersteuning voor one-way replication. Replication maakt het mogelijk om databases realtime te synchroniseren over een cluster van database servers. In het geval van one-way replication moeten alle updates naar ťťn master server gestuurd worden, waarna de wijzigingen door de master worden doorgegeven aan de slave servers. MySQL ondersteunt meerdere slaves per master in een ster-topologie, maar er zijn ook mensen die er in zijn geslaagd om slave servers te daisy-chainen (slave is master van een andere slave) en circulaire replication (elke server in de ring is zowel slave als master) aan de praat te krijgen. Dit laatste werkt alleen als er geen inserts worden gedaan op tabellen met auto-increment kolommen. MySQL kent namelijk geen logica die het verstrekken van auto-increments op meerdere masters regelt.

Replication ken enerzijds gebruikt worden om de redundancy te verbeteren en anderzijds om de load te verdelen over meerdere servers. In het geval van one-way replication wordt de bottle-neck bepaald door de snelheid waarmee de master de updates en inserts kan verwerken en de slaves de master kunnen bijhouden. Bij het bekende scenario van een website zal het aantal wijzigingen in de database relatief laag zijn, zodat de bottleneck vooral wordt bepaald door de snelheid waarmee de selects verwerkt kunnen worden door de database servers. Een derde handige toepassing van replication is het vereenvoudigen van backup procedures. MySQL zet bij het draaien van een backup een lock op de tabel die op dat moment wordt gedumpt. Dit resulteert nog wel eens in langdurige table locks en daardoor uitvloeiende ongemakken bij gebruikers. Door een backup te maken vanaf een replication slave ondervinden gebruikers van de master server geen hinder van de backup. Ook kan replication goed gebruikt worden voor het realtime bijhouden van een off-site backup. De verbinding tussen de master server in de co-locatie ruimte en de lokale backup server kan met SSH beveiligd worden.

De database is veruit de zwakste schakel in het hosting raderwerk van Tweakers.net gebleken. Als bezoekers heb je dit met enige regelmaat aan den lijve kunnen ondervinden. In het afgelopen half jaar hebben we een heel scala aan problemen voorbij zien komen, variŽrend van een simpel gebrek aan capaciteit tot thread-limieten in de Linux kernel. Sinds onze verhuizing naar TrueServer en de ingebruikname van de tweede database server (Apollo) is de betrouwbaarheid van onze database backend aanmerkelijk verbeterd. Dit komt deels omdat de load per database server veel lager is, maar ook vooral omdat de servers veel optimaler geconfigureerd zijn.

Tweakers.net is bijna volledig database-driven en dat betekent dat we voor onze content vrijwel geheel afhankelijk zijn van de database server. Is de server stuk, dan kunnen wij niet meer dan een gecachede error pagina laten zien. Tweakers.net is bovendien erg dynamisch, waardoor de databases vrijwel continu aan veranderingen overhevig zijn. Het regelmatig kopiŽren van een backup naar een tweede standby database server zou weinig effect sorteren, omdat de backup server altijd out-of-date zou zijn. Alleen een goed werkende replication functionaliteit van de database server kan ons hierbij helpen. Tot voor kort ontbrak het ons aan een tweede database server en bovendien leek de replication functionaliteit bij eerdere tests behoorlijk onbruikbaar te zijn.

Sinds de verhuizing naar TrueServer, nu bijna een maand geleden, zijn de databases van Tweakers.net en GoT verdeeld over twee servers. Met alleen een verdeling van de databases en de load over meerdere servers zou de database server echter in stand blijven als single point of failure. Daarom was ik erg benieuwd naar de mogelijkheden van MySQL replication. Sinds drie weken wordt hiervan gebruik gemaakt, zowel voor load balancing als het verhogen van de redundancy.

Op dit moment worden alleen de databases op Artemis gerepliceerd door Apollo, met uitzondering van de Fokforum database die niet werkt met replication vanwege een vermoedelijk probleem met temporary tables in de search engine. Load balancing wordt bereikt door de SQL queries voor de pagina's op Tweakers.net random in een verhouding van 70/30 te verdelen over Artemis en Apollo. Redundancy kan simpel gerealiseerd worden door een paar extra regeltjes code in het connect scripts dat er voor zorgt dat een connectie wordt gemaakt met de slave zodra de master down is. Hierbij moet je wel rekening houden dat de MySQL connect funcite van PHP nogal onhandig omgaat met dode servers die wel zouden moeten bestaan. In dat geval blijft het script oneindig hangen. Dit probleem is op te lossen door een check met fsocksopen op de poort van de MySQL server voor het aanroepen van de connect functie.

Aangezien MySQL uitsluitend ondersteuning heeft voor one-way replication blijft overlast onvermijdelijk als de master down is. Het posten van reacties zal dan bijvoorbeeld niet mogelijk zijn. Wel behoudt Tweakers.net in ieder geval zijn content en dat is al veel beter dan een situatie waarbij alleen een error pagina getoond kan worden, ook al staat die error pagina vol met mooie BMW's . Gelukkig heeft de noodzaak van replication zich nog niet bewezen sinds het in gebruik werd genomen. De database servers draaien al drie weken zonder problemen en de MySQL server op Artemis heeft inmiddels een uptime van 15 dagen bereikt, iets wat we al heel lang niet meer hebben mogen meemaken. In die 15 dagen heeft Artemis meer dan 125 miljoen queries uitgevoerd. En hoewel Artemis het sinds de komst van Apollo minder druk heeft, verwerkt hij tijdens de topuren nog steeds een respectabele 150 queries per seconde.

De betrouwbaarheid van MySQL replication bleek bij eerdere tests op Artemis en Athena nogal problematisch te zijn. Dit was vooral te wijten aan het feit dat de snapshots werden gemaakt met mysqldump op een draaiende database server. Het tarren van de data directories terwijl de server offline is, blijkt veel beter te werken. Inmiddels draait replication al 15 dagen onafgebroken zonder veel problemen. Al met al kunnen we hier dik tevreden over zijn . De goede werking van replication betekent tevens dat MySQL een belangrijk streepje voor heeft op Postgres en SAP DB. Deze twee open source DBMS'en moeten het nog zonder replication functionaliteit stellen.

Tot slot nog een twee tips voor mensen die zelf aan de slag willen gaan met MySQL replication. Voordat je replication pratend kunt maken, zul je een snapshot van de databases op de master moeten kopiŽren naar de slave. De veruit beste methode om dit te doen is het bouwen van een tarbal op de master (ik ga voor het gemak uit van een Unix-achtig systeem). Dit zal wat overlast veroorzaken omdat de master voor enkele minuten platgegooid moet worden, maar het werkt veel beter dan een online mysqldump. In dat geval zou je alle tabellen gedurende de dump moeten locken om verzekerd te zijn van een backup die consistent is in de tijd. Het kopiŽren van tarretjes tussen servers is geen probleem zolang hetzelfde OS gebruikt worden.

Ten tweede is het uitermate belangrijk dat je ten alle tijde voorkomt dat er buiten de master om wijzigingen worden gemaakt in de gerepliceerde databases op de slaves. Dit is vooral belangrijk op tabellen met auto-increment kolommen, omdat inserts in deze tabellen tot gevolg kunnen hebben dat de replication stopt met een 'duplicate entry'-error. Vaak is de enige oplossing dan het maken van een nieuw snapshot op de master. Snapshotjes aanleggen doe je bij voorkeur in de nacht als de overlast het minst is. Ik heb al meerdere keren mijn wekker moeten zetten voor deze handeling en daarom zie ik m'n replication niet graag kapot gaan . De eenvoudigste manier om te voorkomen dat er op de slave per ongeluk wijzigingen worden gemaakt is het connecten met een aparte MySQL user die alleen leesrechten heeft op de replication tabellen.

MySQL replication: privileges

Reacties (39)

Wijzig sortering
Nog wta info: volgens een posting van Sasha Pachev (MySQL developer) op de MySQL mailinglist staat 3.23.40 op het punt van uitkomen. In deze versie wordt een belangrijke replication bug gefixt:
"Hello, everyone:

Good news - I was able to repeat and fix the bug that several people have reported but were not able to repeat. No wonder - even after I noticed the
problem in the source, it took some creative work to be able to write a test case for it. ( We try to write a test case for every bug we find, even if we find it just by visual inspection).

The symptom of the bug was that you would get a message in the slave error log about the lost connection due to a low setting of max_allowed_packet when max_allowed_packet setting was not the problem at all.

The fix is to upgrade to 3.23.40, which should be out within 24 hours ( this is why I have not bothered to make a patch, if somebody really cannot wait,
let me know)."

Op dit item kan niet meer gereageerd worden.


Call of Duty: Black Ops 4 HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S9 Dual Sim Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V. © 1998 - 2018 Hosting door True