Zaterdag ochtend werd ik, helaas, om 7 uur ’s ochtends wakker ge-SMS-ed, omdat er een probleem was met de replicatie van Database cluster #13. Volgers van onze onderhoud-pagina herinneren zich wellicht nog dat dit niet de eerste keer deze week was dat er problemen met deze server waren. Een paar dagen terug viel de replicatie ook uit met een vage error, en was ondergetekende bezig tot 03:00 ’s nachts om deze te fixen. En nu weer iets!

Een eerste analyse zag er al meteen niet goed uit. MySQL, SMTP, en ssh deden het allemaal niet meer. Verbindingen werden geweigerd of braken halverwege spontaan af. Die server was behoorlijk in de war.
Het eerste wat ik probeerde was natuurlijk om over het netwerk op de console in te loggen, maar helaas, ook die kwam met een rare error terug. Meteen springen er doom-scenario’s door het hoofd. Om half 8 in het datacenter staan? De hele dag bezig een server met rare fouten te fixen? Straks valt de hoofd server ook uit en zijn er honderden sites offline? Daar gaat mijn weekend…

Gelukkig duurde deze gedachten maar een paar seconden. Toen kwam er een stemmetje omhoog met de gedachte “We hebben nog genoeg spare servers. Maak gewoon een nieuwe replicator aan!” En inderdaad, zo gezegd, zo gedaan. Het hardware overzicht erbij gehaald, en daar stonden nog een 5 tal spare servers klaar. Deze servers hangen als een soort stamcellen in het rack; ze hebben een standaard installatie gehad, maar zijn nog nergens in gespecialiseerd.

 

dbr13 synchronizing

dbr13 is synchronizing

 

Een van de grootste voordelen van de setup van het byte netwerk, is dat de meeste servers Expendable kunnen zijn. Ze bevatten geen informatie die uniek is, en als ze uitvallen is dat geen enorm probleem. Zo ook een replicatie server. Alle data staat nog gewoon op de master server en omdat deze automatisch geïnstalleerd worden en centraal worden bijgehouden zijn er geen scripts of instellingen op die server die nodig zijn om de opvolger te laten draaien.

Met die gedachtes in het achterhoofd maar begonnen. Eerst via onze database de server als defect gemarkeerd, en de server van “dbr13” gerenamed naar een spare. Daarna de oude server van het netwerk gehaald, een paar simpele commando’s op onze network switches om de netwerk poorten dicht te zetten.
Toen door naar de nieuwe server. Deze gerenamed van spare47 naar db13, en in de database deze als productie gemarkeerd. Snel voor deze nieuwe server downtime instellen in onze monitor software om te voorkomen dat we daar nou ook weer SMSjes over gaan krijgen(Er draait geen MySQL op dbr13!', De replicatie doet het niet!’).

dbr13 - Alles weer OK

dbr13 – Alles weer OK

 

Vervolgens op de nieuwe dbr13 ingelogd, en inderdaad, een kale spare server. Een paar commando’s later en de server was lekker bezig met het installeren van tientallen kleine Debian pakketten waaruit een replicator is opgebouwd. Daarna de harde schijf opnieuw gepartitioneerd, extra ruimte voor de backups aangemaakt, en de Byte installer voor database replicatie servers maakt alles af voor me. En inderdaad, 10 minuten later stond er een mooie schone replicator te wachten.

Nog een commando gegeven en de replicatie software logde in op de hoofdserver en begon vanaf daar data te kopiëren naar zichzelf. 22GB aan data later startte MySQL de replicatie weer, was hij nog 1 minuutje bezig met het inlopen van recente changes, en toen gingen alle lampjes weer mooi op groen; alles deed het weer prima.

En de oude server? Die hangt nog in het datacentrum, afgesloten van de buitenwereld. Daar gaan we maandag nog wel even naar kijken, met een warm bakkie drinken op kantoor. Nu eerst maar eens lekker terug naar bed.

Scan je eigen Magento shop op veiligheidslekken