Databaseonderhoud maandag 8 december *afgerond*

Aanstaande maandag 8 december willen we de software op onze databaseservers Artemis en Apollo updaten. Daarnaast zullen we voorbereidingen voor het gebruik van replication treffen en worden de servers voorzien van een nieuwe kernel, waardoor een reboot onvermijdelijk is. Al met al verwachten wij dat de databaseservers tussen 7:30 tot 8:30 af en toe kort onbereikbaar zijn.

Het gebruik van replication staat al lang op onze verlanglijst. Helaas bevatte de door ons gebruikte Mysql-versie een lastig beestje. Elke keer als deze bug tevoorschijn kwam - en dat gebeurde meerdere keren per dag - stopte de replication en moesten we dat handmatig weer opstarten. Deze bug is opgelost in Mysql Community Server 5.0.67 zodat we eindelijk fatsoenlijk replication kunnen gebruiken.

De server die in eerste instantie de replication zou verzorgen - Ate, een oude versie van Artemis - kreeg in de tussentijd echter andere taken. Ook bleek dat deze niet genoeg capaciteit had om zowel Apollo als Artemis bij te houden. We moesten dus een andere server uitrangeren en deze de replication laten doen. De keuze viel op Atlas, een server die we een jaar geleden al wilden vervangen. De vervangende server, die als nfs-fileserver moest worden ingezet, bleek echter zo instabiel dat hij niet langer dan een week in ons netwerk heeft kunnen meedraaien.

Een andere oplossing was dus gewenst, en onze keuze viel uiteindelijk op een Dell MD3000i. Alle webservers kunnen op deze machine een van Ocfs2 voorziene iScsi-disk mounten. Dat biedt diverse voordelen boven nfs, waaronder een beter cachebeheer. In enkele tests bleek deze oplossing vijf tot tien keer sneller te werken dan een nfs-mount en sinds zaterdag 8 november komen alle gedeelde files vanaf deze MD3000i, die Athos is gedoopt. De verbinding van de servers met Athos verloopt via meerdere paden zodat, als er onverhoopt een switch uitvalt, een netwerkkabel breekt, een voeding stukgaat of een raidcontroller in Athos overlijdt, de servers nog steeds bij de files kunnen komen.

Ook de installatie van Athos verliep overigens niet geheel zonder problemen. In eerste instantie werd gewerkt met Gfs1 en Gfs2. De tweede versie bleek echter ook al enkele vervelende bugs te bevatten. Zo was het niet mogelijk om in sommige releases een file te maken die meer dan 4kB data bevat, en Gfs2 was dan ook totaal onbruikbaar voor productiemachines. Ook de eerste versie van Gfs bleek niet helemaal goed te werken; zodra een server uitviel dacht Gfs er verstandig aan te doen om het gebruik van de shared storage voor iedere aangesloten server af te sluiten, wat tot enige downtime leidde aangezien hij toen al een deel van de cluster van gedeelde files voorzag.

De specs van Athos zijn als volgt:

Merk	Dell
Type	MD3000i
Aantal disks	15
Type disks	SATA
Grootte disks	500GB
Snelheid disks	7200 rpm
Raidtype	RAID 5
Bruto ruimte	7500GB
Effectieve ruimte	~6 TB

Voor- en achterkant van de MD3000i in de colo

Kortom, met een stabiele MD3000i, een Atlas die weinig te doen heeft en een Mysql-versie die eindelijk stabiele replication ondersteunt, is het tijd om de databaseservers Artemis en Apollo to voorzien van een nieuwe Mysql-installatie en de databases te kopiëren naar Atlas. Wij danken jullie bij voorbaat voor jullie geduld

Update 8:40: Iets later dan gepland, maar beide databaseservers zijn weer up and running. Alles wat gepland was is gelukt en de site zou, zodra de caches gevuld zijn, weer ouderwets snel moeten zijn.

Reacties (28)

Merken de gebruikers hier ook nog iets van? Als in: word het sneller, komen er nieuwe functies bij etc? Of is dit puur iets voor de achtergrond?

Alvast succes met de operatie maandag

Het is puur op de achtergrond, in in theorie wordt het zelfs iets langzamer (elke wijziging moet ook naar een andere file geschreven worden). Het voordeel is echter wel dat; mocht het ooit eens plat liggen, wij die db readonly kunnen gaan gebruiken, verder kunnen wij makkelijk de replicatie stop zetten, een consistente backup eraf halen en de replicate weer starten. Verder kunnen crontabs, die bijvoorbeeld statistieken genereren aan de hand van databases die database gebruiken voor hun read activiteiten waardoor de hoofd database minder belast wordt.

Alle reads splitten gaan we voorlopig niet doen; de server die dit gaat doen is bij lange na niet zo snel als artemis of apollo, en queries zullen daardoor veel langzamer uitgevoerd worden dan op hoofdservers, maar voor crons/backups maakt dat niet zo veel uit.

Kortom, in theorie gaat hij meer dan, maar in de praktijk kunnen we hem daardoor minder laten doen, en in totaal denk ik dat we het allemaal iets sneller gaat worden dan voorheen (maar marginaal; 10% winst op 0.01s is 0.001s; maar daar merk je als bezoeker nog steeds weinig van).

Dus als ik het goed heb is dit (Athos) server nummer 17 in de lijst van de servers. Ik mis hem alleen nog wel in de statistieken pagina van tweakers.

In ieder geval veel succes maandag bij de databasehandelingen.

[Reactie gewijzigd door _reboot_ op 5 december 2008 20:46]

Athos is geen server. Althans, niet een waar wij voldoende controle over hebben om hem zelf via een php-script zijn gebruiksstatistieken weg te laten schrijven

Helaas biedt de Dell MD3000i verder maar weinig data aan, dus ook met externe scripting kunnen we er weinig moois van maken. Dat is voor ons statistieken-gekken uiteraard ook wel een nadeel van het ding, maar we hebben nu eindelijk een werkende filesharing-omgeving, waar we voorlopig maar niet opnieuw aan gaan sleutelen

(overigens is het wel mogelijk om dmv een aantal php + java scripts er wat data uit te trekken, maar dat wordt dan missen we nog steeds veel data die onze php scripts wel produceren )

Wordt OCFS op dit moment ook al gebruikt? En wat zijn jullie ervaringen hiermee?

Het draait al sinds 8 november in productie; en heeft last van enkele limieten (max 32k subdirs bijvoorbeeld) en enkele minder briljante keuzes (fencing is niet erg goed geregeled; je hebt de keuze tussen reboten of niet reboten basically). Afgezien van deze 'problemen' draait het heel erg soepel, is vele malen makkelijker te configureren dan GFS en gaat het erg goed met crashes om (als test een (dev) server laten crashen; het cluster werkte gewoon door na een recovery binnen een seconde, met gfs hing het hele cluster voor 20-30 seconden tot een paar minuten)

Ik gebruik zelf ook al een hele tijd MySQL replication, maar ik vind het toch niet de holy grail die MySQL claimt dat het is. Op een grote databaseserver met veel wijzigingen lopen de binairy logs al snel in de paar GB.

Verder doet het niks tegen "human error". Als iemand een verkeerde handeling op de DB uitvoert, is dat op de slave ook al doorgevoerd. Dus je zit alsnog met backups draaien.

Verder, als de master eens dood gaat, en je zet de slave in als je nieuwe master, is t een bitch om al die changes later weer terug te zetten naar de master, hoewel de slave readonly maken dat probleem "oplost", maar dan zit je in feite alsnog met een maar half werkende website.

Heb ook een tijdje ge-experimenteerd met een dual-master structuur, maar daar kan je dan weer geen slaves aan hangen. Aangezien één slave maar naar één master kan luisteren, mis je bij een dual-master structuur op elke slave de writes die gedaan zijn op de master waar deze niet naar luistert.

Al met al vind ik replication dus nogal brak geïmplementeerd in MySQL.

De laatste keer dat ik aan replication deed liepen de binary logs inderdaad tegen de 10 gigabyte per dag aan. Dat is geen probleem, als de updates eenmaal uitgevoerd zijn dan kun je ze namelijk weghalen; en op deze manier gebruiken wij ook die bijna 1 terabyte aan harde schijfruimte effectief.

Verder is een read only database nog altijd beter dan helemaal geen website. Een master-master opstelling vereist eigenlijk twee identieke servers kwa capaciteit en die hebben wij op dit moment niet; in ons geval zou het dan zelfs om 4 servers gaan die identiek zijn.

Verder doet het niks tegen "human error". Als iemand een verkeerde handeling op de DB uitvoert, is dat op de slave ook al doorgevoerd. Dus je zit alsnog met backups draaien.

Je zal altijd backups moeten draaien, ook als je wel een goed werkende replcatie hebt. Daarbij lijkt het me meer dan logisch dat als een 'gebruiker' een foutje maakt ,de replicatie niet door kan hebben dat het fout is en het gewoon repliceert.

Je zou met een vertraging in je replicatie kunnen werken, het is niet zalig-makend maar daarmee heb je wat speling als een gebruiker iets verkeerd doet.

_{* gebruiker bewust tussen quotes gezet, normale gebruikers mogen immers geen rechten hebben waarmee ze een database flink kunnen verzieken.}

Succes maandag...

Wat voegt de pricewatch prijs bij aan het artikel btw?

Scheelt vragen als 'wat moet dat kosten?' 'waar komt het vandaan' (naja; in dit geval was dat niet heel erg onduidelijk). Dit zijn vaak terugkerende vragen, en zo'n pw tabelletje is niet zo moeilijk erin te frotten en geeft op een aantal vraqgen 'subtiel' antwoord.

Op GoT loopt een draadje over de prijzen die Dell rekent voor de schijven. Wellicht leuk om te vermelden hoe jullie dat hebben opgelost mocht je dat kwijt willen klik

Als je een groot of interessant genoege klant bent willen ze best wat van die nogal hoge standaardprijs afhalen. Wat in principe bij alle bedrijven in elke branch geldt natuurlijk

Grappig dat henk officieel is 'ge-exit' door tweakers.net, en we vervolgens wel een casebadge rechts op de voorkant van de serve rterugzien.

Geen tweakers-steeksleutel-logo voor op de casebadge? .

Niet dat dat nieuwe logo mooi vind hoor.

Grappig dat henk officieel is 'ge-exit' door tweakers.net

Kijk eens naar de achtergrond op GoT

Wel raar dat jullie zo vaak last hebben van slechte nieuwe hardware (server die maar 1 week werkt) en dan bijna altijd toch iets nieuwers (kant en klaars ) moeten kopen, ook een ontzettende pech met bugjes (wtf max 4KB files)

Hoop dat de bugjes morgen wegblijven!

We hebben ook zat hardware gekocht die zonder problemen hun werk vanaf het begin doet. Maar soms zit het niet heel erg mee nee...

die database error van vanmiddag... had deze toevallig iets te maken met deze update?

voor de mensen die het niet meegekregen hebben.. als je ergens op drukte zoals V&A kreeg je een database error..

Zojuist kreeg ik die ook voor enkele minuten.