22. august 2003 - 00:34Der er
6 kommentarer og 1 løsning
MySQL-tabeller går i stykker
Hej, det er første gang, jeg selv prøver at oprette et spørgsmål her, så nu håber jeg, at jeg gør det rigtigt :).
Jeg driver et site med to fora. Sitet benytter PHP og MySQL-database. Tingene har fungeret uden problemer i godt et halvt år, men i den sidste uges tid har jeg fået det problem, at MySQL-tabellerne med de to fora jævnligt går i stykker. Når problemet opstår, viser PhpMyAdmins oversigt over databasen, at tabellerne er "i brug", og hvis jeg vælger den enkelte tabel, får jeg en melding om, at filen "tabelnavn.MYI" mangler. Så kan jeg køre en "Reparer tabel", og så virker det igen i et stykke tid.
Sidste weekend skete det 3-4 gange i løbet af weekenden, at en af de to tabeller væltede.
Sitet ligger på en Linux-server, og MySQL-databasen ligger (angiveligt) på en anden Linux-server.
Min webhoteludbyder siger, at flere af deres kunder, som benytter PhpBB-forum, har oplevet dette problem efter, at udbyderen opgraderede (vistnok) MySQL. I deres tilfælde hjalp det ifølge udbyderen at flytte dem til en anden MySQL-server. Jeg har selv programmeret mine fora og benytter altså ikke PhpBB, men i mandags prøvede vi at flytte mig over på en anden MySQL-server. Tilsyneladende hjalp det, men her torsdag aften var den gal igen - på begge tabeller samtidigt eller næsten samtidigt, efter at tingene havde kørt stabilt i tre dage på den "nye" server.
De to tabeller har hhv. cirka 1800 og cirka 500 rækker (en række pr. post) og modtager vel tilsammen 10-20 nye posts på en normal dag. Sitet har 3-400 daglige besøgende ifølge chart.dk. Men for cirka tre måneder siden blev sitet omtalt på landsdækkende tv og havde i dagene derefter op til ti gange så mange besøgende, og det gav ikke dengang problemer - derfor tror jeg ikke, at det bare er et belastningsproblem.
Der er fem andre databasetabeller, som der indtil videre ikke har været problemer med, men de er heller ikke lige så store.
Mit spørgsmål er: Hvorfor hulen er det her lige pludselig begyndt at ske? Eller mere konkret: Kan jeg selv på nogen måde være skyld i det, eller kan det kun være webhoteludbyderen, der har fejlen? Og hvis jeg selv kan være skyld i det, hvad kan det så være, jeg gør forkert? Jeg har ikke ændret i scriptene for nylig.
Jeg har kun adgang til databasen via mine PHP-scripts og udbyderens PhpMyAdmin, jeg har ikke direkte adgang til selve databasefilerne.
Den, jeg har haft mest bøvl med, ser sådan ud i PhpMyAdmin:
Feltnavn Datatype Attributter Nulværdi Standardværdi Ekstra nr int(10) Nej auto_increment dato int(10) Nej 0 overskrift tinytext Nej tekst longtext Nej afsender int(10) Nej 0 senderip tinytext Nej hits int(10) Nej 0 sidsteip tinytext Nej vismail tinyint(1) Nej 0 sendmail tinyint(1) Nej 0 refnr int(11) Nej 0
Nøgle Datatype Kardinalitet Handling Feltnavn nr INDEX 1755 Slet Ret nr
Altså nu er du jo ikke den eneste der har en database på den pågældende MySQL-server. Din webudbyder lader sikkert andre benytte den også og du har derfor ingen mulighed for at bedømme hvor belastet MySQL-serveren er.
Prøv evt. at eksportere hele databasen som sql-statements, slet databasen, opret den igen og sæt alle de eksporterede data ind igen. Du kan evt. oprette en ny database og overføre dine data for at være sikker på intet går tabt. MySQL er ikke just regnet for at være en stabil database-server; fokus er performance ikke data-sikkerhed. Og jaja "jeg har ikke haft problemer siden 1784" er der mange der vil sige. For et par ugers tid siden mistede den virksomhed jeg arbejdede for en drift-database med præcis samme fejl. Du bruger MyISAM tabel-typer vi anvendte InnoDB, som ikke kan repereres på samme vis som du gør. Derfor gik en masse data tabt, som IKKE må gå tabt - stort set intet kunne reddes. Tabel-filerne var korrupte og ligeså backuppen. Dvs., at databasen har været korrupt i længere tid, måske flere dage, før MySQL gik ned med et hult drøn.
Et gratis alternativ til MySQL er PostgreSQL, som er langt mere stabil og mindst ligeså hurtig, men den har du sikkert ikke mulighed for at få adgang til hos din webudbyder.
MySQL har tendens til at crashe under for stor belastning (ok, der skal en hel del til), mens f.eks. PostgreSQL bare bliver langsommere. Hvis ikke dine data er større kommerciel betydning burde skulle MySQL kunne gøre det, også uden at lave fejl så ofte som du nævner.
Prøv at oprette en ny database og overfør alle dine data til den og se om det hjælper.
dsj: Tak for dit detaljerede svar. Jeg tror ikke, at jeg selv kan oprette en ny database - men er det lige så godt at slette tabellerne og oprette dem påny? I så fald er det allerede forsøgt uden held.
Men egentlig tror jeg, at udbyderen oprettede en ny database, da de flyttede mig til en anden server (det må de vel have gjort? - han sagde, at han exportede indholdet fra den gamle database, så jeg regner med, at han ikke bare kopierede databasefilerne).
At jeg ikke kan vide noget om belastningen på serveren, da den også bruges af andre kunder, må jeg jo give dig ret i :). Det ser ikke ud til, at min udbyder tilbyder PostgreSQL.
Nåh ja, man får jo én database som man ikke selv hverken kan slette eller oprette.
Hvis jeg var webudbyder ville jeg synes det var langt det letteste bare at kopiere database-filerne, men nu han siger at han eksporterede dem, kan det godt være han har gjort det.
Jeg har ikke lige nogen forslag til løsninger. MySQL kan gøre det bedre, hvis ikke den er hårdt belastet.
Ok - du var den eneste, der gav et bud, så du får da lige pointene :). I mellemtiden har webhoteludbyderen nedgraderet den "gamle" server til MySQL 3.23.57-log og flyttet mig tilbage dertil. Det er nogenlunde samme versionsnummer, som de brugte, før problemerne startede. Så må jeg krydse fingre for, at dette er løsningen.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
