Nieuwe databaseserver op 23 juni - update

In oktober installeerden we Artemis 6, onze huidige primaire databaseserver, en op 23 juni nemen we ook een nieuwe secundaire databaseserver in gebruik: Apollo 6. Deze server neemt de replicatiefunctie van Artemis 5 over. We gaan op woensdagochtend 23 juni om 08:00 aan de slag en we verwachten ongeveer vier uur nodig te hebben.

Omdat MySQL's replicatie-omgeving niet fail-safe is, willen we met een consistente backup en de bijbehorende binlogs beginnen. Nu kan in MySQL met MyISAM-tabellen alleen een consistente backup worden gemaakt als de database geen nieuwe data aangeleverd krijgt, dus MySQL moet worden stilgelegd.

Het stoppen en starten van onze MySQL-server duurt een aantal minuten: er moeten tenslotte tientallen gigabytes aan ram-cache worden verwerkt. Omdat we MySQL liever niet te vaak platgooien, nemen we de gelegenheid te baat om enkele wijzigingen in grote tabellen aan te brengen en een minor upgrade van de op Artemis draaiende MySQL uit te voeren.

Omdat we tegenwoordig over een read-onlymodus beschikken, kan de site gedurende het onderhoud grotendeels online blijven, al kan er uiteraard niets naar de database geschreven worden. Dat betekent dat je niet kunt reageren of modereren, niet kan inloggen, geen nieuwe topics kan starten, enzovoorts. Zolang de read-onlymodus actief is, wordt bovenaan de pagina een gele waarschuwingsbalk getoond.

De nieuwe machine is een Dell PowerEdge R710, die naar het voorbeeld van Artemis 6 is gemodelleerd. Apollo 6 krijgt een tweetal Xeon X5660-hexacores en 48GB geheugen, en net als zijn primaire broertje beschikt hij over een zestal 50GB-ssd's en twee 300GB grote sas-schijven.

Daarmee is Apollo 6 onze vierde machine met solid state drives: naast Artemis 6 zijn ook de zoekmachine en de nieuwe fileserver hiermee uitgerust. De fileserver gebruikt de flashdisks overigens alleen als cache en voor logs, in aanvulling op een array van normale sata-disks.

	Artemis 6 (24-10-2009)	Apollo 6
Processors	2x Xeon X5570 2,93GHz	2x Xeon X5660 2,80GHz
Geheugen	72GB DDR3-800	48GB DDR3-1333
Raid-controller	Dell Perc 6/i	Dell Perc H700
Opslag	2x Seagate Savvio 10K.3 300GB 6x Dell / Samsung MCCOE50G5MPQ 50GB	2x Seagate Savvio 10K.3 300GB 6x Dell / Samsung MCB4E50G5MXP 50GB

De oplettende lezer zal zien dat de nieuwe Apollo toch behoorlijk wat reken- en i/o-capaciteit heeft. Voor het maken van de eerder genoemde consistente backups heeft Apollo nog wel wat spierballen nodig, maar wat MySQL betreft blijft het daarbij. Artemis heeft het normaliter niet heel erg druk, waardoor het weinig zin heeft om het MySQL-leeswerk over beide machines te verdelen.

Wel hadden we al langer de wens om de sessies en de voorkeuren van gebruikers flexibeler op te slaan, zodat een gebruiker zijn instellingen zowel per sessie als voor al zijn sessies kan opslaan. Ook zou het prettig zijn als we de database niet elke keer hoeven te verbouwen als we een instelling willen toevoegen.

De starre MySQL-tabelstructuur die we nu gebruiken, sluit niet aan bij die wensen. We stonden daardoor voor de keus om een flexibelere MySQL-database te bouwen of om alternatieve databases te bekijken.

Aangezien de flexibele variant in MySQL zou betekenen dat we extra queries moesten introduceren en de overzichtelijkheid van de code zou afnemen, hebben we een inventarisatie van NoSQL-databases gemaakt. Daarvoor hadden we een aantal eisen geformuleerd.

• We hebben geen zin of tijd om het beheerwerk zelf te schrijven. Cassandra en Hadoop vielen daardoor af.
• We willen de instellingen per gebruiker logisch gegroepeerd houden, zonder concessies te doen aan het aantal en het type van de instellingen. Hierdoor viel een hoop software af, waaronder MemcacheDB en Tokyo Cabinet, en bleven vooral document databases over.
• We willen niet verplicht zijn om meer hardware toe te voegen als er meer data dan ram is - dus moesten we Redis en Terrastore schrappen.
• Query's als 'geef de instellingen behorende bij sessie X', 'geef alle sessies voor gebruiker Y' en 'hoeveel sessies zijn er voor Firefox-gebruikers' moeten efficiënt en snel worden uitgevoerd. De mapreduce-only document databases, zoals bijvoorbeeld CouchDB en Riak, waren daarom ongeschikt.
• We slaan slechts een paar gigabyte aan data op, dus rauwe performance is voor ons belangrijker dan uitgebreide schaalbaarheid.
• Aangezien we met PHP werken, moet daar eenvoudig mee gecommuniceerd kunnen worden.

Uiteindelijk is de keus gevallen op MongoDB. Apollo 6 gaat, naast MySQL-replicatie, dus MongoDB draaien om de flexibele opslag van voorkeuren te faciliteren. Als Apollo 6 onverhoopt uitvalt, zou deze constructie wel betekenen dat bezoekers niets meer mogen doen, ook niet als de primaire MySQL-server nog wel goed werkt. Daarom hebben we Artemis 6 zo ingericht dat hij de MongoDB-backupserver wordt. Kortom: Apollo is de backup voor de MySQL-database en in ruil daarvoor is Artemis de backup voor de MongoDB.

Ook deze wijziging gaan we woensdagochtend doorvoeren. Als het goed is merken jullie daar in eerste instantie niets van: we implementeren de infrastructuur, maar niet de toepassingen. Het is dus niet zo dat er ineens allerlei nieuwe instellingen beschikbaar komen - dat komt allemaal later wel

Aangezien we ondertussen een behoorlijk complexe variant op LAMP hebben opgebouwd, zie je hierboven een overzicht van wat we ondertussen aan logische onderdelen hebben. De twee rode blokken representeren respectievelijk Artemis 6 en de nieuwe Apollo. Verder zie je de memcached- en ActiveMQ-services en de diverse web- en applicatieservers die we naast Apache geïntroduceerd hebben. Deze laatste zijn gegroepeerd in het bruine blok en deze groep is op vier identiek ingerichte webservers geinstalleerd. Uiteraard geven de lijntjes aan hoe de communicatie ongeveer loopt.

Update, 12:32: ondertussen zijn de werkzaamheden achter de rug: de upgrade is om 11:30 voltooid. Ondanks een paar kleine tegenslagen verliep een en ander volgens schema. Het voornaamste probleem was wel dat de MySQL-replicatie door Artemis 5 een grote achterstand had opgebouwd, waardoor de data op deze server onbruikbaar was. Omdat de data op Apollo 6 nu volledig consistent met de primaire databaseserver is, zou dat probleem een volgende keer niet meer mogen optreden.

Reacties (114)

[GlowMouse]

Het stoppen en starten van onze MySQL-server duurt een aantal minuten: er moeten tenslotte tientallen gigabytes aan ram-cache worden verwerkt.

Voor de volgende keer: http://www.mysqlperforman...se-innodb-shutdown-times/

[PolarBear]

Hoezo moet er RAM cache worden verwerkt? Transacties zijn al weggeschreven mag ik toch hopen?

[GlowMouse]

De data zelf wordt niet weggeschreven, dat zou teveel performance kosten omdat je dan bij elke wijziging 16 kB of meer mag wegschrijven op een random plek . Als je wat aanpast, dan gebeurt dat primair in het geheugen. Zo kan een page van 16 kB meerdere keren aangepast worden zonder dat hij elke keer wordt weggeschreven. Zijn er teveel dirty pages in het geheugen, dan worden er een paar weggeschreven, bij voorkeur in aaneengesloten stukken. Om te voorkomen dat wijzigingen verloren gaan, is er een redo-log. Die redo-log wordt sequentieel beschreven.

[PolarBear]

Ik ken MySQL niet, maar het lijkt me toch dat alle transacties in een write-ahead log heeft. Een transactie wordt en sequentieel naar het transactielog geschreven en naar de in RAM page. Vanuit daar wordt het asynchroon naar disk geschreven. Zo werken MS SQL en Oracle as far as I know. Als je de stekker er uit trekt heb je hooguit verlies van de transacties die nog niet naar het transactielog geschreven zijn.

Dus waar er gigabytes aan ram cache moet worden verwerkt is mij echt nog steeds een raadsel.

[GlowMouse]

