150625 22:53:17 mysqld_safe Number of processes running now: 0 150625 22:53:17 mysqld_safe mysqld restarted 150625 22:53:17 [Note] /usr/libexec/mysqld (mysqld 10.0.19-MariaDB) starting as process 3366 ... 150625 22:53:17 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150625 22:53:17 [Note] InnoDB: The InnoDB memory heap is disabled 150625 22:53:17 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150625 22:53:17 [Note] InnoDB: Memory barrier is not used 150625 22:53:17 [Note] InnoDB: Compressed tables use zlib 1.2.8 150625 22:53:17 [Note] InnoDB: Using Linux native AIO 150625 22:53:17 [Note] InnoDB: Using CPU crc32 instructions 150625 22:53:17 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150625 22:53:17 [Note] InnoDB: Completed initialization of buffer pool 150625 22:53:17 [Note] InnoDB: Highest supported file format is Barracuda. 150625 22:53:17 [Note] InnoDB: The log sequence numbers 31054400373 and 31054400373 in ibdata files do not match the log sequence number 31054400383 in the ib_logfiles! 150625 22:53:17 [Note] InnoDB: Database was not shutdown normally! 150625 22:53:17 [Note] InnoDB: Starting crash recovery. 150625 22:53:17 [Note] InnoDB: Reading tablespace information from the .ibd files... 150625 22:53:17 [Note] InnoDB: Restoring possible half-written data pages 150625 22:53:17 [Note] InnoDB: from the doublewrite buffer... 150625 22:53:17 [Note] InnoDB: 128 rollback segment(s) are active. 150625 22:53:17 [Note] InnoDB: Waiting for purge to start 150625 22:53:18 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.23-72.1 started; log sequence number 31054400383 150625 22:53:18 [Note] Recovering after a crash using tc.log 150625 22:53:18 [Note] Starting crash recovery... 150625 22:53:18 [Note] Crash recovery finished. 150625 22:53:18 [Note] Server socket created on IP: '::'. 150625 22:53:18 [Note] Event Scheduler: Loaded 0 events 150625 22:53:18 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.19-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150625 22:53:20 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:53:20 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:53:20 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.19-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f41501ba3d8 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 = 0x7f414e6a3dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f414e15837d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f414dcd0e3d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f414d373430] /usr/libexec/mysqld(+0x8688a4)[0x7f414e00a8a4] /usr/libexec/mysqld(+0x7b51b2)[0x7f414df571b2] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f414dc6574c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f414dc67b30] /usr/libexec/mysqld(+0x602a8f)[0x7f414dda4a8f] /usr/libexec/mysqld(+0x602f3d)[0x7f414dda4f3d] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f414ddb6ff8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f414dc0982a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f414db72d64] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f414db76cd3] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f414db78701] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f414dc3cb82] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f414dc3cc20] /lib64/libpthread.so.0(+0x3775a07555)[0x7f414d36a555] /lib64/libc.so.6(clone+0x6d)[0x7f414b901f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f410c004c60): update `taganka-demo`.`appl_profile_doc` set `date_of_issue` = '2010-01-13' where `id_doc` = '5929b9e6-ff5e-11e4-94b6-e86a5c8ba7a2' and `id_profile` = '10b1d51c-ff5e-11e4-94b6-e86a5c8ba7a2' and `id_doc_type` = '1' and `series` = '8002' and `number` = '12345678' and `date_of_issue` = '2010-01-01' and `date_of_expire` is null and `authority` is null and `subdivision_code` is null and `priority_type` is null and `ldate` is null and `mdate` = '2015-06-25 22:41:34' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150625 22:53:20 mysqld_safe Number of processes running now: 0 150625 22:53:20 mysqld_safe mysqld restarted 150625 22:53:20 [Note] /usr/libexec/mysqld (mysqld 10.0.19-MariaDB) starting as process 3442 ... 150625 22:53:20 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150625 22:53:20 [Note] InnoDB: The InnoDB memory heap is disabled 150625 22:53:20 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150625 22:53:20 [Note] InnoDB: Memory barrier is not used 150625 22:53:20 [Note] InnoDB: Compressed tables use zlib 1.2.8 150625 22:53:20 [Note] InnoDB: Using Linux native AIO 150625 22:53:20 [Note] InnoDB: Using CPU crc32 instructions 150625 22:53:20 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150625 22:53:20 [Note] InnoDB: Completed initialization of buffer pool 150625 22:53:20 [Note] InnoDB: Highest supported file format is Barracuda. 150625 22:53:20 [Note] InnoDB: The log sequence numbers 31054400373 and 31054400373 in ibdata files do not match the log sequence number 31054400393 in the ib_logfiles! 150625 22:53:20 [Note] InnoDB: Database was not shutdown normally! 150625 22:53:20 [Note] InnoDB: Starting crash recovery. 150625 22:53:20 [Note] InnoDB: Reading tablespace information from the .ibd files... 150625 22:53:20 [Note] InnoDB: Restoring possible half-written data pages 150625 22:53:20 [Note] InnoDB: from the doublewrite buffer... 150625 22:53:20 [Note] InnoDB: 128 rollback segment(s) are active. 150625 22:53:20 [Note] InnoDB: Waiting for purge to start 150625 22:53:20 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.23-72.1 started; log sequence number 31054400393 150625 22:53:20 [Note] Recovering after a crash using tc.log 150625 22:53:20 [Note] Starting crash recovery... 150625 22:53:20 [Note] Crash recovery finished. 150625 22:53:20 [Note] Server socket created on IP: '::'. 150625 22:53:20 [Note] Event Scheduler: Loaded 0 events 150625 22:53:20 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.19-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150625 22:56:44 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:56:44 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:56:44 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:56:44 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:56:44 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:56:44 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:56:44 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:56:44 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:56:53 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:56:53 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:56:53 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:56:53 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:56:53 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:56:53 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:56:53 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:56:53 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:57:14 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:57:14 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:57:14 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:57:14 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:57:14 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:57:14 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:57:14 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:57:14 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:57:16 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:57:16 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:57:16 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:57:16 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:57:16 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:57:16 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:57:16 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:57:16 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:57:17 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:57:17 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:57:17 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:57:17 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:57:17 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:57:17 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:57:17 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:57:17 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:58:21 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150625 22:58:23 [Note] feedback plugin: server replied 'ok' 150625 22:58:42 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:58:42 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:58:42 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:58:42 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:58:42 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:58:42 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:58:42 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:58:42 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:59:09 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:59:09 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:59:09 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:59:09 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:59:09 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:59:09 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:59:09 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:59:09 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:59:09 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:59:09 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:59:09 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:59:09 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:59:09 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:59:09 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:59:09 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:59:09 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:59:09 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:59:09 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:59:09 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:59:09 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:59:09 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:59:09 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 22:59:09 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 22:59:09 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:00:50 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:00:50 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:00:50 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:00:50 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:00:50 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:00:50 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:00:50 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:00:50 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:01:21 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:01:21 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:01:21 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:01:21 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:01:21 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:01:21 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:01:21 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:01:21 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:01:21 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:01:21 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:01:21 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:01:21 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:01:21 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:01:21 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:01:21 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:01:21 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:01:21 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:01:21 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:01:21 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:01:21 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:01:21 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:01:21 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:01:21 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:01:21 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:03:38 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:03:38 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:03:38 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:03:38 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:03:38 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:03:38 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:03:38 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:03:38 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:04:08 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:04:08 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:04:08 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:04:08 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:04:08 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:04:08 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:04:08 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:04:08 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:04:08 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:04:08 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:04:08 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:04:08 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:04:08 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:04:08 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:04:08 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:04:08 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:04:08 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:04:08 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:04:08 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:04:08 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:04:08 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:04:08 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:04:08 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150625 23:04:08 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150625 23:42:43 [Warning] IP address '222.186.190.124' could not be resolved: Name or service not known 150626 10:46:20 [Warning] IP address '222.186.62.55' could not be resolved: Name or service not known 150626 11:05:04 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150626 11:05:04 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150626 13:02:26 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150626 13:02:26 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150626 13:02:27 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150626 13:02:27 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150626 13:02:27 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150626 13:02:27 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150626 15:31:50 [Warning] IP address '222.186.59.142' could not be resolved: Name or service not known 150626 16:30:35 [Note] /usr/libexec/mysqld: Normal shutdown 150626 16:30:35 [Note] Event Scheduler: Purging the queue. 0 events 150626 16:30:36 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150626 16:30:39 [Note] feedback plugin: server replied 'ok' 150626 16:30:39 [Note] InnoDB: FTS optimize thread exiting. 150626 16:30:39 [Note] InnoDB: Starting shutdown... 150626 16:30:41 [Note] InnoDB: Shutdown completed; log sequence number 32388419792 150626 16:30:41 [Note] /usr/libexec/mysqld: Shutdown complete 150626 16:30:41 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended 150626 16:31:27 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150626 16:31:29 [Note] /usr/libexec/mysqld (mysqld 10.0.19-MariaDB) starting as process 687 ... 150626 16:31:30 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150626 16:31:30 [Note] InnoDB: The InnoDB memory heap is disabled 150626 16:31:30 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150626 16:31:30 [Note] InnoDB: Memory barrier is not used 150626 16:31:30 [Note] InnoDB: Compressed tables use zlib 1.2.8 150626 16:31:30 [Note] InnoDB: Using Linux native AIO 150626 16:31:30 [Note] InnoDB: Using CPU crc32 instructions 150626 16:31:30 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150626 16:31:30 [Note] InnoDB: Completed initialization of buffer pool 150626 16:31:30 [Note] InnoDB: Highest supported file format is Barracuda. 150626 16:31:33 [Note] InnoDB: 128 rollback segment(s) are active. 150626 16:31:33 [Note] InnoDB: Waiting for purge to start 150626 16:31:34 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.23-72.1 started; log sequence number 32388419792 150626 16:31:34 [Note] Server socket created on IP: '::'. 150626 16:31:34 [Note] Event Scheduler: Loaded 0 events 150626 16:31:34 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.19-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150626 16:36:34 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150626 16:36:37 [Note] feedback plugin: server replied 'ok' 150626 16:44:57 [Warning] IP address '5.39.222.253' could not be resolved: Name or service not known 150627 7:47:02 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150627 7:47:02 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150627 7:47:03 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150627 7:47:03 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150627 7:47:03 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150627 7:47:03 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150627 7:47:04 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150627 7:47:04 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150627 8:03:55 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.19-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=4 max_threads=153 thread_count=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f83a42e88c8 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 = 0x7f838c1b6dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f83a21b037d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f83a1d28e3d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f83a13cb430] /usr/libexec/mysqld(+0x8688a4)[0x7f83a20628a4] /usr/libexec/mysqld(+0x7b51b2)[0x7f83a1faf1b2] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f83a1cbd74c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f83a1cbfb30] /usr/libexec/mysqld(+0x602a8f)[0x7f83a1dfca8f] /usr/libexec/mysqld(+0x602f3d)[0x7f83a1dfcf3d] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f83a1e0eff8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f83a1c6182a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f83a1bcad64] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f83a1bcecd3] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f83a1bd0701] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f83a1c94b82] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f83a1c94c20] /lib64/libpthread.so.0(+0x3775a07555)[0x7f83a13c2555] /lib64/libc.so.6(clone+0x6d)[0x7f839f959f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f8354004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '2' where `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' and `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' and `id_doc_type` = '1' and `series` = '1' and `number` = '1' and `date_of_issue` = '2015-06-12' and `date_of_expire` is null and `authority` is null and `subdivision_code` is null and `priority_type` is null and `ldate` is null and `mdate` = '2015-06-25 22:41:34' Connection ID (thread ID): 6 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150627 08:03:55 mysqld_safe Number of processes running now: 0 150627 08:03:55 mysqld_safe mysqld restarted 150627 8:03:55 [Note] /usr/libexec/mysqld (mysqld 10.0.19-MariaDB) starting as process 11521 ... 150627 8:03:55 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150627 8:03:55 [Note] InnoDB: The InnoDB memory heap is disabled 150627 8:03:55 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150627 8:03:55 [Note] InnoDB: Memory barrier is not used 150627 8:03:55 [Note] InnoDB: Compressed tables use zlib 1.2.8 150627 8:03:55 [Note] InnoDB: Using Linux native AIO 150627 8:03:55 [Note] InnoDB: Using CPU crc32 instructions 150627 8:03:55 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150627 8:03:55 [Note] InnoDB: Completed initialization of buffer pool 150627 8:03:55 [Note] InnoDB: Highest supported file format is Barracuda. 150627 8:03:55 [Note] InnoDB: The log sequence numbers 32388419792 and 32388419792 in ibdata files do not match the log sequence number 33500219873 in the ib_logfiles! 150627 8:03:55 [Note] InnoDB: Database was not shutdown normally! 150627 8:03:55 [Note] InnoDB: Starting crash recovery. 150627 8:03:55 [Note] InnoDB: Reading tablespace information from the .ibd files... 150627 8:03:58 [Note] InnoDB: Restoring possible half-written data pages 150627 8:03:58 [Note] InnoDB: from the doublewrite buffer... 150627 8:03:59 [Note] InnoDB: 128 rollback segment(s) are active. 150627 8:03:59 [Note] InnoDB: Waiting for purge to start 150627 8:03:59 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.23-72.1 started; log sequence number 33500219873 150627 8:03:59 [Note] Recovering after a crash using tc.log 150627 8:03:59 [Note] Starting crash recovery... 150627 8:03:59 [Note] Crash recovery finished. 150627 8:03:59 [Note] Server socket created on IP: '::'. 150627 8:04:00 [Note] Event Scheduler: Loaded 0 events 150627 8:04:00 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.19-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150627 8:04:24 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150627 8:04:24 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150627 8:05:00 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.19-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f7a5c556b68 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 = 0x7f7a5a208dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f7a59cbd37d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f7a59835e3d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f7a58ed8430] /usr/libexec/mysqld(+0x8688a4)[0x7f7a59b6f8a4] /usr/libexec/mysqld(+0x7b51b2)[0x7f7a59abc1b2] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f7a597ca74c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f7a597ccb30] /usr/libexec/mysqld(+0x602a8f)[0x7f7a59909a8f] /usr/libexec/mysqld(+0x602f3d)[0x7f7a59909f3d] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f7a5991bff8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f7a5976e82a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f7a596d7d64] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f7a596dbcd3] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f7a596dd701] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f7a597a1b82] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f7a597a1c20] /lib64/libpthread.so.0(+0x3775a07555)[0x7f7a58ecf555] /lib64/libc.so.6(clone+0x6d)[0x7f7a57466f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f7a0c004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '4' where `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' and `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' and `id_doc_type` = '1' and `series` = '1' and `number` = '1' and `date_of_issue` = '2015-06-12' and `date_of_expire` is null and `authority` is null and `subdivision_code` is null and `priority_type` is null and `ldate` is null and `mdate` = '2015-06-25 22:41:34' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150627 08:05:00 mysqld_safe Number of processes running now: 0 150627 08:05:00 mysqld_safe mysqld restarted 150627 8:05:00 [Note] /usr/libexec/mysqld (mysqld 10.0.19-MariaDB) starting as process 11627 ... 150627 8:05:00 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150627 8:05:00 [Note] InnoDB: The InnoDB memory heap is disabled 150627 8:05:00 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150627 8:05:00 [Note] InnoDB: Memory barrier is not used 150627 8:05:00 [Note] InnoDB: Compressed tables use zlib 1.2.8 150627 8:05:00 [Note] InnoDB: Using Linux native AIO 150627 8:05:00 [Note] InnoDB: Using CPU crc32 instructions 150627 8:05:00 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150627 8:05:00 [Note] InnoDB: Completed initialization of buffer pool 150627 8:05:00 [Note] InnoDB: Highest supported file format is Barracuda. 150627 8:05:00 [Note] InnoDB: The log sequence numbers 32388419792 and 32388419792 in ibdata files do not match the log sequence number 33500222811 in the ib_logfiles! 150627 8:05:00 [Note] InnoDB: Database was not shutdown normally! 150627 8:05:00 [Note] InnoDB: Starting crash recovery. 150627 8:05:00 [Note] InnoDB: Reading tablespace information from the .ibd files... 150627 8:05:00 [Note] InnoDB: Restoring possible half-written data pages 150627 8:05:00 [Note] InnoDB: from the doublewrite buffer... 150627 8:05:01 [Note] InnoDB: 128 rollback segment(s) are active. 150627 8:05:01 [Note] InnoDB: Waiting for purge to start 150627 8:05:01 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.23-72.1 started; log sequence number 33500222811 150627 8:05:01 [Note] Recovering after a crash using tc.log 150627 8:05:01 [Note] Starting crash recovery... 150627 8:05:01 [Note] Crash recovery finished. 150627 8:05:01 [Note] Server socket created on IP: '::'. 150627 8:05:01 [Note] Event Scheduler: Loaded 0 events 150627 8:05:01 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.19-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150627 8:05:03 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150627 8:05:03 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150627 8:05:03 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.19-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f9b32b7ab68 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 = 0x7f9b30442dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f9b2fef737d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f9b2fa6fe3d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f9b2f112430] /usr/libexec/mysqld(+0x8688a4)[0x7f9b2fda98a4] /usr/libexec/mysqld(+0x7b51b2)[0x7f9b2fcf61b2] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f9b2fa0474c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f9b2fa06b30] /usr/libexec/mysqld(+0x602a8f)[0x7f9b2fb43a8f] /usr/libexec/mysqld(+0x602f3d)[0x7f9b2fb43f3d] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f9b2fb55ff8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f9b2f9a882a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f9b2f911d64] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f9b2f915cd3] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f9b2f917701] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f9b2f9dbb82] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f9b2f9dbc20] /lib64/libpthread.so.0(+0x3775a07555)[0x7f9b2f109555] /lib64/libc.so.6(clone+0x6d)[0x7f9b2d6a0f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f9aec004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '4' where `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' and `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' and `id_doc_type` = '1' and `series` = '1' and `number` = '1' and `date_of_issue` = '2015-06-12' and `date_of_expire` is null and `authority` is null and `subdivision_code` is null and `priority_type` is null and `ldate` is null and `mdate` = '2015-06-25 22:41:34' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150627 08:05:03 mysqld_safe Number of processes running now: 0 150627 08:05:03 mysqld_safe mysqld restarted 150627 8:05:03 [Note] /usr/libexec/mysqld (mysqld 10.0.19-MariaDB) starting as process 11700 ... 150627 8:05:03 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150627 8:05:03 [Note] InnoDB: The InnoDB memory heap is disabled 150627 8:05:03 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150627 8:05:03 [Note] InnoDB: Memory barrier is not used 150627 8:05:03 [Note] InnoDB: Compressed tables use zlib 1.2.8 150627 8:05:03 [Note] InnoDB: Using Linux native AIO 150627 8:05:03 [Note] InnoDB: Using CPU crc32 instructions 150627 8:05:03 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150627 8:05:03 [Note] InnoDB: Completed initialization of buffer pool 150627 8:05:03 [Note] InnoDB: Highest supported file format is Barracuda. 150627 8:05:03 [Note] InnoDB: The log sequence numbers 32388419792 and 32388419792 in ibdata files do not match the log sequence number 33500222821 in the ib_logfiles! 150627 8:05:03 [Note] InnoDB: Database was not shutdown normally! 150627 8:05:03 [Note] InnoDB: Starting crash recovery. 150627 8:05:03 [Note] InnoDB: Reading tablespace information from the .ibd files... 150627 8:05:03 [Note] InnoDB: Restoring possible half-written data pages 150627 8:05:03 [Note] InnoDB: from the doublewrite buffer... 150627 8:05:03 [Note] InnoDB: 128 rollback segment(s) are active. 150627 8:05:03 [Note] InnoDB: Waiting for purge to start 150627 8:05:03 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.23-72.1 started; log sequence number 33500222821 150627 8:05:03 [Note] Recovering after a crash using tc.log 150627 8:05:03 [Note] Starting crash recovery... 150627 8:05:03 [Note] Crash recovery finished. 150627 8:05:03 [Note] Server socket created on IP: '::'. 150627 8:05:03 [Note] Event Scheduler: Loaded 0 events 150627 8:05:03 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.19-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150627 8:09:15 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150627 8:09:15 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150627 8:09:26 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.19-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f8445dd1b68 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 = 0x7f8443c99dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f844374e37d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f84432c6e3d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f8442969430] /usr/libexec/mysqld(+0x8688a4)[0x7f84436008a4] /usr/libexec/mysqld(+0x7b51b2)[0x7f844354d1b2] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f844325b74c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f844325db30] /usr/libexec/mysqld(+0x602a8f)[0x7f844339aa8f] /usr/libexec/mysqld(+0x602f3d)[0x7f844339af3d] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f84433acff8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f84431ff82a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f8443168d64] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f844316ccd3] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f844316e701] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f8443232b82] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f8443232c20] /lib64/libpthread.so.0(+0x3775a07555)[0x7f8442960555] /lib64/libc.so.6(clone+0x6d)[0x7f8440ef7f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f8400004c60): update `taganka-demo`.`appl_profile_addr` set `id_property_type` = '1' where `id_profile` = 'b79c6fdc-6afe-11e4-a1d2-0050563c3a6d' and `addr_type` = 'fact' and `kladr_code` = '02000001000130400' and `fullname` = '450059, , , , 50 , .2' and `country` = ' ' and `region` = ' ' and `build` is null and `korp` is null and `stroen` is null and `flat` is null and `room` is null and `index` = '450059' and `okato` = '80401390000' and `cntrid` = 'RU' and `cntrcode` = '643' and `raion` is null and `city` = ' ' and `place` = '' and `street` = ' 50 ' and `house` = '2' and `rfsub` = '02' and `reg_addr_type` is null and `reg_addr_date` is null and `reg_addr_date_end` is null and `mdate` is null and `ldate` is null and `office` is null and `attendance` is null and `id_property_type` is null and `id_address` = 'de37aa49-6afe-11e4-a1d2-0050563c3a6d' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150627 08:09:26 mysqld_safe Number of processes running now: 0 150627 08:09:26 mysqld_safe mysqld restarted 150627 8:09:26 [Note] /usr/libexec/mysqld (mysqld 10.0.19-MariaDB) starting as process 11747 ... 150627 8:09:26 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150627 8:09:26 [Note] InnoDB: The InnoDB memory heap is disabled 150627 8:09:26 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150627 8:09:26 [Note] InnoDB: Memory barrier is not used 150627 8:09:26 [Note] InnoDB: Compressed tables use zlib 1.2.8 150627 8:09:26 [Note] InnoDB: Using Linux native AIO 150627 8:09:26 [Note] InnoDB: Using CPU crc32 instructions 150627 8:09:26 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150627 8:09:26 [Note] InnoDB: Completed initialization of buffer pool 150627 8:09:26 [Note] InnoDB: Highest supported file format is Barracuda. 150627 8:09:26 [Note] InnoDB: The log sequence numbers 32388419792 and 32388419792 in ibdata files do not match the log sequence number 33500223111 in the ib_logfiles! 150627 8:09:26 [Note] InnoDB: Database was not shutdown normally! 150627 8:09:26 [Note] InnoDB: Starting crash recovery. 150627 8:09:26 [Note] InnoDB: Reading tablespace information from the .ibd files... 150627 8:09:26 [Note] InnoDB: Restoring possible half-written data pages 150627 8:09:26 [Note] InnoDB: from the doublewrite buffer... 150627 8:09:26 [Note] InnoDB: 128 rollback segment(s) are active. 150627 8:09:26 [Note] InnoDB: Waiting for purge to start 150627 8:09:26 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.23-72.1 started; log sequence number 33500223111 150627 8:09:26 [Note] Recovering after a crash using tc.log 150627 8:09:26 [Note] Starting crash recovery... 150627 8:09:26 [Note] Crash recovery finished. 150627 8:09:26 [Note] Server socket created on IP: '::'. 150627 8:09:26 [Note] Event Scheduler: Loaded 0 events 150627 8:09:26 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.19-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150627 8:09:28 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150627 8:09:28 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150627 8:09:28 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.19-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f989c6aab68 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 = 0x7f989ab74dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f989a62937d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f989a1a1e3d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f9899844430] /usr/libexec/mysqld(+0x8688a4)[0x7f989a4db8a4] /usr/libexec/mysqld(+0x7b51b2)[0x7f989a4281b2] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f989a13674c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f989a138b30] /usr/libexec/mysqld(+0x602a8f)[0x7f989a275a8f] /usr/libexec/mysqld(+0x602f3d)[0x7f989a275f3d] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f989a287ff8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f989a0da82a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f989a043d64] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f989a047cd3] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f989a049701] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f989a10db82] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f989a10dc20] /lib64/libpthread.so.0(+0x3775a07555)[0x7f989983b555] /lib64/libc.so.6(clone+0x6d)[0x7f9897dd2f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f9858004c60): update `taganka-demo`.`appl_profile_addr` set `id_property_type` = '1' where `id_profile` = 'b79c6fdc-6afe-11e4-a1d2-0050563c3a6d' and `addr_type` = 'fact' and `kladr_code` = '02000001000130400' and `fullname` = '450059, , , , 50 , .2' and `country` = ' ' and `region` = ' ' and `build` is null and `korp` is null and `stroen` is null and `flat` is null and `room` is null and `index` = '450059' and `okato` = '80401390000' and `cntrid` = 'RU' and `cntrcode` = '643' and `raion` is null and `city` = ' ' and `place` = '' and `street` = ' 50 ' and `house` = '2' and `rfsub` = '02' and `reg_addr_type` is null and `reg_addr_date` is null and `reg_addr_date_end` is null and `mdate` is null and `ldate` is null and `office` is null and `attendance` is null and `id_property_type` is null and `id_address` = 'de37aa49-6afe-11e4-a1d2-0050563c3a6d' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150627 08:09:28 mysqld_safe Number of processes running now: 0 150627 08:09:28 mysqld_safe mysqld restarted 150627 8:09:28 [Note] /usr/libexec/mysqld (mysqld 10.0.19-MariaDB) starting as process 11821 ... 150627 8:09:28 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150627 8:09:28 [Note] InnoDB: The InnoDB memory heap is disabled 150627 8:09:28 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150627 8:09:28 [Note] InnoDB: Memory barrier is not used 150627 8:09:28 [Note] InnoDB: Compressed tables use zlib 1.2.8 150627 8:09:28 [Note] InnoDB: Using Linux native AIO 150627 8:09:28 [Note] InnoDB: Using CPU crc32 instructions 150627 8:09:28 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150627 8:09:28 [Note] InnoDB: Completed initialization of buffer pool 150627 8:09:28 [Note] InnoDB: Highest supported file format is Barracuda. 150627 8:09:28 [Note] InnoDB: The log sequence numbers 32388419792 and 32388419792 in ibdata files do not match the log sequence number 33500223121 in the ib_logfiles! 150627 8:09:28 [Note] InnoDB: Database was not shutdown normally! 150627 8:09:28 [Note] InnoDB: Starting crash recovery. 150627 8:09:28 [Note] InnoDB: Reading tablespace information from the .ibd files... 150627 8:09:28 [Note] InnoDB: Restoring possible half-written data pages 150627 8:09:29 [Note] InnoDB: from the doublewrite buffer... 150627 8:09:29 [Note] InnoDB: 128 rollback segment(s) are active. 150627 8:09:29 [Note] InnoDB: Waiting for purge to start 150627 8:09:29 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.23-72.1 started; log sequence number 33500223121 150627 8:09:29 [Note] Recovering after a crash using tc.log 150627 8:09:29 [Note] Starting crash recovery... 150627 8:09:29 [Note] Crash recovery finished. 150627 8:09:29 [Note] Server socket created on IP: '::'. 150627 8:09:29 [Note] Event Scheduler: Loaded 0 events 150627 8:09:29 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.19-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150627 8:09:34 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150627 8:09:34 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150627 8:09:34 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.19-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f8130237b68 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 = 0x7f812d9a8dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f812d45d37d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f812cfd5e3d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f812c678430] /usr/libexec/mysqld(+0x8688a4)[0x7f812d30f8a4] /usr/libexec/mysqld(+0x7b51b2)[0x7f812d25c1b2] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f812cf6a74c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f812cf6cb30] /usr/libexec/mysqld(+0x602a8f)[0x7f812d0a9a8f] /usr/libexec/mysqld(+0x602f3d)[0x7f812d0a9f3d] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f812d0bbff8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f812cf0e82a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f812ce77d64] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f812ce7bcd3] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f812ce7d701] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f812cf41b82] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f812cf41c20] /lib64/libpthread.so.0(+0x3775a07555)[0x7f812c66f555] /lib64/libc.so.6(clone+0x6d)[0x7f812ac06f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f80ec004c60): update `taganka-demo`.`appl_profile_addr` set `id_property_type` = '1' where `id_profile` = 'b79c6fdc-6afe-11e4-a1d2-0050563c3a6d' and `addr_type` = 'fact' and `kladr_code` = '02000001000130400' and `fullname` = '450059, , , , 50 , .2' and `country` = ' ' and `region` = ' ' and `build` is null and `korp` is null and `stroen` is null and `flat` is null and `room` is null and `index` = '450059' and `okato` = '80401390000' and `cntrid` = 'RU' and `cntrcode` = '643' and `raion` is null and `city` = ' ' and `place` = '' and `street` = ' 50 ' and `house` = '2' and `rfsub` = '02' and `reg_addr_type` is null and `reg_addr_date` is null and `reg_addr_date_end` is null and `mdate` is null and `ldate` is null and `office` is null and `attendance` is null and `id_property_type` is null and `id_address` = 'de37aa49-6afe-11e4-a1d2-0050563c3a6d' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150627 08:09:34 mysqld_safe Number of processes running now: 0 150627 08:09:34 mysqld_safe mysqld restarted 150627 8:09:34 [Note] /usr/libexec/mysqld (mysqld 10.0.19-MariaDB) starting as process 11863 ... 150627 8:09:34 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150627 8:09:34 [Note] InnoDB: The InnoDB memory heap is disabled 150627 8:09:34 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150627 8:09:34 [Note] InnoDB: Memory barrier is not used 150627 8:09:34 [Note] InnoDB: Compressed tables use zlib 1.2.8 150627 8:09:34 [Note] InnoDB: Using Linux native AIO 150627 8:09:34 [Note] InnoDB: Using CPU crc32 instructions 150627 8:09:34 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150627 8:09:34 [Note] InnoDB: Completed initialization of buffer pool 150627 8:09:34 [Note] InnoDB: Highest supported file format is Barracuda. 150627 8:09:34 [Note] InnoDB: The log sequence numbers 32388419792 and 32388419792 in ibdata files do not match the log sequence number 33500223131 in the ib_logfiles! 150627 8:09:34 [Note] InnoDB: Database was not shutdown normally! 150627 8:09:34 [Note] InnoDB: Starting crash recovery. 150627 8:09:34 [Note] InnoDB: Reading tablespace information from the .ibd files... 150627 8:09:34 [Note] InnoDB: Restoring possible half-written data pages 150627 8:09:34 [Note] InnoDB: from the doublewrite buffer... 150627 8:09:35 [Note] InnoDB: 128 rollback segment(s) are active. 150627 8:09:35 [Note] InnoDB: Waiting for purge to start 150627 8:09:35 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.23-72.1 started; log sequence number 33500223131 150627 8:09:35 [Note] Recovering after a crash using tc.log 150627 8:09:35 [Note] Starting crash recovery... 150627 8:09:35 [Note] Crash recovery finished. 150627 8:09:35 [Note] Server socket created on IP: '::'. 150627 8:09:35 [Note] Event Scheduler: Loaded 0 events 150627 8:09:35 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.19-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150627 8:09:37 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150627 8:09:37 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150627 8:09:37 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.19-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7fa721423b68 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 = 0x7fa71ef01dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7fa71e9b637d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7fa71e52ee3d] /lib64/libpthread.so.0(+0x3775a10430)[0x7fa71dbd1430] /usr/libexec/mysqld(+0x8688a4)[0x7fa71e8688a4] /usr/libexec/mysqld(+0x7b51b2)[0x7fa71e7b51b2] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7fa71e4c374c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7fa71e4c5b30] /usr/libexec/mysqld(+0x602a8f)[0x7fa71e602a8f] /usr/libexec/mysqld(+0x602f3d)[0x7fa71e602f3d] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7fa71e614ff8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7fa71e46782a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7fa71e3d0d64] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7fa71e3d4cd3] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7fa71e3d6701] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7fa71e49ab82] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7fa71e49ac20] /lib64/libpthread.so.0(+0x3775a07555)[0x7fa71dbc8555] /lib64/libc.so.6(clone+0x6d)[0x7fa71c15ff3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fa6dc004c60): update `taganka-demo`.`appl_profile_addr` set `id_property_type` = '1' where `id_profile` = 'b79c6fdc-6afe-11e4-a1d2-0050563c3a6d' and `addr_type` = 'fact' and `kladr_code` = '02000001000130400' and `fullname` = '450059, , , , 50 , .2' and `country` = ' ' and `region` = ' ' and `build` is null and `korp` is null and `stroen` is null and `flat` is null and `room` is null and `index` = '450059' and `okato` = '80401390000' and `cntrid` = 'RU' and `cntrcode` = '643' and `raion` is null and `city` = ' ' and `place` = '' and `street` = ' 50 ' and `house` = '2' and `rfsub` = '02' and `reg_addr_type` is null and `reg_addr_date` is null and `reg_addr_date_end` is null and `mdate` is null and `ldate` is null and `office` is null and `attendance` is null and `id_property_type` is null and `id_address` = 'de37aa49-6afe-11e4-a1d2-0050563c3a6d' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150627 08:09:37 mysqld_safe Number of processes running now: 0 150627 08:09:37 mysqld_safe mysqld restarted 150627 8:09:37 [Note] /usr/libexec/mysqld (mysqld 10.0.19-MariaDB) starting as process 11936 ... 150627 8:09:37 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150627 8:09:37 [Note] InnoDB: The InnoDB memory heap is disabled 150627 8:09:37 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150627 8:09:37 [Note] InnoDB: Memory barrier is not used 150627 8:09:37 [Note] InnoDB: Compressed tables use zlib 1.2.8 150627 8:09:37 [Note] InnoDB: Using Linux native AIO 150627 8:09:37 [Note] InnoDB: Using CPU crc32 instructions 150627 8:09:37 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150627 8:09:37 [Note] InnoDB: Completed initialization of buffer pool 150627 8:09:37 [Note] InnoDB: Highest supported file format is Barracuda. 150627 8:09:37 [Note] InnoDB: The log sequence numbers 32388419792 and 32388419792 in ibdata files do not match the log sequence number 33500223141 in the ib_logfiles! 150627 8:09:37 [Note] InnoDB: Database was not shutdown normally! 150627 8:09:37 [Note] InnoDB: Starting crash recovery. 150627 8:09:37 [Note] InnoDB: Reading tablespace information from the .ibd files... 150627 8:09:37 [Note] InnoDB: Restoring possible half-written data pages 150627 8:09:37 [Note] InnoDB: from the doublewrite buffer... 150627 8:09:37 [Note] InnoDB: 128 rollback segment(s) are active. 150627 8:09:37 [Note] InnoDB: Waiting for purge to start 150627 8:09:37 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.23-72.1 started; log sequence number 33500223141 150627 8:09:37 [Note] Recovering after a crash using tc.log 150627 8:09:37 [Note] Starting crash recovery... 150627 8:09:37 [Note] Crash recovery finished. 150627 8:09:37 [Note] Server socket created on IP: '::'. 150627 8:09:37 [Note] Event Scheduler: Loaded 0 events 150627 8:09:37 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.19-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150627 8:09:42 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150627 8:09:42 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150627 8:09:42 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.19-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f7aa2d71b68 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 = 0x7f7aa0fcedc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f7aa0a8337d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f7aa05fbe3d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f7a9fc9e430] /usr/libexec/mysqld(+0x8688a4)[0x7f7aa09358a4] /usr/libexec/mysqld(+0x7b51b2)[0x7f7aa08821b2] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f7aa059074c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f7aa0592b30] /usr/libexec/mysqld(+0x602a8f)[0x7f7aa06cfa8f] /usr/libexec/mysqld(+0x602f3d)[0x7f7aa06cff3d] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f7aa06e1ff8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f7aa053482a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f7aa049dd64] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f7aa04a1cd3] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f7aa04a3701] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f7aa0567b82] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f7aa0567c20] /lib64/libpthread.so.0(+0x3775a07555)[0x7f7a9fc95555] /lib64/libc.so.6(clone+0x6d)[0x7f7a9e22cf3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f7a60004c60): update `taganka-demo`.`appl_profile_addr` set `id_property_type` = '1' where `id_profile` = 'b79c6fdc-6afe-11e4-a1d2-0050563c3a6d' and `addr_type` = 'fact' and `kladr_code` = '02000001000130400' and `fullname` = '450059, , , , 50 , .2' and `country` = ' ' and `region` = ' ' and `build` is null and `korp` is null and `stroen` is null and `flat` is null and `room` is null and `index` = '450059' and `okato` = '80401390000' and `cntrid` = 'RU' and `cntrcode` = '643' and `raion` is null and `city` = ' ' and `place` = '' and `street` = ' 50 ' and `house` = '2' and `rfsub` = '02' and `reg_addr_type` is null and `reg_addr_date` is null and `reg_addr_date_end` is null and `mdate` is null and `ldate` is null and `office` is null and `attendance` is null and `id_property_type` is null and `id_address` = 'de37aa49-6afe-11e4-a1d2-0050563c3a6d' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150627 08:09:43 mysqld_safe Number of processes running now: 0 150627 08:09:43 mysqld_safe mysqld restarted 150627 8:09:43 [Note] /usr/libexec/mysqld (mysqld 10.0.19-MariaDB) starting as process 11978 ... 150627 8:09:43 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150627 8:09:43 [Note] InnoDB: The InnoDB memory heap is disabled 150627 8:09:43 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150627 8:09:43 [Note] InnoDB: Memory barrier is not used 150627 8:09:43 [Note] InnoDB: Compressed tables use zlib 1.2.8 150627 8:09:43 [Note] InnoDB: Using Linux native AIO 150627 8:09:43 [Note] InnoDB: Using CPU crc32 instructions 150627 8:09:43 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150627 8:09:43 [Note] InnoDB: Completed initialization of buffer pool 150627 8:09:43 [Note] InnoDB: Highest supported file format is Barracuda. 150627 8:09:43 [Note] InnoDB: The log sequence numbers 32388419792 and 32388419792 in ibdata files do not match the log sequence number 33500223151 in the ib_logfiles! 150627 8:09:43 [Note] InnoDB: Database was not shutdown normally! 150627 8:09:43 [Note] InnoDB: Starting crash recovery. 150627 8:09:43 [Note] InnoDB: Reading tablespace information from the .ibd files... 150627 8:09:43 [Note] InnoDB: Restoring possible half-written data pages 150627 8:09:43 [Note] InnoDB: from the doublewrite buffer... 150627 8:09:43 [Note] InnoDB: 128 rollback segment(s) are active. 150627 8:09:43 [Note] InnoDB: Waiting for purge to start 150627 8:09:43 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.23-72.1 started; log sequence number 33500223151 150627 8:09:43 [Note] Recovering after a crash using tc.log 150627 8:09:43 [Note] Starting crash recovery... 150627 8:09:43 [Note] Crash recovery finished. 150627 8:09:43 [Note] Server socket created on IP: '::'. 150627 8:09:43 [Note] Event Scheduler: Loaded 0 events 150627 8:09:43 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.19-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150627 8:09:45 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150627 8:09:45 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150627 8:09:45 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.19-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f45e63e8ef8 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 = 0x7f45e466fdc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f45e412437d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f45e3c9ce3d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f45e333f430] /usr/libexec/mysqld(+0x8688a4)[0x7f45e3fd68a4] /usr/libexec/mysqld(+0x7b51b2)[0x7f45e3f231b2] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f45e3c3174c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f45e3c33b30] /usr/libexec/mysqld(+0x602a8f)[0x7f45e3d70a8f] /usr/libexec/mysqld(+0x602f3d)[0x7f45e3d70f3d] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f45e3d82ff8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f45e3bd582a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f45e3b3ed64] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f45e3b42cd3] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f45e3b44701] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f45e3c08b82] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f45e3c08c20] /lib64/libpthread.so.0(+0x3775a07555)[0x7f45e3336555] /lib64/libc.so.6(clone+0x6d)[0x7f45e18cdf3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f45a0004c60): update `taganka-demo`.`appl_profile_addr` set `id_property_type` = '1' where `id_profile` = 'b79c6fdc-6afe-11e4-a1d2-0050563c3a6d' and `addr_type` = 'fact' and `kladr_code` = '02000001000130400' and `fullname` = '450059, , , , 50 , .2' and `country` = ' ' and `region` = ' ' and `build` is null and `korp` is null and `stroen` is null and `flat` is null and `room` is null and `index` = '450059' and `okato` = '80401390000' and `cntrid` = 'RU' and `cntrcode` = '643' and `raion` is null and `city` = ' ' and `place` = '' and `street` = ' 50 ' and `house` = '2' and `rfsub` = '02' and `reg_addr_type` is null and `reg_addr_date` is null and `reg_addr_date_end` is null and `mdate` is null and `ldate` is null and `office` is null and `attendance` is null and `id_property_type` is null and `id_address` = 'de37aa49-6afe-11e4-a1d2-0050563c3a6d' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150627 08:09:45 mysqld_safe Number of processes running now: 0 150627 08:09:45 mysqld_safe mysqld restarted 150627 8:09:45 [Note] /usr/libexec/mysqld (mysqld 10.0.19-MariaDB) starting as process 12053 ... 150627 8:09:45 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150627 8:09:45 [Note] InnoDB: The InnoDB memory heap is disabled 150627 8:09:45 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150627 8:09:45 [Note] InnoDB: Memory barrier is not used 150627 8:09:45 [Note] InnoDB: Compressed tables use zlib 1.2.8 150627 8:09:45 [Note] InnoDB: Using Linux native AIO 150627 8:09:45 [Note] InnoDB: Using CPU crc32 instructions 150627 8:09:45 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150627 8:09:45 [Note] InnoDB: Completed initialization of buffer pool 150627 8:09:45 [Note] InnoDB: Highest supported file format is Barracuda. 150627 8:09:45 [Note] InnoDB: The log sequence numbers 32388419792 and 32388419792 in ibdata files do not match the log sequence number 33500223161 in the ib_logfiles! 150627 8:09:45 [Note] InnoDB: Database was not shutdown normally! 150627 8:09:45 [Note] InnoDB: Starting crash recovery. 150627 8:09:45 [Note] InnoDB: Reading tablespace information from the .ibd files... 150627 8:09:45 [Note] InnoDB: Restoring possible half-written data pages 150627 8:09:45 [Note] InnoDB: from the doublewrite buffer... 150627 8:09:45 [Note] InnoDB: 128 rollback segment(s) are active. 150627 8:09:45 [Note] InnoDB: Waiting for purge to start 150627 8:09:45 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.23-72.1 started; log sequence number 33500223161 150627 8:09:45 [Note] Recovering after a crash using tc.log 150627 8:09:45 [Note] Starting crash recovery... 150627 8:09:45 [Note] Crash recovery finished. 150627 8:09:45 [Note] Server socket created on IP: '::'. 150627 8:09:45 [Note] Event Scheduler: Loaded 0 events 150627 8:09:45 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.19-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150627 8:13:59 [Note] /usr/libexec/mysqld: Normal shutdown 150627 8:13:59 [Note] Event Scheduler: Purging the queue. 0 events 150627 8:13:59 [Note] InnoDB: FTS optimize thread exiting. 150627 8:13:59 [Note] InnoDB: Starting shutdown... 150627 8:14:00 [Note] InnoDB: Shutdown completed; log sequence number 33500223171 150627 8:14:00 [Note] /usr/libexec/mysqld: Shutdown complete 150627 08:14:00 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended 150628 10:29:39 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150628 10:29:41 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 1109 ... 150628 10:29:43 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150628 10:29:43 [Note] InnoDB: The InnoDB memory heap is disabled 150628 10:29:43 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150628 10:29:43 [Note] InnoDB: Memory barrier is not used 150628 10:29:43 [Note] InnoDB: Compressed tables use zlib 1.2.8 150628 10:29:43 [Note] InnoDB: Using Linux native AIO 150628 10:29:43 [Note] InnoDB: Using CPU crc32 instructions 150628 10:29:43 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150628 10:29:43 [Note] InnoDB: Completed initialization of buffer pool 150628 10:29:44 [Note] InnoDB: Highest supported file format is Barracuda. 150628 10:29:48 [Note] InnoDB: 128 rollback segment(s) are active. 150628 10:29:48 [Note] InnoDB: Waiting for purge to start 150628 10:29:48 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 33500223171 150628 10:29:48 [Note] Server socket created on IP: '::'. 150628 10:29:49 [Note] Event Scheduler: Loaded 0 events 150628 10:29:49 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150628 10:34:49 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150628 10:34:51 [Note] feedback plugin: server replied 'ok' 150628 10:36:24 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150628 10:36:24 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150628 10:36:24 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150628 10:36:24 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150628 10:36:24 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150628 10:36:24 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150628 10:36:24 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150628 10:36:24 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150628 11:06:08 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150628 11:06:08 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150628 11:06:15 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150628 11:06:15 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150628 11:06:15 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=3 max_threads=153 thread_count=3 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f615ba20a38 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 = 0x7f615784cdc0 thread_stack 0x48000 150628 11:06:15 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150628 11:06:15 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f615832b43d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f6157ea324d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f6157545430] /usr/libexec/mysqld(+0x730dd4)[0x7f61580a4dd4] /usr/libexec/mysqld(+0x67cc12)[0x7f6157ff0c12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f6157e37b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f6157e39ef0] /usr/libexec/mysqld(+0x60324f)[0x7f6157f7724f] /usr/libexec/mysqld(+0x6036fd)[0x7f6157f776fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f6157f897b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f6157ddbb8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f6157d451a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f6157d49113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f6157d4ab41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f6157e0ef42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f6157e0efe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7f615753c555] /lib64/libc.so.6(clone+0x6d)[0x7f6155ad3f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f610ce67be0): update `taganka-demo`.`appl_profile_doc` set `series` = '2' where `id_doc` = '02284678-6b01-11e4-a1d2-0050563c3a6d' and `id_profile` = 'e690e802-6b00-11e4-a1d2-0050563c3a6d' and `id_doc_type` = '1' and `series` = '1' and `number` = '1' and `date_of_issue` = '2015-06-12' and `date_of_expire` is null and `authority` is null and `subdivision_code` = '000-000' and `priority_type` is null and `ldate` is null and `mdate` = '2015-06-25 22:41:34' Connection ID (thread ID): 15 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150628 11:06:15 mysqld_safe Number of processes running now: 0 150628 11:06:15 mysqld_safe mysqld restarted 150628 11:06:15 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 1625 ... 150628 11:06:15 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150628 11:06:15 [Note] InnoDB: The InnoDB memory heap is disabled 150628 11:06:15 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150628 11:06:15 [Note] InnoDB: Memory barrier is not used 150628 11:06:15 [Note] InnoDB: Compressed tables use zlib 1.2.8 150628 11:06:15 [Note] InnoDB: Using Linux native AIO 150628 11:06:15 [Note] InnoDB: Using CPU crc32 instructions 150628 11:06:15 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150628 11:06:15 [Note] InnoDB: Completed initialization of buffer pool 150628 11:06:16 [Note] InnoDB: Highest supported file format is Barracuda. 150628 11:06:16 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 33500223211 in the ib_logfiles! 150628 11:06:16 [Note] InnoDB: Database was not shutdown normally! 150628 11:06:16 [Note] InnoDB: Starting crash recovery. 150628 11:06:16 [Note] InnoDB: Reading tablespace information from the .ibd files... 150628 11:06:19 [Note] InnoDB: Restoring possible half-written data pages 150628 11:06:19 [Note] InnoDB: from the doublewrite buffer... 150628 11:06:19 [Note] InnoDB: 128 rollback segment(s) are active. 150628 11:06:19 [Note] InnoDB: Waiting for purge to start 150628 11:06:19 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 33500223211 150628 11:06:19 [Note] Recovering after a crash using tc.log 150628 11:06:19 [Note] Starting crash recovery... 150628 11:06:20 [Note] Crash recovery finished. 150628 11:06:20 [Note] Server socket created on IP: '::'. 150628 11:06:20 [Note] Event Scheduler: Loaded 0 events 150628 11:06:20 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150628 11:06:26 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150628 11:06:26 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150628 11:06:26 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=2 max_threads=153 thread_count=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f04fd8a8a28 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 = 0x7f04fa549dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f04fb07143d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f04fabe924d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f04fa28b430] /usr/libexec/mysqld(+0x730dd4)[0x7f04fadeadd4] /usr/libexec/mysqld(+0x67cc12)[0x7f04fad36c12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f04fab7db0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f04fab7fef0] /usr/libexec/mysqld(+0x60324f)[0x7f04facbd24f] /usr/libexec/mysqld(+0x6036fd)[0x7f04facbd6fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f04faccf7b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f04fab21b8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f04faa8b1a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f04faa8f113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f04faa90b41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f04fab54f42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f04fab54fe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7f04fa282555] /lib64/libc.so.6(clone+0x6d)[0x7f04f8819f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f04ac004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '2' where `id_doc` = '02284678-6b01-11e4-a1d2-0050563c3a6d' and `id_profile` = 'e690e802-6b00-11e4-a1d2-0050563c3a6d' and `id_doc_type` = '1' and `series` = '1' and `number` = '1' and `date_of_issue` = '2015-06-12' and `date_of_expire` is null and `authority` is null and `subdivision_code` = '000-000' and `priority_type` is null and `ldate` is null and `mdate` = '2015-06-25 22:41:34' Connection ID (thread ID): 4 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150628 11:06:26 mysqld_safe Number of processes running now: 0 150628 11:06:26 mysqld_safe mysqld restarted 150628 11:06:26 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 1733 ... 150628 11:06:26 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150628 11:06:26 [Note] InnoDB: The InnoDB memory heap is disabled 150628 11:06:26 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150628 11:06:26 [Note] InnoDB: Memory barrier is not used 150628 11:06:26 [Note] InnoDB: Compressed tables use zlib 1.2.8 150628 11:06:26 [Note] InnoDB: Using Linux native AIO 150628 11:06:26 [Note] InnoDB: Using CPU crc32 instructions 150628 11:06:26 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150628 11:06:26 [Note] InnoDB: Completed initialization of buffer pool 150628 11:06:26 [Note] InnoDB: Highest supported file format is Barracuda. 150628 11:06:26 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 33500223221 in the ib_logfiles! 150628 11:06:26 [Note] InnoDB: Database was not shutdown normally! 150628 11:06:26 [Note] InnoDB: Starting crash recovery. 150628 11:06:26 [Note] InnoDB: Reading tablespace information from the .ibd files... 150628 11:06:26 [Note] InnoDB: Restoring possible half-written data pages 150628 11:06:26 [Note] InnoDB: from the doublewrite buffer... 150628 11:06:26 [Note] InnoDB: 128 rollback segment(s) are active. 150628 11:06:26 [Note] InnoDB: Waiting for purge to start 150628 11:06:26 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 33500223221 150628 11:06:26 [Note] Recovering after a crash using tc.log 150628 11:06:26 [Note] Starting crash recovery... 150628 11:06:26 [Note] Crash recovery finished. 150628 11:06:26 [Note] Server socket created on IP: '::'. 150628 11:06:26 [Note] Event Scheduler: Loaded 0 events 150628 11:06:26 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150628 11:06:28 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150628 11:06:28 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150628 11:06:28 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=2 max_threads=153 thread_count=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f46c5344a28 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 = 0x7f46c19f3dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f46c251b43d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f46c209324d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f46c1735430] /usr/libexec/mysqld(+0x730dd4)[0x7f46c2294dd4] /usr/libexec/mysqld(+0x67cc12)[0x7f46c21e0c12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f46c2027b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f46c2029ef0] /usr/libexec/mysqld(+0x60324f)[0x7f46c216724f] /usr/libexec/mysqld(+0x6036fd)[0x7f46c21676fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f46c21797b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f46c1fcbb8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f46c1f351a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f46c1f39113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f46c1f3ab41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f46c1ffef42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f46c1ffefe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7f46c172c555] /lib64/libc.so.6(clone+0x6d)[0x7f46bfcc3f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f467c004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '2' where `id_doc` = '02284678-6b01-11e4-a1d2-0050563c3a6d' and `id_profile` = 'e690e802-6b00-11e4-a1d2-0050563c3a6d' and `id_doc_type` = '1' and `series` = '1' and `number` = '1' and `date_of_issue` = '2015-06-12' and `date_of_expire` is null and `authority` is null and `subdivision_code` = '000-000' and `priority_type` is null and `ldate` is null and `mdate` = '2015-06-25 22:41:34' Connection ID (thread ID): 4 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150628 11:06:28 mysqld_safe Number of processes running now: 0 150628 11:06:28 mysqld_safe mysqld restarted 150628 11:06:28 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 1808 ... 150628 11:06:28 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150628 11:06:28 [Note] InnoDB: The InnoDB memory heap is disabled 150628 11:06:28 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150628 11:06:28 [Note] InnoDB: Memory barrier is not used 150628 11:06:28 [Note] InnoDB: Compressed tables use zlib 1.2.8 150628 11:06:28 [Note] InnoDB: Using Linux native AIO 150628 11:06:28 [Note] InnoDB: Using CPU crc32 instructions 150628 11:06:28 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150628 11:06:28 [Note] InnoDB: Completed initialization of buffer pool 150628 11:06:28 [Note] InnoDB: Highest supported file format is Barracuda. 150628 11:06:28 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 33500223231 in the ib_logfiles! 150628 11:06:28 [Note] InnoDB: Database was not shutdown normally! 150628 11:06:28 [Note] InnoDB: Starting crash recovery. 150628 11:06:28 [Note] InnoDB: Reading tablespace information from the .ibd files... 150628 11:06:28 [Note] InnoDB: Restoring possible half-written data pages 150628 11:06:28 [Note] InnoDB: from the doublewrite buffer... 150628 11:06:28 [Note] InnoDB: 128 rollback segment(s) are active. 150628 11:06:28 [Note] InnoDB: Waiting for purge to start 150628 11:06:28 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 33500223231 150628 11:06:28 [Note] Recovering after a crash using tc.log 150628 11:06:28 [Note] Starting crash recovery... 150628 11:06:28 [Note] Crash recovery finished. 150628 11:06:28 [Note] Server socket created on IP: '::'. 150628 11:06:28 [Note] Event Scheduler: Loaded 0 events 150628 11:06:28 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150628 11:06:31 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150628 11:06:31 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150628 11:06:32 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=2 max_threads=153 thread_count=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7fb3c7fc8838 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 = 0x7fb3c45d7dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7fb3c50ff43d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7fb3c4c7724d] /lib64/libpthread.so.0(+0x3775a10430)[0x7fb3c4319430] /usr/libexec/mysqld(+0x730dd4)[0x7fb3c4e78dd4] /usr/libexec/mysqld(+0x67cc12)[0x7fb3c4dc4c12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7fb3c4c0bb0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7fb3c4c0def0] /usr/libexec/mysqld(+0x60324f)[0x7fb3c4d4b24f] /usr/libexec/mysqld(+0x6036fd)[0x7fb3c4d4b6fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7fb3c4d5d7b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7fb3c4bafb8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7fb3c4b191a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7fb3c4b1d113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7fb3c4b1eb41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7fb3c4be2f42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7fb3c4be2fe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7fb3c4310555] /lib64/libc.so.6(clone+0x6d)[0x7fb3c28a7f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fb378004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '2' where `id_doc` = '02284678-6b01-11e4-a1d2-0050563c3a6d' and `id_profile` = 'e690e802-6b00-11e4-a1d2-0050563c3a6d' and `id_doc_type` = '1' and `series` = '1' and `number` = '1' and `date_of_issue` = '2015-06-12' and `date_of_expire` is null and `authority` is null and `subdivision_code` = '000-000' and `priority_type` is null and `ldate` is null and `mdate` = '2015-06-25 22:41:34' Connection ID (thread ID): 4 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150628 11:06:32 mysqld_safe Number of processes running now: 0 150628 11:06:32 mysqld_safe mysqld restarted 150628 11:06:32 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 1851 ... 150628 11:06:32 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150628 11:06:32 [Note] InnoDB: The InnoDB memory heap is disabled 150628 11:06:32 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150628 11:06:32 [Note] InnoDB: Memory barrier is not used 150628 11:06:32 [Note] InnoDB: Compressed tables use zlib 1.2.8 150628 11:06:32 [Note] InnoDB: Using Linux native AIO 150628 11:06:32 [Note] InnoDB: Using CPU crc32 instructions 150628 11:06:32 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150628 11:06:32 [Note] InnoDB: Completed initialization of buffer pool 150628 11:06:32 [Note] InnoDB: Highest supported file format is Barracuda. 150628 11:06:32 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 33500223241 in the ib_logfiles! 150628 11:06:32 [Note] InnoDB: Database was not shutdown normally! 150628 11:06:32 [Note] InnoDB: Starting crash recovery. 150628 11:06:32 [Note] InnoDB: Reading tablespace information from the .ibd files... 150628 11:06:32 [Note] InnoDB: Restoring possible half-written data pages 150628 11:06:32 [Note] InnoDB: from the doublewrite buffer... 150628 11:06:32 [Note] InnoDB: 128 rollback segment(s) are active. 150628 11:06:32 [Note] InnoDB: Waiting for purge to start 150628 11:06:32 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 33500223241 150628 11:06:32 [Note] Recovering after a crash using tc.log 150628 11:06:32 [Note] Starting crash recovery... 150628 11:06:32 [Note] Crash recovery finished. 150628 11:06:32 [Note] Server socket created on IP: '::'. 150628 11:06:32 [Note] Event Scheduler: Loaded 0 events 150628 11:06:32 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150628 11:06:34 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150628 11:06:34 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150628 11:06:34 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=2 max_threads=153 thread_count=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f66441cba28 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 = 0x7f66417c8dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f66422f043d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f6641e6824d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f664150a430] /usr/libexec/mysqld(+0x730dd4)[0x7f6642069dd4] /usr/libexec/mysqld(+0x67cc12)[0x7f6641fb5c12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f6641dfcb0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f6641dfeef0] /usr/libexec/mysqld(+0x60324f)[0x7f6641f3c24f] /usr/libexec/mysqld(+0x6036fd)[0x7f6641f3c6fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f6641f4e7b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f6641da0b8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f6641d0a1a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f6641d0e113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f6641d0fb41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f6641dd3f42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f6641dd3fe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7f6641501555] /lib64/libc.so.6(clone+0x6d)[0x7f663fa98f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f65f4004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '2' where `id_doc` = '02284678-6b01-11e4-a1d2-0050563c3a6d' and `id_profile` = 'e690e802-6b00-11e4-a1d2-0050563c3a6d' and `id_doc_type` = '1' and `series` = '1' and `number` = '1' and `date_of_issue` = '2015-06-12' and `date_of_expire` is null and `authority` is null and `subdivision_code` = '000-000' and `priority_type` is null and `ldate` is null and `mdate` = '2015-06-25 22:41:34' Connection ID (thread ID): 4 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150628 11:06:34 mysqld_safe Number of processes running now: 0 150628 11:06:34 mysqld_safe mysqld restarted 150628 11:06:34 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 1925 ... 150628 11:06:34 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150628 11:06:34 [Note] InnoDB: The InnoDB memory heap is disabled 150628 11:06:34 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150628 11:06:34 [Note] InnoDB: Memory barrier is not used 150628 11:06:34 [Note] InnoDB: Compressed tables use zlib 1.2.8 150628 11:06:34 [Note] InnoDB: Using Linux native AIO 150628 11:06:34 [Note] InnoDB: Using CPU crc32 instructions 150628 11:06:34 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150628 11:06:34 [Note] InnoDB: Completed initialization of buffer pool 150628 11:06:34 [Note] InnoDB: Highest supported file format is Barracuda. 150628 11:06:34 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 33500223251 in the ib_logfiles! 150628 11:06:34 [Note] InnoDB: Database was not shutdown normally! 150628 11:06:34 [Note] InnoDB: Starting crash recovery. 150628 11:06:34 [Note] InnoDB: Reading tablespace information from the .ibd files... 150628 11:06:34 [Note] InnoDB: Restoring possible half-written data pages 150628 11:06:34 [Note] InnoDB: from the doublewrite buffer... 150628 11:06:34 [Note] InnoDB: 128 rollback segment(s) are active. 150628 11:06:34 [Note] InnoDB: Waiting for purge to start 150628 11:06:34 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 33500223251 150628 11:06:34 [Note] Recovering after a crash using tc.log 150628 11:06:34 [Note] Starting crash recovery... 150628 11:06:34 [Note] Crash recovery finished. 150628 11:06:34 [Note] Server socket created on IP: '::'. 150628 11:06:34 [Note] Event Scheduler: Loaded 0 events 150628 11:06:34 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150628 11:06:36 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150628 11:06:36 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150628 11:06:37 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=2 max_threads=153 thread_count=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7fab7093da28 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 = 0x7fab6c913dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7fab6d43b43d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7fab6cfb324d] /lib64/libpthread.so.0(+0x3775a10430)[0x7fab6c655430] /usr/libexec/mysqld(+0x730dd4)[0x7fab6d1b4dd4] /usr/libexec/mysqld(+0x67cc12)[0x7fab6d100c12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7fab6cf47b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7fab6cf49ef0] /usr/libexec/mysqld(+0x60324f)[0x7fab6d08724f] /usr/libexec/mysqld(+0x6036fd)[0x7fab6d0876fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7fab6d0997b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7fab6ceebb8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7fab6ce551a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7fab6ce59113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7fab6ce5ab41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7fab6cf1ef42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7fab6cf1efe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7fab6c64c555] /lib64/libc.so.6(clone+0x6d)[0x7fab6abe3f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fab20004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '2' where `id_doc` = '02284678-6b01-11e4-a1d2-0050563c3a6d' and `id_profile` = 'e690e802-6b00-11e4-a1d2-0050563c3a6d' and `id_doc_type` = '1' and `series` = '1' and `number` = '1' and `date_of_issue` = '2015-06-12' and `date_of_expire` is null and `authority` is null and `subdivision_code` = '000-000' and `priority_type` is null and `ldate` is null and `mdate` = '2015-06-25 22:41:34' Connection ID (thread ID): 4 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150628 11:06:37 mysqld_safe Number of processes running now: 0 150628 11:06:37 mysqld_safe mysqld restarted 150628 11:06:37 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 1968 ... 150628 11:06:37 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150628 11:06:37 [Note] InnoDB: The InnoDB memory heap is disabled 150628 11:06:37 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150628 11:06:37 [Note] InnoDB: Memory barrier is not used 150628 11:06:37 [Note] InnoDB: Compressed tables use zlib 1.2.8 150628 11:06:37 [Note] InnoDB: Using Linux native AIO 150628 11:06:37 [Note] InnoDB: Using CPU crc32 instructions 150628 11:06:37 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150628 11:06:37 [Note] InnoDB: Completed initialization of buffer pool 150628 11:06:37 [Note] InnoDB: Highest supported file format is Barracuda. 150628 11:06:37 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 33500223261 in the ib_logfiles! 150628 11:06:37 [Note] InnoDB: Database was not shutdown normally! 150628 11:06:37 [Note] InnoDB: Starting crash recovery. 150628 11:06:37 [Note] InnoDB: Reading tablespace information from the .ibd files... 150628 11:06:37 [Note] InnoDB: Restoring possible half-written data pages 150628 11:06:37 [Note] InnoDB: from the doublewrite buffer... 150628 11:06:37 [Note] InnoDB: 128 rollback segment(s) are active. 150628 11:06:37 [Note] InnoDB: Waiting for purge to start 150628 11:06:37 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 33500223261 150628 11:06:37 [Note] Recovering after a crash using tc.log 150628 11:06:37 [Note] Starting crash recovery... 150628 11:06:37 [Note] Crash recovery finished. 150628 11:06:37 [Note] Server socket created on IP: '::'. 150628 11:06:37 [Note] Event Scheduler: Loaded 0 events 150628 11:06:37 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150628 11:06:39 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150628 11:06:39 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150628 11:06:39 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=2 max_threads=153 thread_count=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f8452a07a28 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 = 0x7f844f25edc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f844fd8643d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f844f8fe24d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f844efa0430] /usr/libexec/mysqld(+0x730dd4)[0x7f844faffdd4] /usr/libexec/mysqld(+0x67cc12)[0x7f844fa4bc12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f844f892b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f844f894ef0] /usr/libexec/mysqld(+0x60324f)[0x7f844f9d224f] /usr/libexec/mysqld(+0x6036fd)[0x7f844f9d26fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f844f9e47b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f844f836b8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f844f7a01a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f844f7a4113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f844f7a5b41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f844f869f42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f844f869fe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7f844ef97555] /lib64/libc.so.6(clone+0x6d)[0x7f844d52ef3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f8400004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '2' where `id_doc` = '02284678-6b01-11e4-a1d2-0050563c3a6d' and `id_profile` = 'e690e802-6b00-11e4-a1d2-0050563c3a6d' and `id_doc_type` = '1' and `series` = '1' and `number` = '1' and `date_of_issue` = '2015-06-12' and `date_of_expire` is null and `authority` is null and `subdivision_code` = '000-000' and `priority_type` is null and `ldate` is null and `mdate` = '2015-06-25 22:41:34' Connection ID (thread ID): 4 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150628 11:06:39 mysqld_safe Number of processes running now: 0 150628 11:06:39 mysqld_safe mysqld restarted 150628 11:06:39 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 2042 ... 150628 11:06:39 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150628 11:06:39 [Note] InnoDB: The InnoDB memory heap is disabled 150628 11:06:39 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150628 11:06:39 [Note] InnoDB: Memory barrier is not used 150628 11:06:39 [Note] InnoDB: Compressed tables use zlib 1.2.8 150628 11:06:39 [Note] InnoDB: Using Linux native AIO 150628 11:06:39 [Note] InnoDB: Using CPU crc32 instructions 150628 11:06:39 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150628 11:06:39 [Note] InnoDB: Completed initialization of buffer pool 150628 11:06:39 [Note] InnoDB: Highest supported file format is Barracuda. 150628 11:06:39 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 33500223271 in the ib_logfiles! 150628 11:06:39 [Note] InnoDB: Database was not shutdown normally! 150628 11:06:39 [Note] InnoDB: Starting crash recovery. 150628 11:06:39 [Note] InnoDB: Reading tablespace information from the .ibd files... 150628 11:06:39 [Note] InnoDB: Restoring possible half-written data pages 150628 11:06:39 [Note] InnoDB: from the doublewrite buffer... 150628 11:06:39 [Note] InnoDB: 128 rollback segment(s) are active. 150628 11:06:39 [Note] InnoDB: Waiting for purge to start 150628 11:06:39 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 33500223271 150628 11:06:39 [Note] Recovering after a crash using tc.log 150628 11:06:39 [Note] Starting crash recovery... 150628 11:06:39 [Note] Crash recovery finished. 150628 11:06:39 [Note] Server socket created on IP: '::'. 150628 11:06:39 [Note] Event Scheduler: Loaded 0 events 150628 11:06:39 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150628 11:11:40 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150628 11:11:42 [Note] feedback plugin: server replied 'ok' 150628 22:29:31 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150628 22:29:31 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150628 22:29:32 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150628 22:29:32 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150628 22:29:32 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150628 22:29:32 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150628 22:29:32 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150628 22:29:32 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 9:59:19 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 9:59:19 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 9:59:55 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=8 max_threads=153 thread_count=8 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7fee771e8c38 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 = 0x7fee728c4dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7fee733ec43d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7fee72f6424d] /lib64/libpthread.so.0(+0x3775a10430)[0x7fee72606430] /usr/libexec/mysqld(+0x730dd4)[0x7fee73165dd4] /usr/libexec/mysqld(+0x67cc12)[0x7fee730b1c12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7fee72ef8b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7fee72efaef0] /usr/libexec/mysqld(+0x60324f)[0x7fee7303824f] /usr/libexec/mysqld(+0x6036fd)[0x7fee730386fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7fee7304a7b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7fee72e9cb8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7fee72e061a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7fee72e0a113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7fee72e0bb41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7fee72ecff42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7fee72ecffe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7fee725fd555] /lib64/libc.so.6(clone+0x6d)[0x7fee70b94f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fee242616d0): update `taganka-demo`.`appl_profile_doc` set `series` = '1', `number` = '1', `date_of_issue` = '2015-06-12' where `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' and `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' and `id_doc_type` = '1' and `date_of_expire` is null and `authority` is null and `subdivision_code` is null and `priority_type` is null and `ldate` is null and `mdate` = '2015-04-22 05:19:43' Connection ID (thread ID): 22 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 09:59:55 mysqld_safe Number of processes running now: 0 150629 09:59:55 mysqld_safe mysqld restarted 150629 9:59:56 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 6863 ... 150629 9:59:56 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 9:59:56 [Note] InnoDB: The InnoDB memory heap is disabled 150629 9:59:56 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 9:59:56 [Note] InnoDB: Memory barrier is not used 150629 9:59:56 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 9:59:56 [Note] InnoDB: Using Linux native AIO 150629 9:59:56 [Note] InnoDB: Using CPU crc32 instructions 150629 9:59:56 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 9:59:56 [Note] InnoDB: Completed initialization of buffer pool 150629 9:59:56 [Note] InnoDB: Highest supported file format is Barracuda. 150629 9:59:56 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 35793068509 in the ib_logfiles! 150629 9:59:56 [Note] InnoDB: Database was not shutdown normally! 150629 9:59:56 [Note] InnoDB: Starting crash recovery. 150629 9:59:56 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 10:00:09 [Note] InnoDB: Restoring possible half-written data pages 150629 10:00:09 [Note] InnoDB: from the doublewrite buffer... 150629 10:00:11 [Note] InnoDB: 128 rollback segment(s) are active. 150629 10:00:11 [Note] InnoDB: Waiting for purge to start 150629 10:00:11 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 35793068509 150629 10:00:12 [Note] Recovering after a crash using tc.log 150629 10:00:12 [Note] Starting crash recovery... 150629 10:00:12 [Note] Crash recovery finished. 150629 10:00:12 [Note] Server socket created on IP: '::'. 150629 10:00:13 [Note] Event Scheduler: Loaded 0 events 150629 10:00:13 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 10:00:43 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:00:43 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:00:43 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7fa52f4d7908 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 = 0x7fa52c7b9dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7fa52d29843d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7fa52ce1024d] /lib64/libpthread.so.0(+0x3775a10430)[0x7fa52c4b2430] /usr/libexec/mysqld(+0x730dd4)[0x7fa52d011dd4] /usr/libexec/mysqld(+0x67cc12)[0x7fa52cf5dc12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7fa52cda4b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7fa52cda6ef0] /usr/libexec/mysqld(+0x60324f)[0x7fa52cee424f] /usr/libexec/mysqld(+0x6036fd)[0x7fa52cee46fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7fa52cef67b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7fa52cd48b8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7fa52ccb21a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7fa52ccb6113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7fa52ccb7b41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7fa52cd7bf42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7fa52cd7bfe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7fa52c4a9555] /lib64/libc.so.6(clone+0x6d)[0x7fa52aa40f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fa4e0004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '1', `number` = '2', `date_of_issue` = '2015-06-12' where `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' and `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' and `id_doc_type` = '1' and `date_of_expire` is null and `authority` is null and `subdivision_code` is null and `priority_type` is null and `ldate` is null Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 10:00:43 mysqld_safe Number of processes running now: 0 150629 10:00:43 mysqld_safe mysqld restarted 150629 10:00:43 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 6986 ... 150629 10:00:43 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 10:00:43 [Note] InnoDB: The InnoDB memory heap is disabled 150629 10:00:43 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 10:00:43 [Note] InnoDB: Memory barrier is not used 150629 10:00:43 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 10:00:43 [Note] InnoDB: Using Linux native AIO 150629 10:00:43 [Note] InnoDB: Using CPU crc32 instructions 150629 10:00:43 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 10:00:43 [Note] InnoDB: Completed initialization of buffer pool 150629 10:00:43 [Note] InnoDB: Highest supported file format is Barracuda. 150629 10:00:43 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 35793071991 in the ib_logfiles! 150629 10:00:43 [Note] InnoDB: Database was not shutdown normally! 150629 10:00:43 [Note] InnoDB: Starting crash recovery. 150629 10:00:43 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 10:00:43 [Note] InnoDB: Restoring possible half-written data pages 150629 10:00:43 [Note] InnoDB: from the doublewrite buffer... 150629 10:00:43 [Note] InnoDB: 128 rollback segment(s) are active. 150629 10:00:43 [Note] InnoDB: Waiting for purge to start 150629 10:00:43 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 35793071991 150629 10:00:43 [Note] Recovering after a crash using tc.log 150629 10:00:43 [Note] Starting crash recovery... 150629 10:00:43 [Note] Crash recovery finished. 150629 10:00:43 [Note] Server socket created on IP: '::'. 150629 10:00:44 [Note] Event Scheduler: Loaded 0 events 150629 10:00:44 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 10:00:59 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:00:59 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:00:59 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7fc216a55908 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 = 0x7fc212df7dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7fc2138d643d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7fc21344e24d] /lib64/libpthread.so.0(+0x3775a10430)[0x7fc212af0430] /usr/libexec/mysqld(+0x730dd4)[0x7fc21364fdd4] /usr/libexec/mysqld(+0x67cc12)[0x7fc21359bc12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7fc2133e2b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7fc2133e4ef0] /usr/libexec/mysqld(+0x60324f)[0x7fc21352224f] /usr/libexec/mysqld(+0x6036fd)[0x7fc2135226fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7fc2135347b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7fc213386b8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7fc2132f01a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7fc2132f4113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7fc2132f5b41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7fc2133b9f42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7fc2133b9fe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7fc212ae7555] /lib64/libc.so.6(clone+0x6d)[0x7fc21107ef3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fc1d0004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '1', `number` = '1', `date_of_issue` = '2015-06-12' where `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' and `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' and `id_doc_type` = '1' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 10:00:59 mysqld_safe Number of processes running now: 0 150629 10:00:59 mysqld_safe mysqld restarted 150629 10:00:59 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 7028 ... 150629 10:00:59 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 10:00:59 [Note] InnoDB: The InnoDB memory heap is disabled 150629 10:00:59 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 10:00:59 [Note] InnoDB: Memory barrier is not used 150629 10:00:59 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 10:00:59 [Note] InnoDB: Using Linux native AIO 150629 10:00:59 [Note] InnoDB: Using CPU crc32 instructions 150629 10:00:59 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 10:00:59 [Note] InnoDB: Completed initialization of buffer pool 150629 10:00:59 [Note] InnoDB: Highest supported file format is Barracuda. 150629 10:00:59 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 35793072792 in the ib_logfiles! 150629 10:00:59 [Note] InnoDB: Database was not shutdown normally! 150629 10:00:59 [Note] InnoDB: Starting crash recovery. 150629 10:00:59 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 10:00:59 [Note] InnoDB: Restoring possible half-written data pages 150629 10:00:59 [Note] InnoDB: from the doublewrite buffer... 150629 10:00:59 [Note] InnoDB: 128 rollback segment(s) are active. 150629 10:00:59 [Note] InnoDB: Waiting for purge to start 150629 10:00:59 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 35793072792 150629 10:00:59 [Note] Recovering after a crash using tc.log 150629 10:00:59 [Note] Starting crash recovery... 150629 10:00:59 [Note] Crash recovery finished. 150629 10:00:59 [Note] Server socket created on IP: '::'. 150629 10:00:59 [Note] Event Scheduler: Loaded 0 events 150629 10:00:59 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 10:01:01 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:01:01 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:01:01 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7fa2de431908 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 = 0x7fa2db32bdc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7fa2dbe0a43d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7fa2db98224d] /lib64/libpthread.so.0(+0x3775a10430)[0x7fa2db024430] /usr/libexec/mysqld(+0x730dd4)[0x7fa2dbb83dd4] /usr/libexec/mysqld(+0x67cc12)[0x7fa2dbacfc12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7fa2db916b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7fa2db918ef0] /usr/libexec/mysqld(+0x60324f)[0x7fa2dba5624f] /usr/libexec/mysqld(+0x6036fd)[0x7fa2dba566fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7fa2dba687b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7fa2db8bab8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7fa2db8241a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7fa2db828113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7fa2db829b41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7fa2db8edf42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7fa2db8edfe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7fa2db01b555] /lib64/libc.so.6(clone+0x6d)[0x7fa2d95b2f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fa298004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '1', `number` = '1', `date_of_issue` = '2015-06-12' where `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' and `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' and `id_doc_type` = '1' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 10:01:01 mysqld_safe Number of processes running now: 0 150629 10:01:01 mysqld_safe mysqld restarted 150629 10:01:01 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 7118 ... 150629 10:01:01 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 10:01:01 [Note] InnoDB: The InnoDB memory heap is disabled 150629 10:01:01 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 10:01:01 [Note] InnoDB: Memory barrier is not used 150629 10:01:01 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 10:01:01 [Note] InnoDB: Using Linux native AIO 150629 10:01:01 [Note] InnoDB: Using CPU crc32 instructions 150629 10:01:01 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 10:01:01 [Note] InnoDB: Completed initialization of buffer pool 150629 10:01:01 [Note] InnoDB: Highest supported file format is Barracuda. 150629 10:01:01 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 35793072802 in the ib_logfiles! 150629 10:01:01 [Note] InnoDB: Database was not shutdown normally! 150629 10:01:01 [Note] InnoDB: Starting crash recovery. 150629 10:01:01 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 10:01:02 [Note] InnoDB: Restoring possible half-written data pages 150629 10:01:02 [Note] InnoDB: from the doublewrite buffer... 150629 10:01:02 [Note] InnoDB: 128 rollback segment(s) are active. 150629 10:01:02 [Note] InnoDB: Waiting for purge to start 150629 10:01:02 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 35793072802 150629 10:01:02 [Note] Recovering after a crash using tc.log 150629 10:01:02 [Note] Starting crash recovery... 150629 10:01:02 [Note] Crash recovery finished. 150629 10:01:02 [Note] Server socket created on IP: '::'. 150629 10:01:02 [Note] Event Scheduler: Loaded 0 events 150629 10:01:02 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 10:01:12 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:01:12 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:01:12 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f6793933908 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 = 0x7f678fca9dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f679078843d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f679030024d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f678f9a2430] /usr/libexec/mysqld(+0x730dd4)[0x7f6790501dd4] /usr/libexec/mysqld(+0x67cc12)[0x7f679044dc12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f6790294b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f6790296ef0] /usr/libexec/mysqld(+0x60324f)[0x7f67903d424f] /usr/libexec/mysqld(+0x6036fd)[0x7f67903d46fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f67903e67b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f6790238b8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f67901a21a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f67901a6113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f67901a7b41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f679026bf42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f679026bfe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7f678f999555] /lib64/libc.so.6(clone+0x6d)[0x7f678df30f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f6744004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '2', `number` = '1', `date_of_issue` = '2015-06-12' where `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' and `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' and `id_doc_type` = '1' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 10:01:12 mysqld_safe Number of processes running now: 0 150629 10:01:12 mysqld_safe mysqld restarted 150629 10:01:12 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 7160 ... 150629 10:01:12 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 10:01:12 [Note] InnoDB: The InnoDB memory heap is disabled 150629 10:01:12 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 10:01:12 [Note] InnoDB: Memory barrier is not used 150629 10:01:12 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 10:01:12 [Note] InnoDB: Using Linux native AIO 150629 10:01:12 [Note] InnoDB: Using CPU crc32 instructions 150629 10:01:12 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 10:01:12 [Note] InnoDB: Completed initialization of buffer pool 150629 10:01:12 [Note] InnoDB: Highest supported file format is Barracuda. 150629 10:01:12 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 35793072812 in the ib_logfiles! 150629 10:01:12 [Note] InnoDB: Database was not shutdown normally! 150629 10:01:12 [Note] InnoDB: Starting crash recovery. 150629 10:01:12 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 10:01:12 [Note] InnoDB: Restoring possible half-written data pages 150629 10:01:12 [Note] InnoDB: from the doublewrite buffer... 150629 10:01:13 [Note] InnoDB: 128 rollback segment(s) are active. 150629 10:01:13 [Note] InnoDB: Waiting for purge to start 150629 10:01:13 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 35793072812 150629 10:01:13 [Note] Recovering after a crash using tc.log 150629 10:01:13 [Note] Starting crash recovery... 150629 10:01:13 [Note] Crash recovery finished. 150629 10:01:13 [Note] Server socket created on IP: '::'. 150629 10:01:13 [Note] Event Scheduler: Loaded 0 events 150629 10:01:13 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 10:01:15 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:01:15 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:01:15 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f831dfc3c38 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 = 0x7f831a047dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f831ab2643d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f831a69e24d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f8319d40430] /usr/libexec/mysqld(+0x730dd4)[0x7f831a89fdd4] /usr/libexec/mysqld(+0x67cc12)[0x7f831a7ebc12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f831a632b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f831a634ef0] /usr/libexec/mysqld(+0x60324f)[0x7f831a77224f] /usr/libexec/mysqld(+0x6036fd)[0x7f831a7726fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f831a7847b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f831a5d6b8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f831a5401a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f831a544113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f831a545b41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f831a609f42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f831a609fe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7f8319d37555] /lib64/libc.so.6(clone+0x6d)[0x7f83182cef3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f82d8004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '2', `number` = '1', `date_of_issue` = '2015-06-12' where `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' and `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' and `id_doc_type` = '1' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 10:01:15 mysqld_safe Number of processes running now: 0 150629 10:01:15 mysqld_safe mysqld restarted 150629 10:01:15 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 7233 ... 150629 10:01:15 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 10:01:15 [Note] InnoDB: The InnoDB memory heap is disabled 150629 10:01:15 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 10:01:15 [Note] InnoDB: Memory barrier is not used 150629 10:01:15 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 10:01:15 [Note] InnoDB: Using Linux native AIO 150629 10:01:15 [Note] InnoDB: Using CPU crc32 instructions 150629 10:01:15 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 10:01:15 [Note] InnoDB: Completed initialization of buffer pool 150629 10:01:15 [Note] InnoDB: Highest supported file format is Barracuda. 150629 10:01:15 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 35793072822 in the ib_logfiles! 150629 10:01:15 [Note] InnoDB: Database was not shutdown normally! 150629 10:01:15 [Note] InnoDB: Starting crash recovery. 150629 10:01:15 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 10:01:15 [Note] InnoDB: Restoring possible half-written data pages 150629 10:01:15 [Note] InnoDB: from the doublewrite buffer... 150629 10:01:15 [Note] InnoDB: 128 rollback segment(s) are active. 150629 10:01:15 [Note] InnoDB: Waiting for purge to start 150629 10:01:15 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 35793072822 150629 10:01:15 [Note] Recovering after a crash using tc.log 150629 10:01:15 [Note] Starting crash recovery... 150629 10:01:15 [Note] Crash recovery finished. 150629 10:01:15 [Note] Server socket created on IP: '::'. 150629 10:01:15 [Note] Event Scheduler: Loaded 0 events 150629 10:01:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 10:01:27 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:01:27 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:01:46 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f4f86970908 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 = 0x7f4f830fbdc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f4f83bda43d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f4f8375224d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f4f82df4430] /usr/libexec/mysqld(+0x730dd4)[0x7f4f83953dd4] /usr/libexec/mysqld(+0x67cc12)[0x7f4f8389fc12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f4f836e6b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f4f836e8ef0] /usr/libexec/mysqld(+0x60324f)[0x7f4f8382624f] /usr/libexec/mysqld(+0x6036fd)[0x7f4f838266fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f4f838387b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f4f8368ab8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f4f835f41a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f4f835f8113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f4f835f9b41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f4f836bdf42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f4f836bdfe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7f4f82deb555] /lib64/libc.so.6(clone+0x6d)[0x7f4f81382f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f4f40004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '2', `number` = '1', `date_of_issue` = '2015-06-12' where `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' and `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 10:01:46 mysqld_safe Number of processes running now: 0 150629 10:01:46 mysqld_safe mysqld restarted 150629 10:01:47 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 7275 ... 150629 10:01:47 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 10:01:47 [Note] InnoDB: The InnoDB memory heap is disabled 150629 10:01:47 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 10:01:47 [Note] InnoDB: Memory barrier is not used 150629 10:01:47 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 10:01:47 [Note] InnoDB: Using Linux native AIO 150629 10:01:47 [Note] InnoDB: Using CPU crc32 instructions 150629 10:01:47 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 10:01:47 [Note] InnoDB: Completed initialization of buffer pool 150629 10:01:47 [Note] InnoDB: Highest supported file format is Barracuda. 150629 10:01:47 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 35793073319 in the ib_logfiles! 150629 10:01:47 [Note] InnoDB: Database was not shutdown normally! 150629 10:01:47 [Note] InnoDB: Starting crash recovery. 150629 10:01:47 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 10:01:47 [Note] InnoDB: Restoring possible half-written data pages 150629 10:01:47 [Note] InnoDB: from the doublewrite buffer... 150629 10:01:47 [Note] InnoDB: 128 rollback segment(s) are active. 150629 10:01:47 [Note] InnoDB: Waiting for purge to start 150629 10:01:47 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 35793073319 150629 10:01:47 [Note] Recovering after a crash using tc.log 150629 10:01:47 [Note] Starting crash recovery... 150629 10:01:47 [Note] Crash recovery finished. 150629 10:01:47 [Note] Server socket created on IP: '::'. 150629 10:01:47 [Note] Event Scheduler: Loaded 0 events 150629 10:01:47 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 10:01:49 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:01:49 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:01:49 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7fd5f4960c38 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 = 0x7fd5f07b2dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7fd5f129143d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7fd5f0e0924d] /lib64/libpthread.so.0(+0x3775a10430)[0x7fd5f04ab430] /usr/libexec/mysqld(+0x730dd4)[0x7fd5f100add4] /usr/libexec/mysqld(+0x67cc12)[0x7fd5f0f56c12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7fd5f0d9db0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7fd5f0d9fef0] /usr/libexec/mysqld(+0x60324f)[0x7fd5f0edd24f] /usr/libexec/mysqld(+0x6036fd)[0x7fd5f0edd6fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7fd5f0eef7b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7fd5f0d41b8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7fd5f0cab1a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7fd5f0caf113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7fd5f0cb0b41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7fd5f0d74f42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7fd5f0d74fe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7fd5f04a2555] /lib64/libc.so.6(clone+0x6d)[0x7fd5eea39f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fd5ac004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '2', `number` = '1', `date_of_issue` = '2015-06-12' where `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' and `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 10:01:49 mysqld_safe Number of processes running now: 0 150629 10:01:49 mysqld_safe mysqld restarted 150629 10:01:49 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 7348 ... 150629 10:01:49 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 10:01:49 [Note] InnoDB: The InnoDB memory heap is disabled 150629 10:01:49 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 10:01:49 [Note] InnoDB: Memory barrier is not used 150629 10:01:49 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 10:01:49 [Note] InnoDB: Using Linux native AIO 150629 10:01:49 [Note] InnoDB: Using CPU crc32 instructions 150629 10:01:49 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 10:01:49 [Note] InnoDB: Completed initialization of buffer pool 150629 10:01:49 [Note] InnoDB: Highest supported file format is Barracuda. 150629 10:01:49 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 35793073329 in the ib_logfiles! 150629 10:01:49 [Note] InnoDB: Database was not shutdown normally! 150629 10:01:49 [Note] InnoDB: Starting crash recovery. 150629 10:01:49 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 10:01:49 [Note] InnoDB: Restoring possible half-written data pages 150629 10:01:49 [Note] InnoDB: from the doublewrite buffer... 150629 10:01:49 [Note] InnoDB: 128 rollback segment(s) are active. 150629 10:01:49 [Note] InnoDB: Waiting for purge to start 150629 10:01:49 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 35793073329 150629 10:01:49 [Note] Recovering after a crash using tc.log 150629 10:01:49 [Note] Starting crash recovery... 150629 10:01:49 [Note] Crash recovery finished. 150629 10:01:49 [Note] Server socket created on IP: '::'. 150629 10:01:49 [Note] Event Scheduler: Loaded 0 events 150629 10:01:49 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 10:01:57 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:01:57 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:01:57 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f7cc8261908 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 = 0x7f7cc5884dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f7cc636343d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f7cc5edb24d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f7cc557d430] /usr/libexec/mysqld(+0x730dd4)[0x7f7cc60dcdd4] /usr/libexec/mysqld(+0x67cc12)[0x7f7cc6028c12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f7cc5e6fb0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f7cc5e71ef0] /usr/libexec/mysqld(+0x60324f)[0x7f7cc5faf24f] /usr/libexec/mysqld(+0x6036fd)[0x7f7cc5faf6fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f7cc5fc17b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f7cc5e13b8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f7cc5d7d1a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f7cc5d81113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f7cc5d82b41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f7cc5e46f42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f7cc5e46fe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7f7cc5574555] /lib64/libc.so.6(clone+0x6d)[0x7f7cc3b0bf3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f7c84004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '1' where `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' and `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 10:01:57 mysqld_safe Number of processes running now: 0 150629 10:01:57 mysqld_safe mysqld restarted 150629 10:01:57 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 7390 ... 150629 10:01:57 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 10:01:57 [Note] InnoDB: The InnoDB memory heap is disabled 150629 10:01:57 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 10:01:57 [Note] InnoDB: Memory barrier is not used 150629 10:01:57 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 10:01:57 [Note] InnoDB: Using Linux native AIO 150629 10:01:57 [Note] InnoDB: Using CPU crc32 instructions 150629 10:01:57 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 10:01:57 [Note] InnoDB: Completed initialization of buffer pool 150629 10:01:57 [Note] InnoDB: Highest supported file format is Barracuda. 150629 10:01:57 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 35793073339 in the ib_logfiles! 150629 10:01:57 [Note] InnoDB: Database was not shutdown normally! 150629 10:01:57 [Note] InnoDB: Starting crash recovery. 150629 10:01:57 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 10:01:57 [Note] InnoDB: Restoring possible half-written data pages 150629 10:01:57 [Note] InnoDB: from the doublewrite buffer... 150629 10:01:57 [Note] InnoDB: 128 rollback segment(s) are active. 150629 10:01:57 [Note] InnoDB: Waiting for purge to start 150629 10:01:57 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 35793073339 150629 10:01:57 [Note] Recovering after a crash using tc.log 150629 10:01:57 [Note] Starting crash recovery... 150629 10:01:57 [Note] Crash recovery finished. 150629 10:01:57 [Note] Server socket created on IP: '::'. 150629 10:01:57 [Note] Event Scheduler: Loaded 0 events 150629 10:01:57 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 10:02:00 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:02:00 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:02:00 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f5263110c38 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 = 0x7f525f345dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f525fe2443d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f525f99c24d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f525f03e430] /usr/libexec/mysqld(+0x730dd4)[0x7f525fb9ddd4] /usr/libexec/mysqld(+0x67cc12)[0x7f525fae9c12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f525f930b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f525f932ef0] /usr/libexec/mysqld(+0x60324f)[0x7f525fa7024f] /usr/libexec/mysqld(+0x6036fd)[0x7f525fa706fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f525fa827b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f525f8d4b8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f525f83e1a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f525f842113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f525f843b41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f525f907f42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f525f907fe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7f525f035555] /lib64/libc.so.6(clone+0x6d)[0x7f525d5ccf3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f521c004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '1' where `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' and `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 10:02:00 mysqld_safe Number of processes running now: 0 150629 10:02:00 mysqld_safe mysqld restarted 150629 10:02:00 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 7463 ... 150629 10:02:00 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 10:02:00 [Note] InnoDB: The InnoDB memory heap is disabled 150629 10:02:00 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 10:02:00 [Note] InnoDB: Memory barrier is not used 150629 10:02:00 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 10:02:00 [Note] InnoDB: Using Linux native AIO 150629 10:02:00 [Note] InnoDB: Using CPU crc32 instructions 150629 10:02:00 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 10:02:00 [Note] InnoDB: Completed initialization of buffer pool 150629 10:02:00 [Note] InnoDB: Highest supported file format is Barracuda. 150629 10:02:00 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 35793073349 in the ib_logfiles! 150629 10:02:00 [Note] InnoDB: Database was not shutdown normally! 150629 10:02:00 [Note] InnoDB: Starting crash recovery. 150629 10:02:00 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 10:02:00 [Note] InnoDB: Restoring possible half-written data pages 150629 10:02:00 [Note] InnoDB: from the doublewrite buffer... 150629 10:02:00 [Note] InnoDB: 128 rollback segment(s) are active. 150629 10:02:00 [Note] InnoDB: Waiting for purge to start 150629 10:02:00 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 35793073349 150629 10:02:00 [Note] Recovering after a crash using tc.log 150629 10:02:00 [Note] Starting crash recovery... 150629 10:02:00 [Note] Crash recovery finished. 150629 10:02:00 [Note] Server socket created on IP: '::'. 150629 10:02:00 [Note] Event Scheduler: Loaded 0 events 150629 10:02:00 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 10:02:10 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:02:10 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:02:10 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7fe243c27c38 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 = 0x7fe240589dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7fe24106843d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7fe240be024d] /lib64/libpthread.so.0(+0x3775a10430)[0x7fe240282430] /usr/libexec/mysqld(+0x730dd4)[0x7fe240de1dd4] /usr/libexec/mysqld(+0x67cc12)[0x7fe240d2dc12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7fe240b74b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7fe240b76ef0] /usr/libexec/mysqld(+0x60324f)[0x7fe240cb424f] /usr/libexec/mysqld(+0x6036fd)[0x7fe240cb46fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7fe240cc67b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7fe240b18b8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7fe240a821a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7fe240a86113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7fe240a87b41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7fe240b4bf42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7fe240b4bfe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7fe240279555] /lib64/libc.so.6(clone+0x6d)[0x7fe23e810f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fe200004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '6' where `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' and `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 10:02:10 mysqld_safe Number of processes running now: 0 150629 10:02:10 mysqld_safe mysqld restarted 150629 10:02:10 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 7505 ... 150629 10:02:10 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 10:02:10 [Note] InnoDB: The InnoDB memory heap is disabled 150629 10:02:10 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 10:02:10 [Note] InnoDB: Memory barrier is not used 150629 10:02:10 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 10:02:10 [Note] InnoDB: Using Linux native AIO 150629 10:02:10 [Note] InnoDB: Using CPU crc32 instructions 150629 10:02:10 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 10:02:10 [Note] InnoDB: Completed initialization of buffer pool 150629 10:02:10 [Note] InnoDB: Highest supported file format is Barracuda. 150629 10:02:10 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 35793073359 in the ib_logfiles! 150629 10:02:10 [Note] InnoDB: Database was not shutdown normally! 150629 10:02:10 [Note] InnoDB: Starting crash recovery. 150629 10:02:10 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 10:02:10 [Note] InnoDB: Restoring possible half-written data pages 150629 10:02:10 [Note] InnoDB: from the doublewrite buffer... 150629 10:02:10 [Note] InnoDB: 128 rollback segment(s) are active. 150629 10:02:10 [Note] InnoDB: Waiting for purge to start 150629 10:02:10 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 35793073359 150629 10:02:10 [Note] Recovering after a crash using tc.log 150629 10:02:10 [Note] Starting crash recovery... 150629 10:02:10 [Note] Crash recovery finished. 150629 10:02:10 [Note] Server socket created on IP: '::'. 150629 10:02:10 [Note] Event Scheduler: Loaded 0 events 150629 10:02:10 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 10:02:12 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:02:12 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:02:12 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f8be16f5908 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 = 0x7f8bdd5e8dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f8bde0c743d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f8bddc3f24d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f8bdd2e1430] /usr/libexec/mysqld(+0x730dd4)[0x7f8bdde40dd4] /usr/libexec/mysqld(+0x67cc12)[0x7f8bddd8cc12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f8bddbd3b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f8bddbd5ef0] /usr/libexec/mysqld(+0x60324f)[0x7f8bddd1324f] /usr/libexec/mysqld(+0x6036fd)[0x7f8bddd136fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f8bddd257b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f8bddb77b8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f8bddae11a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f8bddae5113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f8bddae6b41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f8bddbaaf42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f8bddbaafe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7f8bdd2d8555] /lib64/libc.so.6(clone+0x6d)[0x7f8bdb86ff3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f8b9c004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '6' where `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' and `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 10:02:12 mysqld_safe Number of processes running now: 0 150629 10:02:12 mysqld_safe mysqld restarted 150629 10:02:12 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 7578 ... 150629 10:02:12 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 10:02:12 [Note] InnoDB: The InnoDB memory heap is disabled 150629 10:02:12 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 10:02:12 [Note] InnoDB: Memory barrier is not used 150629 10:02:12 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 10:02:12 [Note] InnoDB: Using Linux native AIO 150629 10:02:12 [Note] InnoDB: Using CPU crc32 instructions 150629 10:02:12 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 10:02:12 [Note] InnoDB: Completed initialization of buffer pool 150629 10:02:12 [Note] InnoDB: Highest supported file format is Barracuda. 150629 10:02:12 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 35793073369 in the ib_logfiles! 150629 10:02:12 [Note] InnoDB: Database was not shutdown normally! 150629 10:02:12 [Note] InnoDB: Starting crash recovery. 150629 10:02:12 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 10:02:12 [Note] InnoDB: Restoring possible half-written data pages 150629 10:02:12 [Note] InnoDB: from the doublewrite buffer... 150629 10:02:13 [Note] InnoDB: 128 rollback segment(s) are active. 150629 10:02:13 [Note] InnoDB: Waiting for purge to start 150629 10:02:13 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 35793073369 150629 10:02:13 [Note] Recovering after a crash using tc.log 150629 10:02:13 [Note] Starting crash recovery... 150629 10:02:13 [Note] Crash recovery finished. 150629 10:02:13 [Note] Server socket created on IP: '::'. 150629 10:02:13 [Note] Event Scheduler: Loaded 0 events 150629 10:02:13 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 10:02:56 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:02:56 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:03:44 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=2 max_threads=153 thread_count=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f1076d19c38 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 = 0x7f10746cedc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f10751ad43d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f1074d2524d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f10743c7430] /usr/libexec/mysqld(+0x730dd4)[0x7f1074f26dd4] /usr/libexec/mysqld(+0x67cc12)[0x7f1074e72c12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f1074cb9b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f1074cbbef0] /usr/libexec/mysqld(+0x60324f)[0x7f1074df924f] /usr/libexec/mysqld(+0x6036fd)[0x7f1074df96fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f1074e0b7b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f1074c5db8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f1074bc71a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f1074bcb113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f1074bccb41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f1074c90f42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f1074c90fe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7f10743be555] /lib64/libc.so.6(clone+0x6d)[0x7f1072955f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f102c004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '6' where `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' and `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 10:03:44 mysqld_safe Number of processes running now: 0 150629 10:03:44 mysqld_safe mysqld restarted 150629 10:03:44 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 7623 ... 150629 10:03:44 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 10:03:44 [Note] InnoDB: The InnoDB memory heap is disabled 150629 10:03:44 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 10:03:44 [Note] InnoDB: Memory barrier is not used 150629 10:03:44 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 10:03:44 [Note] InnoDB: Using Linux native AIO 150629 10:03:44 [Note] InnoDB: Using CPU crc32 instructions 150629 10:03:44 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 10:03:44 [Note] InnoDB: Completed initialization of buffer pool 150629 10:03:44 [Note] InnoDB: Highest supported file format is Barracuda. 150629 10:03:44 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 35793089876 in the ib_logfiles! 150629 10:03:44 [Note] InnoDB: Database was not shutdown normally! 150629 10:03:44 [Note] InnoDB: Starting crash recovery. 150629 10:03:44 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 10:03:44 [Note] InnoDB: Restoring possible half-written data pages 150629 10:03:44 [Note] InnoDB: from the doublewrite buffer... 150629 10:03:44 [Note] InnoDB: 128 rollback segment(s) are active. 150629 10:03:44 [Note] InnoDB: Waiting for purge to start 150629 10:03:45 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 35793089876 150629 10:03:45 [Note] Recovering after a crash using tc.log 150629 10:03:45 [Note] Starting crash recovery... 150629 10:03:45 [Note] Crash recovery finished. 150629 10:03:45 [Note] Server socket created on IP: '::'. 150629 10:03:45 [Note] Event Scheduler: Loaded 0 events 150629 10:03:45 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 10:03:47 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:03:47 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:03:47 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7fab648bb368 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 = 0x7fab621bbdc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7fab62c9a43d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7fab6281224d] /lib64/libpthread.so.0(+0x3775a10430)[0x7fab61eb4430] /usr/libexec/mysqld(+0x730dd4)[0x7fab62a13dd4] /usr/libexec/mysqld(+0x67cc12)[0x7fab6295fc12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7fab627a6b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7fab627a8ef0] /usr/libexec/mysqld(+0x60324f)[0x7fab628e624f] /usr/libexec/mysqld(+0x6036fd)[0x7fab628e66fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7fab628f87b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7fab6274ab8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7fab626b41a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7fab626b8113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7fab626b9b41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7fab6277df42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7fab6277dfe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7fab61eab555] /lib64/libc.so.6(clone+0x6d)[0x7fab60442f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fab20004c60): update `taganka-demo`.`appl_profile_doc` set `series` = '6' where `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' and `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 10:03:47 mysqld_safe Number of processes running now: 0 150629 10:03:47 mysqld_safe mysqld restarted 150629 10:03:47 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 7696 ... 150629 10:03:47 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 10:03:47 [Note] InnoDB: The InnoDB memory heap is disabled 150629 10:03:47 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 10:03:47 [Note] InnoDB: Memory barrier is not used 150629 10:03:47 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 10:03:47 [Note] InnoDB: Using Linux native AIO 150629 10:03:47 [Note] InnoDB: Using CPU crc32 instructions 150629 10:03:47 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 10:03:47 [Note] InnoDB: Completed initialization of buffer pool 150629 10:03:47 [Note] InnoDB: Highest supported file format is Barracuda. 150629 10:03:47 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 35793089886 in the ib_logfiles! 150629 10:03:47 [Note] InnoDB: Database was not shutdown normally! 150629 10:03:47 [Note] InnoDB: Starting crash recovery. 150629 10:03:47 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 10:03:47 [Note] InnoDB: Restoring possible half-written data pages 150629 10:03:47 [Note] InnoDB: from the doublewrite buffer... 150629 10:03:47 [Note] InnoDB: 128 rollback segment(s) are active. 150629 10:03:47 [Note] InnoDB: Waiting for purge to start 150629 10:03:47 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 35793089886 150629 10:03:47 [Note] Recovering after a crash using tc.log 150629 10:03:47 [Note] Starting crash recovery... 150629 10:03:47 [Note] Crash recovery finished. 150629 10:03:47 [Note] Server socket created on IP: '::'. 150629 10:03:47 [Note] Event Scheduler: Loaded 0 events 150629 10:03:47 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 10:05:48 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:05:48 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:05:48 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=2 max_threads=153 thread_count=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f297989dea8 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 = 0x7f297683cdc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f297736443d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f2976edc24d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f297657e430] /usr/libexec/mysqld(+0x730dd4)[0x7f29770dddd4] /usr/libexec/mysqld(+0x67cc12)[0x7f2977029c12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f2976e70b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f2976e72ef0] /usr/libexec/mysqld(+0x60324f)[0x7f2976fb024f] /usr/libexec/mysqld(+0x6036fd)[0x7f2976fb06fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f2976fc27b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f2976e14b8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f2976d7e1a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f2976d82113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f2976d83b41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f2976e47f42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f2976e47fe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7f2976575555] /lib64/libc.so.6(clone+0x6d)[0x7f2974b0cf3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f292c004c80): UPDATE `taganka-demo`.`appl_profile_doc` SET `series` = '7' WHERE `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' AND `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' Connection ID (thread ID): 5 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 10:05:48 mysqld_safe Number of processes running now: 0 150629 10:05:48 mysqld_safe mysqld restarted 150629 10:05:48 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 7770 ... 150629 10:05:48 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 10:05:48 [Note] InnoDB: The InnoDB memory heap is disabled 150629 10:05:48 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 10:05:48 [Note] InnoDB: Memory barrier is not used 150629 10:05:48 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 10:05:48 [Note] InnoDB: Using Linux native AIO 150629 10:05:48 [Note] InnoDB: Using CPU crc32 instructions 150629 10:05:48 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 10:05:48 [Note] InnoDB: Completed initialization of buffer pool 150629 10:05:48 [Note] InnoDB: Highest supported file format is Barracuda. 150629 10:05:48 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 35793090148 in the ib_logfiles! 150629 10:05:48 [Note] InnoDB: Database was not shutdown normally! 150629 10:05:48 [Note] InnoDB: Starting crash recovery. 150629 10:05:48 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 10:05:48 [Note] InnoDB: Restoring possible half-written data pages 150629 10:05:48 [Note] InnoDB: from the doublewrite buffer... 150629 10:05:48 [Note] InnoDB: 128 rollback segment(s) are active. 150629 10:05:48 [Note] InnoDB: Waiting for purge to start 150629 10:05:48 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 35793090148 150629 10:05:48 [Note] Recovering after a crash using tc.log 150629 10:05:48 [Note] Starting crash recovery... 150629 10:05:48 [Note] Crash recovery finished. 150629 10:05:48 [Note] Server socket created on IP: '::'. 150629 10:05:48 [Note] Event Scheduler: Loaded 0 events 150629 10:05:48 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 10:06:07 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:06:07 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:07:09 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=2 max_threads=153 thread_count=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f7a99b70ea8 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 = 0x7f7a96a53dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f7a9757b43d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f7a970f324d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f7a96795430] /usr/libexec/mysqld(+0x730dd4)[0x7f7a972f4dd4] /usr/libexec/mysqld(+0x67cc12)[0x7f7a97240c12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f7a97087b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f7a97089ef0] /usr/libexec/mysqld(+0x60324f)[0x7f7a971c724f] /usr/libexec/mysqld(+0x6036fd)[0x7f7a971c76fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f7a971d97b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f7a9702bb8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f7a96f951a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f7a96f99113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f7a96f9ab41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f7a9705ef42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f7a9705efe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7f7a9678c555] /lib64/libc.so.6(clone+0x6d)[0x7f7a94d23f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f7a48004c40): UPDATE `taganka-demo`.`appl_profile_doc` SET `series` = '7' WHERE `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' AND `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' Connection ID (thread ID): 5 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 10:07:09 mysqld_safe Number of processes running now: 0 150629 10:07:09 mysqld_safe mysqld restarted 150629 10:07:09 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 7833 ... 150629 10:07:09 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 10:07:09 [Note] InnoDB: The InnoDB memory heap is disabled 150629 10:07:09 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 10:07:09 [Note] InnoDB: Memory barrier is not used 150629 10:07:09 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 10:07:09 [Note] InnoDB: Using Linux native AIO 150629 10:07:09 [Note] InnoDB: Using CPU crc32 instructions 150629 10:07:09 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 10:07:09 [Note] InnoDB: Completed initialization of buffer pool 150629 10:07:09 [Note] InnoDB: Highest supported file format is Barracuda. 150629 10:07:09 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 35793093778 in the ib_logfiles! 150629 10:07:09 [Note] InnoDB: Database was not shutdown normally! 150629 10:07:09 [Note] InnoDB: Starting crash recovery. 150629 10:07:09 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 10:07:09 [Note] InnoDB: Restoring possible half-written data pages 150629 10:07:09 [Note] InnoDB: from the doublewrite buffer... 150629 10:07:09 [Note] InnoDB: 128 rollback segment(s) are active. 150629 10:07:09 [Note] InnoDB: Waiting for purge to start 150629 10:07:09 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 35793093778 150629 10:07:09 [Note] Recovering after a crash using tc.log 150629 10:07:09 [Note] Starting crash recovery... 150629 10:07:09 [Note] Crash recovery finished. 150629 10:07:09 [Note] Server socket created on IP: '::'. 150629 10:07:09 [Note] Event Scheduler: Loaded 0 events 150629 10:07:09 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 10:07:18 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:07:18 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:12:11 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150629 10:12:11 [Note] feedback plugin: server replied 'ok' 150629 10:14:11 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:14:11 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:14:11 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:14:11 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:14:11 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:14:11 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:14:43 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:14:43 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:14:43 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:14:43 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:14:43 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:14:43 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 10:14:43 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 10:14:43 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 18:12:27 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 18:12:27 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 20:16:54 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=10 max_threads=153 thread_count=9 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7fca6e9d9a08 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 = 0x7fca6b250dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7fca6bd7843d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7fca6b8f024d] /lib64/libpthread.so.0(+0x3775a10430)[0x7fca6af92430] /usr/libexec/mysqld(+0x730dd4)[0x7fca6baf1dd4] /usr/libexec/mysqld(+0x67cc12)[0x7fca6ba3dc12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7fca6b884b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7fca6b886ef0] /usr/libexec/mysqld(+0x60324f)[0x7fca6b9c424f] /usr/libexec/mysqld(+0x6036fd)[0x7fca6b9c46fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7fca6b9d67b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7fca6b828b8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7fca6b7921a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7fca6b796113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7fca6b797b41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7fca6b85bf42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7fca6b85bfe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7fca6af89555] /lib64/libc.so.6(clone+0x6d)[0x7fca69520f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fca0c004c60): UPDATE `taganka-demo`.`appl_profile_doc` SET `series` = '7' WHERE `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' AND `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' Connection ID (thread ID): 5 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 20:16:54 mysqld_safe Number of processes running now: 0 150629 20:16:54 mysqld_safe mysqld restarted 150629 20:16:54 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 9679 ... 150629 20:16:54 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 20:16:54 [Note] InnoDB: The InnoDB memory heap is disabled 150629 20:16:54 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 20:16:54 [Note] InnoDB: Memory barrier is not used 150629 20:16:54 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 20:16:54 [Note] InnoDB: Using Linux native AIO 150629 20:16:54 [Note] InnoDB: Using CPU crc32 instructions 150629 20:16:54 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 20:16:54 [Note] InnoDB: Completed initialization of buffer pool 150629 20:16:54 [Note] InnoDB: Highest supported file format is Barracuda. 150629 20:16:54 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 36904493523 in the ib_logfiles! 150629 20:16:54 [Note] InnoDB: Database was not shutdown normally! 150629 20:16:54 [Note] InnoDB: Starting crash recovery. 150629 20:16:54 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 20:17:00 [Note] InnoDB: Restoring possible half-written data pages 150629 20:17:00 [Note] InnoDB: from the doublewrite buffer... 150629 20:17:02 [Note] InnoDB: 128 rollback segment(s) are active. 150629 20:17:02 [Note] InnoDB: Waiting for purge to start 150629 20:17:02 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 36904493523 150629 20:17:02 [Note] Recovering after a crash using tc.log 150629 20:17:02 [Note] Starting crash recovery... 150629 20:17:02 [Note] Crash recovery finished. 150629 20:17:02 [Note] Server socket created on IP: '::'. 150629 20:17:02 [Note] Event Scheduler: Loaded 0 events 150629 20:17:02 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 20:17:17 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 20:17:17 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 20:17:17 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=2 max_threads=153 thread_count=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f1a6c9e2278 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 = 0x7f1a69ac6dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f1a6a5ee43d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f1a6a16624d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f1a69808430] /usr/libexec/mysqld(+0x730dd4)[0x7f1a6a367dd4] /usr/libexec/mysqld(+0x67cc12)[0x7f1a6a2b3c12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f1a6a0fab0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f1a6a0fcef0] /usr/libexec/mysqld(+0x60324f)[0x7f1a6a23a24f] /usr/libexec/mysqld(+0x6036fd)[0x7f1a6a23a6fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f1a6a24c7b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f1a6a09eb8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f1a6a0081a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f1a6a00c113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f1a6a00db41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f1a6a0d1f42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f1a6a0d1fe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7f1a697ff555] /lib64/libc.so.6(clone+0x6d)[0x7f1a67d96f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f1a20004c60): UPDATE `taganka-demo`.`appl_profile_doc` SET `series` = '7' WHERE `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' AND `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' Connection ID (thread ID): 4 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 20:17:17 mysqld_safe Number of processes running now: 0 150629 20:17:17 mysqld_safe mysqld restarted 150629 20:17:17 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 9788 ... 150629 20:17:17 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 20:17:17 [Note] InnoDB: The InnoDB memory heap is disabled 150629 20:17:17 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 20:17:17 [Note] InnoDB: Memory barrier is not used 150629 20:17:17 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 20:17:17 [Note] InnoDB: Using Linux native AIO 150629 20:17:17 [Note] InnoDB: Using CPU crc32 instructions 150629 20:17:17 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 20:17:17 [Note] InnoDB: Completed initialization of buffer pool 150629 20:17:17 [Note] InnoDB: Highest supported file format is Barracuda. 150629 20:17:17 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 36904498111 in the ib_logfiles! 150629 20:17:17 [Note] InnoDB: Database was not shutdown normally! 150629 20:17:17 [Note] InnoDB: Starting crash recovery. 150629 20:17:17 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 20:17:17 [Note] InnoDB: Restoring possible half-written data pages 150629 20:17:17 [Note] InnoDB: from the doublewrite buffer... 150629 20:17:17 [Note] InnoDB: 128 rollback segment(s) are active. 150629 20:17:17 [Note] InnoDB: Waiting for purge to start 150629 20:17:18 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 36904498111 150629 20:17:18 [Note] Recovering after a crash using tc.log 150629 20:17:18 [Note] Starting crash recovery... 150629 20:17:18 [Note] Crash recovery finished. 150629 20:17:18 [Note] Server socket created on IP: '::'. 150629 20:17:18 [Note] Event Scheduler: Loaded 0 events 150629 20:17:18 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 20:22:18 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150629 20:22:21 [Note] feedback plugin: server replied 'ok' 150629 20:33:46 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 20:33:46 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 20:34:12 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=8 max_threads=153 thread_count=8 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7fc308a338a8 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 = 0x7fc2ec0eddc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7fc306f0943d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7fc306a8124d] /lib64/libpthread.so.0(+0x3775a10430)[0x7fc306123430] /usr/libexec/mysqld(+0x730dd4)[0x7fc306c82dd4] /usr/libexec/mysqld(+0x67cc12)[0x7fc306bcec12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7fc306a15b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7fc306a17ef0] /usr/libexec/mysqld(+0x60324f)[0x7fc306b5524f] /usr/libexec/mysqld(+0x6036fd)[0x7fc306b556fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7fc306b677b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7fc3069b9b8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7fc3069231a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7fc306927113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7fc306928b41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7fc3069ecf42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7fc3069ecfe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7fc30611a555] /lib64/libc.so.6(clone+0x6d)[0x7fc3046b1f3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fc2a8004c70): UPDATE `taganka-demo`.`appl_profile_doc` SET `series` = '9' WHERE `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' AND `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' Connection ID (thread ID): 11 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 20:34:12 mysqld_safe Number of processes running now: 0 150629 20:34:12 mysqld_safe mysqld restarted 150629 20:34:12 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 9889 ... 150629 20:34:12 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 20:34:12 [Note] InnoDB: The InnoDB memory heap is disabled 150629 20:34:12 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 20:34:12 [Note] InnoDB: Memory barrier is not used 150629 20:34:12 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 20:34:12 [Note] InnoDB: Using Linux native AIO 150629 20:34:12 [Note] InnoDB: Using CPU crc32 instructions 150629 20:34:12 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 20:34:12 [Note] InnoDB: Completed initialization of buffer pool 150629 20:34:12 [Note] InnoDB: Highest supported file format is Barracuda. 150629 20:34:12 [Note] InnoDB: The log sequence numbers 33500223171 and 33500223171 in ibdata files do not match the log sequence number 36904544470 in the ib_logfiles! 150629 20:34:12 [Note] InnoDB: Database was not shutdown normally! 150629 20:34:12 [Note] InnoDB: Starting crash recovery. 150629 20:34:12 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 20:34:13 [Note] InnoDB: Restoring possible half-written data pages 150629 20:34:13 [Note] InnoDB: from the doublewrite buffer... 150629 20:34:14 [Note] InnoDB: 128 rollback segment(s) are active. 150629 20:34:14 [Note] InnoDB: Waiting for purge to start 150629 20:34:14 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 36904544470 150629 20:34:15 [Note] Recovering after a crash using tc.log 150629 20:34:15 [Note] Starting crash recovery... 150629 20:34:15 [Note] Crash recovery finished. 150629 20:34:15 [Note] Server socket created on IP: '::'. 150629 20:34:15 [Note] Event Scheduler: Loaded 0 events 150629 20:34:15 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 20:34:16 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150629 20:34:16 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150629 20:34:16 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=1 max_threads=153 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f1d05ffbb38 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 = 0x7f1d03088dc0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7f1d03b6743d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x7f1d036df24d] /lib64/libpthread.so.0(+0x3775a10430)[0x7f1d02d81430] /usr/libexec/mysqld(+0x730dd4)[0x7f1d038e0dd4] /usr/libexec/mysqld(+0x67cc12)[0x7f1d0382cc12] /usr/libexec/mysqld(_ZN7handler27multi_range_read_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x17c)[0x7f1d03673b0c] /usr/libexec/mysqld(_ZN10DsMrr_impl16dsmrr_info_constEjP15st_range_seq_ifPvjPjS3_P13Cost_estimate+0x50)[0x7f1d03675ef0] /usr/libexec/mysqld(+0x60324f)[0x7f1d037b324f] /usr/libexec/mysqld(+0x6036fd)[0x7f1d037b36fd] /usr/libexec/mysqld(_ZN10SQL_SELECT17test_quick_selectEP3THD6BitmapILj64EEyybb+0x828)[0x7f1d037c57b8] /usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x6ba)[0x7f1d03617b8a] /usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3694)[0x7f1d035811a4] /usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x203)[0x7f1d03585113] /usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19d1)[0x7f1d03586b41] /usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1e2)[0x7f1d0364af42] /usr/libexec/mysqld(handle_one_connection+0x40)[0x7f1d0364afe0] /lib64/libpthread.so.0(+0x3775a07555)[0x7f1d02d78555] /lib64/libc.so.6(clone+0x6d)[0x7f1d0130ff3d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f1cbc009540): UPDATE `taganka-demo`.`appl_profile_doc` SET `series` = '9' WHERE `id_doc` = '6b5cb828-e89e-11e4-a546-0050563c3a6d' AND `id_profile` = '6b4183ee-e89e-11e4-a546-0050563c3a6d' Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150629 20:34:16 mysqld_safe Number of processes running now: 0 150629 20:34:16 mysqld_safe mysqld restarted 150629 20:34:16 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 9964 ... 150629 20:34:16 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150629 20:34:16 [Note] InnoDB: The InnoDB memory heap is disabled 150629 20:34:16 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150629 20:34:16 [Note] InnoDB: Memory barrier is not used 150629 20:34:16 [Note] InnoDB: Compressed tables use zlib 1.2.8 150629 20:34:16 [Note] InnoDB: Using Linux native AIO 150629 20:34:16 [Note] InnoDB: Using CPU crc32 instructions 150629 20:34:16 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150629 20:34:16 [Note] InnoDB: Completed initialization of buffer pool 150629 20:34:16 [Note] InnoDB: Highest supported file format is Barracuda. 150629 20:34:16 [Note] InnoDB: Log scan progressed past the checkpoint lsn 36904544470 150629 20:34:16 [Note] InnoDB: Database was not shutdown normally! 150629 20:34:16 [Note] InnoDB: Starting crash recovery. 150629 20:34:16 [Note] InnoDB: Reading tablespace information from the .ibd files... 150629 20:34:16 [Note] InnoDB: Restoring possible half-written data pages 150629 20:34:16 [Note] InnoDB: from the doublewrite buffer... InnoDB: Doing recovery: scanned up to log sequence number 36904544619 150629 20:34:16 [Note] InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 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 150629 20:34:16 [Note] InnoDB: 128 rollback segment(s) are active. 150629 20:34:16 [Note] InnoDB: Waiting for purge to start 150629 20:34:16 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 36904544619 150629 20:34:16 [Note] Recovering after a crash using tc.log 150629 20:34:16 [Note] Starting crash recovery... 150629 20:34:16 [Note] Crash recovery finished. 150629 20:34:16 [Note] Server socket created on IP: '::'. 150629 20:34:16 [Note] Event Scheduler: Loaded 0 events 150629 20:34:16 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150629 20:39:17 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150629 20:39:17 [Note] feedback plugin: server replied 'ok' 150630 5:06:57 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 5:06:57 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 5:06:57 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 5:06:57 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 5:06:57 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 5:06:57 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 5:06:58 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 5:06:58 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:02:18 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:02:18 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:02:18 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:02:18 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:02:18 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:02:18 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:02:19 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:02:19 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:02:50 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:02:50 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:02:50 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:02:50 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:02:50 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:02:50 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:02:50 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:02:50 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:03:40 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:03:40 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:03:40 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:03:40 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:03:40 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:03:40 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:03:40 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:03:40 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:03:41 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:03:41 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:03:41 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:03:41 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:03:41 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:03:41 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:03:41 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:03:41 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:03:41 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:03:41 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:03:41 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:03:41 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:03:41 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:03:41 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:03:41 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:03:41 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:03:42 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:03:42 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:03:42 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:03:42 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:03:42 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:03:42 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:03:42 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:03:42 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:38:48 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:38:49 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:38:49 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:38:49 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:38:49 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:38:49 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:38:49 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:38:49 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:39:22 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:39:22 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:39:22 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:39:22 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:39:22 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:39:22 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:39:22 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:39:22 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:39:23 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:39:23 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:39:23 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:39:23 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:39:23 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:39:23 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:39:23 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:39:23 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:39:23 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:39:23 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:39:23 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:39:23 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:39:23 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:39:23 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:39:23 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:39:23 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:39:23 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:39:23 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:39:23 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:39:23 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:39:23 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:39:23 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 19:39:23 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150630 19:39:23 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150630 20:39:18 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150630 20:39:21 [Note] feedback plugin: server replied 'ok' 150701 5:31:06 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150701 5:31:06 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150701 5:31:07 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150701 5:31:07 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150701 5:31:07 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150701 5:31:07 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150701 5:31:07 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150701 5:31:07 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150704 21:34:38 [Note] /usr/libexec/mysqld: Normal shutdown 150704 21:34:39 [Note] Event Scheduler: Purging the queue. 0 events 150704 21:34:40 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150704 21:34:40 [Note] feedback plugin: server replied 'ok' 150704 21:34:40 [Note] InnoDB: FTS optimize thread exiting. 150704 21:34:40 [Note] InnoDB: Starting shutdown... 150704 21:34:42 [Note] InnoDB: Shutdown completed; log sequence number 38238949719 150704 21:34:42 [Note] /usr/libexec/mysqld: Shutdown complete 150704 21:34:42 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended 150704 21:35:33 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150704 21:35:36 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 1006 ... 150704 21:35:37 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150704 21:35:37 [Note] InnoDB: The InnoDB memory heap is disabled 150704 21:35:37 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150704 21:35:37 [Note] InnoDB: Memory barrier is not used 150704 21:35:37 [Note] InnoDB: Compressed tables use zlib 1.2.8 150704 21:35:37 [Note] InnoDB: Using Linux native AIO 150704 21:35:38 [Note] InnoDB: Using CPU crc32 instructions 150704 21:35:38 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150704 21:35:38 [Note] InnoDB: Completed initialization of buffer pool 150704 21:35:38 [Note] InnoDB: Highest supported file format is Barracuda. 150704 21:35:41 [Note] InnoDB: 128 rollback segment(s) are active. 150704 21:35:41 [Note] InnoDB: Waiting for purge to start 150704 21:35:41 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 38238949719 150704 21:35:41 [Note] Server socket created on IP: '::'. 150704 21:35:42 [Note] Event Scheduler: Loaded 0 events 150704 21:35:42 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150704 21:40:42 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150704 21:40:44 [Note] feedback plugin: server replied 'ok' 150705 21:40:46 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150705 21:40:49 [Note] feedback plugin: server replied 'ok' 150706 10:44:53 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150706 10:44:53 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150706 10:44:53 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150706 10:44:53 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150706 10:44:53 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150706 10:44:53 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150706 10:44:54 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150706 10:44:54 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150706 11:41:12 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150706 11:41:12 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150706 11:41:13 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150706 11:41:13 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150706 11:41:13 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150706 11:41:13 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150706 11:41:13 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150706 11:41:13 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150706 13:20:41 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150706 13:20:41 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150706 13:20:41 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150706 13:20:41 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150706 13:20:41 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150706 13:20:41 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150706 13:20:41 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150706 13:20:41 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150707 9:35:53 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150707 9:35:54 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150707 9:35:54 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150707 9:35:54 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150707 9:35:54 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150707 9:35:54 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150707 9:35:54 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150707 9:35:54 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:18:55 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:18:55 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:18:55 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:18:55 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:18:55 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:18:55 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:18:55 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:18:55 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:02 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:02 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:02 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:02 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:02 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:02 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:02 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:02 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:03 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:03 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:03 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:03 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:03 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:03 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:03 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:03 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:03 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:03 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:03 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:03 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:03 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:03 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:03 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:03 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:37 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:37 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:37 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:37 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:37 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:37 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:37 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:37 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:37 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:37 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:37 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:37 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:37 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:37 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:37 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:37 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:37 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:37 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:37 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:37 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:37 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:37 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:37 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:37 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:38 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:38 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:38 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:38 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:38 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:38 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:38 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:38 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:52 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:52 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:52 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:52 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:52 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:52 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:52 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:52 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:52 [ERROR] Table ./taganka@002ddemo/appl_profile_account has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:52 [Warning] Table ./taganka@002ddemo/appl_profile_account key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:52 [ERROR] Table ./taganka@002ddemo/appl_profile_addr has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:52 [Warning] Table ./taganka@002ddemo/appl_profile_addr key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:53 [ERROR] Table ./taganka@002ddemo/appl_profile_contact has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:53 [Warning] Table ./taganka@002ddemo/appl_profile_contact key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150708 19:19:53 [ERROR] Table ./taganka@002ddemo/appl_profile_doc has no primary key in InnoDB data dictionary, but has one in MySQL! If you created the table with a MySQL version < 3.23.54 and did not define a primary key, but defined a unique key with all non-NULL columns, then MySQL internally treats that key as the primary key. You can fix this error by dump + DROP + CREATE + reimport of the table. 150708 19:19:53 [Warning] Table ./taganka@002ddemo/appl_profile_doc key_used_on_scan is 0 even though there is no primary key inside InnoDB. 150712 21:40:49 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150712 21:40:51 [Note] feedback plugin: server replied 'ok' 150714 23:31:37 [Note] /usr/libexec/mysqld: Normal shutdown 150714 23:31:37 [Note] Event Scheduler: Purging the queue. 0 events 150714 23:31:38 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150714 23:31:38 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=18 max_threads=153 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f8cc0000998 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... 150714 23:33:52 mysqld_safe Number of processes running now: 0 150714 23:33:52 mysqld_safe mysqld restarted 150714 23:33:52 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 15683 ... 150714 23:33:52 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150714 23:33:52 [Note] InnoDB: The InnoDB memory heap is disabled 150714 23:33:52 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150714 23:33:52 [Note] InnoDB: Memory barrier is not used 150714 23:33:52 [Note] InnoDB: Compressed tables use zlib 1.2.8 150714 23:33:52 [Note] InnoDB: Using Linux native AIO 150714 23:33:52 [Note] InnoDB: Using CPU crc32 instructions 150714 23:33:52 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150714 23:33:52 [Note] InnoDB: Completed initialization of buffer pool 150714 23:33:52 [Note] InnoDB: Highest supported file format is Barracuda. 150714 23:33:52 [Note] InnoDB: The log sequence numbers 38238949719 and 38238949719 in ibdata files do not match the log sequence number 44023883143 in the ib_logfiles! 150714 23:33:52 [Note] InnoDB: Database was not shutdown normally! 150714 23:33:52 [Note] InnoDB: Starting crash recovery. 150714 23:33:52 [Note] InnoDB: Reading tablespace information from the .ibd files... 150714 23:33:56 [Note] InnoDB: Restoring possible half-written data pages 150714 23:33:56 [Note] InnoDB: from the doublewrite buffer... 150714 23:33:56 [Note] InnoDB: 128 rollback segment(s) are active. 150714 23:33:56 [Note] InnoDB: Waiting for purge to start 150714 23:33:56 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 44023883143 150714 23:33:56 [Note] Recovering after a crash using tc.log 150714 23:33:56 [Note] Starting crash recovery... 150714 23:33:56 [Note] Crash recovery finished. 150714 23:33:56 [Note] Server socket created on IP: '::'. 150714 23:33:56 [Note] Event Scheduler: Loaded 0 events 150714 23:33:56 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150714 23:37:25 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150714 23:37:27 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 994 ... 150714 23:37:28 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150714 23:37:28 [Note] InnoDB: The InnoDB memory heap is disabled 150714 23:37:28 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150714 23:37:28 [Note] InnoDB: Memory barrier is not used 150714 23:37:28 [Note] InnoDB: Compressed tables use zlib 1.2.8 150714 23:37:28 [Note] InnoDB: Using Linux native AIO 150714 23:37:28 [Note] InnoDB: Using CPU crc32 instructions 150714 23:37:28 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150714 23:37:28 [Note] InnoDB: Completed initialization of buffer pool 150714 23:37:29 [Note] InnoDB: Highest supported file format is Barracuda. 150714 23:37:29 [Note] InnoDB: The log sequence numbers 38238949719 and 38238949719 in ibdata files do not match the log sequence number 44023887773 in the ib_logfiles! 150714 23:37:29 [Note] InnoDB: Database was not shutdown normally! 150714 23:37:29 [Note] InnoDB: Starting crash recovery. 150714 23:37:29 [Note] InnoDB: Reading tablespace information from the .ibd files... 150714 23:37:35 [Note] InnoDB: Restoring possible half-written data pages 150714 23:37:35 [Note] InnoDB: from the doublewrite buffer... 150714 23:37:37 [Note] InnoDB: 128 rollback segment(s) are active. 150714 23:37:37 [Note] InnoDB: Waiting for purge to start 150714 23:37:37 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 44023887773 150714 23:37:37 [Note] Recovering after a crash using tc.log 150714 23:37:37 [Note] Starting crash recovery... 150714 23:37:37 [Note] Crash recovery finished. 150714 23:37:37 [Note] Server socket created on IP: '::'. 150714 23:37:37 [Note] Event Scheduler: Loaded 0 events 150714 23:37:37 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150714 23:42:38 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150714 23:42:40 [Note] feedback plugin: server replied 'ok' 150715 23:42:41 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150715 23:42:44 [Note] feedback plugin: server replied 'ok' 150720 8:16:01 [Note] /usr/libexec/mysqld: Normal shutdown 150720 8:16:03 [Note] Event Scheduler: Purging the queue. 0 events 150720 8:16:05 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150720 8:16:05 [Note] feedback plugin: server replied 'ok' 150720 8:16:09 [Note] InnoDB: FTS optimize thread exiting. 150720 8:16:09 [Note] InnoDB: Starting shutdown... 150720 8:16:11 [Note] InnoDB: Shutdown completed; log sequence number 44073831026 150720 8:16:11 [Note] /usr/libexec/mysqld: Shutdown complete 150720 08:16:11 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended 150720 08:17:06 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150720 8:17:09 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 984 ... 150720 8:17:10 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150720 8:17:10 [Note] InnoDB: The InnoDB memory heap is disabled 150720 8:17:10 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150720 8:17:10 [Note] InnoDB: Memory barrier is not used 150720 8:17:10 [Note] InnoDB: Compressed tables use zlib 1.2.8 150720 8:17:10 [Note] InnoDB: Using Linux native AIO 150720 8:17:11 [Note] InnoDB: Using CPU crc32 instructions 150720 8:17:11 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150720 8:17:11 [Note] InnoDB: Completed initialization of buffer pool 150720 8:17:12 [Note] InnoDB: Highest supported file format is Barracuda. 150720 8:17:18 [Note] InnoDB: 128 rollback segment(s) are active. 150720 8:17:18 [Note] InnoDB: Waiting for purge to start 150720 8:17:18 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 44073831026 150720 8:17:19 [Note] Server socket created on IP: '::'. 150720 8:17:20 [Note] Event Scheduler: Loaded 0 events 150720 8:17:20 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150720 8:22:18 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150720 8:22:21 [Note] feedback plugin: server replied 'ok' 150721 8:22:21 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150721 8:22:26 [Note] feedback plugin: server replied 'ok' 150726 21:12:51 [Note] /usr/libexec/mysqld: Normal shutdown 150726 21:12:51 [Note] Event Scheduler: Purging the queue. 0 events 150726 21:14:59 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150726 21:15:04 [Note] feedback plugin: server replied 'ok' 150726 21:15:04 [Note] InnoDB: FTS optimize thread exiting. 150726 21:15:04 [Note] InnoDB: Starting shutdown... 150726 21:15:05 [Note] InnoDB: Shutdown completed; log sequence number 44404659698 150726 21:15:05 [Note] /usr/libexec/mysqld: Shutdown complete 150726 21:15:06 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended 150726 21:16:00 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150726 21:16:05 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 1005 ... 150726 21:16:07 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150726 21:16:07 [Note] InnoDB: The InnoDB memory heap is disabled 150726 21:16:07 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150726 21:16:07 [Note] InnoDB: Memory barrier is not used 150726 21:16:07 [Note] InnoDB: Compressed tables use zlib 1.2.8 150726 21:16:07 [Note] InnoDB: Using Linux native AIO 150726 21:16:07 [Note] InnoDB: Using CPU crc32 instructions 150726 21:16:08 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150726 21:16:08 [Note] InnoDB: Completed initialization of buffer pool 150726 21:16:08 [Note] InnoDB: Highest supported file format is Barracuda. 150726 21:16:13 [Note] InnoDB: 128 rollback segment(s) are active. 150726 21:16:13 [Note] InnoDB: Waiting for purge to start 150726 21:16:13 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 44404659698 150726 21:16:14 [Note] Server socket created on IP: '::'. 150726 21:16:14 [Note] Event Scheduler: Loaded 0 events 150726 21:16:14 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150726 21:21:14 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150726 21:21:14 [Note] feedback plugin: server replied 'ok' 150727 21:21:15 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150727 21:21:20 [Note] feedback plugin: server replied 'ok' 150729 5:51:28 [Note] /usr/libexec/mysqld: Normal shutdown 150729 5:51:28 [Note] Event Scheduler: Purging the queue. 0 events 150729 5:51:29 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150729 5:51:30 [Note] feedback plugin: server replied 'ok' 150729 5:51:30 [Note] InnoDB: FTS optimize thread exiting. 150729 5:51:30 [Note] InnoDB: Starting shutdown... 150729 5:51:32 [Note] InnoDB: Shutdown completed; log sequence number 44404907571 150729 5:51:32 [Note] /usr/libexec/mysqld: Shutdown complete 150729 05:51:32 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended 150729 05:52:20 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150729 5:52:23 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 954 ... 150729 5:52:24 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150729 5:52:24 [Note] InnoDB: The InnoDB memory heap is disabled 150729 5:52:24 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150729 5:52:24 [Note] InnoDB: Memory barrier is not used 150729 5:52:24 [Note] InnoDB: Compressed tables use zlib 1.2.8 150729 5:52:24 [Note] InnoDB: Using Linux native AIO 150729 5:52:24 [Note] InnoDB: Using CPU crc32 instructions 150729 5:52:24 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150729 5:52:24 [Note] InnoDB: Completed initialization of buffer pool 150729 5:52:25 [Note] InnoDB: Highest supported file format is Barracuda. 150729 5:52:27 [Note] InnoDB: 128 rollback segment(s) are active. 150729 5:52:27 [Note] InnoDB: Waiting for purge to start 150729 5:52:27 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 44404907571 150729 5:52:28 [Note] Server socket created on IP: '::'. 150729 5:52:29 [Note] Event Scheduler: Loaded 0 events 150729 5:52:29 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150729 5:57:28 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150729 5:57:31 [Note] feedback plugin: server replied 'ok' 150730 5:57:32 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150730 5:57:34 [Note] feedback plugin: server replied 'ok' 150806 5:57:35 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150806 5:57:54 [Note] feedback plugin: server replied 'ok' 150806 19:10:39 [Note] /usr/libexec/mysqld: Normal shutdown 150806 19:10:39 [Note] Event Scheduler: Purging the queue. 0 events 150806 19:10:39 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.20-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=17 max_threads=153 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467005 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7ff5ec000998 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 = 0x35 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55fa73b8f43d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x55fa7370724d] /lib64/libpthread.so.0(+0x30aa810430)[0x7ff627bce430] /usr/libexec/mysqld(_Z17vprint_msg_to_log8loglevelPKcP13__va_list_tag+0x242)[0x55fa737b58c2] /usr/libexec/mysqld(_ZN25Log_to_file_event_handler9log_errorE8loglevelPKcP13__va_list_tag+0x11)[0x55fa737b5921] /usr/libexec/mysqld(_ZN6LOGGER15error_log_printE8loglevelPKcP13__va_list_tag+0x43)[0x55fa737ab013] /usr/libexec/mysqld(_Z15error_log_print8loglevelPKcP13__va_list_tag+0x18)[0x55fa737ad798] /usr/libexec/mysqld(_Z21sql_print_informationPKcz+0xa5)[0x55fa737b13c5] /usr/libexec/mysqld(+0x97b43c)[0x55fa73b5343c] /usr/libexec/mysqld(+0x32b67e)[0x55fa7350367e] /usr/libexec/mysqld(+0x97af6f)[0x55fa73b52f6f] /lib64/libpthread.so.0(+0x30aa807555)[0x7ff627bc5555] /lib64/libc.so.6(clone+0x6d)[0x7ff62615db9d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x656e697375426520): Can't read from address 0x656e697375426520 Connection ID (thread ID): 53 Status: NOT_KILLED Optimizer switch: index_merge=off,index_merge_union=off,index_merge_sort_union=off,index_merge_intersection=on,index_merge_sort_intersection=on,engine_condition_pushdown=on,index_condition_pushdown=on,derived_merge=off,derived_with_keys=off,firstmatch=off,loosescan=off,materialization=off,in_to_exists=off,semijoin=off,partial_match_rowid_merge=off,partial_match_table_scan=off,subquery_cache=off,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=off,semijoin_with_cache=off,join_cache_incremental=off,join_cache_hashed=off,join_cache_bka=off,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=off 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. 150806 19:10:40 mysqld_safe Number of processes running now: 0 150806 19:10:40 mysqld_safe mysqld restarted 150806 19:10:40 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 1941 ... 150806 19:10:40 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150806 19:10:40 [Note] InnoDB: The InnoDB memory heap is disabled 150806 19:10:40 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150806 19:10:40 [Note] InnoDB: Memory barrier is not used 150806 19:10:40 [Note] InnoDB: Compressed tables use zlib 1.2.8 150806 19:10:40 [Note] InnoDB: Using Linux native AIO 150806 19:10:40 [Note] InnoDB: Using CPU crc32 instructions 150806 19:10:40 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150806 19:10:40 [Note] InnoDB: Completed initialization of buffer pool 150806 19:10:40 [Note] InnoDB: Highest supported file format is Barracuda. 150806 19:10:40 [Note] InnoDB: The log sequence numbers 44404907571 and 44404907571 in ibdata files do not match the log sequence number 46341761738 in the ib_logfiles! 150806 19:10:40 [Note] InnoDB: Database was not shutdown normally! 150806 19:10:40 [Note] InnoDB: Starting crash recovery. 150806 19:10:40 [Note] InnoDB: Reading tablespace information from the .ibd files... 150806 19:10:45 [Note] InnoDB: Restoring possible half-written data pages 150806 19:10:45 [Note] InnoDB: from the doublewrite buffer... 150806 19:10:46 [Note] InnoDB: 128 rollback segment(s) are active. 150806 19:10:46 [Note] InnoDB: Waiting for purge to start 150806 19:10:46 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 46341761738 150806 19:10:47 [Note] Recovering after a crash using tc.log 150806 19:10:47 [Note] Starting crash recovery... 150806 19:10:47 [Note] Crash recovery finished. 150806 19:10:47 [Note] Server socket created on IP: '::'. 150806 19:10:48 [Note] Event Scheduler: Loaded 0 events 150806 19:10:48 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150806 19:16:41 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150806 19:16:45 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 962 ... 150806 19:16:46 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150806 19:16:46 [Note] InnoDB: The InnoDB memory heap is disabled 150806 19:16:46 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150806 19:16:46 [Note] InnoDB: Memory barrier is not used 150806 19:16:46 [Note] InnoDB: Compressed tables use zlib 1.2.8 150806 19:16:46 [Note] InnoDB: Using Linux native AIO 150806 19:16:46 [Note] InnoDB: Using CPU crc32 instructions 150806 19:16:46 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150806 19:16:46 [Note] InnoDB: Completed initialization of buffer pool 150806 19:16:47 [Note] InnoDB: Highest supported file format is Barracuda. 150806 19:16:48 [Note] InnoDB: The log sequence numbers 44404907571 and 44404907571 in ibdata files do not match the log sequence number 46341764396 in the ib_logfiles! 150806 19:16:48 [Note] InnoDB: Database was not shutdown normally! 150806 19:16:48 [Note] InnoDB: Starting crash recovery. 150806 19:16:48 [Note] InnoDB: Reading tablespace information from the .ibd files... 150806 19:16:50 [Note] InnoDB: Restoring possible half-written data pages 150806 19:16:50 [Note] InnoDB: from the doublewrite buffer... 150806 19:16:52 [Note] InnoDB: 128 rollback segment(s) are active. 150806 19:16:52 [Note] InnoDB: Waiting for purge to start 150806 19:16:52 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 46341764396 150806 19:16:52 [Note] Recovering after a crash using tc.log 150806 19:16:52 [Note] Starting crash recovery... 150806 19:16:52 [Note] Crash recovery finished. 150806 19:16:52 [Note] Server socket created on IP: '::'. 150806 19:16:52 [Note] Event Scheduler: Loaded 0 events 150806 19:16:52 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150806 19:21:52 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150806 19:21:55 [Note] feedback plugin: server replied 'ok' 150807 16:24:20 [Note] /usr/libexec/mysqld: Normal shutdown 150807 16:24:21 [Note] Event Scheduler: Purging the queue. 0 events 150807 16:24:21 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150807 16:24:24 [Note] feedback plugin: server replied 'ok' 150807 16:24:25 [Note] InnoDB: FTS optimize thread exiting. 150807 16:24:25 [Note] InnoDB: Starting shutdown... 150807 16:24:27 [Note] InnoDB: Shutdown completed; log sequence number 51103238310 150807 16:24:27 [Note] /usr/libexec/mysqld: Shutdown complete 150807 16:24:27 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended 150807 16:25:25 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150807 16:25:28 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 956 ... 150807 16:25:30 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150807 16:25:30 [Note] InnoDB: The InnoDB memory heap is disabled 150807 16:25:30 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150807 16:25:30 [Note] InnoDB: Memory barrier is not used 150807 16:25:30 [Note] InnoDB: Compressed tables use zlib 1.2.8 150807 16:25:30 [Note] InnoDB: Using Linux native AIO 150807 16:25:30 [Note] InnoDB: Using CPU crc32 instructions 150807 16:25:30 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150807 16:25:30 [Note] InnoDB: Completed initialization of buffer pool 150807 16:25:31 [Note] InnoDB: Highest supported file format is Barracuda. 150807 16:25:35 [Note] InnoDB: 128 rollback segment(s) are active. 150807 16:25:35 [Note] InnoDB: Waiting for purge to start 150807 16:25:36 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 51103238310 150807 16:25:36 [Note] Server socket created on IP: '::'. 150807 16:25:36 [Note] Event Scheduler: Loaded 0 events 150807 16:25:36 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150807 16:30:40 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150807 16:30:42 [Note] feedback plugin: server replied 'ok' 150808 16:30:42 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150808 16:30:47 [Note] feedback plugin: server replied 'ok' 150812 22:44:43 [Note] /usr/libexec/mysqld: Normal shutdown 150812 22:44:43 [Note] Event Scheduler: Purging the queue. 0 events 150812 22:44:44 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150812 22:44:44 [Note] feedback plugin: server replied 'ok' 150812 22:44:44 [Note] InnoDB: FTS optimize thread exiting. 150812 22:44:44 [Note] InnoDB: Starting shutdown... 150812 22:44:47 [Note] InnoDB: Shutdown completed; log sequence number 55670924018 150812 22:44:47 [Note] /usr/libexec/mysqld: Shutdown complete 150812 22:44:47 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended 150812 20:45:43 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150812 20:45:46 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 974 ... 150812 20:45:49 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150812 20:45:49 [Note] InnoDB: The InnoDB memory heap is disabled 150812 20:45:49 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150812 20:45:49 [Note] InnoDB: Memory barrier is not used 150812 20:45:49 [Note] InnoDB: Compressed tables use zlib 1.2.8 150812 20:45:49 [Note] InnoDB: Using Linux native AIO 150812 20:45:49 [Note] InnoDB: Using CPU crc32 instructions 150812 20:45:49 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150812 20:45:50 [Note] InnoDB: Completed initialization of buffer pool 150812 20:45:51 [Note] InnoDB: Highest supported file format is Barracuda. 150812 20:45:58 [Note] InnoDB: 128 rollback segment(s) are active. 150812 20:45:58 [Note] InnoDB: Waiting for purge to start 150812 20:45:58 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 55670924018 150812 20:45:58 [Note] Server socket created on IP: '::'. 150812 20:45:59 [Note] Event Scheduler: Loaded 0 events 150812 20:45:59 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150812 22:50:15 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150812 22:50:15 [Note] feedback plugin: server replied 'ok' 150812 22:51:18 [Note] /usr/libexec/mysqld: Normal shutdown 150812 22:51:18 [Note] Event Scheduler: Purging the queue. 0 events 150812 22:51:19 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150812 22:51:19 [Note] feedback plugin: server replied 'ok' 150812 22:51:19 [Note] InnoDB: FTS optimize thread exiting. 150812 22:51:19 [Note] InnoDB: Starting shutdown... 150812 22:51:20 [Note] InnoDB: Shutdown completed; log sequence number 55670925624 150812 22:51:20 [Note] /usr/libexec/mysqld: Shutdown complete 150813 01:51:21 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended 150813 01:51:57 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150813 1:51:57 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 842 ... 150813 1:51:57 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150813 1:51:57 [Note] InnoDB: The InnoDB memory heap is disabled 150813 1:51:57 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150813 1:51:57 [Note] InnoDB: Memory barrier is not used 150813 1:51:57 [Note] InnoDB: Compressed tables use zlib 1.2.8 150813 1:51:57 [Note] InnoDB: Using Linux native AIO 150813 1:51:57 [Note] InnoDB: Using CPU crc32 instructions 150813 1:51:57 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150813 1:51:57 [Note] InnoDB: Completed initialization of buffer pool 150813 1:51:57 [Note] InnoDB: Highest supported file format is Barracuda. 150813 1:51:58 [Note] InnoDB: 128 rollback segment(s) are active. 150813 1:51:58 [Note] InnoDB: Waiting for purge to start 150813 1:51:58 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.24-72.2 started; log sequence number 55670925624 150813 1:51:58 [ERROR] feedback plugin: failed to retrieve the MAC address 150813 1:51:58 [ERROR] Plugin 'FEEDBACK' init function returned error. 150813 1:51:58 [ERROR] Plugin 'FEEDBACK' registration as a INFORMATION SCHEMA failed. 150813 1:51:58 [Note] Server socket created on IP: '::'. 150813 1:51:58 [Note] Event Scheduler: Loaded 0 events 150813 1:51:58 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.20-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 2015-08-14 18:59:27 7f64737fe700 InnoDB: FTS Optimize Removing table ugaik/#sql2-34a-17 150815 11:55:50 [Note] /usr/libexec/mysqld: Normal shutdown 150815 11:55:50 [Note] Event Scheduler: Purging the queue. 0 events 150815 11:55:51 [Note] InnoDB: FTS optimize thread exiting. 150815 11:55:51 [Note] InnoDB: Starting shutdown... 150815 11:55:52 [Note] InnoDB: Shutdown completed; log sequence number 56765554114 150815 11:55:52 [Note] /usr/libexec/mysqld: Shutdown complete 150815 11:55:52 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended 150815 11:55:53 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150815 11:55:53 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 8847 ... 150815 11:55:53 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150815 11:55:53 [Note] InnoDB: The InnoDB memory heap is disabled 150815 11:55:53 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150815 11:55:53 [Note] InnoDB: Memory barrier is not used 150815 11:55:53 [Note] InnoDB: Compressed tables use zlib 1.2.8 150815 11:55:53 [Note] InnoDB: Using Linux native AIO 150815 11:55:53 [Note] InnoDB: Using CPU crc32 instructions 150815 11:55:53 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150815 11:55:53 [Note] InnoDB: Completed initialization of buffer pool 150815 11:55:53 [Note] InnoDB: Highest supported file format is Barracuda. 150815 11:55:55 [Note] InnoDB: 128 rollback segment(s) are active. 150815 11:55:55 [Note] InnoDB: Waiting for purge to start 150815 11:55:55 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 56765554114 150815 11:55:56 [Note] Server socket created on IP: '::'. 150815 11:55:56 [Note] Event Scheduler: Loaded 0 events 150815 11:55:56 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150815 11:57:53 [Note] /usr/libexec/mysqld: Normal shutdown 150815 11:57:53 [Note] Event Scheduler: Purging the queue. 0 events 150815 11:57:53 [Note] InnoDB: FTS optimize thread exiting. 150815 11:57:53 [Note] InnoDB: Starting shutdown... 150815 11:57:54 [Note] InnoDB: Shutdown completed; log sequence number 56765557584 150815 11:57:54 [Note] /usr/libexec/mysqld: Shutdown complete 150815 11:57:54 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended 150815 11:58:50 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150815 11:58:54 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 956 ... 150815 11:58:55 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150815 11:58:55 [Note] InnoDB: The InnoDB memory heap is disabled 150815 11:58:55 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150815 11:58:55 [Note] InnoDB: Memory barrier is not used 150815 11:58:55 [Note] InnoDB: Compressed tables use zlib 1.2.8 150815 11:58:55 [Note] InnoDB: Using Linux native AIO 150815 11:58:56 [Note] InnoDB: Using CPU crc32 instructions 150815 11:58:56 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150815 11:58:56 [Note] InnoDB: Completed initialization of buffer pool 150815 11:58:56 [Note] InnoDB: Highest supported file format is Barracuda. 150815 11:59:00 [Note] InnoDB: 128 rollback segment(s) are active. 150815 11:59:00 [Note] InnoDB: Waiting for purge to start 150815 11:59:00 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 56765557584 150815 11:59:01 [Note] Server socket created on IP: '::'. 150815 11:59:01 [Note] Event Scheduler: Loaded 0 events 150815 11:59:01 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150815 12:04:00 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150815 12:04:01 [Note] feedback plugin: server replied 'ok' 2015-08-15 14:04:57 7f49feffd700 InnoDB: FTS Optimize Removing table dev/#sql2-3bc-e 2015-08-15 14:08:12 7f49feffd700 InnoDB: FTS Optimize Removing table dev/#sql2-3bc-f 2015-08-15 14:09:48 7f49feffd700 InnoDB: FTS Optimize Removing table demo/#sql2-3bc-10 2015-08-15 14:10:36 7f49feffd700 InnoDB: FTS Optimize Removing table demo/#sql2-3bc-11 2015-08-15 14:12:47 7f49feffd700 InnoDB: FTS Optimize Removing table ugaik/#sql2-3bc-12 2015-08-15 14:16:33 7f49feffd700 InnoDB: FTS Optimize Removing table itpark/#sql2-3bc-13 150816 12:04:02 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150816 12:04:05 [Note] feedback plugin: server replied 'ok' 2015-08-18 16:16:38 7f49feffd700 InnoDB: FTS Optimize Removing table itpark/#sql2-3bc-5e 2015-08-18 16:18:51 7f49feffd700 InnoDB: FTS Optimize Removing table itpark/#sql2-3bc-5f 2015-08-18 21:10:52 7f49feffd700 InnoDB: FTS Optimize Removing table ugaik/crm_client 2015-08-18 21:19:48 7f49feffd700 InnoDB: FTS Optimize Removing table ugaik/#sql2-3bc-6b 2015-08-18 21:23:19 7f49feffd700 InnoDB: FTS Optimize Removing table ugaik/#sql2-3bc-6c 2015-08-19 02:12:32 7f49feffd700 InnoDB: FTS Optimize Removing table ugaik/#sql2-3bc-75 2015-08-19 02:14:04 7f49feffd700 InnoDB: FTS Optimize Removing table ugaik/#sql2-3bc-76 150823 12:04:05 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150823 12:04:10 [Note] feedback plugin: server replied 'ok' 2015-08-25 04:39:44 7f49feffd700 InnoDB: FTS Optimize Removing table dev/#sql2-3bc-c3 2015-08-26 05:23:48 7f49feffd700 InnoDB: FTS Optimize Removing table itpark/#sql2-3bc-dd 2015-08-26 14:39:42 7f49feffd700 InnoDB: FTS Optimize Removing table dev/#sql2-3bc-ef 150827 15:19:26 [Note] /usr/libexec/mysqld: Normal shutdown 150827 15:19:26 [Note] Event Scheduler: Purging the queue. 0 events 150827 15:19:27 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.21-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=27 max_threads=153 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467003 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f49ec112c08 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 = 0x613301531415a02 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x563b75522e1d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x563b75099d0d] /lib64/libpthread.so.0(+0x30aa810430)[0x7f4a2df4c430] /usr/libexec/mysqld(_Z17vprint_msg_to_log8loglevelPKcP13__va_list_tag+0x242)[0x563b751484c2] /usr/libexec/mysqld(_ZN25Log_to_file_event_handler9log_errorE8loglevelPKcP13__va_list_tag+0x11)[0x563b75148521] /usr/libexec/mysqld(_ZN6LOGGER15error_log_printE8loglevelPKcP13__va_list_tag+0x43)[0x563b7513dc63] /usr/libexec/mysqld(_Z15error_log_print8loglevelPKcP13__va_list_tag+0x18)[0x563b751403e8] /usr/libexec/mysqld(_Z21sql_print_informationPKcz+0xa5)[0x563b75144015] /usr/libexec/mysqld(+0x97ccec)[0x563b754e6cec] /usr/libexec/mysqld(+0x32bc37)[0x563b74e95c37] /usr/libexec/mysqld(+0x97c81f)[0x563b754e681f] /lib64/libpthread.so.0(+0x30aa807555)[0x7f4a2df43555] /lib64/libc.so.6(clone+0x6d)[0x7f4a2c4dbb9d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x61762e7777772f2f): Can't read from address 0x61762e7777772f2f Connection ID (thread ID): 16015729188732545216 Status: UNKNOWN Optimizer switch: index_merge=on,index_merge_union=off,index_merge_sort_union=on,index_merge_intersection=off,index_merge_sort_intersection=off,engine_condition_pushdown=on,index_condition_pushdown=off,derived_merge=off,derived_with_keys=off,firstmatch=off,loosescan=off,materialization=off,in_to_exists=off,semijoin=off,partial_match_rowid_merge=off,partial_match_table_scan=off,subquery_cache=off,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=off,semijoin_with_cache=off,join_cache_incremental=off,join_cache_hashed=off,join_cache_bka=off,optimize_join_buffer_size=off,table_elimination=off,extended_keys=off,exists_to_in=off 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. 150827 15:19:27 mysqld_safe Number of processes running now: 0 150827 15:19:27 mysqld_safe mysqld restarted 150827 15:19:28 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 2896 ... 150827 15:19:28 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150827 15:19:28 [Note] InnoDB: The InnoDB memory heap is disabled 150827 15:19:28 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150827 15:19:28 [Note] InnoDB: Memory barrier is not used 150827 15:19:28 [Note] InnoDB: Compressed tables use zlib 1.2.8 150827 15:19:28 [Note] InnoDB: Using Linux native AIO 150827 15:19:28 [Note] InnoDB: Using CPU crc32 instructions 150827 15:19:28 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150827 15:19:28 [Note] InnoDB: Completed initialization of buffer pool 150827 15:19:28 [Note] InnoDB: Highest supported file format is Barracuda. 150827 15:19:28 [Note] InnoDB: Log scan progressed past the checkpoint lsn 60374052319 150827 15:19:28 [Note] InnoDB: Database was not shutdown normally! 150827 15:19:28 [Note] InnoDB: Starting crash recovery. 150827 15:19:28 [Note] InnoDB: Reading tablespace information from the .ibd files... 150827 15:19:35 [Note] InnoDB: Restoring possible half-written data pages 150827 15:19:35 [Note] InnoDB: from the doublewrite buffer... InnoDB: Doing recovery: scanned up to log sequence number 60374063450 150827 15:19:36 [Note] InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 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 150827 15:19:37 [Note] InnoDB: 128 rollback segment(s) are active. 150827 15:19:37 [Note] InnoDB: Waiting for purge to start 150827 15:19:37 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 60374063450 150827 15:19:37 [Note] Recovering after a crash using tc.log 150827 15:19:37 [Note] Starting crash recovery... 150827 15:19:37 [Note] Crash recovery finished. 150827 15:19:37 [Note] Server socket created on IP: '::'. 150827 15:19:38 [Note] Event Scheduler: Loaded 0 events 150827 15:19:38 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150827 15:24:27 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150827 15:24:27 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 3139 ... 150827 15:24:27 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150827 15:24:27 [Note] InnoDB: The InnoDB memory heap is disabled 150827 15:24:27 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150827 15:24:27 [Note] InnoDB: Memory barrier is not used 150827 15:24:27 [Note] InnoDB: Compressed tables use zlib 1.2.8 150827 15:24:27 [Note] InnoDB: Using Linux native AIO 150827 15:24:27 [Note] InnoDB: Using CPU crc32 instructions 150827 15:24:27 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150827 15:24:27 [Note] InnoDB: Completed initialization of buffer pool 150827 15:24:27 [Note] InnoDB: Highest supported file format is Barracuda. 150827 15:24:27 [Note] InnoDB: The log sequence numbers 56765557584 and 56765557584 in ibdata files do not match the log sequence number 60374067371 in the ib_logfiles! 150827 15:24:27 [Note] InnoDB: Database was not shutdown normally! 150827 15:24:27 [Note] InnoDB: Starting crash recovery. 150827 15:24:27 [Note] InnoDB: Reading tablespace information from the .ibd files... 150827 15:24:27 [Note] InnoDB: Restoring possible half-written data pages 150827 15:24:27 [Note] InnoDB: from the doublewrite buffer... 150827 15:24:28 [Note] InnoDB: 128 rollback segment(s) are active. 150827 15:24:28 [Note] InnoDB: Waiting for purge to start 150827 15:24:28 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 60374067371 150827 15:24:28 [Note] Recovering after a crash using tc.log 150827 15:24:28 [Note] Starting crash recovery... 150827 15:24:28 [Note] Crash recovery finished. 150827 15:24:28 [Note] Server socket created on IP: '::'. 150827 15:24:28 [Note] Event Scheduler: Loaded 0 events 150827 15:24:28 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150827 15:29:28 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150827 15:29:29 [Note] feedback plugin: server replied 'ok' 2015-08-27 15:30:23 7fc03effd700 InnoDB: FTS Optimize Removing table itpark/#sql2-c43-c 2015-08-27 15:31:26 7fc03effd700 InnoDB: FTS Optimize Removing table itpark/#sql2-c43-d 150827 15:45:03 [Note] /usr/libexec/mysqld: Normal shutdown 150827 15:45:03 [Note] Event Scheduler: Purging the queue. 0 events 150827 15:45:04 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150827 15:45:04 [Note] feedback plugin: server replied 'ok' 150827 15:45:04 [Note] InnoDB: FTS optimize thread exiting. 150827 15:45:04 [Note] InnoDB: Starting shutdown... 150827 15:45:06 [Note] InnoDB: Shutdown completed; log sequence number 60596104528 150827 15:45:06 [Note] /usr/libexec/mysqld: Shutdown complete 150827 15:45:06 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended 150827 15:46:07 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150827 15:46:10 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 964 ... 150827 15:46:12 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150827 15:46:12 [Note] InnoDB: The InnoDB memory heap is disabled 150827 15:46:12 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150827 15:46:12 [Note] InnoDB: Memory barrier is not used 150827 15:46:12 [Note] InnoDB: Compressed tables use zlib 1.2.8 150827 15:46:12 [Note] InnoDB: Using Linux native AIO 150827 15:46:12 [Note] InnoDB: Using CPU crc32 instructions 150827 15:46:12 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150827 15:46:12 [Note] InnoDB: Completed initialization of buffer pool 150827 15:46:12 [Note] InnoDB: Highest supported file format is Barracuda. 150827 15:46:16 [Note] InnoDB: 128 rollback segment(s) are active. 150827 15:46:16 [Note] InnoDB: Waiting for purge to start 150827 15:46:16 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 60596104528 150827 15:46:16 [Note] Server socket created on IP: '::'. 150827 15:46:18 [Note] Event Scheduler: Loaded 0 events 150827 15:46:18 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150827 15:51:16 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150827 15:51:17 [Note] feedback plugin: server replied 'ok' 2015-08-27 16:02:27 7f87337fe700 InnoDB: FTS Optimize Removing table itpark/#sql2-3c4-e 150828 15:51:17 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150828 15:51:22 [Note] feedback plugin: server replied 'ok' 150902 9:52:59 [Note] /usr/libexec/mysqld: Normal shutdown 150902 9:52:59 [Note] Event Scheduler: Purging the queue. 0 events 150902 9:53:00 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.21-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=21 max_threads=153 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467003 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f873c110b88 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 = 0x35 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55c54cd73e1d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x55c54c8ead0d] /lib64/libpthread.so.0(+0x30aa810430)[0x7f8767226430] /usr/libexec/mysqld(_Z17vprint_msg_to_log8loglevelPKcP13__va_list_tag+0x246)[0x55c54c9994c6] /usr/libexec/mysqld(_ZN25Log_to_file_event_handler9log_errorE8loglevelPKcP13__va_list_tag+0x11)[0x55c54c999521] /usr/libexec/mysqld(_ZN6LOGGER15error_log_printE8loglevelPKcP13__va_list_tag+0x43)[0x55c54c98ec63] /usr/libexec/mysqld(_Z15error_log_print8loglevelPKcP13__va_list_tag+0x18)[0x55c54c9913e8] /usr/libexec/mysqld(_Z21sql_print_informationPKcz+0xa5)[0x55c54c995015] /usr/libexec/mysqld(+0x97ccec)[0x55c54cd37cec] /usr/libexec/mysqld(+0x32bc37)[0x55c54c6e6c37] /usr/libexec/mysqld(+0x97c81f)[0x55c54cd3781f] /lib64/libpthread.so.0(+0x30aa807555)[0x7f876721d555] /lib64/libc.so.6(clone+0x6d)[0x7f87657b5b9d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f873c11a1f0): Thawte Consulting cc Connection ID (thread ID): 8390880395950580054 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on 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. 150902 09:53:00 mysqld_safe Number of processes running now: 0 150902 09:53:00 mysqld_safe mysqld restarted 150902 9:53:01 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 11825 ... 150902 9:53:01 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150902 9:53:01 [Note] InnoDB: The InnoDB memory heap is disabled 150902 9:53:01 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150902 9:53:01 [Note] InnoDB: Memory barrier is not used 150902 9:53:01 [Note] InnoDB: Compressed tables use zlib 1.2.8 150902 9:53:01 [Note] InnoDB: Using Linux native AIO 150902 9:53:01 [Note] InnoDB: Using CPU crc32 instructions 150902 9:53:01 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150902 9:53:01 [Note] InnoDB: Completed initialization of buffer pool 150902 9:53:01 [Note] InnoDB: Highest supported file format is Barracuda. 150902 9:53:01 [Note] InnoDB: The log sequence numbers 60596104528 and 60596104528 in ibdata files do not match the log sequence number 60652292445 in the ib_logfiles! 150902 9:53:01 [Note] InnoDB: Database was not shutdown normally! 150902 9:53:01 [Note] InnoDB: Starting crash recovery. 150902 9:53:01 [Note] InnoDB: Reading tablespace information from the .ibd files... 150902 9:53:09 [Note] InnoDB: Restoring possible half-written data pages 150902 9:53:09 [Note] InnoDB: from the doublewrite buffer... 150902 9:53:11 [Note] InnoDB: 128 rollback segment(s) are active. 150902 9:53:11 [Note] InnoDB: Waiting for purge to start 150902 9:53:11 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 60652292445 150902 9:53:11 [Note] Recovering after a crash using tc.log 150902 9:53:11 [Note] Starting crash recovery... 150902 9:53:11 [Note] Crash recovery finished. 150902 9:53:11 [Note] Server socket created on IP: '::'. 150902 9:53:11 [Note] Event Scheduler: Loaded 0 events 150902 9:53:11 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150902 09:58:51 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150902 9:58:54 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 1067 ... 150902 9:58:55 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150902 9:58:55 [Note] InnoDB: The InnoDB memory heap is disabled 150902 9:58:55 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150902 9:58:55 [Note] InnoDB: Memory barrier is not used 150902 9:58:55 [Note] InnoDB: Compressed tables use zlib 1.2.8 150902 9:58:55 [Note] InnoDB: Using Linux native AIO 150902 9:58:55 [Note] InnoDB: Using CPU crc32 instructions 150902 9:58:55 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150902 9:58:55 [Note] InnoDB: Completed initialization of buffer pool 150902 9:58:56 [Note] InnoDB: Highest supported file format is Barracuda. 150902 9:58:56 [Note] InnoDB: The log sequence numbers 60596104528 and 60596104528 in ibdata files do not match the log sequence number 60652295882 in the ib_logfiles! 150902 9:58:56 [Note] InnoDB: Database was not shutdown normally! 150902 9:58:56 [Note] InnoDB: Starting crash recovery. 150902 9:58:56 [Note] InnoDB: Reading tablespace information from the .ibd files... 150902 9:58:57 [Note] InnoDB: Restoring possible half-written data pages 150902 9:58:57 [Note] InnoDB: from the doublewrite buffer... 150902 9:58:59 [Note] InnoDB: 128 rollback segment(s) are active. 150902 9:58:59 [Note] InnoDB: Waiting for purge to start 150902 9:58:59 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 60652295882 150902 9:59:00 [Note] Recovering after a crash using tc.log 150902 9:59:00 [Note] Starting crash recovery... 150902 9:59:00 [Note] Crash recovery finished. 150902 9:59:00 [Note] Server socket created on IP: '::'. 150902 9:59:00 [Note] Event Scheduler: Loaded 0 events 150902 9:59:00 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150902 10:04:00 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150902 10:04:04 [Note] feedback plugin: server replied 'ok' 150903 10:04:05 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150903 10:04:43 [Note] feedback plugin: server replied 'ok' 2015-09-03 10:37:20 7fa3cfff7700 InnoDB: FTS Optimize Removing table itpark/#sql2-42b-2f 2015-09-03 10:38:34 7fa3cfff7700 InnoDB: FTS Optimize Removing table itpark/#sql2-42b-31 150905 14:36:03 [Note] /usr/libexec/mysqld: Normal shutdown 150905 14:36:05 [Note] Event Scheduler: Purging the queue. 0 events 150905 14:36:06 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150905 14:36:06 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.21-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=28 max_threads=153 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467003 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7fa3c0110a48 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 = 0xffffffffffffffff thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55b4400fbe1d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x55b43fc72d0d] /lib64/libpthread.so.0(+0x30aa810430)[0x7fa3fe8c2430] /usr/libexec/mysqld(thd_wait_begin+0x19)[0x55b43fae7859] /usr/libexec/mysqld(vio_io_wait+0x14a)[0x55b44013d8ea] /usr/libexec/mysqld(vio_socket_io_wait+0x18)[0x55b44013d9a8] /usr/libexec/mysqld(vio_ssl_read+0x9d)[0x55b44013e5ed] /usr/libexec/mysqld(+0x97cd05)[0x55b4400bfd05] /usr/libexec/mysqld(+0x32bc37)[0x55b43fa6ec37] /usr/libexec/mysqld(+0x97c81f)[0x55b4400bf81f] /lib64/libpthread.so.0(+0x30aa807555)[0x7fa3fe8b9555] /lib64/libc.so.6(clone+0x6d)[0x7fa3fce51b9d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x206e6f6974616469): Can't read from address 0x206e6f6974616469 Connection ID (thread ID): 12884902144 Status: NOT_KILLED Optimizer switch: index_merge=off,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=off,derived_with_keys=on,firstmatch=off,loosescan=on,materialization=off,in_to_exists=off,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=off,subquery_cache=off,mrr=off,mrr_cost_based=on,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=off,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=off,exists_to_in=on 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. 150905 14:36:06 mysqld_safe Number of processes running now: 0 150905 14:36:06 mysqld_safe mysqld restarted 150905 14:36:07 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 10810 ... 150905 14:36:07 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150905 14:36:07 [Note] InnoDB: The InnoDB memory heap is disabled 150905 14:36:07 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150905 14:36:07 [Note] InnoDB: Memory barrier is not used 150905 14:36:07 [Note] InnoDB: Compressed tables use zlib 1.2.8 150905 14:36:07 [Note] InnoDB: Using Linux native AIO 150905 14:36:07 [Note] InnoDB: Using CPU crc32 instructions 150905 14:36:07 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150905 14:36:07 [Note] InnoDB: Completed initialization of buffer pool 150905 14:36:07 [Note] InnoDB: Highest supported file format is Barracuda. 150905 14:36:07 [Note] InnoDB: The log sequence numbers 60596104528 and 60596104528 in ibdata files do not match the log sequence number 60752764278 in the ib_logfiles! 150905 14:36:07 [Note] InnoDB: Database was not shutdown normally! 150905 14:36:07 [Note] InnoDB: Starting crash recovery. 150905 14:36:07 [Note] InnoDB: Reading tablespace information from the .ibd files... 150905 14:36:16 [Note] InnoDB: Restoring possible half-written data pages 150905 14:36:16 [Note] InnoDB: from the doublewrite buffer... 150905 14:36:18 [Note] InnoDB: 128 rollback segment(s) are active. 150905 14:36:18 [Note] InnoDB: Waiting for purge to start 150905 14:36:18 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 60752764278 150905 14:36:18 [Note] Recovering after a crash using tc.log 150905 14:36:18 [Note] Starting crash recovery... 150905 14:36:18 [Note] Crash recovery finished. 150905 14:36:18 [Note] Server socket created on IP: '::'. 150905 14:36:19 [Note] Event Scheduler: Loaded 0 events 150905 14:36:19 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150905 14:42:00 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150905 14:42:04 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 950 ... 150905 14:42:05 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150905 14:42:05 [Note] InnoDB: The InnoDB memory heap is disabled 150905 14:42:05 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150905 14:42:05 [Note] InnoDB: Memory barrier is not used 150905 14:42:05 [Note] InnoDB: Compressed tables use zlib 1.2.8 150905 14:42:05 [Note] InnoDB: Using Linux native AIO 150905 14:42:06 [Note] InnoDB: Using CPU crc32 instructions 150905 14:42:06 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150905 14:42:06 [Note] InnoDB: Completed initialization of buffer pool 150905 14:42:07 [Note] InnoDB: Highest supported file format is Barracuda. 150905 14:42:07 [Note] InnoDB: The log sequence numbers 60596104528 and 60596104528 in ibdata files do not match the log sequence number 60752768112 in the ib_logfiles! 150905 14:42:07 [Note] InnoDB: Database was not shutdown normally! 150905 14:42:07 [Note] InnoDB: Starting crash recovery. 150905 14:42:07 [Note] InnoDB: Reading tablespace information from the .ibd files... 150905 14:42:09 [Note] InnoDB: Restoring possible half-written data pages 150905 14:42:09 [Note] InnoDB: from the doublewrite buffer... 150905 14:42:12 [Note] InnoDB: 128 rollback segment(s) are active. 150905 14:42:12 [Note] InnoDB: Waiting for purge to start 150905 14:42:12 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 60752768112 150905 14:42:12 [Note] Recovering after a crash using tc.log 150905 14:42:12 [Note] Starting crash recovery... 150905 14:42:12 [Note] Crash recovery finished. 150905 14:42:12 [Note] Server socket created on IP: '::'. 150905 14:42:12 [Note] Event Scheduler: Loaded 0 events 150905 14:42:12 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150905 14:47:13 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150905 14:47:13 [Note] feedback plugin: server replied 'ok' 150906 06:59:51 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150906 6:59:57 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 1063 ... 150906 6:59:58 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150906 6:59:58 [Note] InnoDB: The InnoDB memory heap is disabled 150906 6:59:58 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150906 6:59:58 [Note] InnoDB: Memory barrier is not used 150906 6:59:58 [Note] InnoDB: Compressed tables use zlib 1.2.8 150906 6:59:58 [Note] InnoDB: Using Linux native AIO 150906 6:59:59 [Note] InnoDB: Using CPU crc32 instructions 150906 6:59:59 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150906 6:59:59 [Note] InnoDB: Completed initialization of buffer pool 150906 7:00:00 [Note] InnoDB: Highest supported file format is Barracuda. 150906 7:00:00 [Note] InnoDB: The log sequence numbers 60596104528 and 60596104528 in ibdata files do not match the log sequence number 60752773880 in the ib_logfiles! 150906 7:00:00 [Note] InnoDB: Database was not shutdown normally! 150906 7:00:00 [Note] InnoDB: Starting crash recovery. 150906 7:00:00 [Note] InnoDB: Reading tablespace information from the .ibd files... 150906 7:00:29 [Note] InnoDB: Restoring possible half-written data pages 150906 7:00:29 [Note] InnoDB: from the doublewrite buffer... 150906 7:00:31 [Note] InnoDB: 128 rollback segment(s) are active. 150906 7:00:31 [Note] InnoDB: Waiting for purge to start 150906 7:00:31 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 60752773880 150906 7:00:32 [Note] Recovering after a crash using tc.log 150906 7:00:32 [Note] Starting crash recovery... 150906 7:00:32 [Note] Crash recovery finished. 150906 7:00:32 [Note] Server socket created on IP: '::'. 150906 7:00:32 [Note] Event Scheduler: Loaded 0 events 150906 7:00:32 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150906 7:05:32 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150906 7:05:34 [Note] feedback plugin: server replied 'ok' 150907 7:05:35 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150907 7:05:38 [Note] feedback plugin: server replied 'ok' 150910 23:47:07 [Note] /usr/libexec/mysqld: Normal shutdown 150910 23:47:07 [Note] Event Scheduler: Purging the queue. 0 events 150910 23:47:08 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150910 23:47:08 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.21-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=23 max_threads=153 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467003 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7fb8b0110a48 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 = 0x25 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5618aa2b0e1d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x5618a9e27d0d] /lib64/libpthread.so.0(+0x30aa810430)[0x7fb8ee04b430] [0x7fb8b00000b8] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x61762e7777772f2f): Can't read from address 0x61762e7777772f2f Connection ID (thread ID): 0 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=off,index_merge_sort_union=off,index_merge_intersection=off,index_merge_sort_intersection=off,engine_condition_pushdown=on,index_condition_pushdown=on,derived_merge=off,derived_with_keys=on,firstmatch=on,loosescan=off,materialization=off,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=off,subquery_cache=on,mrr=on,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=off,join_cache_bka=off,optimize_join_buffer_size=off,table_elimination=off,extended_keys=off,exists_to_in=off 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. 150910 23:47:08 mysqld_safe Number of processes running now: 0 150910 23:47:08 mysqld_safe mysqld restarted 150910 23:47:09 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 31861 ... 150910 23:47:09 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150910 23:47:09 [Note] InnoDB: The InnoDB memory heap is disabled 150910 23:47:09 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150910 23:47:09 [Note] InnoDB: Memory barrier is not used 150910 23:47:09 [Note] InnoDB: Compressed tables use zlib 1.2.8 150910 23:47:09 [Note] InnoDB: Using Linux native AIO 150910 23:47:09 [Note] InnoDB: Using CPU crc32 instructions 150910 23:47:09 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150910 23:47:09 [Note] InnoDB: Completed initialization of buffer pool 150910 23:47:09 [Note] InnoDB: Highest supported file format is Barracuda. 150910 23:47:09 [Note] InnoDB: Log scan progressed past the checkpoint lsn 60755957448 150910 23:47:09 [Note] InnoDB: Database was not shutdown normally! 150910 23:47:09 [Note] InnoDB: Starting crash recovery. 150910 23:47:09 [Note] InnoDB: Reading tablespace information from the .ibd files... 150910 23:47:17 [Note] InnoDB: Restoring possible half-written data pages 150910 23:47:17 [Note] InnoDB: from the doublewrite buffer... InnoDB: Doing recovery: scanned up to log sequence number 60755966936 150910 23:47:19 [Note] InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 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 150910 23:47:19 [Note] InnoDB: 128 rollback segment(s) are active. 150910 23:47:19 [Note] InnoDB: Waiting for purge to start 150910 23:47:19 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 60755966936 150910 23:47:19 [Note] Recovering after a crash using tc.log 150910 23:47:19 [Note] Starting crash recovery... 150910 23:47:19 [Note] Crash recovery finished. 150910 23:47:19 [Note] Server socket created on IP: '::'. 150910 23:47:20 [Note] Event Scheduler: Loaded 0 events 150910 23:47:20 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150910 23:52:57 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150910 23:53:00 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 959 ... 150910 23:53:02 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150910 23:53:02 [Note] InnoDB: The InnoDB memory heap is disabled 150910 23:53:02 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150910 23:53:02 [Note] InnoDB: Memory barrier is not used 150910 23:53:02 [Note] InnoDB: Compressed tables use zlib 1.2.8 150910 23:53:02 [Note] InnoDB: Using Linux native AIO 150910 23:53:02 [Note] InnoDB: Using CPU crc32 instructions 150910 23:53:02 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150910 23:53:03 [Note] InnoDB: Completed initialization of buffer pool 150910 23:53:03 [Note] InnoDB: Highest supported file format is Barracuda. 150910 23:53:03 [Note] InnoDB: The log sequence numbers 60596104528 and 60596104528 in ibdata files do not match the log sequence number 60755967207 in the ib_logfiles! 150910 23:53:03 [Note] InnoDB: Database was not shutdown normally! 150910 23:53:03 [Note] InnoDB: Starting crash recovery. 150910 23:53:03 [Note] InnoDB: Reading tablespace information from the .ibd files... 150910 23:53:05 [Note] InnoDB: Restoring possible half-written data pages 150910 23:53:05 [Note] InnoDB: from the doublewrite buffer... 150910 23:53:08 [Note] InnoDB: 128 rollback segment(s) are active. 150910 23:53:08 [Note] InnoDB: Waiting for purge to start 150910 23:53:08 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 60755967207 150910 23:53:08 [Note] Recovering after a crash using tc.log 150910 23:53:08 [Note] Starting crash recovery... 150910 23:53:08 [Note] Crash recovery finished. 150910 23:53:08 [Note] Server socket created on IP: '::'. 150910 23:53:08 [Note] Event Scheduler: Loaded 0 events 150910 23:53:08 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150910 23:58:08 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150910 23:58:09 [Note] feedback plugin: server replied 'ok' 2015-09-11 21:34:29 7ff2b1ffb700 InnoDB: FTS Optimize Removing table itpark/#sql2-3bf-28 2015-09-11 21:35:27 7ff2b1ffb700 InnoDB: FTS Optimize Removing table itpark/#sql2-3bf-29 150911 23:58:09 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150911 23:58:12 [Note] feedback plugin: server replied 'ok' 150914 17:31:22 [Note] /usr/libexec/mysqld: Normal shutdown 150914 17:31:23 [Note] Event Scheduler: Purging the queue. 0 events 150914 17:31:23 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.21-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=19 max_threads=153 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467003 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7ff2a4110a48 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 = 0x0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55d492f5de1d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x55d492ad4d0d] /lib64/libpthread.so.0(+0x30aa810430)[0x7ff2e0d4a430] /usr/libexec/mysqld(_Z17vprint_msg_to_log8loglevelPKcP13__va_list_tag+0x242)[0x55d492b834c2] /usr/libexec/mysqld(_ZN25Log_to_file_event_handler9log_errorE8loglevelPKcP13__va_list_tag+0x11)[0x55d492b83521] /usr/libexec/mysqld(_ZN6LOGGER15error_log_printE8loglevelPKcP13__va_list_tag+0x43)[0x55d492b78c63] /usr/libexec/mysqld(_Z15error_log_print8loglevelPKcP13__va_list_tag+0x18)[0x55d492b7b3e8] /usr/libexec/mysqld(_Z21sql_print_informationPKcz+0xa5)[0x55d492b7f015] /usr/libexec/mysqld(+0x97ccec)[0x55d492f21cec] /usr/libexec/mysqld(+0x32bc37)[0x55d4928d0c37] /usr/libexec/mysqld(+0x97c81f)[0x55d492f2181f] /lib64/libpthread.so.0(+0x30aa807555)[0x7ff2e0d41555] /lib64/libc.so.6(clone+0x6d)[0x7ff2df2d9b9d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x61561b1307045503): Can't read from address 0x61561b1307045503 Connection ID (thread ID): 0 Status: UNKNOWN Optimizer switch: index_merge=off,index_merge_union=on,index_merge_sort_union=off,index_merge_intersection=on,index_merge_sort_intersection=on,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=off,firstmatch=on,loosescan=off,materialization=off,in_to_exists=on,semijoin=off,partial_match_rowid_merge=off,partial_match_table_scan=off,subquery_cache=on,mrr=on,mrr_cost_based=on,mrr_sort_keys=on,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=off,exists_to_in=on 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. 150914 17:31:24 mysqld_safe Number of processes running now: 0 150914 17:31:24 mysqld_safe mysqld restarted 150914 17:31:24 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 13136 ... 150914 17:31:24 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150914 17:31:24 [Note] InnoDB: The InnoDB memory heap is disabled 150914 17:31:24 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150914 17:31:24 [Note] InnoDB: Memory barrier is not used 150914 17:31:24 [Note] InnoDB: Compressed tables use zlib 1.2.8 150914 17:31:24 [Note] InnoDB: Using Linux native AIO 150914 17:31:24 [Note] InnoDB: Using CPU crc32 instructions 150914 17:31:24 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150914 17:31:24 [Note] InnoDB: Completed initialization of buffer pool 150914 17:31:24 [Note] InnoDB: Highest supported file format is Barracuda. 150914 17:31:24 [Note] InnoDB: Log scan progressed past the checkpoint lsn 60901414772 150914 17:31:24 [Note] InnoDB: Database was not shutdown normally! 150914 17:31:24 [Note] InnoDB: Starting crash recovery. 150914 17:31:24 [Note] InnoDB: Reading tablespace information from the .ibd files... 150914 17:31:32 [Note] InnoDB: Restoring possible half-written data pages 150914 17:31:32 [Note] InnoDB: from the doublewrite buffer... InnoDB: Doing recovery: scanned up to log sequence number 60901420397 150914 17:31:33 [Note] InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 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 150914 17:31:34 [Note] InnoDB: 128 rollback segment(s) are active. 150914 17:31:34 [Note] InnoDB: Waiting for purge to start 150914 17:31:34 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 60901420397 150914 17:31:34 [Note] Recovering after a crash using tc.log 150914 17:31:34 [Note] Starting crash recovery... 150914 17:31:34 [Note] Crash recovery finished. 150914 17:31:34 [Note] Server socket created on IP: '::'. 150914 17:31:34 [Note] Event Scheduler: Loaded 0 events 150914 17:31:34 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150914 12:37:14 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150914 12:37:18 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 950 ... 150914 12:37:19 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150914 12:37:19 [Note] InnoDB: The InnoDB memory heap is disabled 150914 12:37:19 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150914 12:37:19 [Note] InnoDB: Memory barrier is not used 150914 12:37:19 [Note] InnoDB: Compressed tables use zlib 1.2.8 150914 12:37:19 [Note] InnoDB: Using Linux native AIO 150914 12:37:20 [Note] InnoDB: Using CPU crc32 instructions 150914 12:37:20 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150914 12:37:20 [Note] InnoDB: Completed initialization of buffer pool 150914 12:37:21 [Note] InnoDB: Highest supported file format is Barracuda. 150914 12:37:21 [Note] InnoDB: The log sequence numbers 60596104528 and 60596104528 in ibdata files do not match the log sequence number 60901422608 in the ib_logfiles! 150914 12:37:21 [Note] InnoDB: Database was not shutdown normally! 150914 12:37:21 [Note] InnoDB: Starting crash recovery. 150914 12:37:21 [Note] InnoDB: Reading tablespace information from the .ibd files... 150914 17:37:23 [Note] InnoDB: Restoring possible half-written data pages 150914 17:37:23 [Note] InnoDB: from the doublewrite buffer... 150914 17:37:26 [Note] InnoDB: 128 rollback segment(s) are active. 150914 17:37:26 [Note] InnoDB: Waiting for purge to start 150914 17:37:26 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 60901422608 150914 17:37:26 [Note] Recovering after a crash using tc.log 150914 17:37:27 [Note] Starting crash recovery... 150914 17:37:27 [Note] Crash recovery finished. 150914 17:37:27 [Note] Server socket created on IP: '::'. 150914 17:37:27 [Note] Event Scheduler: Loaded 0 events 150914 17:37:27 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150914 17:42:26 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150914 17:42:29 [Note] feedback plugin: server replied 'ok' 150915 17:42:30 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150915 17:42:33 [Note] feedback plugin: server replied 'ok' 150922 17:42:34 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150922 17:42:39 [Note] feedback plugin: server replied 'ok' 2015-09-23 10:39:13 7f309bff7700 InnoDB: FTS Optimize Removing table dev/#sql2-3b6-9a 150924 23:37:20 [Note] /usr/libexec/mysqld: Normal shutdown 150924 23:37:20 [Note] Event Scheduler: Purging the queue. 0 events 150924 23:37:22 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.21-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=25 max_threads=153 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467003 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f308c000998 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 = 0x7f308c12b670 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5596183cae1d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x559617f41d0d] /lib64/libpthread.so.0(+0x30aa810430)[0x7f30ca800430] /usr/libexec/mysqld(_Z17vprint_msg_to_log8loglevelPKcP13__va_list_tag+0x242)[0x559617ff04c2] /usr/libexec/mysqld(_ZN25Log_to_file_event_handler9log_errorE8loglevelPKcP13__va_list_tag+0x11)[0x559617ff0521] /usr/libexec/mysqld(_ZN6LOGGER15error_log_printE8loglevelPKcP13__va_list_tag+0x43)[0x559617fe5c63] /usr/libexec/mysqld(_Z15error_log_print8loglevelPKcP13__va_list_tag+0x18)[0x559617fe83e8] /usr/libexec/mysqld(_Z21sql_print_informationPKcz+0xa5)[0x559617fec015] /usr/libexec/mysqld(+0x97ccec)[0x55961838ecec] /usr/libexec/mysqld(+0x32bc37)[0x559617d3dc37] /usr/libexec/mysqld(+0x97c81f)[0x55961838e81f] /lib64/libpthread.so.0(+0x30aa807555)[0x7f30ca7f7555] /lib64/libc.so.6(clone+0x6d)[0x7f30c8d8fb9d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x5c0447cf2b33adee): Can't read from address 0x5c0447cf2b33adee Connection ID (thread ID): 7959953410951049313 Status: UNKNOWN Optimizer switch: index_merge=off,index_merge_union=off,index_merge_sort_union=off,index_merge_intersection=off,index_merge_sort_intersection=on,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=off,derived_with_keys=off,firstmatch=off,loosescan=off,materialization=off,in_to_exists=on,semijoin=off,partial_match_rowid_merge=off,partial_match_table_scan=off,subquery_cache=off,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=off,semijoin_with_cache=off,join_cache_incremental=off,join_cache_hashed=off,join_cache_bka=off,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=off 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. 150924 23:37:22 mysqld_safe Number of processes running now: 0 150924 23:37:22 mysqld_safe mysqld restarted 150924 23:37:23 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 13286 ... 150924 23:37:23 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150924 23:37:23 [Note] InnoDB: The InnoDB memory heap is disabled 150924 23:37:23 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150924 23:37:23 [Note] InnoDB: Memory barrier is not used 150924 23:37:23 [Note] InnoDB: Compressed tables use zlib 1.2.8 150924 23:37:23 [Note] InnoDB: Using Linux native AIO 150924 23:37:23 [Note] InnoDB: Using CPU crc32 instructions 150924 23:37:23 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150924 23:37:23 [Note] InnoDB: Completed initialization of buffer pool 150924 23:37:23 [Note] InnoDB: Highest supported file format is Barracuda. 150924 23:37:23 [Note] InnoDB: Log scan progressed past the checkpoint lsn 60903573486 150924 23:37:23 [Note] InnoDB: Database was not shutdown normally! 150924 23:37:23 [Note] InnoDB: Starting crash recovery. 150924 23:37:23 [Note] InnoDB: Reading tablespace information from the .ibd files... 150924 23:37:32 [Note] InnoDB: Restoring possible half-written data pages 150924 23:37:32 [Note] InnoDB: from the doublewrite buffer... InnoDB: Doing recovery: scanned up to log sequence number 60903576683 150924 23:37:33 [Note] InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 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 150924 23:37:34 [Note] InnoDB: 128 rollback segment(s) are active. 150924 23:37:34 [Note] InnoDB: Waiting for purge to start 150924 23:37:34 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 60903576683 150924 23:37:34 [Note] Recovering after a crash using tc.log 150924 23:37:34 [Note] Starting crash recovery... 150924 23:37:34 [Note] Crash recovery finished. 150924 23:37:35 [Note] Server socket created on IP: '::'. 150924 23:37:35 [Note] Event Scheduler: Loaded 0 events 150924 23:37:35 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150924 18:43:18 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150924 23:43:21 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 1120 ... 150924 23:43:22 [Note] InnoDB: Using mutexes to ref count buffer pool pages 150924 23:43:22 [Note] InnoDB: The InnoDB memory heap is disabled 150924 23:43:22 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 150924 23:43:22 [Note] InnoDB: Memory barrier is not used 150924 23:43:22 [Note] InnoDB: Compressed tables use zlib 1.2.8 150924 23:43:22 [Note] InnoDB: Using Linux native AIO 150924 23:43:22 [Note] InnoDB: Using CPU crc32 instructions 150924 23:43:22 [Note] InnoDB: Initializing buffer pool, size = 128.0M 150924 23:43:22 [Note] InnoDB: Completed initialization of buffer pool 150924 23:43:23 [Note] InnoDB: Highest supported file format is Barracuda. 150924 23:43:23 [Note] InnoDB: The log sequence numbers 60596104528 and 60596104528 in ibdata files do not match the log sequence number 60903577008 in the ib_logfiles! 150924 23:43:23 [Note] InnoDB: Database was not shutdown normally! 150924 23:43:23 [Note] InnoDB: Starting crash recovery. 150924 23:43:23 [Note] InnoDB: Reading tablespace information from the .ibd files... 150924 23:43:24 [Note] InnoDB: Restoring possible half-written data pages 150924 23:43:24 [Note] InnoDB: from the doublewrite buffer... 150924 23:43:25 [Note] InnoDB: 128 rollback segment(s) are active. 150924 23:43:25 [Note] InnoDB: Waiting for purge to start 150924 23:43:25 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 60903577008 150924 23:43:25 [Note] Recovering after a crash using tc.log 150924 23:43:25 [Note] Starting crash recovery... 150924 23:43:25 [Note] Crash recovery finished. 150924 23:43:25 [Note] Server socket created on IP: '::'. 150924 23:43:25 [Note] Event Scheduler: Loaded 0 events 150924 23:43:25 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 150924 23:48:25 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150924 23:48:26 [Note] feedback plugin: server replied 'ok' 150925 23:48:27 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 150925 23:48:30 [Note] feedback plugin: server replied 'ok' 2015-09-28 03:24:55 7fa515ffb700 InnoDB: FTS Optimize Removing table itpark/#sql2-460-4c 2015-09-28 03:25:14 7fa515ffb700 InnoDB: FTS Optimize Removing table itpark/#sql2-460-4c 2015-09-29 02:28:14 7fa515ffb700 InnoDB: FTS Optimize Removing table itpark/#sql2-460-6d 2015-09-29 02:57:35 7fa515ffb700 InnoDB: FTS Optimize Removing table itpark/#sql2-460-6f 2015-09-29 03:10:26 7fa515ffb700 InnoDB: FTS Optimize Removing table itpark/#sql2-460-73 2015-09-29 03:29:45 7fa515ffb700 InnoDB: FTS Optimize Removing table itpark/#sql2-460-75 2015-09-29 04:03:58 7fa515ffb700 InnoDB: FTS Optimize Removing table itpark/#sql2-460-77 151002 23:48:31 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 151002 23:48:33 [Note] feedback plugin: server replied 'ok' 2015-10-06 19:28:21 7fa515ffb700 InnoDB: FTS Optimize Removing table itpark/#sql2-460-222 151009 23:48:34 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 151009 23:48:37 [Note] feedback plugin: server replied 'ok' 2015-10-12 04:03:40 7fa515ffb700 InnoDB: FTS Optimize Removing table itpark/#sql2-460-287 2015-10-12 04:31:14 7fa515ffb700 InnoDB: FTS Optimize Removing table itpark/#sql2-460-289 151016 23:48:38 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 151016 23:48:43 [Note] feedback plugin: server replied 'ok' 151019 1:19:40 [Note] /usr/libexec/mysqld: Normal shutdown 151019 1:19:41 [Note] Event Scheduler: Purging the queue. 0 events 151019 1:19:42 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 151019 1:19:42 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.21-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=32 max_threads=153 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467003 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7fa508000998 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 = 0x8cb541824d13cc19 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x55f9bbf03e1d] /usr/libexec/mysqld(handle_fatal_signal+0x33d)[0x55f9bba7ad0d] /lib64/libpthread.so.0(+0x30aa810430)[0x7fa54473f430] /usr/libexec/mysqld(thd_wait_begin+0x19)[0x55f9bb8ef859] /usr/libexec/mysqld(vio_io_wait+0x14a)[0x55f9bbf458ea] /usr/libexec/mysqld(vio_socket_io_wait+0x18)[0x55f9bbf459a8] /usr/libexec/mysqld(vio_ssl_read+0x9d)[0x55f9bbf465ed] /usr/libexec/mysqld(+0x97cd05)[0x55f9bbec7d05] /usr/libexec/mysqld(+0x32bc37)[0x55f9bb876c37] /usr/libexec/mysqld(+0x97c81f)[0x55f9bbec781f] /lib64/libpthread.so.0(+0x30aa807555)[0x7fa544736555] /lib64/libc.so.6(clone+0x6d)[0x7fa542cceb9d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0xb0455030618301a): Can't read from address 0xb0455030618301a Connection ID (thread ID): 1 Status: UNKNOWN Optimizer switch: index_merge=off,index_merge_union=off,index_merge_sort_union=off,index_merge_intersection=off,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=off,derived_merge=off,derived_with_keys=off,firstmatch=off,loosescan=off,materialization=off,in_to_exists=off,semijoin=off,partial_match_rowid_merge=off,partial_match_table_scan=off,subquery_cache=off,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=off,semijoin_with_cache=off,join_cache_incremental=off,join_cache_hashed=off,join_cache_bka=off,optimize_join_buffer_size=off,table_elimination=off,extended_keys=off,exists_to_in=off 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. 151019 01:19:42 mysqld_safe Number of processes running now: 0 151019 01:19:42 mysqld_safe mysqld restarted 151019 1:19:43 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 19490 ... 151019 1:19:43 [Note] InnoDB: Using mutexes to ref count buffer pool pages 151019 1:19:43 [Note] InnoDB: The InnoDB memory heap is disabled 151019 1:19:43 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 151019 1:19:43 [Note] InnoDB: Memory barrier is not used 151019 1:19:43 [Note] InnoDB: Compressed tables use zlib 1.2.8 151019 1:19:43 [Note] InnoDB: Using Linux native AIO 151019 1:19:43 [Note] InnoDB: Using CPU crc32 instructions 151019 1:19:43 [Note] InnoDB: Initializing buffer pool, size = 128.0M 151019 1:19:43 [Note] InnoDB: Completed initialization of buffer pool 151019 1:19:43 [Note] InnoDB: Highest supported file format is Barracuda. 151019 1:19:43 [Note] InnoDB: The log sequence numbers 60596104528 and 60596104528 in ibdata files do not match the log sequence number 71219404089 in the ib_logfiles! 151019 1:19:43 [Note] InnoDB: Database was not shutdown normally! 151019 1:19:43 [Note] InnoDB: Starting crash recovery. 151019 1:19:43 [Note] InnoDB: Reading tablespace information from the .ibd files... 151019 1:19:52 [Note] InnoDB: Restoring possible half-written data pages 151019 1:19:52 [Note] InnoDB: from the doublewrite buffer... 151019 1:19:54 [Note] InnoDB: 128 rollback segment(s) are active. 151019 1:19:54 [Note] InnoDB: Waiting for purge to start 151019 1:19:54 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 71219404089 151019 1:19:54 [Note] Recovering after a crash using tc.log 151019 1:19:54 [Note] Starting crash recovery... 151019 1:19:54 [Note] Crash recovery finished. 151019 1:19:54 [Note] Server socket created on IP: '::'. 151019 1:19:55 [Note] Event Scheduler: Loaded 0 events 151019 1:19:55 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 151018 20:25:40 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 151018 20:25:42 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 1157 ... 151019 1:25:44 [Note] InnoDB: Using mutexes to ref count buffer pool pages 151019 1:25:44 [Note] InnoDB: The InnoDB memory heap is disabled 151019 1:25:44 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 151019 1:25:44 [Note] InnoDB: Memory barrier is not used 151019 1:25:44 [Note] InnoDB: Compressed tables use zlib 1.2.8 151019 1:25:44 [Note] InnoDB: Using Linux native AIO 151019 1:25:45 [Note] InnoDB: Using CPU crc32 instructions 151019 1:25:45 [Note] InnoDB: Initializing buffer pool, size = 128.0M 151019 1:25:45 [Note] InnoDB: Completed initialization of buffer pool 151019 1:25:45 [Note] InnoDB: Highest supported file format is Barracuda. 151019 1:25:45 [Note] InnoDB: The log sequence numbers 60596104528 and 60596104528 in ibdata files do not match the log sequence number 71219407890 in the ib_logfiles! 151019 1:25:45 [Note] InnoDB: Database was not shutdown normally! 151019 1:25:45 [Note] InnoDB: Starting crash recovery. 151019 1:25:45 [Note] InnoDB: Reading tablespace information from the .ibd files... 151019 1:25:47 [Note] InnoDB: Restoring possible half-written data pages 151019 1:25:47 [Note] InnoDB: from the doublewrite buffer... 151019 1:25:48 [Note] InnoDB: 128 rollback segment(s) are active. 151019 1:25:48 [Note] InnoDB: Waiting for purge to start 151019 1:25:48 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 71219407890 151019 1:25:48 [Note] Recovering after a crash using tc.log 151019 1:25:49 [Note] Starting crash recovery... 151019 1:25:49 [Note] Crash recovery finished. 151019 1:25:49 [Note] Server socket created on IP: '::'. 151019 1:25:49 [Note] Event Scheduler: Loaded 0 events 151019 1:25:49 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 151019 1:30:49 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 151019 1:30:50 [Note] feedback plugin: server replied 'ok' 2015-10-19 02:28:44 7fda957fa700 InnoDB: FTS Optimize Removing table itpark/#sql2-485-f 2015-10-19 02:47:01 7fda957fa700 InnoDB: FTS Optimize Removing table itpark/#sql2-485-18 151020 1:30:51 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 151020 1:30:59 [Note] feedback plugin: server replied 'ok' 151020 23:33:01 [Note] /usr/libexec/mysqld: Normal shutdown 151020 23:33:02 [Note] Event Scheduler: Purging the queue. 0 events 151020 23:33:03 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 151020 23:33:04 [Note] feedback plugin: server replied 'ok' 151020 23:33:04 [Note] InnoDB: FTS optimize thread exiting. 151020 23:33:04 [Note] InnoDB: Starting shutdown... 151020 23:33:05 [Note] InnoDB: Shutdown completed; log sequence number 71556955897 151020 23:33:05 [Note] /usr/libexec/mysqld: Shutdown complete 151020 23:33:05 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended 151020 18:34:10 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 151020 23:34:14 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 1171 ... 151020 23:34:17 [Note] InnoDB: Using mutexes to ref count buffer pool pages 151020 23:34:17 [Note] InnoDB: The InnoDB memory heap is disabled 151020 23:34:17 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 151020 23:34:17 [Note] InnoDB: Memory barrier is not used 151020 23:34:17 [Note] InnoDB: Compressed tables use zlib 1.2.8 151020 23:34:17 [Note] InnoDB: Using Linux native AIO 151020 23:34:18 [Note] InnoDB: Using CPU crc32 instructions 151020 23:34:18 [Note] InnoDB: Initializing buffer pool, size = 128.0M 151020 23:34:18 [Note] InnoDB: Completed initialization of buffer pool 151020 23:34:18 [Note] InnoDB: Highest supported file format is Barracuda. 151020 23:34:22 [Note] InnoDB: 128 rollback segment(s) are active. 151020 23:34:22 [Note] InnoDB: Waiting for purge to start 151020 23:34:22 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 71556955897 151020 23:34:22 [Note] Server socket created on IP: '::'. 151020 23:34:24 [Note] Event Scheduler: Loaded 0 events 151020 23:34:24 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 151020 23:39:23 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 151020 23:39:23 [Note] feedback plugin: server replied 'ok' 2015-10-21 00:12:02 7ff28b7fe700 InnoDB: FTS Optimize Removing table dev/#sql2-493-a 151021 23:39:24 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 151021 23:39:27 [Note] feedback plugin: server replied 'ok' 2015-10-22 22:45:45 7ff28b7fe700 InnoDB: FTS Optimize Removing table itpark/#sql2-493-87 2015-10-22 22:46:03 7ff28b7fe700 InnoDB: FTS Optimize Removing table itpark/#sql2-493-87 151028 23:39:28 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 151028 23:39:33 [Note] feedback plugin: server replied 'ok' 151030 3:06:38 [Note] /usr/libexec/mysqld: Normal shutdown 151030 3:06:38 [Note] Event Scheduler: Purging the queue. 0 events 151030 3:06:39 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 151030 3:06:39 [ERROR] 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. To report this bug, see http://kb.askmonty.org/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.0.21-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=28 max_threads=153 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467003 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7ff294110b88 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... 151030 03:06:56 mysqld_safe Number of processes running now: 0 151030 03:06:56 mysqld_safe mysqld restarted 151030 3:06:57 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 28273 ... 151030 3:06:57 [Note] InnoDB: Using mutexes to ref count buffer pool pages 151030 3:06:57 [Note] InnoDB: The InnoDB memory heap is disabled 151030 3:06:57 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 151030 3:06:57 [Note] InnoDB: Memory barrier is not used 151030 3:06:57 [Note] InnoDB: Compressed tables use zlib 1.2.8 151030 3:06:57 [Note] InnoDB: Using Linux native AIO 151030 3:06:57 [Note] InnoDB: Using CPU crc32 instructions 151030 3:06:57 [Note] InnoDB: Initializing buffer pool, size = 128.0M 151030 3:06:57 [Note] InnoDB: Completed initialization of buffer pool 151030 3:06:57 [Note] InnoDB: Highest supported file format is Barracuda. 151030 3:06:57 [Note] InnoDB: The log sequence numbers 71556955897 and 71556955897 in ibdata files do not match the log sequence number 71612029688 in the ib_logfiles! 151030 3:06:57 [Note] InnoDB: Database was not shutdown normally! 151030 3:06:57 [Note] InnoDB: Starting crash recovery. 151030 3:06:57 [Note] InnoDB: Reading tablespace information from the .ibd files... 151030 3:07:11 [Note] InnoDB: Restoring possible half-written data pages 151030 3:07:11 [Note] InnoDB: from the doublewrite buffer... 151030 3:07:13 [Note] InnoDB: 128 rollback segment(s) are active. 151030 3:07:13 [Note] InnoDB: Waiting for purge to start 151030 3:07:13 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 71612029688 151030 3:07:13 [Note] Recovering after a crash using tc.log 151030 3:07:13 [Note] Starting crash recovery... 151030 3:07:13 [Note] Crash recovery finished. 151030 3:07:13 [Note] Server socket created on IP: '::'. 151030 3:07:13 [Note] Event Scheduler: Loaded 0 events 151030 3:07:13 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 151030 03:36:29 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 151030 3:36:29 [Note] /usr/libexec/mysqld (mysqld 10.0.21-MariaDB) starting as process 29840 ... 151030 3:36:29 [Note] InnoDB: Using mutexes to ref count buffer pool pages 151030 3:36:29 [Note] InnoDB: The InnoDB memory heap is disabled 151030 3:36:29 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 151030 3:36:29 [Note] InnoDB: Memory barrier is not used 151030 3:36:29 [Note] InnoDB: Compressed tables use zlib 1.2.8 151030 3:36:29 [Note] InnoDB: Using Linux native AIO 151030 3:36:29 [Note] InnoDB: Using CPU crc32 instructions 151030 3:36:29 [Note] InnoDB: Initializing buffer pool, size = 128.0M 151030 3:36:29 [Note] InnoDB: Completed initialization of buffer pool 151030 3:36:30 [Note] InnoDB: Highest supported file format is Barracuda. 151030 3:36:30 [Note] InnoDB: 128 rollback segment(s) are active. 151030 3:36:30 [Note] InnoDB: Waiting for purge to start 151030 3:36:30 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.25-73.1 started; log sequence number 71612033773 151030 3:36:30 [Note] Recovering after a crash using tc.log 151030 3:36:30 [Note] Starting crash recovery... 151030 3:36:30 [Note] Crash recovery finished. 151030 3:36:30 [Note] Server socket created on IP: '::'. 151030 3:36:30 [Note] Event Scheduler: Loaded 0 events 151030 3:36:30 [Note] /usr/libexec/mysqld: ready for connections. Version: '10.0.21-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 151030 3:41:31 [Note] feedback plugin: report to 'https://mariadb.org/feedback_plugin/post' was sent 151030 3:41:34 [Note] feedback plugin: server replied 'ok'