MySQL Forums
Forum List  »  German

Datenbank stürzt bei SELECT ab
Posted by: Stefan Barth
Date: January 13, 2014 03:56AM

Hallo zusammen,

ich habe ein Problem mit meiner MySQL Datenbank: Diese läuft Fehlerfrei und stabil seit....langer Zeit. Vor kurzem habe ich eine Funktion und einige Views eingespielt. Seit diesem Zeitpunkt kann ich weder von den Tabellen noch von den Views etwas selektieren. So bald ich SELECT * from Table; mache (was vor den Views ging) stürzt der MySQL Server ab. Folgendes taucht dann in den Logs auf:
------------LOG-Start
140110 14:54:15 mysqld_safe Number of processes running now: 0
140110 14:54:15 mysqld_safe mysqld restarted
140110 14:54:15 [Warning] '--default-character-set' is deprecated and will be removed in a future release. Please use '--character-set-server' instead.
140110 14:54:15 [Warning] '--default-collation' is deprecated and will be removed in a future release. Please use '--collation-server' instead.
140110 14:54:15 InnoDB: Initializing buffer pool, size = 256.0M
140110 14:54:15 InnoDB: Completed initialization of buffer pool
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
140110 14:54:15 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
140110 14:54:15 InnoDB: Started; log sequence number 2 135994925
140110 14:54:15 [Note] Event Scheduler: Loaded 0 events
140110 14:54:15 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.69' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
13:54:22 UTC - 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=134217728
read_buffer_size=131072
max_used_connections=1
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 461216 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x2d7d520
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...
stack_bottom = 7ff6a46a6d98 thread_stack 0x40000
/usr/libexec/mysqld(my_print_stacktrace+0x29) [0x84f539]
/usr/libexec/mysqld(handle_fatal_signal+0x483) [0x6a3713]
/lib64/libpthread.so.0() [0x370700f500]
/usr/libexec/mysqld(Item::save_in_field(Field*, bool)+0x12f) [0x51d75f]
/usr/libexec/mysqld() [0x54d822]
/usr/libexec/mysqld(Item_bool_func2::fix_length_and_dec()+0x2a3) [0x555e13]
/usr/libexec/mysqld(Item_func::fix_fields(THD*, Item**)+0x1ad) [0x53cafd]
/usr/libexec/mysqld(setup_conds(THD*, TABLE_LIST*, TABLE_LIST*, Item**)+0xf1) [0x601571]
/usr/libexec/mysqld(JOIN::prepare(Item***, TABLE_LIST*, unsigned int, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, st_select_lex*, st_select_lex_unit*)+0x308) [0x6247a8]
/usr/libexec/mysqld(st_select_lex_unit::prepare(THD*, select_result*, unsigned long)+0x75b) [0x6e91eb]
/usr/libexec/mysqld(mysql_derived_prepare(THD*, st_lex*, TABLE_LIST*)+0x128) [0x6ea278]
/usr/libexec/mysqld(mysql_handle_derived(st_lex*, bool (*)(THD*, st_lex*, TABLE_LIST*))+0x68) [0x6e9f38]
/usr/libexec/mysqld(open_normal_and_derived_tables(THD*, TABLE_LIST*, unsigned int)+0x40) [0x60b5e0]
/usr/libexec/mysqld(mysqld_list_fields(THD*, TABLE_LIST*, char const*)+0x20) [0x6c8c40]
/usr/libexec/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x15ee) [0x5d1c7e]
/usr/libexec/mysqld(do_command(THD*)+0xea) [0x5d1f4a]
/usr/libexec/mysqld(handle_one_connection+0x23e) [0x5c51de]
/lib64/libpthread.so.0() [0x3707007851]
/lib64/libc.so.6(clone+0x6d) [0x37068e890d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7ff674004a40): is an invalid pointer
Connection ID (thread ID): 1
Status: NOT_KILLED

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
140110 14:54:22 mysqld_safe Number of processes running now: 0
140110 14:54:22 mysqld_safe mysqld restarted
140110 14:54:22 [Warning] '--default-character-set' is deprecated and will be removed in a future release. Please use '--character-set-server' instead.
140110 14:54:22 [Warning] '--default-collation' is deprecated and will be removed in a future release. Please use '--collation-server' instead.
140110 14:54:22 InnoDB: Initializing buffer pool, size = 256.0M
140110 14:54:22 InnoDB: Completed initialization of buffer pool
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
140110 14:54:22 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
140110 14:54:23 InnoDB: Started; log sequence number 2 135994925
140110 14:54:23 [Note] Event Scheduler: Loaded 0 events
140110 14:54:23 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.69' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
14:10:21 UTC - 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=134217728
read_buffer_size=131072
max_used_connections=11
max_threads=151
thread_count=11
connection_count=11
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 461216 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x31894a0
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...
stack_bottom = 7f8b441f6d98 thread_stack 0x40000
/usr/libexec/mysqld(my_print_stacktrace+0x29) [0x84f539]
/usr/libexec/mysqld(handle_fatal_signal+0x483) [0x6a3713]
/lib64/libpthread.so.0() [0x370700f500]
/usr/libexec/mysqld(Item::save_in_field(Field*, bool)+0x12f) [0x51d75f]
/usr/libexec/mysqld() [0x54d822]
/usr/libexec/mysqld(Item_bool_func2::fix_length_and_dec()+0x2a3) [0x555e13]
/usr/libexec/mysqld(Item_func::fix_fields(THD*, Item**)+0x1ad) [0x53cafd]
/usr/libexec/mysqld(setup_conds(THD*, TABLE_LIST*, TABLE_LIST*, Item**)+0xf1) [0x601571]
/usr/libexec/mysqld(JOIN::prepare(Item***, TABLE_LIST*, unsigned int, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, st_select_lex*, st_select_lex_unit*)+0x308) [0x6247a8]
/usr/libexec/mysqld(st_select_lex_unit::prepare(THD*, select_result*, unsigned long)+0x75b) [0x6e91eb]
/usr/libexec/mysqld(mysql_derived_prepare(THD*, st_lex*, TABLE_LIST*)+0x128) [0x6ea278]
/usr/libexec/mysqld(mysql_handle_derived(st_lex*, bool (*)(THD*, st_lex*, TABLE_LIST*))+0x68) [0x6e9f38]
/usr/libexec/mysqld(open_normal_and_derived_tables(THD*, TABLE_LIST*, unsigned int)+0x40) [0x60b5e0]
/usr/libexec/mysqld(mysqld_list_fields(THD*, TABLE_LIST*, char const*)+0x20) [0x6c8c40]
/usr/libexec/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x15ee) [0x5d1c7e]
/usr/libexec/mysqld(do_command(THD*)+0xea) [0x5d1f4a]
/usr/libexec/mysqld(handle_one_connection+0x23e) [0x5c51de]
/lib64/libpthread.so.0() [0x3707007851]
/lib64/libc.so.6(clone+0x6d) [0x37068e890d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f8ae4004a20): is an invalid pointer
Connection ID (thread ID): 13
Status: NOT_KILLED
------------------------------LOG-Ende

Als ich dann "resolve_stack_dump" genutzt habe bin ich aber auch zu keinem wirklich schlaueren Ergebnis gekommen. Hier das Ergebnis:

-----------------STACK-Resolve
tech@host:~# resolve_stack_dump -s /tmp/mysqld.stack -n /root/stack.dmp2
0x84f539 _end + 89813
0x51d75f trx_undo_report_row_operation + 415
0x53cafd dict_boot + 3501
0x6247a8 _ZNK8TaoCrypt7Integer10InverseModERKS0_ + 792
0x6ea278 tab_uni_jisx020832 + 344
0x60b5e0 _ZN5yaSSL14DoProcessReplyERNS_3SSLE + 400
0x5d1f4a my_strntoull10rnd_8bit + 858
0x68e890d _end + 101380777
-------------------------STACK-Resolv-Ende

Leider kann ich damit nicht wirklich etwas anfangen und weiss auch nicht, ob ich alles richtig gemacht habe?

Da die Funktion + Views auf anderen Datenbanken ebenfalls laufen schließe ich diese als Fehlerquelle aus. Hat jemand Ideen wie ich weiter vorgehen soll?

Danke und Gruß
Stefan



Edited 1 time(s). Last edit at 01/13/2014 04:00AM by Stefan Barth.

Options: ReplyQuote


Subject
Views
Written By
Posted
Datenbank stürzt bei SELECT ab
2134
January 13, 2014 03:56AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.