[Bug?] Reactie 's nachts niet te wijzigen

[Verwijderd]

Dit heb ik nu al twee keer meegemaakt, en ik vroeg me af of het aan got/t.net ligt of aan de server bij mijn provider (@home):

Rond de nacht (3-4 uur) heb ik nu dus al twee keer meegemaakt dat heel GoT en t.net opzich prima werken, en ik kan zelfs op "edit" klikken bij mn berichten...maar de wijzigingen versturen, ho maar. Ik krijg na een tijdje een time-out (wit scherm in firefox) op http://gathering.tweakers.net/forum/ .

WinXP Home, Firefox 1.5.0.8.

Iemand enig idee?

[Satch]

Volgens mij worden er s'nachts iets van backups gemaakt rond dat tijdstip. Kan zijn dat het dan even niet mogelijk is om te posten.

[Verwijderd]

Daar dacht ik ook al aan ja...maar geef dan een melding oid . Niet een time out.

[JohnB]

Ook mee te maken gehad. Vannacht weer. Error dubbelpost of kon server niet vinden.

[Spider.007]

Ik zou het forum gewoon in maintenance zetten tijdens de backup; of duurt het daar te lang voor?

[APClll]

Is het niet iets om tijdens die backup andere banners te draaien, met als tekst "het forum is wegens backup tijdelijk read-only" of zo iets?

[mithras]

APClll schreef op zondag 03 december 2006 @ 15:02:
Is het niet iets om tijdens die backup andere banners te draaien, met als tekst "het forum is wegens backup tijdelijk read-only" of zo iets?

Maak er dan een mededeling van (zoals ook met je voorkeur opgeven tijdens de merge als je dat nog niet gedaan had).

Verder lijkt me het geven van zo'n mededeling wel een goed idee ja

[PromWarMachine]

Klopt, heb ik ook last van. Heel vreemd. Het leek net alsof de POST gewoon hing. Tamelijk irritant.

[Verwijderd]

Andere banners draaien lijkt me niet zo'n goed idee, geef gewoon een Error message bij het klikken op de "post" of "edit" knop tijdens het draaien van een backup. Lijkt me even veel moeite, en is gelijk een stuk duidelijker!

Want niet iedereen ziet banners (of ze worden geblokkeerd, of mensen met een betaald pakket hebben ze uit staan).

[ Voor 16% gewijzigd door Verwijderd op 03-12-2006 16:05 ]

[Dersan]

Ik dacht al slapen tweakers 's nachts?

[Verwijderd]

Late dienst hè . Terug om 24:00, en dan krijg ik pas weer slaap rond 3:30.

[crisp]

Spider.007 schreef op zondag 03 december 2006 @ 14:20:
Ik zou het forum gewoon in maintenance zetten tijdens de backup; of duurt het daar te lang voor?

Anderhalf uur ongeveer...

[BasieP]

crisp schreef op zondag 03 december 2006 @ 16:26:
[...]

Anderhalf uur ongeveer...

laten we het forum anderhalf uur per dag uitschakelen!

nee liever aan laten staan en gewoon wat moeite hebben met posten .. dan nog maar eens proberen hoor..

trouwens: kan priority van die backups niet wat naar beneden?

[Verwijderd]

Het forum hoeft toch ook niet uit? Lezen gaat nog prima, maar posten niet . Dus enkel die pagina's uit tijdens een backup lijkt mij een prima oplossing.

[ACM]

Spider.007 schreef op zondag 03 december 2006 @ 14:20:
Ik zou het forum gewoon in maintenance zetten tijdens de backup; of duurt het daar te lang voor?

Hoezo zouden we dat nou weer moeten doen? Het forum hoort gewoon lees- en schrijfbaar te zijn. We hebben niet voor niets een transactionele database!

[mithras]

ACM schreef op zondag 03 december 2006 @ 17:10:
[...]

Hoezo zouden we dat nou weer moeten doen? Het forum hoort gewoon lees- en schrijfbaar te zijn. We hebben niet voor niets een transactionele database!

Maar het blijkt dus uit ervaring dat de database een beetje moeite ermee heeft wanneer users gaan posten tijdens de backup. Een korte mededeling over dat dit proces gaande is lijkt me dan netjes.

Het is een kleine moeite en de users weten dat het mogelijk is dat ze, als het posten niet lukt, gewoon even moeten wachten en/of het nog een keer moeten proberen.

[Verwijderd]

Nou, streep dat even wachten/nog een keer proberen ook maar door...dat heb ik dus geprobeert, maar zonder resultaat. Of ik heb niet lang genoeg gewacht, want ik ben uiteindelijk maar gaan slapen .

[ACM]

mithras86 schreef op zondag 03 december 2006 @ 17:21:
Maar het blijkt dus uit ervaring dat de database een beetje moeite ermee heeft wanneer users gaan posten tijdens de backup. Een korte mededeling over dat dit proces gaande is lijkt me dan netjes.

Ben ik niet met je eens. De site hoort gewoon te werken tijdens het maken van backups, dus daar moeten we onze aandacht aan besteden. Niet aan een of andere message die eigenlijk niet met enige zekerheid kan stellen dat we daadwerkelijk met de backup te maken hebben tonen.

[ACM]

Even voor mijn beeldvorming trouwens:

Hebben we het nu over de periode 3:00u t/m 4:00u of juist over 4:00u t/m 5:00u ?

[Verwijderd]

Ik persoonlijk heb het 2 maal meegemaakt tussen 3 en 4 uur.
Kan ook wat eerder (2:30 bijv.) zijn geweest, maar zeker niet later.

Maar inderdaad, het kan ook een geheel andere oorzaak hebben die toevallig tijdens het draaien van de backup ook in werking treed...want backups maken en ongeveer tegelijkertijd problemen hebben met posten is natuurlijk geen sluitend bewijs.

[ Voor 85% gewijzigd door Verwijderd op 03-12-2006 18:39 ]