MySQL doet hetzelfde (InnoDB althans), alleen dat asynchroon naar disk schrijven gebeurt niet zo snel. Tot wel 90% van het gebruikte geheugen wordt gebruikt om aangepaste maar nog niet weggeschreven pages te bewaren. Hoe vaker je een page kunt beschrijven zonder hem naar disk te schrijven, hoe groter de winst. En bij een shutdown moeten die nog wel worden weggeschreven als je bij de volgende start niet al die logfiles wilt doorlopen, wat in de regel meer tijd in beslag neemt.

[Reactie gewijzigd door GlowMouse op 23 juli 2024 01:31]

[Jeroen]

Nee? Het idee van cache is dat dingen sneller gaan door ze voorlopig in RAM te houden. Op het moment dat je het gaat afsluiten moet je dus wel zorgen dat alles wat nog in RAM staat weggeschreven wordt. Als alles al weggeschreven zou zijn dan zou er geen cache zijn.

[moto-moi]

(If the server is being actively used, it won't get to zero.)

En zo erg is ff wachten nou ook weer niet, het duurt alleen even, that's all. Het is tenslotte maar 60 gig ofzo die 'ie ff moet verwerken

[Jeroen]

Once it's pretty low, you can perform the shutdown and there'll be a lot less unfinished work to do

[bitflusher]

en na deze upgrade?

krijgt Athena een nieuw jasje? die lijkt het nu het drukst van alle servers te hebben (50% cpu) http://tweakers.net/stats/?Action=Serverstats


iig veel sucess morgen

[ACM]

We vervangen servers in principe gewoon onafhankelijk van elkaar en na een vaste periode. Daar wijken we doorgaans wel wat van af als de betreffende taak bijvoorbeeld gevirtualiseerd kan worden of niet enorm belangrijk is of als bijvoorbeeld een nieuwe architectuur (zoals de Intel X5500- en later de X5600-cpu's) net aangekondigd is maar nog niet beschikbaar is gekomen.
Ook kan het zijn dat we investeringen naar voren halen doordat bijvoorbeeld een eerdere keuze niet goed werkt (zoals de iscsi-storage) en dan kan het zijn dat wat husselen met investeringsmomenten handiger is dan proberen het management te overtuigen dat we tussendoor even een paar duizend euro extra nodig hebben

Wees gerust, elke oude server, inclusief athena, staat in principe gewoon op het programma om tzt vervangen te worden. Athena's load is overigens bij vlagen (zie load-grafiek hier: http://tweakers.net/stats...n=PerServer&Server=Athena ) en het maken van backups is nou eenmaal gewoon vrij veel werk (door de compressie van data) met als gevolg dat het weinig zin heeft het systeem te vervangen omdat ie 'op 50% zit'. Het is juist de bedoeling dat die cpu's zoveel mogelijk tijd aan het comprimeren besteden Wel is het zo dat de grootte van de databases waar we backups van maken groeien, en dus ook de tijd die Athena er aan besteedt.
Gelukkig hebben we volgende week een veel snellere machine ('Artemis 5') over, dus die kan nog een paar maanden dat werk op zich nemen terwijl we de vervanging meer permanent regelen

[Reactie gewijzigd door ACM op 23 juli 2024 01:31]

[RobbyTown]

Leuke tekening.

Een kleine vraag. Waarom worden de werkzaamheden nooit in de nacht verricht, hebben de meeste mensen er toch het minste last van ?

[Rob Coops]

Ooit wel eens changes in de nacht gedaan?

Goed als jij zo als de meeste mensen een normale kantoor ban hebt dan is je lichaam gewent aan het slapen van af een uur of 23:00 tot ongeveer 07:00 als jouw werkgever dan besluit dat het een goed idee is om van 23:00 tot 07:00 even een redelijk complexe en risicovolle operatie uit te gaan voeren dan kun je daar vast wel extra voor betaald krijgen en zo maar je lichaam is niet minder gewend aan slapen rond die tijd en dus is je concentratie een heleboel minder.

Ik heb dat soort dingen zelf mogen doen en geloof me het is echt heel erg veel moeilijker om s'nachts je concentratie er bij te houden dan om dat overdag te doen. Daar naast komt er ook nog eens bij kijken dat ondersteuning van andere partijen zo als hier boven al genoemd heel erg veel makkelijker te regelen is overdag dan midden in de nacht. Ook al moet ik wel zeggen dat de radio midden in de nacht vaak leuker is om naar te luisteren dan overdag maar dat komt voornamelijk omdat er dan iet wat meer volwassen onderwerpen voorbij komen.


Wat ik niet helemaal begrijp is dat de twee machines niet gewoon gelijk zijn. Als de primaire database server met 72GB draait waarom de failover server dan niet? Als je nu een failure hebt op de primaire server dan zijn alle gebruikers gelijk de dupe van een veel minder ruim bemeten failover server, als de de failover al lukt omdat er gedurende de jaren natuurlijk het een en ander zal groeien en het nu nog ruim bemeten geheugen op de primaire server wel eens krap kon zijn over een jaar of 2 a 3 op het moment dat de server wat ouder is en sneller zal falen dan op het moment dat het ding net aan een jaartje aan staat.
Ik kan zo een tiental problemen bedenken waar ik de afgelopen paar jaar mee te maken gehad heb waar dit soort ongelijkheden na een paar jaar tot grote problemen hebben geleid op het moment dat de primaire server voor het eerst na lange tijd faalde...
Ik hoop dan ook dat jullie ook een (minimaal) jaarlijkse failover test hebben gepland niet omdat het nu niet werkt maar wel om de procedures scherp te houden en zo wel mensen als machines te testen op het moment dat dit soort procedures uitgevoerd moeten worden. Want als Jantje ziek is en Kees op vakantie dan klapt die doos er natuurlijk uit en dan is het op eens aan de stagiaire en de voormalig koffie dame om de failover te begeleiden en dat kon nog wel eens vies tegen vallen omdat Kees bepaalde punten niet heeft opgeschreven want dat weet toch iedereen en Jan natuurlijk ook niet wist dat na de laatste change iedereen vergeten was die ene versie van die andere lib te updaten en dus het hele ding nooit kan werken...

Het klinkt vast gek maar het kan helemaal geen kwaad om zo af en toe gewoon de stekker er eens uit te trekken en te kijken hoe men reageert zeker als men nog redelijk nieuw is kan de opwinding van een echte outage en nu komt alles op jouw neer wel eens te veel zijn voor ze om zich op de werkelijke problemen te concentreren, en dat soort dingen kun je beter oefenen als het een gecontroleerde situatie is dan wanneer er echt stront aan de knikker is.

[ACM]

Basically is de keus uit 12x betaalbare modules die op 1333Mhz draaien of 18x en dan 800Mhz. Dus wat je wint aan extra ram verlies je deels weer aan snelheid ervan.
Bovendien is de huidige master behoorlijk overgedimensioneerd, waardoor we niet verwachten tijdens een uitval ervan om performance verlegen te zitten met de failover-machine.

Overigens zijn de SSD's van de slave ook een generatie nieuwer (en dus sneller) met als gevolg dat een cache-miss relatief gezien goedkoper is. Naast dus het feit dat een cache-hit ook sneller is.

Failover (iig de automatische readonly-modus) hoeven we niet te testen, dat komt weliswaar sporadisch, maar vaak genoeg voor om daar niet een vaste test voor in te richten. Daarna is het overstappen naar de slave een kwestie van de master helemaal uitzetten en de configuraties aanpassen dat ze de slave als master behandelen... Niet iets wat een hoop werk is. Desalniettemin is het, zeker bij meer complexe opstellingen, inderdaad verstandig af en toe te testen of je nog weet hoe het moet

[humbug]

Dat snap ik niet. mySQL ondersteund gewoon automatische failover. Ook het gebruik van configuraties met een read/write server aangevuld met read only servers waarbij de readonly servers een deel van de leesopdrachten van de master overnemen is niet ongebruikelijk. In die situatie krijg je ook automatisch een read only systeem als de master uitvalt. Waarom is daar niet voor gekozen ipv dat iemand 's nachts uit zijn bed moet worden gebeld om een configuratiescriptje te draaien bij een probleem?

[ACM]

't Verbinden met een andere databaseserver is iets dat de driver moet doen. Php's standaard mysql-driver doet dat niet vanzelf, maar de readonly mode, die in deze aankondiging genoemd wordt, doet juist wat jij denkt dat we niet doen.

De reads verspreiden over de master en slave vinden we niet erg zinvol, de master heeft het daar lang niet druk genoeg voor en dan zorgt het er alleen maar voor dat je moeilijk moet doen met kijken of je stiekem toch een writable-connectie nodig hebt.
En dat op alle plekken in de, vaak relatief oude, code goed te verwerken is gewoon domweg de moeite niet waard. Nog afgezien van het feit dat het dus niet nodig is vooralsnog.

[AtleX]

Ja, maar de ervaring leert dan mensen 's nachts een stuk minder scherp zijn. Er worden fouten gemaakt, het werk duurt langer en erger nog: Als het klaar is gaat iedereen zijn bed in. Mocht het dan nog een keer fout gaan heb je een probleem, want ieder relevant persoon ligt dan op 1 oor. Dan beter 's ochtends aangekondigd down gaan. Iedereen is dan lekker fris en als het uitloopt of fout gaat na het weer online brengen is er geen probleem qua beschikbare mankracht.

[himlims_]

zou dat niet andersom zijn? bijna iedere ITér die ik ken werkt liefste snachts.

[tormentor1985]

Ik lig liever op 1 oor in de nacht en werk gewoon doordeweeks. Onderhoud doe je (dubbel betaald) in het weekend als iedereen thuis zit.

Verder mooie ontwikkeling. Leuk om te zien hoe tweakers blijft groeien. Van home made servers naar krachtpatsers waar ik alleen maar van kan dromen

Keep up the good work!

[YopY]

zou dat niet andersom zijn? bijna iedere ITér die ik ken werkt liefste snachts.

Hoeveel ITers ken je dan? ik ken er geeneen. Allemaal dagmensen die ik ken.

[Garma]

tsja, je kan dan misschien beter zaterdag- of zondagochtend pakken?

[HoD85]

Voor gewone bedrijven wel, maar ik neem aan dat Tweakers meer bekeken wordt op zaterdag en zondag.

[VVVJeroen]

Waarschijnlijk omdat ze zelf ook willen slapen en om deze tijden bijvoorbeeld ook helpdesken bereikbaar zijn: als er iets mis is lijkt me dat ze zo Dell kunnen bellen die een mannetje paraat hebben, waardoor problemen makkelijker opgelost kunnen worden (en als je fit bent zul je ook minder snel fouten maken lijkt me).

[moto-moi]

Dell mag ik 24/7 bellen hoor, en dan moeten ze binnen 4 uur een oplossing verzinnen. Feit is gewoon dat je 's nachts minder scherp bent, dus vandaar dat we liever overdags aan de servers klussen

[Craven]

Just admit it je wil er je nachtrust niet voor opgeven

Hebben jullie overigens misschien uitgebreidere documentatie over bovenstaande dingen? Ben wel geinteresseerd in dit soort spul. Snap de tekening namelijk wel maar ik vind hem niet echt logisch (wat waarschijnlijk komt door mijn gebrek aan kennis maar toch... ).

[Damic]

Ik vind de tekening ook niet logisch.

je hebt 4 verbindingen naa de prim mysql+sec mongo liggen, maar maar 2 naar de sec mysql en prim mongo. Denk dat je 2 servers vergeten bent nl.: die met die cd bij en de ActiveMQ messaging server

[Craven]

Begin er zelf langzaam wat meer logica in te zien. Maar de lijntjes zijn geen verbindingen, het gaat hier om de logische componenten binnen de verschillende servers.

Snap alleen het hele idee van die loadbalancer niet echt... hij load balanced naar verschillende onderdelen binnen de apache server? Dus tussen de apache server die de php serveert, de lighttpd server die videos streamt en de proxy (die ik niet weet wat hij doet)?

Die apache server die trekt vervolgens gecachede info bij memcached weg. Bestanden van de fileserver en "apps van de tomcat server" (al zie ik dat niet helemaal voor me). En achter de apache server hangen straks dus ook 2 db server met mysql en mongodb.

Maar wat doet die activemq messaging? met alleen een verbinding richting artemis 6? Ik snap sowieso niet helemaal wat het is (vergelijkbaar met msmq onder windows ofzo?). En waarom heeft hij geen verbinding met de apollo 6 straks?

Zooow dat lijken me wel weer genoeg vragen

[ripexx]

Ach dat valt toch reuze mee, als ik deze plaat lees;

Loadbalancer zal iets doen zodat je zowel apache als lighttp kan draaien, de varnish proxy zal waarschijnlijk voor apache draaien.

Apache draait vooral php en betrekt & deelt via verschillende bronnen informatie, oa.

• Fileserver
• Memchache:
• Database (mysql)
• MongoDB
• Java App Server
• ActiveMQ

Ik verwacht dat de MQ wordt gebruikt voor delayed inserts, zoals topic counters, stats etc, die heb je niet direct nodig en een DB insert is relatief duur in tegenstelling tot een fire and foreget MQ bericht. Maar als je main server tijdelijk eruit ligt, dan wordt de queue gewoon groter, en als je echt een failure hebt knoop je MQ gewoon aan de andere DB.

Daarnaast zal die Java app server gewoon via http informatie beschikbaar stellen, ACM heeft daar een heel plan voor geschreven (plan: Tweakers.net introduceert snellere Pricewatch-engine) Enige wat een beetje inconsequent is dat de JavaApp server niet connect naar de failover DB Server.

Maar deze opzet is inmiddels redelijke gemeengoed, vooral bij wat grotere enterprise oplossingen zie je dit soort hybride oplossingen steeds meer. Het beheer wordt wel complexer, maar gezien de reacties en onderbouwing heb ik wel het idee dat men er goed over na heeft gedacht.

[Craven]

Ahh dus de tomcat serveert java meuk en de activemq is een soort van buffer tussen de db en apache. Duidelijk. Maar waarvoor zorgt die proxy dan? apache kan toch ook gewoon direct naar de loadbalancer?

[ACM]

Klopt, de Apaches kunnen inderdaad direct met de loadbalancers communiceren. En dat doen ze ook
Alleen de resources op 'tweakimg.net' gaan via Lighttpd en 'ic.tweakimg.net' via Varnish. Het leek ons niet heel zinvol om processingtijd, en dus latency, te verspillen aan Varnish als we van bepaalde requests toch zeker weten dat ze nooit gecached gaan worden. Dat is dus zo'n beetje alles wat je nog vanaf 'tweakers.net' krijgt.
Varnish haalt overigens wel zijn data weer uit Apache, vooral omdat sommige afbeeldingen in potentie eerst gegenereerd moeten worden (zoals de prijsgrafiekjes bij producten), maar met een cachehitratio ergens in de buurt van de 99% zijn dat er relatief weinig.
In de praktijk is het dus vooral de php-request (en dus de html die je terug krijgt) en de Ajax-requests die gedaan worden ivm de diverse dynamische onderdelen van de site wat nog bij Apache terecht komt. De rest gaat via Lighttpd voor de vaste layout-componenten en via Varnish voor de semi-dynamische content-afbeeldingen.

ripexx had het dus bijna helemaal goed

Dat de tomcat-engine's nog niet met de readonly database kunnen verbinden is een stukje achterstallige configuratie. Die kunnen dmv de jdbc-driver natuurlijk ook vrij eenvoudig (readonly) met de slave-database verbinden en dat gaat ook vandaag nog zo ingesteld worden
[edit]
En ondertussen is dat aangepast.

[Reactie gewijzigd door ACM op 23 juli 2024 01:31]

[ripexx]

Lees de plans maar eens door waarna ACM linkt (plan: Content-afbeeldingen voortaan via ic.tweakimg.net)

[HyperBart]

Alhoewel ze er niet zo uit zien, zijn de admins hier ook maar mensen...

Die hebben ook graag hun slaap, en aangezien dat de site nog bereikbaar blijkt (weliswaar read-only) is de downtime imho niet ZO ingrijpend...

[Reactie gewijzigd door HyperBart op 23 juli 2024 01:31]

[CH4OS]

Een kleine vraag. Waarom worden de werkzaamheden nooit in de nacht verricht, hebben de meeste mensen er toch het minste last van ?

Een vraag die elke keer terugkomt en hetzelfde antwoord krijgt:

De kans op fouten is het kleinst, ook kun je via leveranciers dan het snelste support krijgen. En dan nog: jij werkt toch ook niet 's nachts of wel dan?

[jip_86]

Die discussie is al meerdere keren gevoerd bij downtimes. Hierboven staan al wat redenen daarvoor.

[voodooless]

Ik ben benieuwd naar de ervaringen van MongoDB. Ik heb net even zitten kijken naar de Java client, maar dat ziet er niet echt heel erg geweldig uit. Ze missen een behoorlijke stuk goede OR mapping, en doen alles nog met Maps. Dat is eigenlijk wel erg jammer. Er zijn zo te zien wel wat 3rd party tools die het wel kunnen. Eens kijken./


Edit... ondertussen gedaan: conclusie: 't suckt voor onze toepassing. diskspace verbruik is factor 4 hoger t.o.v Postgresql (resultaat is een database van meerdere TB's i.p.v honderden GB's)), en het ophalen van veel records is in verhouding tot Postgresql hierdoor ook trager.

Bepaalde queries zijn/lijken dan wel weer heel snel, en je kunt er vast heel erg leuke dingen mee doen als je de juiste toepassingen bedenkt

[Reactie gewijzigd door voodooless op 23 juli 2024 01:31]

[AndrewF]

Go Mongo!
MongoDB is echt fantastisch. Zeker voor webapps.
Het is wel een aanpassing om het typische relationele denken weg te laten en in documenten te denken.

vb: traditioneel heb je een object "artikel" met "comments" die elk van een "user" zijn. In een genormaliseerde SQL db zou je daar 3 tabellen voor gebruiken en met een join query'en. In een document store zou je één "artikel" document hebben met embedded "comment" documenten. En waarschijnlijk zou je de naam van de "user" bij elke commentaar opslaan (de-normalised). Zo kan je met 1 query alles ophalen.

[ACM]

Wij willen er buckets met data in opslaan, waarbij elke bucket dus een stelletje key-value paren heeft. En daarvoor is het communiceren met JSON uiteraard zeer geschikt, wat met de native-client in PHP dan ook nog eens transparant gebeurd. Ik kan me voorstellen dat je dat voor Java wat minder handig vindt (hoewel je daar effectief ook gewoon met een collection of maps zal werken?)

[wallyberk]

Dit komt omdat MongoDB een "Document store" database is, hierdoor is er altijd een vertaling ( maping) nodig. Ik denk je beter naar een object georiënteerde db kan kijken. Zie http://nosql-database.org/ en scroll naar beneden. Waarom zou je immers vertalen (mappen) als niet hoeft.

Tevens, ik dacht dat OR stond voor Object-relational ( http://en.wikipedia.org/wiki/Object-relational_mapping ) en relationeel is nou juist wat ze niet willen. zie hiervoor de definitie op http://nosql-database.org/ .

<off topic>
Overigens ben ik het niet eens de definitie, omdat ik geen reden zou kunnen bedenken waarom je in een NoSQL database geen relaties zou mogen leggen. Overigens bedoel ik hier niet mee, dat dit niet onverstandig is. Een papegaai kan je laten kakelen als een kip, maar misschien is dat niet het verstandigst omdat ze veel meer kan. Zie http://www.xaprb.com/blog...esnt-mean-non-relational/

Ook het woord NoSQL vind ongelukkig om er niet van hou als de definitie wordt afgeleid van iets wat het niet is. Gelukkig ben hier niet de enige in: http://www.thevirtualcirc.../sql-or-nosql-you-choose/ . Immers gaan we straks blogs definiëren als NoMessageboard?
</off topic>

edit: url toegevoegd.

[Reactie gewijzigd door wallyberk op 23 juli 2024 01:31]

[NFaZe]

Met wat voor programma hebben jullie die conceptuele weergave gemaakt?

[ACM]

Dat is met Inkscape gemaakt en daar dan diverse vrij te gebruiken server-plaatjes/templates voor. Vond het er wel aardig uitzien, andere tools hebben vaak lelijke/ouderwetse plaatjes voor servers.

[ThomasG]

Ik weet het niet zeker, maar volgens mij is het Draw uit OpenOffice.org.

[grobbel]

"Als het goed is merken jullie daar in eerste instantie niets van: we implementeren de infrastructuur, maar niet de toepassingen"

hmm, lees ik daar nu 'data opslaan om er wellicht later iets mee te doen'? goegle voorbeeld doet goegle volgen zeg maar :-)

[ACM]

Nee. We leggen de basis ermee om veel dynamischer instellingen van gebruikers (zoals de tracker-layout of de customized frontpage) vast te kunnen leggen. Ook verwachten we daarmee instellingen zowel aan je account als per sessie instelbaar te kunnen maken en is het de bedoeling dat we bepaalde zaken die we nu via cookies bijhouden, dan ook makkelijker aan ofwel je sessie ofwel je account kunnen koppelen (of zelfs je de keus bieden).

Maar al dat is dus toekomstpraat, enkel de faciliteit om dat uitgebreider en flexibeler op te slaan komt nu

[jpm.lensen]

Ik kreeg alleen op een gegeven moment een melding, dat tweakers down was.
Terwijl ik dacht, dat hij read only zou zijn, maar dus wel beschikbaar?

Maar maakt niet zoveel uit, hij is BacK.

[crisp]

Tijdens het migreren van de sessies en de bijbehorende code zijn we inderdaad eventjes helemaal down gegaan zodat we zelf eerst even alles konden verifieren

[r3solution]

Zo, jullie waren even moeilijk te bereiken.
Wat is er gebeurd??

[Toettoetdaan]

hier ook, even kijken bij de load grafiekjes

EDIT: de stats pagina laat duidelijk een deukje zien, maar zo te zien niks ernstigs
(of Tnet was er echt heeeeeeeeeeeel snel bij)

http://tweakers.net/stats

[Reactie gewijzigd door Toettoetdaan op 23 juli 2024 01:31]

[Kees]

Memcached ging even uit voor een upgrade, en dat zorgde voor een stortvloed aan nieuwe connecties op de dbserver, waarbij al die connecties ook nog eens op dezelfde db server wilden melden dat het allemaal fout ging. Het is nu opgelost, en het komt een volgende keer niet weer voor.

[Fid3lity]

Is dan toch wel leuk om te zien dat Tweakers.net, met hun mooie, uitgebreide BBG discussie topic's dan een DELL machine aanschaffen

[moto-moi]

ik zou niet graag zut uit de BBG in de colo willen hebben. Sowieso mis je dan support en 4U grafbakken til ik persoonlijk liever uit een rack dan erin

[zeef]

7U grafbakken, daar weten we wel raad mee....

[Reactie gewijzigd door zeef op 23 juli 2024 01:31]

[moto-moi]

dat was een 7U machine

[Verwijderd]

Beknopt m'n ervaringen:
- werken onberispelijk
- zeer degelijk gebouwd
- wel gezeur met trays voor harde schijven die standaard niet worden meegeleverd voor de sleuven die je niet bezet hebt. Is gedoe met uitbreiden omdat je alleen via Dell kunt bestellen.
- Linux support is er wel, maar is niet bepaald inzichtelijk.


Laatst een RAM module kapot. Dat wist de machine mij op afstand nog keurig mee te delen. En dat scheelt een enorme hoop gedoe, als je meteen met het juiste reepje naar het datacentrum kunt rijden.

[El Snorro]

Mee eens.
Heb hier een Equallogic PS4000 hangen. Laatst schijf van kapot, case aangemaakt. Binnen 1,5u stond er een koerier voor de deur met een vervangend exemplaar
Echter betaal je bij zo'n SAN ook wel een groot deel voor dit soort support natuurlijk.

[robvanwijk]

dan een DELL machine aanschaffen

In plaats van zelf een machine samenstelling uit onderdelen (zoals "vroegâh")? Of bedoelde je dat jij een ander merk aan zou raden??
Nou ja, de configuraties die in de BBGs langskomen zullen niet een van de grootste websites van Nederland en België (met het veeleisendste en kieskeurigste publiek? ) hoeven draaien. Apollo 6 moet dat wel gaan doen, dus is het belangrijk om downtime tot het absolute minimum te beperken. Een servicecontract bij DELL kan daarbij prima helpen en tja, die contracten kun je niet afsluiten op een bak die je zelf gebouwd hebt.

[EvilWhiteDragon]

Probeer jij maar eens een 1u 19" rackmount te kopen/bouwen die goedkoper is en vergelijkbaar is aan een Dell R210. Zo goed als onmogelijk volgens mij. Dat plus dat dell 1 jaar garantie geeft op het geheel, zorgt er voor dat Dell toch niet heel duur meer is.

[Relief2009]

Volgens mij is Dell op de servermarkt gewoonweg heel goed

[moto-moi]

Dell business support is erg goed hoor, vaak genoeg gebruik van moeten maken.

[PetervdM]

uhhh, als ik support NODIG heb, is het dus niet goed.
hebben hier 10 dell's R9xx, 25+ HP DL380Gx, drie maal raden waar we meer storing aan hebben...

[InZane]

Mijn ervaring zijn tot nu toe anders heel positief. Oke, heb in het verleden heus weleens problemen gehad, maar dat is toch al behoorlijk lang terug.

We hebben sinds een paar maanden een stel R610's draaien (1U) en die zitten echt goed in mekaar vind ik en ze doen precies wat ze moeten doen.

[BD1]

Volgens mij heb ik enkele dagen geleden ook al eens een gele balk gezien waarin stond dat de site alleen read-only beschikbaar was...

[Petervanakelyen]

Ja, inderdaad. Maar was ontzettend snel weer weg, eigenlijk.

[Kees]

Ja, ik had perongeluk de netwerk interface van de db server uitgezet, maar binnen een minuut heb ik dat weer via de kvm kunnen verhelpen. Was wel even een oops momentje: Oops, verkeerde interface down gegooit

[Roytoch]

Haha zo zie je maar weer: al heb je zoveel apparatuur staan, oepmomentjes blijven moeilijk uit te bannen die readonly modus klapt er dan automatisch in dan? Dat werkt wel vrij goed dan...

[Carpento]

Ik ook, dat is waarschijnlijk een momentje geweest dat de database-verbinding even weg was

(Of ze waren de melding aan het testen natuurlijk )