Bekijk Volledige Versie : 'Opeens' vreemde records in mysql database
CeeReM.com
17/10/13, 20:49
Vraag, wij hebben een tabel met +/- 2 miljoen records. 2 velden zijn de primary key. In deze tabel worden artikelen van een bestelling opgeslagen. Het opslaan van de artikelen is een eenvoudig proces, met een eenvoudige query.
Nu het vraagstuk:
1) De artikelen zijn om 12.05:01 allemaal toegevoegd.
2) Om 12.08:00 is er een export gedaan hiervan (csv). In dit bestand trof ik naast de 10 artikelen, ook 3 regels aan met een artikelId (niet een primary key) '0'. Heel vreemd.
3) Op basis hiervan zijn wij gaan kijken wat we in de tabel aantroffen: 3 records met allemaal NULL velden, alleen de OrderId was gevuld.
Punt 3 is heel vreemd, en zeer onverklaarbaar. Maar wat nog onverklaarbaarder is, dat de timestamp van deze records op 12.15:31 staat! Terwijl er al een export op 12.08.00 was gedaan!
Ik begin mij zorgen te maken om de database, en zoek het probleem niet zozeer in de applicatie. Er wordt maar op 1 plek in de app artikelen aangemaakt, en dat is goed te overzien. En de NULL waarden verontrusten mij, maar ook zeer zeker de timestamp.
Iemand een idee wat dit kan zijn? De sql logs tonen geen fouten. Het gaat hier overigens om een MyISAM tabel.
Alvast bedankt!
Misschien toch een de update notes eens lezen voor je een nieuwe versie van powerdns installeert http://doc.powerdns.com/html/from3.1to3.2.html (zoek naar empty non-terminals)
Als er bv een record bla.blup.piep.zone.tld in je db zit, worden vanaf 3.2 blup.piep.zone.tld en piep.zone.tld als NULL record aangemaakt, tijdens een rectify of een zone transfer, als er geen normale records zijn voor die hostnames.
Dit is nodig om de dnstree compleet te maken en een volledige NSEC3 chain te kunnen genereren.
Is dus normaal powerdns gedrag.
dennis0162
17/10/13, 23:35
Powerdns? TS heeft het over bestellingen.
Sent from my HTC One using webhostingtalk mobile app
Duidelijk geval van bedtijd voor mij sorry...
CeeReM.com
18/10/13, 12:08
Nee idd, geen powerdns.... Hopelijk weten jullie raad?
Yourwebhoster
18/10/13, 12:44
Duidelijk geval van bedtijd voor mij sorry...
Ik vind het mooi!:)
@TS: Hoe weet je zeker dat dit niet de applicatie is? Ik schat de kansen dat daar een fout in zit hoger dan de db. Daarnaast; draait de db server op dezelfde server? Zo nee, dan kan dat de verschillende tijden veroorzaken. Ik neem wel aan dat de genoemde tijden server tijden zijn en niet van je lokale computer.
CeeReM.com
18/10/13, 20:13
Ja, heeeel zeker :) Tijden lopen gelijk.
SebastiaanStok
18/10/13, 21:35
Hoe hoog is de laatste id en wat is het type van het veld?
MySQL heeft vervelende gewoonte om bij het overschrijden van de maximale integer waarde niet standaard een fout te geven.
Alleen als de strict modus aanstaat krijg je een fout, bij de standaard configuratie word dit stilletjes genegeerd.
CeeReM.com
18/10/13, 22:08
Het laatste id is 1759451, het type veld int(11). Dus dat zou het niet mogen kunnen zijn...
systemdeveloper
18/10/13, 22:25
Als je velden die geen NULL's mogen bevatten nu ook declareert als NOT_NULL dan krijg je er geen rotzooi meer in en wellicht (als je scripts ok zijn) ergens een foutmelding (webpage, webactie, cron) zodat je iets gerichter kunt zoeken.
Als je een timestamp van MySQL zelf gebruikt zoals bv. NOW(), TIMESTAMP() dan kun je in principe geen verkeerde timestamp in je tabel krijgen. MySQL gooit er niet vanzelf iets in tenslotte (Nou ja, misschien een foute trigger of stored procedure, maar iig. verzint ie zelf niks)
CeeReM.com
18/10/13, 22:34
In de tabel staat er als default waarde 'CURRENT_TIMESTAMP'. In de insert query wordt het hele timestamp veld niet aangeroepen.
Maar even toch de lijn volgend dat de applicatie goed is, kan dit überhaupt fout gaan op database niveau?
systemdeveloper
18/10/13, 23:00
In de tabel staat er als default waarde 'CURRENT_TIMESTAMP'. In de insert query wordt het hele timestamp veld niet aangeroepen.
Maar even toch de lijn volgend dat de applicatie goed is, kan dit überhaupt fout gaan op database niveau?
Alles kan, maar ik heb het op 15 jaar nog niet gezien. Hooguit als iets (half) buiten de applicatie om wat zit te klooien (googlebot oid die een ajax link spidert) maar dan krijg je geen verkeerde timestamp. Wat wel kan is dat je tijd wél verkeerd liep en die ten tijde van de controle al goed gezet was door ntpd oid.
CeeReM.com
19/10/13, 11:19
Dan ben ik ten einde raad. De fout zit gewoon niet in de applicatie. Na het aanmaken van de bestelling wordt de hele sessie geleegd. Tevens worden items ALTIJD en DIRECT toegevoegd ná het aanmaken van de order zelf. Als er dan al een ajax url (die er niet is) of een POST request opnieuw zou worden uitgevoerd, moet er een nieuwe order worden aangemaakt.
...... :drunk:
systemdeveloper
19/10/13, 11:30
Dan ben ik ten einde raad. De fout zit gewoon niet in de applicatie. Na het aanmaken van de bestelling wordt de hele sessie geleegd. Tevens worden items ALTIJD en DIRECT toegevoegd ná het aanmaken van de order zelf. Als er dan al een ajax url (die er niet is) of een POST request opnieuw zou worden uitgevoerd, moet er een nieuwe order worden aangemaakt.
...... :drunk:
Wat je kunt doen is je app scannen naar inserts op die tabel en overal waar dit gebeurt de zooi apart loggen naar een tekstbestand. Dus gewoon de $_SERVER, $_SESSION, $_POST, $_GET als key/value waarden in een /tmp/blabla.txt bestand dumpen.
Meestal zie je dan snel of er iets mis gaat.
Ik heb zelf wel eens gehad dat ik ergens een extern js-scriptje had dat een page refreshte in IE (maar niet in andere browsers) en daardoor dubbele logrecords aanmaakte. Niet hetzelfde als jouw geval, maar wel iets dat je redelijk wat zoeken bezorgt terwijl in de app zelf (php code) niks mis was.
Zomaar wat andere ideetjes
- Komt het vaker voor of was dit eenmalig?
- Heb je de apache logs al rond hetzelfde moment gechecked? Dat je het veld zelf niet invult wil nog niet zeggen dat iemand anders het niet voor je geprobeerd heeft. Je kan normaalgesproken een default waarde "overschrijven" door zelf een waarde in de betreffende kolom te stoppen.
- Je kijkt naar de database csv export en ziet daar "nullen" staan, heb je al geverifieerd dat die nullen ook daadwerkelijk in de database voorkomen? Zelfde qua datum.
- Disk file system integrity check is OK?
Ik heb zeer recent iets gelijkaardigs gehad met een betrouwbare MySQL server en een nieuwe toepassing. Er was één record geschreven, dat vanuit de CRM toepassing niet kon gewist worden. De melding was dat het record niet bestond.
Alle waarden, muv datum en key, waren NULL. Ik ben er vrij zeker van dat ik het record zelf veroorzaakt heb, door experimenteren. Volgens de devs had het niet mogen kunnen gebeuren.
Ik heb het pas een paar weken later ontdekt. Logging op het dev systeem was nog niet compleet. Ik heb er dan ook niet veel tijd in gestoken.
Wissen van het ene record via MySQL zelf ging ook niet meteen van een leien dakje. Ook daar kreeg ik de melding dat het record niet bestond. Na overschrijven van de NULL waardes met wat onzin, kon ik het wel wissen.
Ik heb een stil vermoeden, dat een upgrade van MySQL (of PHP?) de onderliggende oorzaak is, gezien enkele kleine problemen met andere toepassingen die opdoken op dezelfde datum (de dag na de upgrade).
Andere problemen hadden te maken met tabellen die van MyISAM naar innoDB gezet waren.