[megamuch]

ik heb het zelf ook een aantal keer gehad maar dan vooral tussen 4 en 5.

[ACM]

De backup van het forum is de afgelopen paar dagen niet voor 4:00u gestart. En volgens mij is dat al maanden zo

De backup van de frontpage draait dan echter wel tussen 2:30u en 4:00u oid. En daar zit natuurlijk de deels gedeelde sessie-tabel bij, maar ik neem aan dat je gewoon al lang ingelogd en niet pas rond die tijd ging inloggen?

[Verwijderd]

Dan heeft het bij mij dus zeker niet aan de backup van de forum database gelegen...

Want ja, ik was de rest van de avond/nacht totaan die time out gewoon ingelogd .

[Spider.007]

ACM schreef op zondag 03 december 2006 @ 17:10:
[...]

Hoezo zouden we dat nou weer moeten doen? Het forum hoort gewoon lees- en schrijfbaar te zijn. We hebben niet voor niets een transactionele database!

Tjah; gezien de reacties in dit topic gaat er dan toch iets mis Maargoed; natuurlijk is het beter om je te richten op het oplossen van het probleem

[MAX3400]

Zie ook: MAX3400 in "Algemeen, Centraal, Uniek en Officieel B..."

Ik heb inderdaad niet alleen last met het originele probleem, dat wijzigingen niet verstuurd worden ofzo, maar vandaag echt veel/vaak last van timeouts. En nee, ik heb geen vage programma's open staan en veel andere sites (zelfs in hetzelfde datacenter en op dezelfde vloer als jullie dbase-server) zijn wel te bereiken.

[Verwijderd]

Het begint meestal iets na 4 uur en duurt tot half 6 of iets daarna.

Wat ik alleen vreemd vind en waar ik gewoon nieuwsgierig naar ben: waarom is sinds enige tijd het forum zo traag/onbereikbaar, terwijl de backups voorheen naar ik aanneem ook gewoon werden uitgevoerd maar dan zonder merkbare vertraging. Wat is er nu anders? En waarom? Voldeed de oude methode niet meer?

[Mentalist]

Ik ervaar hetzelfde als HlpDsK, 4 tot half 6, één keer was het bijna 6 uur en werkte het nog niet.

Als het bruikbare info is: één keer probeerde ik om 4 uur ongeveer te posten, en dat duurde iets langer. Toen maakte ik een edit, dat duurde nóg langer, ik geloof dat ik daarna nog een andere post/wijziging deed die héééél lang duurde maar wel voltooide, en daarna was het gewoon afgelopen. Afgelopen als in, als ik probeerde te posten/wijzigen was het gewoon heel lang wachten, en uiteindelijk een wit scherm (Firefox 1.5), en is er niets aangekomen.

Lezen gaat bij mij overal perfect overigens (wat ik getest heb dan). Topics en mijn history openen is geen probleem om die tijden. Alleen posten of editten is er niet bij.

Ik zal straks ff testen of ik wel mijn preferences aan kan passen rond die tijden, of een DM sturen.

[ Voor 18% gewijzigd door Mentalist op 04-12-2006 03:10 ]

[MAX3400]

Merk trouwens net dat bij een willekeurige CTRL+F5 sommige graphics van GoT ook niet worden ingeladen... Bovenste balk is dan wel mooi rood bij mij, maar FAQ en Search komen niet tevoorschijn.

[Mentalist]

MAX3400 schreef op maandag 04 december 2006 @ 03:20:
Merk trouwens net dat bij een willekeurige CTRL+F5 sommige graphics van GoT ook niet worden ingeladen... Bovenste balk is dan wel mooi rood bij mij, maar FAQ en Search komen niet tevoorschijn.

Dat zijn plaatjes zo te zien. Probably heb je gewoon een brakke router die niet genoeg connecties aankan.

Ik heb er zovaak last van gehad als ik niet achter mijn Freesco doos zat. Linksys doet het hierbij wel beter dan b.v. Netgear, maar het blijft matig allemaal. Kan dus héél goed aan jou liggen.

Normaal gesproken gaat het dan goed omdat die plaatjes uit je cache komen.

[Verwijderd]

De laatste dagen gaat lezen wel meestal goed. Dat was in het begin ook niet .. dan lag de zaak gewoon een kleine 2 uur echt plat. Time-outs. Dus er is al verbetering. Jammer alleen als je net een antwoord op een probleem wilt posten. Ik zit dan namelijk meestal wat techtopics door te bladeren.

OK wat ik zie als ik wil posten. Ik druk op verstuur. Lang wachten. En dan krijg ik de hoofdpagina van het forum voor m'n neus ipv het specifieke topic waar ik was. En daar is dan geen reply bijgekomen wanneer ik ga kijken. Read-only dus qua gedrag. En dan zo rond half 6 ineens .. *poef* .. replies komen weer aan.

en omg dat probeer ik dan te posten om 5:11 terwijl dat dus niet wil

en trouwens nu (5:23) is lezen ook niet mogelijk. wederom time-outs als je probeert het forum te benaderen. af en aan dan wel dan niet. 5:24 wel, 5:25 weer niet

5:28 forum werkt weer

[Mentalist]

5:25 heb ik blijkbaar al een post gezet, maar daar kwam uiteindelijk een wit scherm uit dus ik ging er vanuit dat het niet gepost was. 5:28 alles werkt idd weer.

[Verwijderd]

En dat was een dubbelpost geworden die ik zojuist heb getrashed

[Mentalist]

Daar stond de content dus in, de 2de post om 5:28 had ik zelf al gewijzigd naar "bikkelbikkelbikkel" .

* Mentalist knuffelt forumwide diff rechten intens

[ Voor 18% gewijzigd door Mentalist op 04-12-2006 05:36 ]

[Verwijderd]

[Verwijderd]

Ik vind dit een hele rare gang van zaken..

Een tijdje geleden heb ik hier ook over gemailed maar toen geen reactie gekregen.

Het is al een tijdje zo dat je tussen 4 en 6 bijna niet kunt posten, je ziet het ook duidelijk aan active topics waar dan ineens een gat in zit. Je kan niet editen, niet posten etc, je krijgt dan een time-out en krijgt dan de hoofdpagina weer voor je neus (zoals hier al beschreven).

Ik wou het hier gaan posten maar las toen een ander topic:

[Posts]Komen niet door.

Daarin werd de topic starter nogal lomp afgekapt zo van "Dat is een backup en dat is normaal, doe niet zo dom domme gebruiker". Ik dacht dus dat het aan mij lag en durfte eigenlijk niet nog eens een topic te openen erover.

Nu is er weer een topic over en is ineens normale discussie over het probleem (want dat is het toch zeker) wel mogelijk.

Om het in perspectief te zetten: Als het systeem waarvoor ik verantwoordelijk ben op mijn werk er 2 uur uit zou liggen op een dag en dat meer als 1x per jaar dan zou ik ontslagen worden (uitzonderingen daargelaten).

[ACM]

Verwijderd schreef op maandag 04 december 2006 @ 03:00:
Wat ik alleen vreemd vind en waar ik gewoon nieuwsgierig naar ben: waarom is sinds enige tijd het forum zo traag/onbereikbaar, terwijl de backups voorheen naar ik aanneem ook gewoon werden uitgevoerd maar dan zonder merkbare vertraging.

Enig idee over wat voor 'enige tijd' we het dan hebben? Sinds 6 oktober? Of ver daarvoor/daarna?

Wat is er nu anders? En waarom? Voldeed de oude methode niet meer?

Nou, om te beginnen hebben we een andere databaseserver en daarop ook een andere mysql-versie. Maar of dat het probleem oplevert hangt natuurlijk af van wanneer het probleem begon.

[BtM909]

ACM schreef op zondag 03 december 2006 @ 18:34:
[...]
[...] De site hoort gewoon te werken tijdens het maken van backups, dus daar moeten we onze aandacht aan besteden.[...]

Helemaal mee eens

---

Verwijderd schreef op maandag 04 december 2006 @ 06:18:
Ik vind dit een hele rare gang van zaken..

Een tijdje geleden heb ik hier ook over gemailed maar toen geen reactie gekregen.

Het is al een tijdje zo dat je tussen 4 en 6 bijna niet kunt posten, je ziet het ook duidelijk aan active topics waar dan ineens een gat in zit. Je kan niet editen, niet posten etc, je krijgt dan een time-out en krijgt dan de hoofdpagina weer voor je neus (zoals hier al beschreven).

Ik wou het hier gaan posten maar las toen een ander topic:

[Posts]Komen niet door.

Daarin werd de topic starter nogal lomp afgekapt zo van "Dat is een backup en dat is normaal, doe niet zo dom domme gebruiker". Ik dacht dus dat het aan mij lag en durfte eigenlijk niet nog eens een topic te openen erover.

Nu is er weer een topic over en is ineens normale discussie over het probleem (want dat is het toch zeker) wel mogelijk.

Er wordt helemaal niet zo bot (als jij het stelt) afgekapt... De vraag in de TS is:

Of zijn dit de reguliere backup-cronjobs?

Het antwoord:

dat heet een backup.

Met een plaatje erbij die het fenomeen verklaart

Om het in perspectief te zetten: Als het systeem waarvoor ik verantwoordelijk ben op mijn werk er 2 uur uit zou liggen op een dag en dat meer als 1x per jaar dan zou ik ontslagen worden (uitzonderingen daargelaten).

Je maakt hier ook weer aannames en assumptions are the mother of all....

[MAX3400]

W3ird_N3rd schreef op maandag 04 december 2006 @ 03:33:
[...]

Dat zijn plaatjes zo te zien. Probably heb je gewoon een brakke router die niet genoeg connecties aankan.

Ik heb er zovaak last van gehad als ik niet achter mijn Freesco doos zat. Linksys doet het hierbij wel beter dan b.v. Netgear, maar het blijft matig allemaal. Kan dus héél goed aan jou liggen.

Normaal gesproken gaat het dan goed omdat die plaatjes uit je cache komen.

Dit heeft dus weinig met mijn router te maken; sowieso gezien de reakties van anderen maar ook mijn expliciete opmerking dat ik het probleem ook ervaar op genoemde tijd zonder enige andere connectie.

Ik kan op andere momenten zonder problemen een BT-client draaien met een max van 1500 connecties en dan nog kan ik internetten, MSNen en andere dingen doen inclusief GoT.

[Verwijderd]

BtM909 schreef op maandag 04 december 2006 @ 11:39:
[...]

Er wordt helemaal niet zo bot (als jij het stelt) afgekapt... De vraag in de TS is:

[...]

Je maakt hier ook weer aannames en assumptions are the mother of all....

Ik vind het behoorlijk bot overkomen, een plaatje zal daar niet veel aan veranderen.

Hoe is dat een aanname? Ik zet het enkel in perspectief...

[ACM]

Vinden jullie het erg om het over dit probleem te hebben, ipv over hoe er vorige keren op gereageerd is?

Het lijkt er op dat de dumper van mysql 4.1 het nodig vindt om maar standaard een table lock te plaatsen rond de te dumpen tabellen... enneuh, dan kun je in het beste geval nog lezen en het slechtste geval moet je wachten tot de dump van de specifieke tabel klaar is

Dat gaan we uiteraard nu gelijk standaard weer uitzetten, en dan hoor ik graag van jullie of het probleem aankomende nacht nog terugkomt.

[MAX3400]

ACM schreef op maandag 04 december 2006 @ 12:47:Dat gaan we uiteraard nu gelijk standaard weer uitzetten, en dan hoor ik graag van jullie of het probleem aankomende nacht nog terugkomt.

Zal kijken of ik vannacht op genoemde tijdstippen weer van de partij ben en indien mogelijk mijn bevindingen online plempen.

[elevator]

ACM schreef op maandag 04 december 2006 @ 12:47:
Het lijkt er op dat de dumper van mysql 4.1 het nodig vindt om maar standaard een table lock te plaatsen rond de te dumpen tabellen... enneuh, dan kun je in het beste geval nog lezen en het slechtste geval moet je wachten tot de dump van de specifieke tabel klaar is

Loop je met MySQL dan niet het risico dat de 'state' van de bv. users tabel ouder is dan de state van de topics tabel?

Oftewel - dat je bij wijze van spreke in je backup topics hebt zitten van users die nog niet bestaan?

[Verwijderd]

Dat risico loop je toch wel aangezien enkel tabels gelocked worden en niet de hele database.

[ Voor 150% gewijzigd door Verwijderd op 04-12-2006 13:02 ]

[ACM]

elevator schreef op maandag 04 december 2006 @ 12:53:
Loop je met MySQL dan niet het risico dat de 'state' van de bv. users tabel ouder is dan de state van de topics tabel?

Daar is dit de poor-mans solution tegen ja... maar er is ook --single-transaction en bij innodb is dat prima te gebruiken

Anderzijds... wij willen graag deel-restores kunnen doen en dat kan sowieso niet als je een complete dump produceert met zo'n --single-transaction oplossing

Verwijderd schreef op maandag 04 december 2006 @ 12:59:
Dat risico loop je toch wel aangezien enkel tabels gelocked worden en niet de hele database.

Vziw wordt de hele database wel gelocked?

[ Voor 19% gewijzigd door ACM op 04-12-2006 13:00 ]

[elevator]

Nou nee, als je namelijk alle tabellen locked die je gaat backuppen dan is dat geen probleem, ACM's omschrijving zegt dan ook:

Het lijkt er op dat de dumper van mysql 4.1 het nodig vindt om maar standaard een table lock te plaatsen rond de te dumpen tabellen...

[Verwijderd]

Inderdaad, een lock dus voor het dumpen op alle tabellen, dus in principe wel een databaselock als je de hele database dumpt.

Ik heb dat overigens ook gezien dat het dumpen van de database een lock op de database gaf ik MySQL 4.1. Dat was wanneer er vanaf een externe server (AKA de backup server) een dump gestart werd.

Ik heb dit toen opgelost door een dump te starten via een scriptje op de database server zelf (lokaal dus via een Unix socket), ik weet niet of ie daar gewoon zoveel keer sneller van werd dat je niets meer merkte van de locks of dat de locks inderdaad wel goed gingen.

De totale backup van die database duurt maar 2 min, dus die is een stukje kleiner als de database van GoT

En dat kan ook te maken hebben met lokale instellingen etc, het was maar een quick'n'dirty fix van mij, maar als het werkt dan werkt het he?

[ Voor 9% gewijzigd door Verwijderd op 04-12-2006 13:06 ]

[elevator]

ACM schreef op maandag 04 december 2006 @ 13:00:
Daar is dit de poor-mans solution tegen ja... maar er is ook --single-transaction en bij innodb is dat prima te gebruiken

Anderzijds... wij willen graag deel-restores kunnen doen en dat kan sowieso niet als je een complete dump produceert met zo'n --single-transaction oplossing

Dat snap ik niet zo goed - ik ken die single-transaction optie verder niet, maar doet die veel meer dan gewoon een aparte transactie starten aan het begin en eindigen met het sluiten van die transactie, waarom kan je dan geen deel restores meer doen? (pure interesse hoor )

Sowieso heb je natuurlijk in jullie setup het probleem van out-of-sync db's omdat je meerdere database servers hebt waarbij je ook met maximaal 2,5 uur verschil (als ik het goed las?) backups van neemt, dat wil zeggen als de GoT DB eindigt met de users tabel en de FP database er mee begint zit er een aardig verschil in

[ACM]

elevator schreef op maandag 04 december 2006 @ 13:06:
Dat snap ik niet zo goed - ik ken die single-transaction optie verder niet, maar doet die veel meer dan gewoon een aparte transactie starten aan het begin en eindigen met het sluiten van die transactie, waarom kan je dan geen deel restores meer doen? (pure interesse hoor )

Dat is inderdaad ongeveer het enige wat ie doet. En dus krijg je een consistent snap-shot, ook al is er al weer nieuwere data op het moment dat je backup klaar is. --lock-tables pakt het echter wat rigoreuzer aan, die verbiedt gewoon writes naar de tabel.

Maar we willen sowieso de mogelijkheid hebben/houden om een losse tabel van een dump te pakken, sommige wijzigen te weinig om het echt belangrijk voor te zijn om de hele backup terug te zetten.

Sowieso heb je natuurlijk in jullie setup het probleem van out-of-sync db's omdat je meerdere database servers hebt waarbij je ook met maximaal 2,5 uur verschil (als ik het goed las?) backups van neemt, dat wil zeggen als de GoT DB eindigt met de users tabel en de FP database er mee begint zit er een aardig verschil in

Dat is de volgende stap ja.

[ Voor 3% gewijzigd door ACM op 04-12-2006 13:35 ]

[elevator]

ACM schreef op maandag 04 december 2006 @ 13:34:
Dat is inderdaad ongeveer het enige wat ie doet. En dus krijg je een consistent snap-shot, ook al is er al weer nieuwere data op het moment dat je backup klaar is. --lock-tables pakt het echter wat rigoreuzer aan, die verbiedt gewoon writes naar de tabel.

Maar we willen sowieso de mogelijkheid hebben/houden om een losse tabel van een dump te pakken, sommige wijzigen te weinig om het echt belangrijk voor te zijn om de hele backup terug te zetten.

Maar het een sluit het ander toch niet uit? Een 'consistente' database dump kan je toch ook nog partieel terugzetten?

Dat is de volgende stap ja.

Dat is lastiger lijkt me al is 100% pure consistentie in het geval van de Tnet DB natuurlijk niet heel erg belangrijk

[Gé Brander]

Ik heb zelf voornamelijk ervaring met Sybase en SQL Server database systemen, en het idee dat de database niet benaderbaar is tijdens een backup vind ik toch wel erg raar. Bij zowel Sybase als SQL Server (2000/2005) kan je gewoon doorwerken in de database terwijl er een backup gemaakt wordt. Kan MySQL dat dan niet?

[ACM]

elevator schreef op maandag 04 december 2006 @ 14:01:
Maar het een sluit het ander toch niet uit? Een 'consistente' database dump kan je toch ook nog partieel terugzetten?

Niet als het een grote sql-file is... zoek dan de data voor je specifieke tabelletje maar es op

c70070540 schreef op maandag 04 december 2006 @ 14:09:
Kan MySQL dat dan niet?

Heb ik toch al uitgelegd?

[elevator]

ACM schreef op maandag 04 december 2006 @ 14:21:
Niet als het een grote sql-file is... zoek dan de data voor je specifieke tabelletje maar es op

Licentietje UltraEdit declareren bij VNU?

Maar kan je niet zelf een gelijksoortig iets in elkaar bakken met wel aparte filenames terwijl het toch in één transactie zit?

[ Voor 21% gewijzigd door elevator op 04-12-2006 14:24 ]

[ACM]

elevator schreef op maandag 04 december 2006 @ 14:23:
Maar kan je niet zelf een gelijksoortig iets in elkaar bakken met wel aparte filenames terwijl het toch in één transactie zit?

Sure, dat heb ik net zitten klussen

[Gé Brander]

ACM schreef op maandag 04 december 2006 @ 14:21:
[...]

Heb ik toch al uitgelegd?

Oh, sorry. Niet gezien en nog steeds niet gezien. Of bedoel je dat stukje over partial restore?

[ACM]

c70070540 schreef op maandag 04 december 2006 @ 14:34:
Oh, sorry. Niet gezien en nog steeds niet gezien. Of bedoel je dat stukje over partial restore?

Nee, over dat stuk met die locks. Dat ie dat standaard doet en je daardoor natuurlijk niet kan schrijven, terwijl dat niet hoeft bij innodb.

[Verwijderd]

ACM schreef op maandag 04 december 2006 @ 11:22:
Enig idee over wat voor 'enige tijd' we het dan hebben? Sinds 6 oktober? Of ver daarvoor/daarna?

Ik durf er geen harde uitspraak over te doen maar ik ervaar het zelf sinds ruwweg 2 weken. Kan ook 3 zijn. Maar niet al maanden en maanden.

[Verwijderd]

Het doet mij deugt om te zien dat er gezocht wordt naar een oplossing, alleen kan ik zelf de komende 2 weken helaas niet online zijn op de genoemde tijdstippen .

Maar hopenlijk ligt het inderdaad aan het locken van de tabellen, dan hoeft er ook niet verder gezocht te worden naar een oorzaak.

[ACM]

Verwijderd schreef op maandag 04 december 2006 @ 21:11:
Ik durf er geen harde uitspraak over te doen maar ik ervaar het zelf sinds ruwweg 2 weken. Kan ook 3 zijn. Maar niet al maanden en maanden.

Dus zo ongeveer sinds 6 oktober, misschien een weekje erna, zou goed kunnen?

Het moet haast wel het locken van tabellen zijn, domweg omdat de nieuwe hardware alleen maar significant sneller geworden is en de nieuwe mysql hier ook geen dingen ten nadele anders heeft, vziw. Op dat standaard locken na dan

[Verwijderd]

Met mijn beperkte kennis van databases (zeg maar .. heel weinig) lijkt dat toch steeds meer aannemelijk ja.

[Mentalist]

ACM schreef op maandag 04 december 2006 @ 11:22:
[...]

Enig idee over wat voor 'enige tijd' we het dan hebben? Sinds 6 oktober? Of ver daarvoor/daarna?

Je zou kunnen overwegen om wat grafiekjes van aantal posts tussen 3 uur en 6 uur samen te stellen over de afgelopen tijd, dan zie je vanzelf wanneer de gaps precies begonnen (hoe lastig dat met de beschikbare tools is weet ik niet, het zou in principe wel met de search kunnen als je naar tijden kon zoeken).

Ik zou het zo ook niet meer weten, ik heb geen trefwoorden om mijn IRC logs te doorzoeken.

[ Voor 12% gewijzigd door Mentalist op 04-12-2006 22:52 ]

[Mentalist]

ACM schreef op maandag 04 december 2006 @ 12:47:
Vinden jullie het erg om het over dit probleem te hebben, ipv over hoe er vorige keren op gereageerd is?

Het lijkt er op dat de dumper van mysql 4.1 het nodig vindt om maar standaard een table lock te plaatsen rond de te dumpen tabellen... enneuh, dan kun je in het beste geval nog lezen en het slechtste geval moet je wachten tot de dump van de specifieke tabel klaar is

Dat gaan we uiteraard nu gelijk standaard weer uitzetten, en dan hoor ik graag van jullie of het probleem aankomende nacht nog terugkomt.

Hee... Ik kan posten!

Nu is er dus iets aangepast, maar de backup draait nu nog wel gewoon? Dan is het opgelost namelijk .

[edit]Hmm, vergeten te checken op editten. Wellicht is het daar al te laat voor..

Voor de info: activetopics nu:

