Hoofdcategorieën

[RSS] Index » .Plans » Serverbeheer » Downtime voor databaseonderhoud op 4 juni 2008, 16:30u

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

Door Arjen van der Meijden, dinsdag 3 juni 2008 14:18, views: 11.326

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.

Volgende 15:47
Vorige 19:10

Categorie

Arjen van der Meijden

Sinds Oktober 2001 co-developer met als voornaamste taak het technisch beheer van het forum. Ondertussen op alle fronten inzetbaar.

E-mail anti-spam e-mail plaatje
Username ACM Rss-feed
Functie Developer

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 81 reacties zichtbaar810 Neutraal: 78 reacties zichtbaar78+1 Meerwaarde: 12 reacties zichtbaar12+2 Verplicht leesvoer: 0 reacties zichtbaar0
«  1  2  3  »

Door AndriesLouw, dinsdag 3 juni 2008 14:30

Score: 0
We gaan niet weer stiekem de lay-out aanpassen wel? ;)

Door ACM, dinsdag 3 juni 2008 14:30

Score: 0
Dan zijn we langer dan een uur offline :P

Door Saven, woensdag 4 juni 2008 10:53

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

Door Niemand_Anders, dinsdag 3 juni 2008 14:34

Score: 0
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.

Door painkill, dinsdag 3 juni 2008 14:39

Score: 0
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.

Door jeroenr, dinsdag 3 juni 2008 14:50

Score: 0
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.

Door Who Am I?, dinsdag 3 juni 2008 15:47

Score: 0
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?]

Door geerttttt, dinsdag 3 juni 2008 16:24

Score: 0
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.

Door GJtje, dinsdag 3 juni 2008 17:57

Score: 0
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... ;)

Door ACM, dinsdag 3 juni 2008 18:32

Score: 0
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.

Door jeroenr, dinsdag 3 juni 2008 20:02

Score: 0
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.

Door vandeMeulenhof, woensdag 4 juni 2008 10:46

Score: 0
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 ;).

Door Soldaatje, donderdag 5 juni 2008 16:00

Score: 0
Tweakers.net is geen bank of overheidsinstelling.
De Postbank internetbankieren ging een paar dagen geleden ook gewoon om 16 uur plat.

Door HADES2001, dinsdag 3 juni 2008 15:59

Score: 0
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 :)

Door vgroenewold, dinsdag 3 juni 2008 14:58

Score: 1
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]

Door PrinsEdje80, dinsdag 3 juni 2008 15:03

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

Door vgroenewold, dinsdag 3 juni 2008 15:16

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

Door Zyppora, dinsdag 3 juni 2008 16:36

Score: 1
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? :+

Door SRI, woensdag 4 juni 2008 10:36

Score: 0
Misschien eens een keer gewoon werken :p of sociaal contact zoeken met je collega's

Door GJtje, dinsdag 3 juni 2008 17:54

Score: 0
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... ;)

Door SRI, woensdag 4 juni 2008 10:37

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

Door GJtje, woensdag 4 juni 2008 17:43

Score: 0
Het gaat hier om meer dan alleen een back up te maken.
Dan kan je ondanks dat je backup 's nachts nog wel maken... ;)

Door ACM, dinsdag 3 juni 2008 15:14

Score: 1
'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]

Door Rob Coops, woensdag 4 juni 2008 10:48

Score: 0
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.

Door ACM, woensdag 4 juni 2008 11:16

Score: 1
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]

Door Rob Coops, woensdag 4 juni 2008 12:01

Score: 1
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]

Door ACM, woensdag 4 juni 2008 12:09

Score: 1
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.

Door ShadowLord, dinsdag 3 juni 2008 14:37

Score: 0
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?

Door Twigg, dinsdag 3 juni 2008 14:47

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

Door Armorad, dinsdag 3 juni 2008 14:55

Score: 0
Ik denk dat het om 2050 artikeltypes gaat en niet om het jaar 2050...

Door Ramoonus, dinsdag 3 juni 2008 14:58

Score: 0
ik denk dat ze juist wel het jaartal bedoelen!

Door ScSi, dinsdag 3 juni 2008 15:03

Score: 0
Niemand die doorheeft dat die 2050 maar een random jaartal is? :Y)

Door elleP, dinsdag 3 juni 2008 15:17

Score: 0
De komende 42 jaar?

Door ACM, dinsdag 3 juni 2008 15:24

Score: 0
Die 42 was eigenlijk wel toeval :P

Door Henridv, dinsdag 3 juni 2008 19:41

Score: 0
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

Door Lieuwe15, dinsdag 3 juni 2008 15:39

Score: 0
Ze doen het iig na werktijd als ik in de auto naar huis zit, dat is dan wel weer een pluspunt :Y)

Door _Apache_, dinsdag 3 juni 2008 15:50

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

Door ACM, dinsdag 3 juni 2008 16:03

Score: 1
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]

Door _Apache_, dinsdag 3 juni 2008 16:42

Score: 0
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 ;)

Door Jogai, dinsdag 3 juni 2008 16:19

Score: 0
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]

Door moto-moi, dinsdag 3 juni 2008 16:26

Score: 0
en hoe weet je waar reactie nummer 1 bijhoort zonder een artikelid bij te hebben? ;)

Door al-ahlex, dinsdag 3 juni 2008 16:33

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

Door moto-moi, dinsdag 3 juni 2008 20:35

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

Door ACM, dinsdag 3 juni 2008 16:31

Score: 1
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)

Door DOT, dinsdag 3 juni 2008 17:26

Score: 1
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?

Door ACM, dinsdag 3 juni 2008 18:35

Score: 1
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...

Door siepeltjuh, woensdag 4 juni 2008 13:33

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

Door BCC, dinsdag 3 juni 2008 18:10

Score: 0
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 :)

Door ACM, dinsdag 3 juni 2008 18:41

Score: 1
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]

Door Jack Flushell, dinsdag 3 juni 2008 18:43

Score: 0
De piektijd hier ligt tussen 11 en 16 ongeveer.
«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 15:47
Vorige 19:10
VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: