abene Skrevet 8. juli 2011 Del Skrevet 8. juli 2011 Menneskelig svikt var en medvirkende årsak. Derfor kollapset BankID Lenke til kommentar
Pest^N Skrevet 8. juli 2011 Del Skrevet 8. juli 2011 Jøss, jeg trodde det var Skynet. 1 Lenke til kommentar
del_diablo Skrevet 8. juli 2011 Del Skrevet 8. juli 2011 Så feilen var at den hadde ikke stor nok cache, og at gammel metadata må ryddes opp manualt? O.o Lenke til kommentar
Ole-P Skrevet 8. juli 2011 Del Skrevet 8. juli 2011 Virker som gammel data blir slettet automatisk vanligvis, men at noe har skjært seg nå. [ En automatisert «vaktmester» Lenke til kommentar
DanteUseless Skrevet 8. juli 2011 Del Skrevet 8. juli 2011 Ved store nok databaseløsninger må nok menneskelige "vaktmestere" inn å passe på at de automatiske "vaktmesterne" gjør jobben sin. Av og til skjer glipp... Jaja. Noen fikk vel en liten vekker for hvor viktig den jobben er.. Lenke til kommentar
Gjest Slettet-Pqy3rC Skrevet 8. juli 2011 Del Skrevet 8. juli 2011 Gammel sesjonsdata fyller opp tjener... ? Bad programming. Lenke til kommentar
Drømmemannen Skrevet 9. juli 2011 Del Skrevet 9. juli 2011 Å putte session-data i databasen er helt normalt, og det samme er å ha en cronjob som jevnlig rydder opp i dataene. Men man må sørge for å ha automatisk overvåking av kritiske cronjobber, slik at man blir varslet når noe slutter å gå. Dette er ikke vanskelig, men det er lett å glemme hvis man ikke har rutiner på det. Lenke til kommentar
YoYo Skrevet 9. juli 2011 Del Skrevet 9. juli 2011 Gammel sesjonsdata fyller opp tjener... ? Bad programming. Det er en "vaktmester" som rydder opp jevnlig, men ikke har gjort jobben sin på 14 dager. Sitter du på informasjon som ikke er gitt i artikkelen? I så fall, del den gjerne. Ellers så er jeg skikkelig nysgjerrig på hvordan du kan tolke dette som "Bad programming". Å putte session-data i databasen er helt normalt, og det samme er å ha en cronjob som jevnlig rydder opp i dataene. Men man må sørge for å ha automatisk overvåking av kritiske cronjobber, slik at man blir varslet når noe slutter å gå. Dette er ikke vanskelig, men det er lett å glemme hvis man ikke har rutiner på det. Jeg synes ikke dette høres ut som web session data, som jeg tolker din mening til å være. Dersom det hadde vært problemet, så hadde det trolig vært merket tidligere. Nekter å tro at problemet er såpass enkelt at de har gått tom for diskplass på en database server uten å merke det. Jeg synes det høres ut som et absolutt problem. Det vil si kanskje en intern database teller, eller connectionpooling, load balancing osv som ikke blir ryddet opp i og derfor går "out of bounds". Synes det er litt merkelig om det er en job som feiler totalt uten at det blir merket. Kanskje det er en liten del av en større jobb som ikke har bra nok feilhåndtering eller rapportering. På den andre siden, så ble det fikset på 5 timer, og i løpet av den tiden så hadde de rukket å kjøre minst en restore fra backup og fått reprodusert feilen. Noe som i mitt hodet er svært kort tid på å finne ut av og fikse kompliserte problemer. Lenke til kommentar
Drømmemannen Skrevet 11. juli 2011 Del Skrevet 11. juli 2011 Mulig. Min gjetting er basert på: "feilen var knyttet til daglig vedlikehold av databasen" "å tømme databasen" for "gammel sesjonsdata" Det er veldig enkelt å ikke oppdage at en slik automatisk oppryddingsjobb slutter å gå . Det trenger ikke å være snakk om disk-plass heller. Med nok data i databasen kan databasen kveles av at den ikke klarer å behandle sprørringene raskere enn de kommer inn. Det kommer an på...alt. Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå