09:52:40 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=16777216 read_buffer_size=131072 max_used_connections=110 max_threads=151 thread_count=7 connection_count=7 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346700 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x7ff75e4cbb50 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 = 7ff7506e7e60 thread_stack 0x30000 /usr/sbin/mysqld(my_print_stacktrace+0x29)[0x7ff756680d79] /usr/sbin/mysqld(handle_fatal_signal+0x483)[0x7ff756545923] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7ff75528dcb0] /usr/sbin/mysqld(+0x65ef3f)[0x7ff756783f3f] /usr/sbin/mysqld(+0x663bc5)[0x7ff756788bc5] /usr/sbin/mysqld(+0x5edb5d)[0x7ff756712b5d] /usr/sbin/mysqld(+0x5ee855)[0x7ff756713855] /usr/sbin/mysqld(+0x5d73c1)[0x7ff7566fc3c1] /usr/sbin/mysqld(_Z15ha_create_tableP3THDPKcS2_S2_P24st_ha_create_informationb+0x1a2)[0x7ff75654c2c2] /usr/sbin/mysqld(_Z16rea_create_tableP3THDPKcS2_S2_P24st_ha_create_informationR4ListI12Create_fieldEjP6st_keyP7handler+0x209)[0x7ff7564be6a9] /usr/sbin/mysqld(+0x36b931)[0x7ff756490931] /usr/sbin/mysqld(_Z18mysql_create_tableP3THDP10TABLE_LISTP24st_ha_create_informationP10Alter_info+0x9c)[0x7ff7564921bc] /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x623a)[0x7ff75642d59a] /usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x10f)[0x7ff75642dc1f] /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1f26)[0x7ff75642fc16] /usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x1bd)[0x7ff7564d698d] /usr/sbin/mysqld(handle_one_connection+0x50)[0x7ff7564d69f0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7ff755285e9a] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7ff7549b72ed] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (7ff5ac8c4120): is an invalid pointer Connection ID (thread ID): 11676395 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. 150318 10:52:40 [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. 150318 10:52:40 [Note] Plugin 'FEDERATED' is disabled. 150318 10:52:40 InnoDB: The InnoDB memory heap is disabled 150318 10:52:40 InnoDB: Mutexes and rw_locks use GCC atomic builtins 150318 10:52:40 InnoDB: Compressed tables use zlib 1.2.3.4 150318 10:52:40 InnoDB: Initializing buffer pool, size = 4.0G 150318 10:52:41 InnoDB: Completed initialization of buffer pool 150318 10:52:41 InnoDB: highest supported file format is Barracuda. InnoDB: Log scan progressed past the checkpoint lsn 1579007927446 150318 10:52:41 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 1579013170176 InnoDB: Doing recovery: scanned up to log sequence number 1579018413056 InnoDB: Doing recovery: scanned up to log sequence number 1579020482443 150318 10:52:42 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 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 150318 10:52:43 InnoDB: Waiting for the background threads to start 150318 10:52:44 InnoDB: 5.5.41 started; log sequence number 1579020482443 150318 10:52:44 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306 150318 10:52:44 [Note] - '0.0.0.0' resolves to '0.0.0.0'; 150318 10:52:44 [Note] Server socket created on IP: '0.0.0.0'. 150318 10:52:44 [Note] Event Scheduler: Loaded 0 events 150318 10:52:44 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.5.41-0ubuntu0.12.04.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) 150318 10:52:44 [ERROR] /usr/sbin/mysqld: Table './v_vrm_2012/lastLogData' is marked as crashed and should be repaired 150318 10:52:44 [Warning] Checking table: './v_vrm_2012/lastLogData' 150318 10:52:45 [ERROR] /usr/sbin/mysqld: Table './v_vrm_2012_dev/lastLogData' is marked as crashed and should be repaired 150318 10:52:45 [Warning] Checking table: './v_vrm_2012_dev/lastLogData' 150318 10:52:45 [ERROR] /usr/sbin/mysqld: Table './v_vrm_2012_testing/lastLogData' is marked as crashed and should be repaired 150318 10:52:45 [Warning] Checking table: './v_vrm_2012_testing/lastLogData' 09:52:56 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=16777216 read_buffer_size=131072 max_used_connections=6 max_threads=151 thread_count=3 connection_count=3 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346700 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x7f2d039b34f0 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 = 7f2cf97d9e60 thread_stack 0x30000 /usr/sbin/mysqld(my_print_stacktrace+0x29)[0x7f2cf9e3dd79] /usr/sbin/mysqld(handle_fatal_signal+0x483)[0x7f2cf9d02923] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f2cf8a4acb0] /usr/sbin/mysqld(+0x65ef3f)[0x7f2cf9f40f3f] /usr/sbin/mysqld(+0x663bc5)[0x7f2cf9f45bc5] /usr/sbin/mysqld(+0x5edb5d)[0x7f2cf9ecfb5d] /usr/sbin/mysqld(+0x5ee855)[0x7f2cf9ed0855] /usr/sbin/mysqld(+0x5d73c1)[0x7f2cf9eb93c1] /usr/sbin/mysqld(_Z15ha_create_tableP3THDPKcS2_S2_P24st_ha_create_informationb+0x1a2)[0x7f2cf9d092c2] /usr/sbin/mysqld(_Z16rea_create_tableP3THDPKcS2_S2_P24st_ha_create_informationR4ListI12Create_fieldEjP6st_keyP7handler+0x209)[0x7f2cf9c7b6a9] /usr/sbin/mysqld(+0x36b931)[0x7f2cf9c4d931] /usr/sbin/mysqld(_Z18mysql_create_tableP3THDP10TABLE_LISTP24st_ha_create_informationP10Alter_info+0x9c)[0x7f2cf9c4f1bc] /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x623a)[0x7f2cf9bea59a] /usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x10f)[0x7f2cf9beac1f] /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1f26)[0x7f2cf9becc16] /usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x1bd)[0x7f2cf9c9398d] /usr/sbin/mysqld(handle_one_connection+0x50)[0x7f2cf9c939f0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f2cf8a42e9a] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f2cf81738bd] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (7f2b7c00ca50): is an invalid pointer Connection ID (thread ID): 64 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. 150318 10:52:56 [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. 150318 10:52:56 [Note] Plugin 'FEDERATED' is disabled. 150318 10:52:56 InnoDB: The InnoDB memory heap is disabled 150318 10:52:56 InnoDB: Mutexes and rw_locks use GCC atomic builtins 150318 10:52:56 InnoDB: Compressed tables use zlib 1.2.3.4 150318 10:52:56 InnoDB: Initializing buffer pool, size = 4.0G 150318 10:52:56 InnoDB: Completed initialization of buffer pool 150318 10:52:56 InnoDB: highest supported file format is Barracuda. InnoDB: Log scan progressed past the checkpoint lsn 1579012960432 150318 10:52:56 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 1579018203136 InnoDB: Doing recovery: scanned up to log sequence number 1579021575134 150318 10:52:57 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 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 150318 10:52:58 InnoDB: Waiting for the background threads to start 150318 10:52:59 InnoDB: 5.5.41 started; log sequence number 1579021575134 150318 10:52:59 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306 150318 10:52:59 [Note] - '0.0.0.0' resolves to '0.0.0.0'; 150318 10:52:59 [Note] Server socket created on IP: '0.0.0.0'. 150318 10:52:59 [Note] Event Scheduler: Loaded 0 events 150318 10:52:59 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.5.41-0ubuntu0.12.04.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) 150318 10:52:59 [ERROR] /usr/sbin/mysqld: Table './v_vrm_2012/lastLogData' is marked as crashed and should be repaired 150318 10:52:59 [Warning] Checking table: './v_vrm_2012/lastLogData' 150318 10:53:01 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje2 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 10:53:05 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje2 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 09:53:19 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=16777216 read_buffer_size=131072 max_used_connections=11 max_threads=151 thread_count=2 connection_count=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346700 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x7fe426998d70 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 = 7fe41cebae60 thread_stack 0x30000 /usr/sbin/mysqld(my_print_stacktrace+0x29)[0x7fe41d51ed79] /usr/sbin/mysqld(handle_fatal_signal+0x483)[0x7fe41d3e3923] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7fe41c12bcb0] /usr/sbin/mysqld(+0x65ef3f)[0x7fe41d621f3f] /usr/sbin/mysqld(+0x663bc5)[0x7fe41d626bc5] /usr/sbin/mysqld(+0x5edb5d)[0x7fe41d5b0b5d] /usr/sbin/mysqld(+0x5ee855)[0x7fe41d5b1855] /usr/sbin/mysqld(+0x5d73c1)[0x7fe41d59a3c1] /usr/sbin/mysqld(_Z15ha_create_tableP3THDPKcS2_S2_P24st_ha_create_informationb+0x1a2)[0x7fe41d3ea2c2] /usr/sbin/mysqld(_Z16rea_create_tableP3THDPKcS2_S2_P24st_ha_create_informationR4ListI12Create_fieldEjP6st_keyP7handler+0x209)[0x7fe41d35c6a9] /usr/sbin/mysqld(+0x36b931)[0x7fe41d32e931] /usr/sbin/mysqld(_Z18mysql_create_tableP3THDP10TABLE_LISTP24st_ha_create_informationP10Alter_info+0x9c)[0x7fe41d3301bc] /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x623a)[0x7fe41d2cb59a] /usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x10f)[0x7fe41d2cbc1f] /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1f26)[0x7fe41d2cdc16] /usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x1bd)[0x7fe41d37498d] /usr/sbin/mysqld(handle_one_connection+0x50)[0x7fe41d3749f0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7fe41c123e9a] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fe41b8548bd] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (7fe2a0000ca0): is an invalid pointer Connection ID (thread ID): 59 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. 150318 10:53:19 [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. 150318 10:53:19 [Note] Plugin 'FEDERATED' is disabled. 150318 10:53:19 InnoDB: The InnoDB memory heap is disabled 150318 10:53:19 InnoDB: Mutexes and rw_locks use GCC atomic builtins 150318 10:53:19 InnoDB: Compressed tables use zlib 1.2.3.4 150318 10:53:19 InnoDB: Initializing buffer pool, size = 4.0G 150318 10:53:19 InnoDB: Completed initialization of buffer pool 150318 10:53:19 InnoDB: highest supported file format is Barracuda. InnoDB: Log scan progressed past the checkpoint lsn 1579021575283 150318 10:53:19 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 1579023093874 150318 10:53:20 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 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 150318 10:53:20 InnoDB: Waiting for the background threads to start 150318 10:53:21 InnoDB: 5.5.41 started; log sequence number 1579023093874 150318 10:53:21 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306 150318 10:53:21 [Note] - '0.0.0.0' resolves to '0.0.0.0'; 150318 10:53:21 [Note] Server socket created on IP: '0.0.0.0'. 150318 10:53:21 [Note] Event Scheduler: Loaded 0 events 150318 10:53:21 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.5.41-0ubuntu0.12.04.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) 150318 10:53:22 [ERROR] /usr/sbin/mysqld: Table './v_vrm_2012/lastLogData' is marked as crashed and should be repaired 150318 10:53:22 [Warning] Checking table: './v_vrm_2012/lastLogData' 150318 10:53:23 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje2 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 10:53:23 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje3 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 10:55:15 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje2 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 10:55:15 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje3 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:00:16 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje2 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:00:16 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje3 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:05:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje2 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:05:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje3 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:10:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje2 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:10:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje3 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:15:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje2 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:15:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje3 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:20:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje2 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:20:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje3 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:25:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje2 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:25:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje3 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:30:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje2 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:30:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje3 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:35:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje2 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:35:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje3 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:40:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje2 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:40:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje3 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:45:15 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje2 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:45:15 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje3 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:50:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje2 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:50:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje3 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:55:15 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje2 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 11:55:15 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje3 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 12:00:15 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje2 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 12:00:15 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje3 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 12:05:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje2 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 12:05:14 [ERROR] Cannot find or open table v_vrm_2012_dev/logDataWithPartitiontestje3 from the internal data dictionary of InnoDB though the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but have forgotten to delete the corresponding .frm files of InnoDB tables, or you have moved .frm files to another database? or, the table contains indexes that this version of the engine doesn't support. See http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html how you can resolve the problem. 150318 12:10:12 InnoDB: Error: table `v_vrm_2012_dev`.`logDataWithPartitiontestje3` does not exist in the InnoDB internal InnoDB: data dictionary though MySQL is trying to drop it. InnoDB: Have you copied the .frm file of the table to the InnoDB: MySQL database directory from another database? InnoDB: You can look for further help from InnoDB: http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html 150318 12:10:12 InnoDB: Error: table `v_vrm_2012_dev`.`logDataWithPartitiontestje2` does not exist in the InnoDB internal InnoDB: data dictionary though MySQL is trying to drop it. InnoDB: Have you copied the .frm file of the table to the InnoDB: MySQL database directory from another database? InnoDB: You can look for further help from InnoDB: http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html 150318 12:22:21 InnoDB: Warning: trying to init to the tablespace memory cache InnoDB: a tablespace 155274 of name './v_vrm_2012_dev/logDataWithPartitiontestje3.ibd', InnoDB: but a tablespace 155150 of the same name InnoDB: already exists in the tablespace memory cache! InnoDB: We assume that InnoDB did a crash recovery, and you had InnoDB: an .ibd file for which the table did not exist in the InnoDB: InnoDB internal data dictionary in the ibdata files. InnoDB: We assume that you later removed the .ibd and .frm files, InnoDB: and are now trying to recreate the table. We now remove the InnoDB: conflicting tablespace object from the memory cache and try InnoDB: the init again. 11:22: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=16777216 read_buffer_size=131072 max_used_connections=15 max_threads=151 thread_count=8 connection_count=8 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346700 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x7f9ae43356e0 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 = 7f999f86ce60 thread_stack 0x30000 /usr/sbin/mysqld(my_print_stacktrace+0x29)[0x7f9adac1bd79] /usr/sbin/mysqld(handle_fatal_signal+0x483)[0x7f9adaae0923] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f9ad9828cb0] /usr/sbin/mysqld(+0x65ef3f)[0x7f9adad1ef3f] /usr/sbin/mysqld(+0x663bc5)[0x7f9adad23bc5] /usr/sbin/mysqld(+0x5edb5d)[0x7f9adacadb5d] /usr/sbin/mysqld(+0x5ee855)[0x7f9adacae855] /usr/sbin/mysqld(+0x5d73c1)[0x7f9adac973c1] /usr/sbin/mysqld(_Z15ha_create_tableP3THDPKcS2_S2_P24st_ha_create_informationb+0x1a2)[0x7f9adaae72c2] /usr/sbin/mysqld(_Z16rea_create_tableP3THDPKcS2_S2_P24st_ha_create_informationR4ListI12Create_fieldEjP6st_keyP7handler+0x209)[0x7f9adaa596a9] /usr/sbin/mysqld(+0x36b931)[0x7f9adaa2b931] /usr/sbin/mysqld(_Z18mysql_create_tableP3THDP10TABLE_LISTP24st_ha_create_informationP10Alter_info+0x9c)[0x7f9adaa2d1bc] /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x623a)[0x7f9ada9c859a] /usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x10f)[0x7f9ada9c8c1f] /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1f26)[0x7f9ada9cac16] /usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x1bd)[0x7f9adaa7198d] /usr/sbin/mysqld(handle_one_connection+0x50)[0x7f9adaa719f0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f9ad9820e9a] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f9ad8f518bd] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (7f994c00fba0): is an invalid pointer Connection ID (thread ID): 20782 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. 150318 12:22:21 [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. 150318 12:22:21 [Note] Plugin 'FEDERATED' is disabled. 150318 12:22:21 InnoDB: The InnoDB memory heap is disabled 150318 12:22:21 InnoDB: Mutexes and rw_locks use GCC atomic builtins 150318 12:22:21 InnoDB: Compressed tables use zlib 1.2.3.4 150318 12:22:22 InnoDB: Initializing buffer pool, size = 4.0G 150318 12:22:22 InnoDB: Completed initialization of buffer pool 150318 12:22:22 InnoDB: highest supported file format is Barracuda. InnoDB: Log scan progressed past the checkpoint lsn 1579683927788 150318 12:22: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... InnoDB: Doing recovery: scanned up to log sequence number 1579689170432 InnoDB: Doing recovery: scanned up to log sequence number 1579694413312 InnoDB: Doing recovery: scanned up to log sequence number 1579699656192 InnoDB: Doing recovery: scanned up to log sequence number 1579704899072 InnoDB: Doing recovery: scanned up to log sequence number 1579710141952 InnoDB: Doing recovery: scanned up to log sequence number 1579715384832 InnoDB: Doing recovery: scanned up to log sequence number 1579720627712 InnoDB: Doing recovery: scanned up to log sequence number 1579725870592 InnoDB: Doing recovery: scanned up to log sequence number 1579731113472 InnoDB: Doing recovery: scanned up to log sequence number 1579736356352 InnoDB: Doing recovery: scanned up to log sequence number 1579741599232 InnoDB: Doing recovery: scanned up to log sequence number 1579746842112 InnoDB: Doing recovery: scanned up to log sequence number 1579752084992 InnoDB: Doing recovery: scanned up to log sequence number 1579757327872 InnoDB: Doing recovery: scanned up to log sequence number 1579762570752 InnoDB: Doing recovery: scanned up to log sequence number 1579767813632 InnoDB: Doing recovery: scanned up to log sequence number 1579773056512 InnoDB: Doing recovery: scanned up to log sequence number 1579778299392 InnoDB: Doing recovery: scanned up to log sequence number 1579783542272 InnoDB: Doing recovery: scanned up to log sequence number 1579788785152 InnoDB: Doing recovery: scanned up to log sequence number 1579794028032 InnoDB: Doing recovery: scanned up to log sequence number 1579799270912 InnoDB: Doing recovery: scanned up to log sequence number 1579804513792 InnoDB: Doing recovery: scanned up to log sequence number 1579809756672 InnoDB: Doing recovery: scanned up to log sequence number 1579814999552 InnoDB: Doing recovery: scanned up to log sequence number 1579820242432 InnoDB: Doing recovery: scanned up to log sequence number 1579825485312 InnoDB: Doing recovery: scanned up to log sequence number 1579830728192 InnoDB: Doing recovery: scanned up to log sequence number 1579835971072 InnoDB: Doing recovery: scanned up to log sequence number 1579841213952 InnoDB: Doing recovery: scanned up to log sequence number 1579846456832 InnoDB: Doing recovery: scanned up to log sequence number 1579851699712 InnoDB: Doing recovery: scanned up to log sequence number 1579856942592 InnoDB: Doing recovery: scanned up to log sequence number 1579862185472 InnoDB: Doing recovery: scanned up to log sequence number 1579867428352 InnoDB: Doing recovery: scanned up to log sequence number 1579872671232 InnoDB: Doing recovery: scanned up to log sequence number 1579877914112 InnoDB: Doing recovery: scanned up to log sequence number 1579883156992 InnoDB: Doing recovery: scanned up to log sequence number 1579888399872 InnoDB: Doing recovery: scanned up to log sequence number 1579893642752 InnoDB: Doing recovery: scanned up to log sequence number 1579898885632 InnoDB: Doing recovery: scanned up to log sequence number 1579904128512 InnoDB: Doing recovery: scanned up to log sequence number 1579909371392 InnoDB: Doing recovery: scanned up to log sequence number 1579914614272 InnoDB: Doing recovery: scanned up to log sequence number 1579919857152 InnoDB: Doing recovery: scanned up to log sequence number 1579925100032 InnoDB: Doing recovery: scanned up to log sequence number 1579930342912 InnoDB: Doing recovery: scanned up to log sequence number 1579935585792 InnoDB: Doing recovery: scanned up to log sequence number 1579940828672 InnoDB: Doing recovery: scanned up to log sequence number 1579946071552 InnoDB: Doing recovery: scanned up to log sequence number 1579951314432 InnoDB: Doing recovery: scanned up to log sequence number 1579956557312 InnoDB: Doing recovery: scanned up to log sequence number 1579961800192 InnoDB: Doing recovery: scanned up to log sequence number 1579967043072 InnoDB: Doing recovery: scanned up to log sequence number 1579972285952 InnoDB: Doing recovery: scanned up to log sequence number 1579977528832 InnoDB: Doing recovery: scanned up to log sequence number 1579982771712 InnoDB: Doing recovery: scanned up to log sequence number 1579988014592 InnoDB: Doing recovery: scanned up to log sequence number 1579993257472 InnoDB: Doing recovery: scanned up to log sequence number 1579998500352 InnoDB: Doing recovery: scanned up to log sequence number 1580003743232 InnoDB: Doing recovery: scanned up to log sequence number 1580008986112 InnoDB: Doing recovery: scanned up to log sequence number 1580014228992 InnoDB: Doing recovery: scanned up to log sequence number 1580019471872 InnoDB: Doing recovery: scanned up to log sequence number 1580024714752 InnoDB: Doing recovery: scanned up to log sequence number 1580029957632 InnoDB: Doing recovery: scanned up to log sequence number 1580035200512 InnoDB: Doing recovery: scanned up to log sequence number 1580040443392 InnoDB: Doing recovery: scanned up to log sequence number 1580045686272 InnoDB: Doing recovery: scanned up to log sequence number 1580050929152 InnoDB: Doing recovery: scanned up to log sequence number 1580056172032 InnoDB: Doing recovery: scanned up to log sequence number 1580061414912 InnoDB: Doing recovery: scanned up to log sequence number 1580066657792 InnoDB: Doing recovery: scanned up to log sequence number 1580071900672 InnoDB: Doing recovery: scanned up to log sequence number 1580077143552 InnoDB: Doing recovery: scanned up to log sequence number 1580082386432 InnoDB: Doing recovery: scanned up to log sequence number 1580087629312 InnoDB: Doing recovery: scanned up to log sequence number 1580092872192 InnoDB: Doing recovery: scanned up to log sequence number 1580098115072 InnoDB: Doing recovery: scanned up to log sequence number 1580103357952 InnoDB: Doing recovery: scanned up to log sequence number 1580108600832 InnoDB: Doing recovery: scanned up to log sequence number 1580113843712 InnoDB: Doing recovery: scanned up to log sequence number 1580119086592 InnoDB: Doing recovery: scanned up to log sequence number 1580124329472 InnoDB: Doing recovery: scanned up to log sequence number 1580129572352 InnoDB: Doing recovery: scanned up to log sequence number 1580134815232 InnoDB: Doing recovery: scanned up to log sequence number 1580140058112 InnoDB: Doing recovery: scanned up to log sequence number 1580145300992 InnoDB: Doing recovery: scanned up to log sequence number 1580150543872 InnoDB: Doing recovery: scanned up to log sequence number 1580155786752 InnoDB: Doing recovery: scanned up to log sequence number 1580161029632 InnoDB: Doing recovery: scanned up to log sequence number 1580166272512 InnoDB: Doing recovery: scanned up to log sequence number 1580171515392 InnoDB: Doing recovery: scanned up to log sequence number 1580176758272 InnoDB: Doing recovery: scanned up to log sequence number 1580182001152 InnoDB: Doing recovery: scanned up to log sequence number 1580187244032 InnoDB: Doing recovery: scanned up to log sequence number 1580192486912 InnoDB: Doing recovery: scanned up to log sequence number 1580197729792 InnoDB: Doing recovery: scanned up to log sequence number 1580202972672 InnoDB: Doing recovery: scanned up to log sequence number 1580208215552 InnoDB: Doing recovery: scanned up to log sequence number 1580213458432 InnoDB: Doing recovery: scanned up to log sequence number 1580218701312 InnoDB: Doing recovery: scanned up to log sequence number 1580223944192 InnoDB: Doing recovery: scanned up to log sequence number 1580229187072 InnoDB: Doing recovery: scanned up to log sequence number 1580234429952 InnoDB: Doing recovery: scanned up to log sequence number 1580239672832 InnoDB: Doing recovery: scanned up to log sequence number 1580244915712 InnoDB: Doing recovery: scanned up to log sequence number 1580250158592 InnoDB: Doing recovery: scanned up to log sequence number 1580255401472 InnoDB: Doing recovery: scanned up to log sequence number 1580259647133 150318 12:22:39 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 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 150318 12:22:51 InnoDB: Waiting for the background threads to start 150318 12:22:52 InnoDB: 5.5.41 started; log sequence number 1580259647133 150318 12:22:52 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306 150318 12:22:52 [Note] - '0.0.0.0' resolves to '0.0.0.0'; 150318 12:22:52 [Note] Server socket created on IP: '0.0.0.0'. 150318 12:22:52 [Note] Event Scheduler: Loaded 0 events 150318 12:22:52 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.5.41-0ubuntu0.12.04.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) 150318 12:22:53 [ERROR] /usr/sbin/mysqld: Table './v_vrm_2012/lastLogData' is marked as crashed and should be repaired 150318 12:22:53 [Warning] Checking table: './v_vrm_2012/lastLogData' 150318 12:22:54 [ERROR] /usr/sbin/mysqld: Table './mysql/proc' is marked as crashed and should be repaired 150318 12:22:54 [Warning] Checking table: './mysql/proc' 150318 12:25:14 [ERROR] /usr/sbin/mysqld: Table './v_vrm_2012_testing/lastLogData' is marked as crashed and should be repaired 150318 12:25:14 [Warning] Checking table: './v_vrm_2012_testing/lastLogData'