| View previous topic :: View next topic |
| Author |
Message |
Heinzelmännchen
Apprentice
Joined: 11 Mar 2004
Posts: 179
Location: MV, Germany
|
 Posted: Mon May 02, 2005 11:13 am Post subject: MySQL Server will nicht so ganz |
 |
|
Hallo,
ich bräuchte mal ne Info wie ich weiter verfahren sollte. Ich weiß, es hat vielleicht nicht unmittelbar etwas mit Gentoo zutun, erhoffe mir dennoch hilfe von Euch.
Hatte nach einigen SQL Statements die Fehlermeldung 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)' vom Server zurück bekommen. Habe danach versucht den Server neuzustarten um das Problem schnell zu lösen. Dies ging nicht. Also habe ich dann zap als Parameter ausgeführt. Die Childs dann noch über killall rausgeworfen und den MySQL Daemon gestartet. Nach dem Einloggen als Root kam wieder die Fehlermeldung: | Code: | mysql> show databases;
ERROR 2006: MySQL server has gone away
No connection. Trying to reconnect...
ERROR 2002: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)
ERROR:
Can't connect to the server
mysql>
|
Nach 10 Minuten ging es dann wieder.
Wie kann ich dieses Problem langfristig lösen und wie kommt es zustande?
Wäre echt schön, wenn jemand rat weiß.
MfG
Heinzelmännchen
_________________
Gute Dinge, will Weile haben! |
|
| Back to top |
|
 |