HK • Vaag vliegding met volgspot GrimaceODespair 12 05-12-2006 05:25
FGA • [Ervaringen] partyfotografie deel 5 neographikal 24 05-12-2006 05:23
SGD • Diablo2/LoD: Deel 33 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 last Frunz 880 05-12-2006 05:18
IH • [KPN] VoIP dienst InternetPlusBellen deel 10 Edmund 35 05-12-2006 05:14
AVH • [LCD TV] Samsung LCD TV's ( alle series ) Deel 4 aex351 33 05-12-2006 05:03
HK [Snacks]Moeder, ik lust een frikandel! 1 2 3 4 5 6 7 8 9 10 11 12 last sjef hoelenpapers 588 05-12-2006 04:50
HK "Volle" "daadkrachtige" nummers 1 2 3 last Demonfreak 138 05-12-2006 04:48
BUG [Bug?] Reactie 's nachts niet te wijzigen 1 2 last slindenau 60 05-12-2006 04:44
WI Freelance bijklussen Digitalis 11 05-12-2006 04:37
HK Post hier je rariteiten van onze 'vrinden' onder de rivieren 1 2 3 4 5 6 7 8 9 10 last LuNaTiC 462 05-12-2006 04:33
SGD Het Grote Xbox 360 Topic - Deel 25 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 last Muthas 990 05-12-2006 04:23

Posten is dus gewoon doorgegaan .

[ Voor 45% gewijzigd door Mentalist op 05-12-2006 05:34 ]

[ACM]

W3ird_N3rd schreef op dinsdag 05 december 2006 @ 04:44:
Nu is er dus iets aangepast, maar de backup draait nu nog wel gewoon? Dan is het opgelost namelijk .

Euh... *kuch* zo te zien niet. Nouja, weten we iig dat zonder backup het wel goed werkt
Moet ik wel goed kijken, de backup heeft idd gedraait.

[ Voor 9% gewijzigd door ACM op 05-12-2006 10:56 ]

[Verwijderd]

Hehe, dat zou wel een klein "foutje, bedankt" zijn geweest als er dan iets misging .

Maar zolang het dus niet meer terugkomt was dat de oorzaak (gekke mysql...)

[ Voor 31% gewijzigd door Verwijderd op 05-12-2006 16:00 ]

[MAX3400]

Ik wil vanaf hier ook maar even melden dat het probleem niet meer is voorgekomen. Mocht dat wel weer zo zijn, dan meld ik me weer.

[We Are Borg]

Had ook een bugmelding verstuurd (per mail, wilde 'mijn' DB gegevens niet aanpassen door een post te maken), maar probleem lijkt inderdaad te zijn opgelost. Vanwege tijdsverschil ben ik er op onmogelijke tijden vaak te vinden en heb nog niks gemerkt

[Verwijderd]

Ik heb het ook wel eens gehad dat ik in de nacht helemaal niet kan posten. Read-only ging perfect, maar posten echt niet.

Nu, de afgelopen 30 minuten heb ik geen onregelmatigheden gezien.

90 minuten voor een back-up...

Hoe groot is de database?
Hoe zwaar is de CPU? Compressie?
Op welk medium?

Op het GGZ in Oss gebruiken wij voor die afdeling DAT-tapes. Omdat de server een zware CPU heeft gaat comprimeren on the fly en houd de CPU de streamer bij met compressie.
Onze statische back-up (profiel back-up) doe ik persoonlijk met de hand op een DVD in triple opstelling (3 voudige kopie). Ik gebruik hiervoor 7-zip op "LZMA, normal, 64kb, non-solid".
Het voordeel van deze profiel back-up is dat je de profielen of een deel daarvan direct kunt uitpakken zonder het hele medium te moeten aflopen. Ik zie te weinig systeembeheerders met huismiddeltjes werken terwijl deze zo goed kunnen zijn.

Onze server is eens gered met het door mij geïnstalleerde ERUNT terwijl dure software er niet meer uit kwam en een restore noodzakelijk was. Niets restore, creatief zijn! Het was toen even stil in het serverhok


@Admin: Hoe groot is de database nog na compressie met 7-zip? Past hij op een DVD?

Bij het back-uppen op een kwetsbaar medium zoals een DVD heb ik een truukje.
Maak een spanned archief die uit 2 MB chunks bestaat. Brand de bestanden op 2 a 3 identieke DVD schijven. De kans dat op beide DVD's dezelfde chunk onleesbaar is is statistisch gezien heel klein. Met een drievoudige kopie zit je heel veilig.

Gebruik 7-zip met een groot woordenboek omdat een database met tekst zich extreem laat comprimeren. Ik heb ratio's van 200 op 1 gezien!

Het is mijn autisme dat ik soms bombarisch overkom en bedrijven die ik bezoek vinden me soms een rare snuiter, maar dat geeft niet. Zolang ik mijn werk goed aflever zal niemand mij ontslaan.
Ik heb het GGZ zeker 2 ton uitgespaard door slimme zetten te gebruiken. Het is net als schaken. Je moet goed nadenken voordat je iets doet. Geld is er genoeg en de duurste back-up media mag er aan te pas komen, maar 7-zip is samen met de Norton Commander (in het verleden) voor mij wel dé utilitie aller tijden.

[ Voor 34% gewijzigd door Verwijderd op 06-12-2006 05:35 ]

[Mentalist]

Verwijderd schreef op woensdag 06 december 2006 @ 05:12:
Bij het back-uppen op een kwetsbaar medium zoals een DVD heb ik een truukje.
Maak een spanned archief die uit 2 MB chunks bestaat. Brand de bestanden op 2 a 3 identieke DVD schijven.

We gaan hier wel flink offtopic (afsplitsing?), maar ik zou juist verschillende merken DVD's gebruiken. Rot er eentje weg, dan heb je de andere nog.

[ACM]

Verwijderd schreef op woensdag 06 december 2006 @ 05:12:
90 minuten voor een back-up...

Hoe groot is de database?
Hoe zwaar is de CPU? Compressie?
Op welk medium?

De database is zo'n 40GB aan on-disk data. Als tekst blijft er dan 26G van over en na compressie nog zo'n 7G. Er gaat dus sowieso aan 26GB aan data over de Gbit lijn, die ook eerst nog van disk geprepareerd moet worden etc etc.

Met het uitzetten van de compressie kost het overigens nog 'maar' 2500 seconden (gehvalveerd dus), blijkbaar kan de nieuwe Apollo het een stuk sneller dumpen dan onze Athena het kan comprimeren en naar disk wegschrijven. Bij de database van de frontpage is het verschil een stuk minder dramatisch. En het medium is dus disk, we hebben geen zin in gedoe met tapes en dvd's en dat soort zooi.

@Admin: Hoe groot is de database nog na compressie met 7-zip? Past hij op een DVD?

Met gzip past ie iig niet op een dvd en ik betwijfel of 7-zip het zo veel beter kan.

Bij het back-uppen op een kwetsbaar medium zoals een DVD heb ik een truukje.
Maak een spanned archief die uit 2 MB chunks bestaat. Brand de bestanden op 2 a 3 identieke DVD schijven. De kans dat op beide DVD's dezelfde chunk onleesbaar is is statistisch gezien heel klein. Met een drievoudige kopie zit je heel veilig.

Maar we doen toch niet aan removable media. Dit is namelijk maar een van de backups, naast die 7GB wordt er nog wel iets meer gebackupped en houden we in totaal 13G over.

Maar inderdaad het is wel heel erg off-topic zo

[Verwijderd]

ACM schreef op woensdag 06 december 2006 @ 07:26:
[...]

De database is zo'n 40GB aan on-disk data. Als tekst blijft er dan 26G van over en na compressie nog zo'n 7G. Er gaat dus sowieso aan 26GB aan data over de Gbit lijn, die ook eerst nog van disk geprepareerd moet worden etc etc.

De strategie is in mijn ogen niet denderend, maar ik betwijfel of je moet afstappen van jullie systeem omdat mijn plan iets meer manuren kost. Ik heb altijd zoiets gehad dat als iets van je hart gaat je het ook goed moet doen en kwantiteit is van de luien en kwaliteit is van de ijverigen om het zo maar te zeggen. Back-up met vlijt zou mijn Oma geroepen hebben

Advies: Schematisch overzicht van manuren tegen kosten en kwaliteit, generale opmaak matrixen


Met het uitzetten van de compressie kost het overigens nog 'maar' 2500 seconden (gehvalveerd dus), blijkbaar kan de nieuwe Apollo het een stuk sneller dumpen dan onze Athena het kan comprimeren en naar disk wegschrijven. Bij de database van de frontpage is het verschil een stuk minder dramatisch. En het medium is dus disk, we hebben geen zin in gedoe met tapes en dvd's en dat soort zooi.

Slecht medium. Ik wil GoT niet afzeiken, maar een database zonder compressie back-uppen is pas echt wasted space die niet al te goedkoop is. Je doet het op harddisk dus kun je inderdaad 7-zip gaan scripten

[...]

Met gzip past ie iig niet op een dvd en ik betwijfel of 7-zip het zo veel beter kan.

Nou en of! Voor een database zoals deze raad ik aan om PPMd te pakken met een woordenboekgrootte die het werkgeheugen nog net kan behappen en moet jij eens opletten Ik verwed er 'bijna om' dat ik hem op DVD krijg en in het slechste geval op een DVD-9.
Verdiep je maar eens in 7-zip en ga er eens mee knutselen.

PS: 7-zip mag voor commerciële doeleinden gebruikt worden, dat is in mijn ogen te mooi voor woorden en ik als GGZ systeembeheerder heb ze per mail bedankt voor deze topservice!

[...]

Maar we doen toch niet aan removable media. Dit is namelijk maar een van de backups, naast die 7GB wordt er nog wel iets meer gebackupped en houden we in totaal 13G over.

Maar inderdaad het is wel heel erg off-topic zo

Hoezo off-topic, mods? Ik probeer jullie met alle liefde te helpen om zo strubbelingen te beperken. Dit is juist een heel zinvol topic!

Dat GoT bereikbaar moet zijn tijdens de back-up is normaal als het een transactual database is wat eerder in deze topic al is gezegt. Daarom is een andere manier van back-uppen misschien wel de oplossing van de trubbels. Als jullie systeem moeite heeft om de stream bij te houden gaat dat ten koste van de database.
@mod, mag ik je iets vragen: Hoevaak defragmenteren jullie de operationele schijven en met wélk pakket? Hoe staat het met de 'interne' databasefragmentatie?

[ Voor 14% gewijzigd door Verwijderd op 06-12-2006 16:02 ]

[ACM]

Verwijderd schreef op woensdag 06 december 2006 @ 15:51:
De strategie is in mijn ogen niet denderend, maar ik betwijfel of je moet afstappen van jullie systeem omdat mijn plan iets meer manuren kost. Ik heb altijd zoiets gehad dat als iets van je hart gaat je het ook goed moet doen en kwantiteit is van de luien en kwaliteit is van de ijverigen om het zo maar te zeggen. Back-up met vlijt zou mijn Oma geroepen hebben

Advies: Schematisch overzicht van manuren tegen kosten en kwaliteit, generale opmaak matrixen

Euh. Dat was geen schema/strategie, enkel een uitleg van hoeveel data er is. En die data is dus minstens 26GB. Tenzij we heel moeilijk gaan doen met incrementele backups (waar mysql niet zo heel denderende support voor biedt), maar domweg de files die op de disk staan gaan backuppen is naast onhandig ook inefficienter in ruimte.

Slecht medium. Ik wil GoT niet afzeiken, maar een database zonder compressie back-uppen is pas echt wasted space die niet al te goedkoop is. Je doet het op harddisk dus kun je inderdaad 7-zip gaan scripten

Slecht medium? De disks zitten in een andere server en met > 300GB aan ruimte voor de backups van MySQL alleen lijkt me dat niet zo'n probleem kwa ruimte, bovendien comprimeren we het uiteraard wel, alleen niet met 7-zip. Maar we gaan niet elke dag of week naar de colocatie op en neer reizen om een stel tapes te vervangen en een tapeloader is ook aardig duurder en niet gebruiksvriendelijker dan een stel grotere disks...

