everytime I try to backup or check all tables mysql server crashes on Windows server 2012,
I am using XAMPP stack for my development environment.
The database crypto has more then 1100+ tables in DB.
I am including the logs below.
InnoDB: End of page dump
2017-09-24 13:58:35 7dc InnoDB: uncompressed page, stored checksum in field1 2521749199, calculated checksums for field1: crc32 2344073126, innodb 1121903210, none 3735928559, stored checksum in field2 0, calculated checksums for field2: crc32 2344073126, innodb 2892594725, none 3735928559, page LSN 0 2936733816, low 4 bytes of LSN at page end 0, page number (if stored to page already) 34, space id (if created with >= MySQL-4.1.1 and stored already) 1767
InnoDB: page type 17855 meaning INDEX
InnoDB: Page may be an index page where index id is 1522
InnoDB: (index "PRIMARY" of table "crypto"."300-token")
2017-09-24 13:58:35 2012 [ERROR] InnoDB: It is also possible that your operatingsystem has corrupted its own file cache.
2017-09-24 13:58:35 2012 [ERROR] InnoDB: and rebooting your computer removes the error.
2017-09-24 13:58:35 2012 [ERROR] InnoDB: If the corrupt page is an index page you can also try to
2017-09-24 13:58:35 2012 [ERROR] InnoDB: fix the corruption by dumping, dropping, and reimporting
2017-09-24 13:58:35 2012 [ERROR] InnoDB: the corrupt table. You can use CHECK
2017-09-24 13:58:35 2012 [ERROR] InnoDB: TABLE to scan your table for corruption.
2017-09-24 13:58:35 2012 [ERROR] InnoDB: See also http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html about forcing recovery.
2017-09-24 13:58:35 7dc InnoDB: Assertion failure in thread 2012 in file buf0lru.cc line 2394
InnoDB: Failing assertion: bpage->buf_fix_count == 0
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
170924 13:58:35 [ERROR] mysqld got exception 0x80000003 ;
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.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
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.
Server version: 10.1.22-MariaDB key_buffer_size=16777216
read_buffer_size=262144 max_used_connections=1 max_threads=1001
thread_count=1 It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
787106 K bytes of memory Hope that's ok; if not, decrease some
variables in the equation.
Thread pointer: 0x0 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...
mysqld.exe!my_parameter_handler() mysqld.exe!my_wildcmp_mb_bin()
mysqld.exe!?save_in_result_field#Item##UAEX_N#Z()
mysqld.exe!?save_in_result_field#Item##UAEX_N#Z()
mysqld.exe!?save_in_result_field#Item##UAEX_N#Z()
mysqld.exe!?save_in_result_field#Item##UAEX_N#Z()
mysqld.exe!?save_in_result_field#Item##UAEX_N#Z()
KERNEL32.DLL!BaseThreadInitThunk()
ntdll.dll!RtlInitializeExceptionChain()
ntdll.dll!RtlInitializeExceptionChain() 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.
I hope someone will help me out
Thanks.
From this content in your question,
"Server version: 10.1.22-MariaDB key_buffer_size=16777216 read_buffer_size=262144 max_used_connections=1 max_threads=1001 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 787106 K ...."
with max_threads=1001 clue above - check for max_connections in your my.ini or .cnf. Lowering max_connections to = 100 may or may not help get you past the BaseThreadInitThunk() ntdll.dll!
Related
My mysql server couldn' t not restart anymore
i was doing the installation of a wordpress plugin, it crashed, then i tried to relaunch the service, I have the error:
root#ns3371000:~# /etc/init.d/mysql start
[FAIL] Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!
This is the log when i launch it in safe mode:
mysqld_safe Logging to '/var/log/mysql.err'.
180822 16:33:07 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180822 16:33:07 [Note] Plugin 'FEDERATED' is disabled.
180822 16:33:07 InnoDB: The InnoDB memory heap is disabled
180822 16:33:07 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180822 16:33:07 InnoDB: Compressed tables use zlib 1.2.7
180822 16:33:07 InnoDB: Using Linux native AIO
180822 16:33:07 InnoDB: Initializing buffer pool, size = 128.0M
180822 16:33:07 InnoDB: Completed initialization of buffer pool
180822 16:33:07 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 12059835
180822 16:33:07 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...
InnoDB: Error: tried to read 65536 bytes at offset 0 2358272.
InnoDB: Was only able to read 1024.
InnoDB: Fatal error: cannot read from file. OS error number 17.
180822 16:33:10 InnoDB: Assertion failure in thread 140608317830944 in file os0file.c line 2549
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:33:10 UTC - mysqld got signal 6 ;
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_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346701 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x29)[0x56449ac71dc9]
/usr/sbin/mysqld(handle_fatal_signal+0x3d8)[0x56449ab57dc8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x7fe1ec9460a0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7fe1eb1d6125]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x180)[0x7fe1eb1d93a0]
/usr/sbin/mysqld(+0x67926b)[0x56449ada926b]
/usr/sbin/mysqld(+0x63eca0)[0x56449ad6eca0]
/usr/sbin/mysqld(+0x66b906)[0x56449ad9b906]
/usr/sbin/mysqld(+0x670eb7)[0x56449ada0eb7]
/usr/sbin/mysqld(+0x5ce70f)[0x56449acfe70f]
/usr/sbin/mysqld(+0x59aa2f)[0x56449accaa2f]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x56449ab5a151]
/usr/sbin/mysqld(+0x336507)[0x56449aa66507]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xa73)[0x56449aa69553]
/usr/sbin/mysqld(+0x2bb695)[0x56449a9eb695]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x45b)[0x56449a9ec30b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7fe1eb1c2ead]
/usr/sbin/mysqld(+0x2b2c89)[0x56449a9e2c89]
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.
I don' t want to loose all my current databases, anything pointing me to sort out the issues would be greatful
Thanks
If the database is broken you can try to access it in a recovery mode.
In your configuration file (my.ini) try to add:
[mysqld]
innodb_force_recovery = N
where N is from 1 to 6. Then, restart the server.
More information here: https://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
At least, you should be able to access the database in read-only mode to do the dump.
Mysql server crash on start on my Ubuntu 12.04.2 server. Mysql just not starting. Not after reboot, not after service mysql start(it return start: Job failed to start).
Previously it worked fine, but at some point the server crashed and I was not able to run it.
/var/log/mysql/error.log:
151109 10:02:14 [Note] Plugin 'FEDERATED' is disabled.
151109 10:02:14 InnoDB: The InnoDB memory heap is disabled
151109 10:02:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151109 10:02:14 InnoDB: Compressed tables use zlib 1.2.3.4
151109 10:02:14 InnoDB: Initializing buffer pool, size = 128.0M
151109 10:02:14 InnoDB: Completed initialization of buffer pool
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 5.
InnoDB: You may have to recover from a backup.
151109 10:02:15 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex 76607...(I removed the part)...3c3f438045ca5727; asc v` E W1 9 - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? ! " # $ % & ' ( ) * + , _ # _ # jPs <?C E W';
InnoDB: End of page dump
151109 10:02:15 InnoDB: Page checksum 1986035693, prior-to-4.0.14-form checksum 3548252131
InnoDB: stored checksum 1986035693, prior-to-4.0.14-form stored checksum 1010779008
InnoDB: Page lsn 0 1170888497, low 4 bytes of lsn at page end 1170888487
InnoDB: Page number (if stored to page already) 5,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a transaction system page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 5.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
151109 10:02:15 InnoDB: Assertion failure in thread 3065161472 in file buf0buf.c line 3629
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
10:02:15 UTC - mysqld got signal 6 ;
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_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346064 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x33)[0xb733d003]
/usr/sbin/mysqld(handle_fatal_signal+0x484)[0xb71e9f24]
[0xb6ea0400]
/usr/sbin/mysqld(+0x590e78)[0xb7453e78]
/usr/sbin/mysqld(+0x591852)[0xb7454852]
/usr/sbin/mysqld(+0x58109a)[0xb744409a]
/usr/sbin/mysqld(+0x54f75d)[0xb741275d]
/usr/sbin/mysqld(+0x551d09)[0xb7414d09]
/usr/sbin/mysqld(+0x53d5e0)[0xb74005e0]
/usr/sbin/mysqld(+0x501a22)[0xb73c4a22]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x4e)[0xb71ec74e]
/usr/sbin/mysqld(+0x1fbd82)[0xb70bed82]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xbc3)[0xb70c2723]
/usr/sbin/mysqld(+0x16691a)[0xb702991a]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x66a)[0xb702d61a]
/usr/sbin/mysqld(main+0x27)[0xb7022d27]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb6b5f4d3]
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.
I am facing the following error when i try to restart the MySQL service after an unexpected shutdown of the database server last night.
Could not start the MySQL service on Local Computer.
Error 1067: The process terminated unexpectedly.
When i check the .err log file under MySql data folder, the log details are as per below.
InnoDB: Log scan progressed past the checkpoint lsn 804 2135184621
150513 12:20:39 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...
InnoDB: Doing recovery: scanned up to log sequence number 804 2136195241
150513 12:20:50 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 150513 12:20:50 InnoDB: Assertion failure in thread 2412 in file .\rem\rem0rec.c line 337
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http:// bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http:// dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
150513 12:20:51 - mysqld got exception 0xc0000005 ;
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=135266304
read_buffer_size=65536
max_used_connections=0
max_threads=400
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 262617 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd: 0x0
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...
InnoDB: Thread 164 stopped in file .\os\os0sync.c line 391
0070A1A8 mysqld.exe!rec_get_offsets_func()[rem0rec.c:337]
0071B498 mysqld.exe!page_cur_parse_insert_rec()[page0cur.c:798]
0071512F mysqld.exe!recv_parse_or_apply_log_rec_body()[log0recv.c:814]
00715CF1 mysqld.exe!recv_recover_page()[log0recv.c:1294]
006EBE0F mysqld.exe!buf_page_io_complete()[buf0buf.c:2033]
006E4472 mysqld.exe!fil_aio_wait()[fil0fil.c:4273]
006BCDCD mysqld.exe!io_handler_thread()[srv0start.c:437]
77E6482F kernel32.dll!GetModuleHandleA()
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.
Error log show in Event Viewer:
An unhandled win32 exception occurred in mysqld.exe [1200]. Just-In-Time debugging this exception failed with the following error: Debugger could not be started because no user is logged on.
MySQL version: 5.1<br>
Table Type: InnoDB<br>
ibdata1 Size: 28GB
There are no SQL dump backup files for the tables made and there is only the SQL physical data files. I am desperately needed to restore the data of these and bring the website back to online.
Please help.
Apparently this is a known bug within MySQL 5.1 as mentioned within a few bug docs below.
http://bugs.mysql.com/bug.php?id=44416
http://bugs.mysql.com/bug.php?id=45844
I have updated the MySQL version to the latest (5.1.73) and then force recovery the InnoDB at level 6 (can only be started at this level for my case). After that, i can proceed with mysqldump.
setting file my.ini
change or add setting
innodb_flush_method=normal
restart service mysql
Our server has been running mysql just fine for over a year. I ran a set of sql script to build a rather large database and in the middle of those scripts, I started getting errors that I had lost connection. Nobody did anything else happened as far as we know. When I tried to log in to mysql, I got:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
When I try to restart mysql, I get:
# sudo service mysql restart
stop: Unknown instance:
start: Job failed to start
The error.log shows:
130212 9:37:51 [Note] Plugin 'FEDERATED' is disabled.
130212 9:37:51 InnoDB: The InnoDB memory heap is disabled
130212 9:37:51 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130212 9:37:51 InnoDB: Compressed tables use zlib 1.2.7
130212 9:37:51 InnoDB: Using Linux native AIO
130212 9:37:51 InnoDB: Initializing buffer pool, size = 10.0G
130212 9:37:51 InnoDB: Completed initialization of buffer pool
130212 9:37:51 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 2186809272046
130212 9:37:51 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...
InnoDB: Doing recovery: scanned up to log sequence number 2186814514688
InnoDB: Doing recovery: scanned up to log sequence number 2186816162838
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 27964 row operations to undo
InnoDB: Trx id counter is 18834200
130212 9:37:51 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 4424818.
InnoDB: You may have to recover from a backup.
130212 9:37:51 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex 058425e20043847200356a3f003e3720000001fd2807769645bf00000000000000000000000000ef31a083ca0000000031980005000003c8000$
InnoDB: End of page dump
18 130212 9:37:51 InnoDB: Page checksum 1501194131, prior-to-4.0.14-form checksum 441953139
InnoDB: stored checksum 92546530, prior-to-4.0.14-form stored checksum 1240647222
InnoDB: Page lsn 509 671577750, low 4 bytes of lsn at page end 441447404
InnoDB: Page number (if stored to page already) 4424818,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an index page where index id is 1096815
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 4424818.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
130212 9:37:51 InnoDB: Assertion failure in thread 140114781574912 in file buf0buf.c line 3603
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
16:37:51 UTC - mysqld got signal 6 ;
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_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346681 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x29)[0x7f72aa2435b9]
/usr/sbin/mysqld(handle_fatal_signal+0x3d8)[0x7f72aa12c548]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f72a8c8dcb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7f72a82f6425]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7f72a82f9b8b]
/usr/sbin/mysqld(+0x605429)[0x7f72aa32d429]
/usr/sbin/mysqld(+0x631b69)[0x7f72aa359b69]
/usr/sbin/mysqld(+0x5c20a8)[0x7f72aa2ea0a8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f72a8c85e9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f72a83b3cbd]
I cannot find anything running for mysql including any sockets.
I am taking over for a previous SysAdmin and am fairly new to linux and MySql. We've got to get this system back online soon. Please help.
Have you tried adding the following line to your /etc/mysql/my.cnf and then restarting the server?
[mysqld]
innodb_force_recovery = 4
To add to #elico3000 you will now need to dump your corrupt table(s) and Data to repair the innodb fs. There are a number of ways to do this. You can read through the logs to determine the point of failure and possible tablenames, then dump and recreate those specific tables. Or you can dump the entire MySQL DB and all schemas using a single command, but that will take some time depending on how big your DB. Either way once you have addressed the corrupt table(s) you can set the innodb_force option to 0 and restart mysqld_safe.
Here is a good tutorial on recovery options for both MyISAM and InnoDB MySQL instances and covers a few options. It is far easier to point you here, than regurgitate the commands and concepts again in this answer.
Good luck and come back to ask more pointed questions once you have tried one of the options. There are probably more tutorials out there, but I have used this in Development to rebuild my Dev DB and it has plenty of information.
Look here
Today i was trying to import a database(~650MB) which failed because of my max packet size was too small.. While trying to fix this, for some reason the database got corrupted.
Now i have the following problem:
In PhpMyAdmin i try to drop the table which is corrupted and it returns the following:
Fout
SQL-query:
DROP DATABASE `database_name`
MySQL retourneerde:
#2013 - Lost connection to MySQL server during query
Every single other database works fine, exept for this one.
I tried several ways, even by putting innodb_force_recovery to 6 in my.cnf file.
Does someone ever experienced something like this?
The FULL error output is:
Markering - 27 nov. 2012 16:49:06
121127 16:49:18 InnoDB: Assertion failure in thread 4516245504 in file dict0dict.c line 2643
InnoDB: Failing assertion: for_table || ref_table
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
15:49:18 UTC - mysqld got signal 6 ;
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=262144
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 = 134066 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x1010c9000
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 = 10d306ed8 thread_stack 0x40000
0 mysqld 0x000000010027a4fc my_print_stacktrace + 44�
1 mysqld 0x0000000100021134 handle_fatal_signal + 692�
2 libsystem_c.dylib 0x00007fff836038ea _sigtramp + 26�
3 mysqld 0x00000001002efd87 mtr_memo_push + 23�
4 libsystem_c.dylib 0x00007fff8365adce abort + 143�
5 mysqld 0x00000001002baf96 dict_foreign_add_to_cache + 998�
6 mysqld 0x00000001002c09c6 dict_load_foreigns + 1414�
7 mysqld 0x00000001002c2b5b dict_load_table + 1707�
8 mysqld 0x00000001003212b1 row_drop_database_for_mysql + 129�
9 mysqld 0x000000010030b322 _ZL22innobase_drop_databaseP10handlertonPc + 226�
10 mysqld 0x0000000100022601 _ZL17dropdb_handlertonP3THDP13st_plugin_intPv + 33�
11 mysqld 0x0000000100178f7d _Z24plugin_foreach_with_maskP3THDPFcS0_P13st_plugin_intPvEijS3_ + 845�
12 mysqld 0x0000000100140de3 _Z11mysql_rm_dbP3THDPcbb + 1859�
13 mysqld 0x0000000100167143 _Z21mysql_execute_commandP3THD + 13491�
14 mysqld 0x000000010016a386 _Z11mysql_parseP3THDPcjP12Parser_state + 294�
15 mysqld 0x000000010016b49d _Z16dispatch_command19enum_server_commandP3THDPcj + 1709�
16 mysqld 0x000000010016c387 _Z10do_commandP3THD + 231�
17 mysqld 0x000000010020b581 _Z24do_handle_one_connectionP3THD + 353�
18 mysqld 0x000000010020b639 handle_one_connection + 73�
19 libsystem_c.dylib 0x00007fff83615742 _pthread_start + 327�
20 libsystem_c.dylib 0x00007fff83602181 thread_start + 13�
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (10e002810): is an invalid pointer
Connection ID (thread ID): 9
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.
121127 16:49:19 mysqld_safe mysqld restarted
121127 16:49:19 [Warning] Setting lower_case_table_names=2 because file system for /Library/Application Support/appsolute/MAMP PRO/db/mysql/ is case insensitive
121127 16:49:19 [Note] Plugin 'FEDERATED' is disabled.
121127 16:49:19 InnoDB: The InnoDB memory heap is disabled
121127 16:49:19 InnoDB: Mutexes and rw_locks use GCC atomic builtins
121127 16:49:19 InnoDB: Compressed tables use zlib 1.2.3
121127 16:49:19 InnoDB: Initializing buffer pool, size = 128.0M
121127 16:49:19 InnoDB: Completed initialization of buffer pool
121127 16:49:19 InnoDB: highest supported file format is Barracuda.
InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on
InnoDB: Skipping log redo
121127 16:49:19 InnoDB: Waiting for the background threads to start
121127 16:49:20 InnoDB: 1.1.8 started; log sequence number 0
121127 16:49:20 InnoDB: !!! innodb_force_recovery is set to 6 !!!
121127 16:49:20 [Note] Event Scheduler: Loaded 0 events
121127 16:49:20 [Note] /Applications/MAMP/Library/bin/mysqld: ready for connections.
Version: '5.5.25' socket: '/Applications/MAMP/tmp/mysql/mysql.sock' port: 0 Source distribution
If you have tried each of the innodb_force_recovery values, (3 stops transactions being rolled back or forward), then I can only point you at the following
To cut to the chase, the person on this web page ended up deleteing the innodb files.
Until the end I don’t find a clear solution to this problem … but if you are on a testing environment you can just delete ibdata1 and ib_logfile0, ib_logfile1 and restart the server. This worked in my case.
http://www.randombugs.com/linux/crash-innodb-table.html
Obviously, if you have a load of other databases, this will involve backing up and restoring those aswell. If you find any other way around this, I suggest you try it first.
Percona provide a set of data recovery tools, but in your case the data is not the problem
http://code.google.com/p/innodb-tools/
https://launchpad.net/percona-data-recovery-tool-for-innodb