Deever
Veteran
Joined: 06 Jul 2002
Posts: 1354
Location: Zürich / Switzerland
|
| Posted: Mon May 02, 2005 11:23 am Post subject: |
|
|
Naja, so ganz ohne Logs wirds wohl ein Ratespiel werden...
Gruß,
/dev |
|
| Back to top |
|
|
flo_02_mu
n00b
Joined: 06 Aug 2004
Posts: 73
|
| Posted: Mon May 02, 2005 3:25 pm Post subject: |
|
|
Hmm... evtl. kein Platz mehr unter /var/run/mysqld/ oder unzureichende Berechtigungen? Evtl. mal den mysqld herunterfahren (falls möglich) und dann /var/run/mysqld/mysqld.sock von Hand entfernen.
- Flo |
|
| Back to top |
|
|
Heinzelmännchen
Apprentice
Joined: 11 Mar 2004
Posts: 179
Location: MV, Germany
|
| Posted: Tue May 03, 2005 3:22 pm Post subject: |
|
|
Hallo es hat etwas länger gedauert bis der Fehler wieder auftrat.
So ehrlich weiß ich jetzt auch nicht, was diese ganze Mitteilung bedeuten soll.
| Code: |
InnoDB: Submit a detailed bug report to http://bugs.mysql.com
InnoDB: Fatal error: cannot allocate 16793600 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 7048892 bytes. Operating system errno: 12
InnoDB: Cannot continue operation!
InnoDB: Check if you should increase the swap file or
InnoDB: ulimits of your operating system.
InnoDB: On FreeBSD check you have compiled the OS with
InnoDB: a big enough maximum process size.
InnoDB: We now intentionally generate a seg fault so that
InnoDB: on Linux we get a stack trace.
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=0
max_connections=100
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 233983
K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x83f4680
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xbfff6dc8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x811206d
0x40024635
0x82f319e
0x82f31f0
0x8298e42
0x821ef71
0x817a17a
0x816de85
0x8112ef5
0x403117a6
0x80c0a21
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow
instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0xc5c4c3c2 is invalid pointer
thd->thread_id=0
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
|
Speicherplatz probleme sehe ich eigentlich nicht. Warum sollten denn die Zugriffe auf einmal nicht mehr stimmen?
| Code: | Filesystem Size Used Avail Use% Mounted on
/dev/root 7.8G 6.4G 1.4G 83% /
/dev/hdb1 38G 32G 5.7G 85% /var/www
none 30M 0 30M 0% /dev/shm
|
Wäre echt nett, wenn mir jemand dies erklären könnte und wie man es verhindern kann.
Danke + Gruß
Heinz[/code]
_________________
Gute Dinge, will Weile haben! |
|
| Back to top |
|
|
Heinzelmännchen
Apprentice
Joined: 11 Mar 2004
Posts: 179
Location: MV, Germany
|
| Posted: Wed May 04, 2005 7:43 pm Post subject: |
|
|
Hallo zusammen,
mein Problem spitzt sich momentan richtig zu. Bekomme nämlich jetzt andauern die Socket Meldung. Auch sofort nach dem Neustart des MySQL Daemon. Soviel wie ich die Fehlermitteilung verstanden habe, wurde die InnoDB nicht richtig herunter gefahren. Möchte diese nicht auskommentieren, da meine Projekte da stark eingebunden sind und das Backup schon einen Monat zurück liegt.
Hier einmal die Meldung. Bitte entschuldigt, dass ich alles poste: | Code: | 050504 21:27:33 InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 383706542
InnoDB: Doing recovery: scanned up to log sequence number 0 383822661
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 712 row operations to undo
InnoDB: Trx id counter is 0 56778752
050504 21:27:33 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Starting rollback of uncommitted transactions
InnoDB: Rolling back trx with id 0 56778243, 712 rows to undomysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=0
max_connections=100
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 233983 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x83f5680
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xbfff6658, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81124cd
0x40024635
0x828173d
0x827f16e
0x827d641
0x826fd6d
0x824dae4
0x825bfb0
0x825c595
0x825c97f
0x8254a07
0x8254e01
0x8237570
0x82370ca
0x828a630
0x82b43c5
0x822011d
0x817a714
0x816e3c5
0x8113355
0x403117a6
0x80c0b21
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0xc5c4c3c2 is invalid pointer
thd->thread_id=0
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
|
Kann mir einer in dieser Situation helfen, wo nicht gleich alles gelöscht werden muss. Im übrigen habe ich auch gleich auf eine neuere Version geupdated. Mal die Chance genutzt. Doch als ich dann InnoDB gelesen habe, war mir klar, dass ich dies auch sparen konnte.
Bin über jeden Hinweis und Hilfe dankbar.
MfG
Heinzelmännchen
_________________
Gute Dinge, will Weile haben! |
|
| Back to top |
|
|
Mr_Maniac
Guru
Joined: 10 Jun 2004
Posts: 546
|
| Posted: Wed May 04, 2005 9:08 pm Post subject: |
|
|
Ich habe mal die im Log angegebene Adresse angesteuert und einen Stack Trace gemacht...
Hier die Ausgabe:
| Code: | 0x81124cd mysqld_extend_show_tables__FP3THDPCcT1 + 3641
0x40024635 _end + 933781465
0x828173d _mi_pack_key + 37
0x827f16e _mi_kpointer + 158
0x827d641 mi_extra_keyflag + 41
0x826fd6d mem_heap_add_block + 193
0x824dae4 page_dir_slot_check + 2532
0x825bfb0 page_cur_parse_insert_rec + 160
0x825c595 page_cur_parse_insert_rec + 1669
0x825c97f page_cur_parse_insert_rec + 2671
0x8254a07 page_dir_balance_slot + 2047
0x8254e01 page_dir_balance_slot + 3065
0x8237570 lock_rec_inherit_to_gap_if_gap_lock + 1356
0x82370ca lock_rec_inherit_to_gap_if_gap_lock + 166
0x828a630 mi_init_bulk_insert + 172
0x82b43c5 delete_tree_element + 21
0x822011d flst_remove + 629
0x817a714 row_rename_table_for_mysql + 164
0x816e3c5 row_ins_foreign_report_add_err + 1045
0x8113355 mysqld_show_fields__FP3THDP13st_table_listPCcb + 2593
0x403117a6 _end + 936849738
0x80c0b21 find_best__FP4JOINUxUidd + 2473 |
Kann jemand was damit anfangen?
Normalerweise sollte das ja an das MySQL-Team geschickt werden, aber das kann ich natürlich nicht machen 
_________________
AMD Ryzen 5900X
64 GB DDR4 RAM
GeForce RTX 3080
Gentoo Linux (most recent stable kernel - amd64)
Windows 11 x64 |
|
| Back to top |
|
|
Heinzelmännchen
Apprentice
Joined: 11 Mar 2004
Posts: 179
Location: MV, Germany
|
| Posted: Mon May 09, 2005 1:03 pm Post subject: |
|
|
Hi Mr_Maniac,
da ich damit auch nix anfangen konnte, habe ich jetzt die ibdata1 und ibdata2 kopiert und in einem Fremden System, mit den frm, myi und myd Dateien, eingeplegt.
Dann einen Dump da erzeugt und InnoDB auf dem Gentoo System neu erstellt und den Dump eingespielt.
Mittlerweile ist mir der Grund des aussetzen von mysqld.sock auch erkenntlich geworden. Undzwar wurde anhand eines falschen Scriptes immer der swap total in beschlag genommen und hatte somit keinen Spielraum mehr für MySQL gelassen.
Vielen Danke jedoch an alle die sich um eine Lösung meines Problem bemüt haben.
MfG
Heinzel
_________________
Gute Dinge, will Weile haben! |
|
| Back to top |
|
|
dalu
Guru
Joined: 20 Jan 2003
Posts: 530
|
| Posted: Mon May 09, 2005 4:49 pm Post subject: |
|
|
ich hatte ein ähnliches problem
im datadir war dann eine datei die sich ungefähr
log.000000001 nannte , die beinhaltete wahrscheinlich debug informationen die nicht genutzt werden konnten um eine tabelle zu reparieren
ich hatte testweise ein tabelle von myisam zu bdb konvertiert und auch wieder zurück.
das ging wahrscheinlich irgendwie schief und diese logdatei wurde erstellt.
zum glück waren es nur testtabellen. nachdem ich die logdatei gelöscht hatte ging wieder alles. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German)