Overigens kopieren we de backups van onze backup storage ook nog eens naar een andere locatie eens in de zoveel tijd.

Nou en of! Voor een database zoals deze raad ik aan om PPMd te pakken met een woordenboekgrootte die het werkgeheugen nog net kan behappen en moet jij eens opletten Ik verwed er 'bijna om' dat ik hem op DVD krijg en in het slechste geval op een DVD-9.

Euh... de gzip-compressed files is al 7GB he? En past dus op een DVD-9... Wil je beweren dat 7-zip die data met een bijna 2x zo grote compressie weg kan schrijven dan gzip?

Hoezo off-topic, mods? Ik probeer jullie met alle liefde te helpen om zo strubbelingen te beperken. Dit is juist een heel zinvol topic!

Dit topic staat in het bug-meldingen forum en ging over het onbruikbaar zijn van het forum elke nacht, niet over of wij wel de beste backupstrategie toepassen

Daarom is een andere manier van back-uppen misschien wel de oplossing van de trubbels.

Het veranderen van een simpele parameter was al de oplossing Bovendien kom je nauwelijks onder het gebruik van mysqldump uit dus is enkel de manier van opslaan te veranderen, niet de manier van het maken van het opvragen van de data uit de database.

Als jullie systeem moeite heeft om de stream bij te houden gaat dat ten koste van de database.

Hoezo? Dan heeft de database minder werk te verrichten over een langere tijd. Aangezien het om die tijd sowieso rustig is maakt dat weinig uit, niettemin heeft het wel onze voorkeur om er zo snel mogelijk van af te zijn. Vandaar ook dat we nu de compressie van de dumps achteraf ipv on-the-fly doen.

@mod, mag ik je iets vragen: Hoevaak defragmenteren jullie de operationele schijven en met wélk pakket? Hoe staat het met de 'interne' databasefragmentatie?

Defragmenteren? Onder linux? Waarom?
Bovendien betreft het enkel grote files die met vrij forse stappen verlengt worden en zal er dus weinig aan fragmentatie optreden.

Interne databasefragmentatie los je op met 'cluster', maar dat is zo'n ongelofelijke zware en intrusieve oplossing dat we daar niet aan beginnen. Bovendien hebben we vaak genoeg een backup opnieuw ingeladen (bij de vervanging van de servers, afgelopen maand nog) om ze echt gefragmenteerd te laten zijn en standaard doet innodb al zijn best om de data 'op volgorde van de primary key' op te slaan

Overigens wordt meedenken wel gewaardeerd natuurlijk, zelfs als dat niet altijd uit onze reacties blijkt

[Kees]

Verwijderd schreef op woensdag 06 december 2006 @ 15:51:
[...]


Dat GoT bereikbaar moet zijn tijdens de back-up is normaal als het een transactual database is wat eerder in deze topic al is gezegt. Daarom is een andere manier van back-uppen misschien wel de oplossing van de trubbels. Als jullie systeem moeite heeft om de stream bij te houden gaat dat ten koste van de database.
@mod, mag ik je iets vragen: Hoevaak defragmenteren jullie de operationele schijven en met wélk pakket? Hoe staat het met de 'interne' databasefragmentatie?

Interne database fragmentatie is met mysql niet aan te pakken zonder de db te dumpen en opnieuw te importeren, daarom is de interne fragmentatie op dit moment laag (is pas geleden allemaal gedaan). Gzippen gebeurd wel, maar gebeurd achteraf in plaats van tijdens de backup, en mischien heeft 7-zip een betere compressie, maar dat zou betekenen dat we van 88% compressie naar 90% gaan, op een gigabyte gezien dus een winst van 20 MB, niet heel bijzonder, zelfs die 800MB die het op 40G scheelt maakt niet echt heel veel uit, en het zal ongetwijfeld meer van de backupserver vragen.

Maar waarom zouden we van dit systeem af moeten stappen? we moeten hoe dan ook de data van de database server trekken en als dat dan meteen naar een schijf geschreven wordt (= snel, minder downtime) of gezipped naar een dvd (= traag, 5-10x meer tijd per backup - optimistisch gezien, zal eerder 10-50x zijn).

Vervolgens wordt die backup offsite getransporteerd, maar niet op dvd - we hebben dus altijd minimaal 7 backups in de serverruimte, 4 backups offsite en de database server, maar nee, niet op dvd/dat (fyi, elke backup bevat dus alle informatie van voorgaande backups, data van 5 jaar oud wordt niet verwijderd, daar hoeven we dus ook niet een aparte backup voor te hebben in het geval het veranderd is, bij de meeste db's zou dat prima anders kunnen zijn).

[Mentalist]

En dan moeten de serverdudes 7-zip onder Wine gaan draaien ofzo .

7-zip is mooi hoor, maar ik denk niet dat ik het voor backups op Linuxservers in zou willen zetten.

[ACM]

W3ird_N3rd schreef op woensdag 06 december 2006 @ 19:33:
En dan moeten de serverdudes 7-zip onder Wine gaan draaien ofzo .

Denk dat het handiger is gewoon de voor linux geschikte broncode van p7zip te downloaden

[Mentalist]

ACM schreef op woensdag 06 december 2006 @ 20:42:
[...]

Denk dat het handiger is gewoon de voor linux geschikte broncode van p7zip te downloaden

Ik wist niet dat er een *nix versie was ondertussen, Exuimtum had het alleen over 7-zip.. Het originele 7-zip project kent nog steeds alleen Windowsversies .

Hmm da's ook weer mooi dan .

[ Voor 9% gewijzigd door Mentalist op 07-12-2006 01:50 ]

[crisp]

well, geen slechte ervaringen meer na de recente aanpassingen, dus lijkt me fixed \o/