Etikettarkiv: myisam

Så tolkar du MySQL:s felkoder

Rätt ofta så stöter jag problem med MySQL som då spottar ur sig någon typ av felkod. Dessa felkoder och hur de uppkommer brukar jag tyvärr hinna glömma bort mellan varven så därför skriver jag ner dem här för att underlätta för mig och dig:

Följande felmeddelande:

  • ERROR 3 (HY000) at line 11619: Error writing file ‘/tmp/STUkun6Z’ (Errcode: 28)

Avkodas lättast genom att man skriver perror 28 vid en kommandotolk i Linux så bör något liknande komma fram:

  • OS error code  28:  No space left on device
Vilket är tämligen självförklarande. Slut på hårddiskutrymme på den monteringspunkten.
Om du sedemera utför någon typ av import eller dylikt som kan ta sjukt lång tid så brukar jag använda två bra trick:
  • Visa hur lång tid som är kvar av importen med följande kommandorad: pv filnamn.sql | mysql -u root -p (pv är ett användbart litet program som kan installeras via apt-get install pv)
Output blir ungefär följande då:
  • 10,9GB 1:24:51 [ 1,1kB/s] [=====>             ] 19% ETA 5:59:32
Och det andra tricket är att undersöka vad som händer genom SHOW PROCESSLIST vilket med fördel kan köras på följande sätt:
  • echo ‘show processlist’|mysql -u root -plösenord -B
Nu till nästa felmeddelande:
  • ERROR 1071 (42000) at line 11673: Specified key was too long; max key length is 1000 bytes
Det tog ett tag innan jag insåg hur detta felmeddelande uppstod och det var pga att InnoDB-motorn i min MySQL installation ej startades pga felaktiga konfigurationsvariabler i my.cnf och då gick MySQL automatiskt över till MyISAM. Denna ”bugg” har funnits i många år och upprört en hel del (se sista kommentaren här). Kan vara rätt jobbigt om man gör mysqldump på ett system för att sedan läsa in dumpen på ett annat system och det ej fungerar.
Nästa problematik är inte direkt ett felmeddelande utan någon jag stött på då en import tog sjuk lång tid. Vid undersökning så stod det ”repair by sorting” vilket är något som kan ta många timmar. Efter lite googlande så hittade jag att en snabbare repair finns och då skall följande meddelande visas vid SHOW PROCESSLIST: repair using keycache. Fixas genom att sätta myisam_max_sort_file_size=10G i my.cnf.
Om du använder dig av mysqlimport eller LOAD DATA INFILE och får något av följande felmeddelanden:
  • Error: 13, Can’t get stat of ‘/var/lib/mysql/Desktop/abc123′ (Errcode: 2)
  • File ‘/home/standage/Desktop/abc213′ not found (Errcode: 13)

Så beror det troligtvis på att du ej har behörighet eller att du ej angett hela sökvägen till filen. Brukar jag lösa genom att genomföra importen med ett mysql-root konto.

Uppdatering: Något annat som kan ställa till fel hos MySQL är nya AppArmor som standard används i senare versioner av Ubuntu. Om du ändrar exempelvis datadir så kommer det ej att fungera. Då måste du ändra i apparmor-profilen för MySQL.

Optimera din MySQL databas

Jag har suttit många månader och felsökt varför vissa saker går långsamt i MySQL när jag utvecklat bloggsökmotorn och i detta blogginlägg försöker jag sammanfatta de erfarenheter jag lärt mig på vägen:

  1. InnoDB är många gånger att föredra framför MyISAM. Jag fick jättemycket problem med låsningar då jag skriver och läser mycket till stora tabeller. MyISAM är generellt snabbare på INSERT’s
  2. Undvik typkonverteringar. I python exempelvis så görs detta automatiskt ibland och då kan det leda till att MySQL måste göra typkonverteringar vid varje jämförelse.
    • - ”Avoid overuse of MySQL’s automatic type conversion. MySQL will perform automatic type conversion, but if you can avoid conversions, you may get better performance” (från boken MySQL: The definitive guide to using, programming, and administering MySQL 4.1 and 5.0, Third Edition)
  3. Använd EXPLAIN före SELECT manuellt för att se var flaskhalsar kan sitta.
  4. Försök att undvika FULLTEXT indextyper, en vacker dag så sitter du där med tonvis med information och sökningarna tar flera sekunder. Snegla istället på Sphinx.
  5. Tråda så mycket som möjligt. Men var inte dum
  6. Slå på log_slow_queries i my.cnf och kolla loggen vilka frågor som går långsamt och försök optimera dessa.
  7. Bryt ner SQL-frågorna och utred vilket värde som tar lång tid att få fram.
  8. Kör SHOW FULL PROCESSLIST ibland och titta på ”Time” fältet där du ser hur lång tid frågor tar.
  9. Undvik ORDER BY RAND() då dessa frågor kopieras till en temporär tabell vilket tar tid.
  10. Ha full koll på dina INDEX så att de används på ett optimalt sätt. Inte för många och inte för få.
  11. Försök att tweaka my.cnf så att den stämmer överens med just din hårdvara gällande RAM-minne osv. Exempelvis så kan innodb_buffer_pool_size vara upp till 80% av minnesstorleken.
  12. Använd LIMIT där det är möjligt.
  13. Testa att lägg databasen på en separat hårddisk (datadir). Är standard /var/mysql på de flesta OS.
  14. Kör OPTIMIZE TABLE en gång i veckan eller en gång per månad.
  15. Ställ dig frågan att det kanske inte är databasen det är fel på utan kanske hur DU använder den.
  16. Läs mysqlperformanceblog.com samt Google är din vän.

Såja, hoppas det var allt. Fyller på om det är något som jag glömt.

Sökningar i MySQL MyISAM FULL-TEXT

När bloggz.se kom upp i över en miljon indexerade blogginlägg så började MySQL att gå på knäna så jag trodde ju såklart genast att jag hade gjort något fel när det gäller optimeringen av de index som jag använder mig av. Så jag la ungefär en månad på att felsöka och försöka lista ut vad som var galet, visst hittade jag diverse fel som gjorde att sökningarna tog långsammare men tillslut så gav även jag upp och började titta på nya alternativ.

Eter ett tag så fann jag det jag sökte efter: Sphinx. Sphinx indexerar hela MySQL full-text databastabellen och gör den sökbar på långt under en sekund. Vilken lycka! Nu kan jag sova lungt igen.