Hallo Forum,

ich stehe vor einem recht grossen Problem mit mysql in der Version 4

also Folgendes:

ich habe ein Script, welches Artikel in einer Datenbank speichert (von affili.net). Die Aktualisierung der Produktlisten, die im CSV-Format vorliegen, erfolgt per Cronjob, alternativ auch manuell. Das geht auch alles prima, soweit die Liste der Artikel überschaubar bleibt.

Allerdings habe ich über 1.000.000 Artikel in der DB. Wenn ich alles manuell durchführen würde, wäre das eine langwierige Angelegenheit, da die Admin-Oberfläche endlos lange braucht. Wenn ich Cronjob setze dauert es zwar auch lange, Aber der Vorteil ist ja einfach, dass es Nachts läuft.

Allerdings:
jeden Morgen tritt folgendes auf:
Table Error ERROR 1016: Can't open file: 'shop.MYD'. (errno: 144), was ja quasi heisst: Tabelle zerschossen.
Es funktioniert zwar, wenn ich die Tabelle repariere (Server neu starten, Tabelle reparieren), aber das nervt ja auf dauer auch ein wenig.

Ich bin jetzt auf der Suche nach einer Lösung für diese Geschichte. Ich weiss nicht so recht, wo ich da ansetzen soll. Liegt es an der Performance von mysql, oder an den Tabellen?

Wenn Ihr weitere Infos über die Datenbank braucht, dann sagt es bitte. Die Systemvariablen poste ich am Ende.

Wäre Toll wenn jemand für mich eine Lösung hat, bzw. mir helfen kann.

Vielen Dank und Grüsse

Michael


Tabellen Struktur:

Feld Typ Attribute Null Standard Extra Aktion
ID int(100) Nein auto_increment
listid smallint(6) UNSIGNED Nein 0
Title varchar(150) Nein
Description_short text Nein
DisplayPrice varchar(23) Nein
Img_url varchar(150) Nein
DeepLink1 text Nein
Keywords varchar(255) Nein


Indizes:
Name Typ Kardinalität Aktion Feld
PRIMARY PRIMARY 322232 ID
Title FULLTEXT 107410 Title



Systemvariablen:

back log 50 50
basedir /usr/ /usr/
binlog cache size 32768 32768
bulk insert buffer size 8388608 8388608
character set latin1 latin1
character sets latin1 big5 czech euc_kr gb2312 gbk latin1_de sjis tis620 ujis dec8 dos german1 hp8 koi8_ru latin2 swe7 usa7 cp1251 danish hebrew win1251 estonia hungarian koi8_ukr win1251ukr greek win1250 croat cp1257 latin5 latin1 big5 czech euc_kr gb2312 gbk latin1_de sjis tis620 ujis dec8 dos german1 hp8 koi8_ru latin2 swe7 usa7 cp1251 danish hebrew win1251 estonia hungarian koi8_ukr win1251ukr greek win1250 croat cp1257 latin5
concurrent insert ON ON
connect timeout 5 5
convert character set
datadir /var/lib/mysql/ /var/lib/mysql/
default week format 0 0
delay key write ON ON
delayed insert limit 100 100
delayed insert timeout 300 300
delayed queue size 1000 1000
flush OFF OFF
flush time 0 0
ft boolean syntax + -><()~*:""&| + -><()~*:""&|
ft min word len 4 4
ft max word len 254 254
ft max word len for sort 20 20
ft stopword file (built-in) (built-in)
have bdb NO NO
have crypt YES YES
have innodb NO NO
have isam YES YES
have raid NO NO
have symlink YES YES
have openssl NO NO
have query cache YES YES
init file
interactive timeout 28800 28800
join buffer size 131072 131072
key buffer size 16777216 16777216
language /usr/share/mysql/english/ /usr/share/mysql/english/
large files support ON ON
local infile ON ON
locked in memory OFF OFF
log OFF OFF
log update OFF OFF
log bin OFF OFF
log slave updates OFF OFF
log slow queries OFF OFF
log warnings OFF OFF
long query time 10 10
low priority updates OFF OFF
lower case table names 0 0
max allowed packet 1047552 1047552
max binlog cache size 4294967295 4294967295
max binlog size 1073741824 1073741824
max connections 100 100
max connect errors 10 10
max delayed threads 20 20
max heap table size 16777216 16777216
max join size 4294967295 4294967295
max relay log size 0 0
max seeks for key 4294967295 4294967295
max sort length 1024 1024
max user connections 0 0
max tmp tables 32 32
max write lock count 4294967295 4294967295
myisam max extra sort file size 268435456 268435456
myisam max sort file size 2147483647 2147483647
myisam repair threads 1 1
myisam recover options OFF OFF
myisam sort buffer size 8388608 8388608
net buffer length 8192 8192
net read timeout 30 30
net retry count 10 10
net write timeout 60 60
new OFF OFF
open files limit 1024 1024
pid file /var/lib/mysql/mysqld.pid /var/lib/mysql/mysqld.pid
log error
port 3306 3306
protocol version 10 10
query alloc block size 8192 8192
query cache limit 1048576 1048576
query cache size 0 0
query cache type ON ON
query prealloc size 8192 8192
range alloc block size 2048 2048
read buffer size 131072 131072
read only OFF OFF
read rnd buffer size 262144 262144
rpl recovery rank 0 0
server id 1 1
slave net timeout 3600 3600
skip external locking ON ON
skip networking ON ON
skip show database OFF OFF
slow launch time 2 2
socket /var/lib/mysql/mysql.sock /var/lib/mysql/mysql.sock
sort buffer size 524280 524280
sql mode 0 0
table cache 64 64
table type MYISAM MYISAM
thread cache size 0 0
thread stack 196608 196608
tx isolation REPEATABLE-READ REPEATABLE-READ
timezone CET CET
tmp table size 33554432 33554432
tmpdir /tmp/ /tmp/
transaction alloc block size 8192 8192
transaction prealloc size 4096 4096
version 4.0.18 4.0.18
version comment Source distribution Source distribution
wait timeout 28800 28800

Mister Ad

Wie groß ist shop.MYD?
Wie reparierst Du die Tabelle?
Wird dabei auch ein Fehlercode erzeugt? Wenn ja, welcher?

Hallo,

also: die MYD ist 133 MB gross. Wüsste auch nicht, ob und wie ich die verkleinern sollte. Ich habe die Spaltenzahl schon so auf ein Minumum reduziert.

Die Tabelle repariere ich über phpMyAdmin mit dem Befehl "REPAIR TABLE `shop`"
Das funktioniert auch alles einwandfrei ohne Fehlermeldungen.

Grüsse

Michael

Hm, 133MB ist wohl eher keine natürliche Grenze, so wie bspw 2 oder 4 GB.
Hm hm, keine Fehlermeldung? Das ist seltsam.
Die erste Zahl sagt aus, wobei etwas schief gegangen ist (oder wer sich beschwert).
Danach kommt der dieser Nummer zugeordnete Text und meistens am Ende eine errno. errno soll mehr über die Gründe des Fehlers aussagen. Auch diesen Nummern ist eine bestimmte Fehlerquelle und ein Text zugeordnet. Den Text kann man sich per perror anzeigen lassen.
perror 144 -> MySQL error code 144: Table is crashed and last repair failed
Deshalb meine Verwunderung.

hallo,

das habe ich auch schon gelesen. Ich bin echt am Ende mit meiner weisheit.

Ich vermute mal ganz stark, dass es was damit zu tun hat, dass das Admin-Menu so lahm reagiert. beispielsweise: habe ich nur 10.000 Datensätze, dann reagiert alles ratzfatz. Auch das mit dem Cronjob funktioniert einwandfrei.

Die Datenbank selber schaut so aus:

fields => welche Daten erfasst werden sollen (z.B. DeepLink, Beschreibung usw.)
lists => liste der Merchants (Partnerprogrammanbieter von affili)
searchwords => hier werden die letzten Suchbegriffe gespeichert, so werden Doorway-Seiten erstellt
shop => Artikelliste

kann es nicht sein, dass in einer anderen Tabelle der Fehler liegt? Ich weiss diese Frage hätte ich mir wahrscheinlich sparen können, da niemand die DB kennt aber wäre es theoretisch möglich, oder liegt (laut dieser Fehlermeldung) der Fehler auch in der DB shop?

grüsse

Michael

Vielleicht ist es Symptom der selben Urasche, aber sicher nicht der Auslöser. Lahmer Client macht Datei auf dem Server kaputt? Dann könnte mysql einpacken.
Ich würde die Datenbank mal auf einem anderen Medium (andere Partition, anderes Dateisystem, andere Festplatte, anderer Rechner) ausprobieren.

habe es mal auf meinem Server laufen lassen. Da habe ich das gleiche Problem.

ich hatte auch mal das Problem, dass die Shop-Abfragen sehr langsam wurden (mit zunehmenden Artikeln). Das allerdings habe ich in den Griff bekommen, indem ich die Spalte 'title' auf FULLTEXT gesetzt habe. Somit lief es ratzfatz. Kann es nicht sowas sein?
Wo macht FULLTEXT denn generell einen Sinn? Ich denke nämlich wirklich, dass der Fehler in meiner DB liegt...bestimmt nicht bei mysql. mysql ist eine klasse DB!!!

Ich bin bestimmt kein mysql und php coder, der sich super auskennt. Habe mir in diesem Bereich alles selber beigebracht, und wenn ich mal nicht weiterweiss, dann habe ich verschiedene Bücher...aber die helfen mir da auch nicht weiter.

Viele Grüsse

Michael

Dann bin ich ratlos und verweise an http://bugs.mysql.com/