Downtime voor databaseonderhoud op 4 juni 2008, 16:30u

Aanstaande woensdag 4 juni gaan we om 16:30u een paar belangrijke databasetabellen aanpassen. Om een noodzakelijke backup te maken en om zeker te weten dat er geen data wordt gewijzigd als we aan het werk zijn, zal de frontpage een tijdje uit de lucht gehaald moeten worden. Dit zal hopelijk niet langer dan een uur duren. Het forum blijft ondertussen gewoon werken.

Omdat Tweakers.net steeds verder is uitgebreid met nieuwe functionaliteit zijn we tegen een limiet van een oud stuk code aangelopen. Vroeger volstond het prima om reacties op nieuws met een 'n', die op meuk met een 'm' en die op polls met een 'p' te markeren. Tegenwoordig gebruiken we die indicaties voor allerlei soorten artikeltypen en inmiddels zijn we toe aan het 27e reactietype - en dat is natuurlijk lastig als je alfabet maar 26 letters bevat en de opslag doorgaans hoofdletterongevoelig is gedaan. Helaas wordt de constructie juist in een paar grote, centrale tabellen gebruikt, zoals de reacties en koppelingen van producten aan nieuwsitems, waardoor de verbouwing relatief ingrijpend is. Met de door te voeren wijzigingen beschikken we echter weer over genoeg ruimte voor nieuwe artikeltypen om het tot 2050 uit te houden.

Update 16:55u
En we zijn alweer klaar, het lijkt er op dat alles in een keer goed ging en gelukkig is onze productieserver een stuk vlotter dan de testserver waarmee we de schattingen maken.

Reacties (81)

Valt me dan wel een beetje tegen dat jullie je reactie typen niet in een aparte tabel hebben, is wel zo genormaliseerd natuurlijk..

Dat is dan ook effectief wat nu gaat wijzigen Maar het is een beslissing/ontwerp van jaren terug, toen het veel minder speelde en er vooral een site moest komen oid.

En omdat het downtime kost om aan te passen ga je niet zomaar even een keertje tussendoor de boel aanpassen, maar pas als het nodig is.

[Reactie gewijzigd door ACM op 3 juni 2008 16:04]

Begrijpelijk, nice.

Lijkt me echt een uitdaging om het in een live omgeving te doen. Als een topsporter voor een sprintje 100mtr, met alle tooltjes en voorbereiding helemaal opgewarmt om op 16:30hrs het startschot te krijgen. Waarna het na een hoop hectiek afgelopen is na een korte tijd.

Dat laatste hopelijk zonder hectiek, maar dat hebben jullie ongetwijfeld al doorgenoemen/ getest/ getweakt

Ik snap zowieso niet waarom je het type nodig hebt. Reactie is reactie en hoort bij artikel (mbv artikelid).. Die dan evt wel een type kent.

@hieronder: heb ff iets verduidelijkt..

[Reactie gewijzigd door Jogai op 3 juni 2008 16:31]

Reacties hangen ook aan vraag en aanbod meldingen, productreviews, polls, etc ...

In onze opzet (die ook alweer jaren oud is) zijn de artikelen niet geabstraheerd tot een enkele basis-entiteit in de database, wat sowieso een vergelijkbaar probleem had opgeleverd op die plek. En dan moet je toch echt weten aan welk artikel en artikelsoort de reactie hangt (want we hebben review nummer 1, nieuws nummer 1, etc)

Als je dat echt structureel wilt oplossen ben je denk ik wel wat langer bezig. Je zet dan alle artikelen in 1 tabel, met nieuwe ID's. Het regenereren van de ID's en hun foreign keys kost dan erg veel tijd. Dat gaan jullie dus blijkbaar niet doen?

Nee, de meerwaarde daarvan is vziw niet groot genoeg om zoveel downtime en structurele codewijzigingen te verantwoorden. Voor zover er uberhaupt noemenswaardige meerwaarde is.

Dat het semantisch iets beter is... in SQL kan je toch niet echt met OO werken, dus moet je er ook niet te veel moeite voor proberen te doen imho.

Zeker als we ID's gaan hernummeren is het een rotwerk, vooral omdat we dan ook links intern en extern goed moeten zien te vertalen en dergelijke...

Dan zullen je perma links ook wel allemaal op hun smoel gaan. en kom je heel veel andere prob lemen tegen.

en hoe weet je waar reactie nummer 1 bijhoort zonder een artikelid bij te hebben?

Een tussentabelletje "artikel_reactie", en zo ook "nieuws_reactie", "review_reactie", etc.

dus je gaat 30+ tabellen aanleggen voor gelijke data? Lijkt mij niet een heel tof idee..

Ik vind het nogal amateuristisch overkomen: downtime door een update... er zijn legio manieren om dat geheel of gedeelte op te vangen ('s nachts, read only, tijdelijke html fallback). Ik zal mijn klanten eens vertellen dat ik bij hun om 8 uur 's ochtends (piektijd) onderhoud ga doen. Ik denk dat ik ze dan snel kwijt ben

Downtime door een update vindt je amateuristisch... en vervolgens zijn je voorstellen dat je toch downtime creeert - maar dan op een ander tijdstip, of minimaal een fors deel van de functionaliteit uitschakeld.

Als het nou langer zou duren dan een uur zouden we het ook zeker op een ander tijdstip doen, maar je kan ook wel klagen om te klagen. Het is tenslotte niet alsof we dit elke week zo doen. Van de meeste updates die we doorvoeren merk je zelfs helemaal niets, hooguit door veranderde functionaliteit, terwijl we vaak meerdere wijzigingen per dag doorvoeren.

Maar in dit geval wordt een dusdanig belangrijke tabel gewijzigd dat read-only toegang al niet fatsoenlijk te faciliteren is (ik wil helemaal geen reads op die reacties-tabel tijdens de wijziging, al is het alleen maar omdat dan het wijzigen langer duurt). En een html-fallback voor een uurtje? Je kan ook overdrijven hoor

Overigens is rond 17u helemaal niet ons piekuur. 't Is zelfs van alle uren 'overdag' zo'n beetje de rustigste.

[Reactie gewijzigd door ACM op 3 juni 2008 18:42]

De piektijd hier ligt tussen 11 en 16 ongeveer.

Waarom wordt de update niet 's ochtend vroeg uitgevoerd (+/- 07:00 uur) zodat minder mensen er last van kunnen hebben? Of nog beter 's nachts.

't Zijn het soort updates die in principe maar een half uurtje duren, maar als je een fout maakt gelijk een half uur extra kosten omdat je de backup terug moet halen.

Normaliter maak ik 's ochtends vroeg of 's avonds laat meer fouten dan overdag, zelfs dan aan het eind van de middag. Dus de kans op uitloop is tijdens een "wakker moment" kleiner dan op een "slaperig moment".

Vandaar dat we na eerdere niet al te geweldige ervaringen maar hebben besloten niet al te veel moeite te doen om het op een onchristelijk tijdstip uit te voeren.

En mocht er toch een fout of bug door ontstaan, dan kunnen we die 's avonds nog herstellen, in plaats van na het slapen pas...

[Reactie gewijzigd door ACM op 3 juni 2008 15:28]

Alleen jammer dit niet op een betere manier aan gepakt wordt. Dit soort changes kunnen helemaal gedaan worden zonder downtime en zonder dat mensen er iets van merkt, ook overdag.

Kom op zeg een paar tabelen (maakt niet uit hoe groot) waar een aantal dingen moeten veranderen das toch niet zo moeilijk, een outage van een paar seconde op z'n meest is alles wat nodig is niet een uur.

Maar goed wat weet ik nu van dat soort dingen, maakt niet uit hoor soms moet je je zelf ook niet overschatten en gewoon alles zo simpel mogelijk houden, maar soms vraag ik me af of het KISS model niet een beetje misbruikt wordt.

Je hebt blijkbaar geen ervaring met MySQL?

Een structurele wijziging aan een tabel (zelfs het hernoemen van een kolom) betekent namelijk dat de tabel opnieuw uitgeschreven wordt. Dat geldt ook voor het toevoegen, veranderen en verwijderen van kolommen en indexen.
Tijdens zo'n situatie van opnieuw uitschrijven doet MySQL bovendien erg lastig met locks op die tabellen, ondanks dat reads zogenaamd nog op de oude situatie door mogen gaan.

Als je dan dus een veelgebruikte tabel van 2GB wijzigt, duurt dat in mijn ervaring wel wat meer dan een paar seconde. En we hebben vier wijzigingen nodig; kolom toevoegen, nieuwe kolom vullen adhv een oude kolom, index aanpassen/toevoegen om nieuwe kolom te gebruiken, oude kolom verwijderen en nieuwe kolom hernoemen naar oude.
Alleen die laatste stap is niet noodzakelijk, maar bespaard ons wel een hoop code doorlopen/aanpassen. En ja, als al die legacy code niet had bestaan had ook dat niet gehoeven, maar die bestaat nou eenmaal

Ik ben heel benieuwd hoe jij dat in een paar seconde voor je ziet? Want als we iets over het hoofd zien, doen we het graag anders.

In PostgreSQL zou het inderdaad zonder noemenswaardige downtime moeten kunnen, aangezien ieder van die wijzigingen daarin wel via het versiebeheer gaan. En wellicht de grote jongens als SQL-server, DB2 en Oracle ook wel. Maar we draaien MySQL... En ook dat kunnen we niet transparant in een paar seconde wijzigen

[Reactie gewijzigd door ACM op 4 juni 2008 11:17]

Op een Sybase of Oracle system zou ik het volgende doen, kopie maken van de tabel en die gelijk houden met de orgineele tabel (via replicatie) dan de kolom toevoegen aan de kopie, trigger plaatsen voor de nieuwe entries, nieuwe kolom vullen aan de hand van de oude. Index bouwen/aanpassen.

Dan de replicatie breken (wel de que blijven vullen natuurlijk), drop trigger, hernoem kolom, trigger toevoegen voor de records die nog in de replicatie que zitten. En als de replicatie weer in sync is de orgineele tabel en de kopie van naam veranderen in een transactie.

De outage is een paar seconde en niemand die hier iets van merkt. Met MySQL weet ik het inderdaad zo net nog niet maar ik heb het idee dat het ook met MySQL heel goed te doen zou moeten zijn.

ps, 2GB is een kleine tabel, ales onder de 60GB is nog steeds niet echt groot, lastig dat zeker maar niet zo groot.

Ooit ga ik ook nog leren spellen

[Reactie gewijzigd door Rob Coops op 4 juni 2008 12:03]

2GB is inderdaad niet groot Maar wel groot genoeg om meer dan een paar seconden te nemen per bewerking.

En helaas vindt MySQL gewoon dat een wijziging aan de tabelstructuur niet in een transactie hoeft (en kan) en dat je mede daardoor dus alle writers al laat wachten tot je klaar bent. Tegelijkertijd kent MySQL dergelijke zaken als triggers niet of zit je wederom ermee dat je me de niet-transactionele wijzigingen aan tabellen zit.

't Zal allemaal vast wat handiger gekund hebben, maar of dat met een nog redelijke inspanning in MySQL met onze situatie kan betwijfel ik eigenlijk.

Daar is een heel simpel antwoord voor:

Ze zijn dan niet wakker

Je kunt niet van ze verwachten dat ze midden in de nacht naar de servers toegaan om een update uit te voeren, terwijl dit moet gebeuren als men goed wakker is en geen fouten maakt.

Kan zoiets dan niet remote of zelfs automatisch (vooraf in een soort sandbox-idee getest en dan alles voorkauwen en om 2 uur 's nachts laten draaien)? Dit laatste zal wel niet een al te best idee zijn, maar zoiets moet toch met goede controle mogelijk zijn... ik dacht dat er van die mooie oplossingen bestonden voor servers.

[Reactie gewijzigd door vgroenewold op 3 juni 2008 14:59]

Er hoeft maar één ding mis te gaan of niet getest te zijn en dan kom je met je automatische scriptje om 2 uur 's nachts aan een veel langere downtime dan het uurtje waar je met je neus bovenop zit en wanneer je mensen ook op de hoogte kunt houden (via GoT) over eventuele issues en langere downtime. Helemaal zo'n dom idee nog niet dus.

Had alleen wel na 5 uur gemogen Hoe houd ik mijzelf op het werk nu zoet, dat laatste half uurtje?

_{Misschien eens een keer gewoon werken of sociaal contact zoeken met je collega's}

of GoT

En wat dan voor mensen die in een andere tijdszone van tweakers willen genieten?!?

Als die >20-30% van het publiek zouden uitmaken...maar dan zou je nooit kunnen updaten natuurlijk.

Je kunt niet van ze verwachten dat ze midden in de nacht naar de servers toegaan om een update uit te voeren, terwijl dit moet gebeuren als men goed wakker is en geen fouten maakt.

Dat is natuurlijk onzin: heel veel van dit soort updates worden 's-nachts uitgevoerd.

Als ze een commercieel bedrijf zouden zijn met een klanten bestand van 3 miljoen, ja. Tweakers.net is geen bank of overheidsinstelling. Ik denk dat de meeste tweakers er meer dan begrip voor hebben dat er ondehoud gepleegt wordt als dat er voor zorgt dat ze vrolijk kunnen blijven tweakeren tot aan 2050 en daarna.
De crew wil net als ieder ander mens lekker slapen 's nachts.

[Reactie gewijzigd door Who Am I? op 3 juni 2008 15:48]

Als ze een commercieel bedrijf zouden zijn met een klanten bestand van 3 miljoen, ja. Tweakers.net is geen bank of overheidsinstelling. Ik denk dat de meeste tweakers er meer dan begrip voor hebben dat er ondehoud gepleegt wordt als dat er voor zorgt dat ze vrolijk kunnen blijven tweakeren tot aan 2050 en daarna.
De crew wil net als ieder ander mens lekker slapen 's nachts.

Maar Tweakers.net is wel een bedrijf en dus een winst oogmerk...
Beetje vreemd om dan in je piekuren je site tijdelijk offline te gooien, waar je toch je inkomsten van moet hebben... Daar hoef je dan echt geen klantenbestand te hebben met 3 miljoen klanten...

Natuurlijk begrijp ik het wel, die update aan de database moet er doorheen...
Maar ik zou het niet tijdens piekuren doen...

Piekuur? Dat is het helemaal niet... het is normaliter zelfs pas na 23u weer zo rustig als rond 17u. De enige "kantoortijdachtige" betere tijd is 's ochtends tussen 8u en 9u.

Ik heb het uiterste vertrouwen in de crew. Het zal vast niet zo extreem lang duren, en inderdaad, we betalen geen fluit (ik niet althans)... dan hoeven we ook niet te verwachten dat ze overal 100% uptime garanderen.

Daarnaast is het forum wel gewoon online, ik kan wel eventjes de frontpage missen.

Als ze een commercieel bedrijf zouden zijn met een klanten bestand van 3 miljoen, ja. Tweakers.net is geen bank of overheidsinstelling. Ik denk dat de meeste tweakers er meer dan begrip voor hebben dat er ondehoud gepleegt wordt als dat er voor zorgt dat ze vrolijk kunnen blijven tweakeren tot aan 2050 en daarna.
De crew wil net als ieder ander mens lekker slapen 's nachts.

Ten eerste, Tweakers.net is wel een commercieel bedrijf.
Ten tweede, Tweakers.net heeft dan wel geen 3 miljoen gebruikers (hoeveel bedrijven in NL hebben dat wel), maar toch wel zo'n 250 000.
Ten derde, om je downtime 's-nachts te plannen hoef je geen bank of overheidsinstelling te zijn
Ten vierde, ik zeg nergens dat Tweakers hun downtime per se 's-nachts moeten doen, ik reageer alleen op de opmerking van painkill dat je "midden in de nacht niet naar servers toegaat" omdat je dan niet "goed wakker" bent.

Opzichheb je gelijk. Maar half 5 is opzich wel een ideale tijd.

De meeste mensen zijn om 5 uur afgewerkt. Daarna kar je naar huis, doe je ook een flinke tijd over. Ben je thuis, eten. Tegen half 7 / 7 uur ben je overal klaar mee.

Dan is tweakers weer up .

Tweakers.net is geen bank of overheidsinstelling.

De Postbank internetbankieren ging een paar dagen geleden ook gewoon om 16 uur plat.

Optie 1:
Hou iedereen tevreden doe het 3 uur snachts geen teras geen bier maar 100% werk focused.
Optie 2:
We pakken een teras zuipen ons klem 12 uur het bed uit 3 uur is de kater weg half 5 gaan we starten met werken en na de update terug naar het teras.

Oke ik geef tweakers.net gelijk zou ook voor optie 2 gaan als ik de kans had

Daar is een heel simpel antwoord voor:

Ze zijn dan niet wakker

Je kunt niet van ze verwachten dat ze midden in de nacht naar de servers toegaan om een update uit te voeren, terwijl dit moet gebeuren als men goed wakker is en geen fouten maakt.

Waarom zou een backup niet 's nachts kunnen lopen?
In het bedrijfsleven is tijdens werkuren het anders wel erg dodelijk om juist dan een backup te gaan draaien... Dan krijg je een boel mensen op je dak die gaan klagen over traagheid in het netwerk...

Het gaat hier om meer dan alleen een back up te maken.

Het gaat hier om meer dan alleen een back up te maken.

Dan kan je ondanks dat je backup 's nachts nog wel maken...

Hmm, gebruik van de hele ascii tabel kan niet? Dan kun je nog tot bijna een factor 10 doorgaan

Altijd jammer als je tegen een beperking van je orriginele design loopt. Gelukkig valt het dit keer (zo te zien?) relatief makkelijk op te lossen. Hoe komen jullie eigenlijk aan 2050 als jaar dat het weer fout zou kunnen lopen?

En waarom gebeurd deze update trouwens niet 's nachts?

Om te beginnen; ik heb geen fluit verstand van web-applicaties, dus daar zal ik verder niks op zeggen, maar people, toe, zeur 's niet zo.
Hoe ze 't ook plannen, 'r is altijd wel iemand die 'r problemen mee heeft, en je kan niet iedereen tevreden houden.
En al loopt 't wat uit, nobody's perfect.
Willen jullie nou 'n goed werkende site of niet???

weet je wat het is je hebt altijd mensen die nooit tevreden zijn, het is toch nooit goed wat ze ook doen, dit is echt typerend want dat zie je altijd terug.

ze geven netjes aan waarom ze down gaan ze geven netjes aan waarom ze op DAT tijdstip down gaan en niet midden in de nacht of op een ander tijdstip.

wat is het dan voor nut om honderden reacties te plaatsen waarin staat hoe tweakers.net
of beter gezegd op welk tijdstip tweakers.net hun site moet onderhouden..

ik zeg dan de beste stuurlui staan aan wal.. want we weten het altijd beter blijkt..
maar zo zie ik het vanuit mijn standpunt

[Reactie gewijzigd door pino85 op 4 juni 2008 12:36]

Ik kan het mis hebben hoor maar als je 26 letters in het alphabet hebt en je programmeer taal is hoofdletter gevoelig dan heb je toch 52 caracters?

P.s. ik ben echt geen SQL deskundige dus dit kan best een domme opmerking zijn!!!

en de opslag doorgaans hoofdletterongevoelig is gedaan.

De programmeertaal kan wel hoofdlettergevoelig zijn, maar dat betekend nog niet dat er met hoofdletters wordt gewerkt

[Reactie gewijzigd door Heikanu op 3 juni 2008 20:27]

Een SQL query is met bijvoorbeeld met

WHERE x = 'bla'
LIKE '%Blaat%'

standaard niet hoofdlettergevoelig. Je moet de COLLATION aanpassen om dit voor elkaar te krijgen. Als je bijvoorbeeld een wachtwoord wil valideren op de database door middel van een query moet je altijd extra stappen ondernemen.

Dat geldt voor MySQL, niet zozeer voor SQL in zijn algemeenheid

Niemand die doorheeft dat die 2050 maar een random jaartal is?

De komende 42 jaar?

Die 42 was eigenlijk wel toeval

42 is nóóít toeval

Nog een leuk weetje over 42:

Every TIFF begins with a 2-byte indicator of byte order: "II" for little endian and "MM" for big endian byte ordering. The next 2 bytes represent the number 42, selected "for its deep philosophical significance"

TIFF
42 op wikipedia

Answer to Life, the Universe, and Everything

We gaan niet weer stiekem de lay-out aanpassen wel?

Dan zijn we langer dan een uur offline

Zou het niet erg vinden
Anyways
Waarom gebruik je anders niet 2 letters? zo heb je 26² = 676 mogelijkheden lijkt me genoeg toch

2050 maar... dat is niet zo lang ^^
Wel leuk dat er bij staat waarom de site ff down gaat en wat er gaat gebeuren!