2016-03-02 15:57:18 140195577857984 [Note] Using unique option prefix 'myisam-recover' is error-prone and can break in the future. Please use the full name 'myisam-recover-options' instead. 2016-03-02 15:57:18 140195577857984 [Note] InnoDB: Using mutexes to ref count buffer pool pages 2016-03-02 15:57:18 140195577857984 [Note] InnoDB: The InnoDB memory heap is disabled 2016-03-02 15:57:18 140195577857984 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2016-03-02 15:57:18 140195577857984 [Note] InnoDB: Memory barrier is not used 2016-03-02 15:57:18 140195577857984 [Note] InnoDB: Compressed tables use zlib 1.2.8 2016-03-02 15:57:18 140195577857984 [Note] InnoDB: Using Linux native AIO 2016-03-02 15:57:18 140195577857984 [Note] InnoDB: Using SSE crc32 instructions 2016-03-02 15:57:18 140195577857984 [Note] InnoDB: Initializing buffer pool, size = 50.0G 2016-03-02 15:57:20 140195577857984 [Note] InnoDB: Completed initialization of buffer pool 2016-03-02 15:57:20 140195577857984 [Note] InnoDB: Highest supported file format is Barracuda. 2016-03-02 15:57:20 140195577857984 [Note] InnoDB: Log scan progressed past the checkpoint lsn 59544430000469 2016-03-02 15:57:20 140195577857984 [Note] InnoDB: Database was not shutdown normally! 2016-03-02 15:57:20 140195577857984 [Note] InnoDB: Starting crash recovery. 2016-03-02 15:57:20 140195577857984 [Note] InnoDB: Reading tablespace information from the .ibd files... 2016-03-02 15:57:21 140195577857984 [Note] InnoDB: Restoring possible half-written data pages 2016-03-02 15:57:21 140195577857984 [Note] InnoDB: from the doublewrite buffer... InnoDB: Doing recovery: scanned up to log sequence number 59544435243008 InnoDB: Doing recovery: scanned up to log sequence number 59544440485888 InnoDB: Doing recovery: scanned up to log sequence number 59544445728768 InnoDB: Doing recovery: scanned up to log sequence number 59544450971648 InnoDB: Doing recovery: scanned up to log sequence number 59544456214528 InnoDB: Doing recovery: scanned up to log sequence number 59544461457408 InnoDB: Doing recovery: scanned up to log sequence number 59544466700288 InnoDB: Doing recovery: scanned up to log sequence number 59544471943168 InnoDB: Doing recovery: scanned up to log sequence number 59544477186048 InnoDB: Doing recovery: scanned up to log sequence number 59544482428928 InnoDB: Doing recovery: scanned up to log sequence number 59544487671808 InnoDB: Doing recovery: scanned up to log sequence number 59544492914688 InnoDB: Doing recovery: scanned up to log sequence number 59544498157568 InnoDB: Doing recovery: scanned up to log sequence number 59544503400448 InnoDB: Doing recovery: scanned up to log sequence number 59544508643328 InnoDB: Doing recovery: scanned up to log sequence number 59544513886208 InnoDB: Doing recovery: scanned up to log sequence number 59544519129088 InnoDB: Doing recovery: scanned up to log sequence number 59544524371968 InnoDB: Doing recovery: scanned up to log sequence number 59544529614848 InnoDB: Doing recovery: scanned up to log sequence number 59544534857728 InnoDB: Doing recovery: scanned up to log sequence number 59544540100608 InnoDB: Doing recovery: scanned up to log sequence number 59544545343488 InnoDB: Doing recovery: scanned up to log sequence number 59544550586368 InnoDB: Doing recovery: scanned up to log sequence number 59544555829248 InnoDB: Doing recovery: scanned up to log sequence number 59544561072128 InnoDB: Doing recovery: scanned up to log sequence number 59544566315008 InnoDB: Doing recovery: scanned up to log sequence number 59544571557888 InnoDB: Doing recovery: scanned up to log sequence number 59544576800768 InnoDB: Doing recovery: scanned up to log sequence number 59544582043648 InnoDB: Doing recovery: scanned up to log sequence number 59544587286528 InnoDB: Doing recovery: scanned up to log sequence number 59544592529408 InnoDB: Doing recovery: scanned up to log sequence number 59544597772288 InnoDB: Doing recovery: scanned up to log sequence number 59544603015168 InnoDB: Doing recovery: scanned up to log sequence number 59544608258048 InnoDB: Doing recovery: scanned up to log sequence number 59544613500928 InnoDB: Doing recovery: scanned up to log sequence number 59544618743808 InnoDB: Doing recovery: scanned up to log sequence number 59544623986688 InnoDB: Doing recovery: scanned up to log sequence number 59544629229568 InnoDB: Doing recovery: scanned up to log sequence number 59544634472448 InnoDB: Doing recovery: scanned up to log sequence number 59544639715328 InnoDB: Doing recovery: scanned up to log sequence number 59544644958208 InnoDB: Doing recovery: scanned up to log sequence number 59544650201088 InnoDB: Doing recovery: scanned up to log sequence number 59544655443968 InnoDB: Doing recovery: scanned up to log sequence number 59544660686848 InnoDB: Doing recovery: scanned up to log sequence number 59544665929728 InnoDB: Doing recovery: scanned up to log sequence number 59544671172608 InnoDB: Doing recovery: scanned up to log sequence number 59544676415488 InnoDB: Doing recovery: scanned up to log sequence number 59544681658368 InnoDB: Doing recovery: scanned up to log sequence number 59544686901248 InnoDB: Doing recovery: scanned up to log sequence number 59544692144128 InnoDB: Doing recovery: scanned up to log sequence number 59544697387008 InnoDB: Doing recovery: scanned up to log sequence number 59544702629888 InnoDB: Doing recovery: scanned up to log sequence number 59544707872768 InnoDB: Doing recovery: scanned up to log sequence number 59544713115648 InnoDB: Doing recovery: scanned up to log sequence number 59544718358528 InnoDB: Doing recovery: scanned up to log sequence number 59544723601408 InnoDB: Doing recovery: scanned up to log sequence number 59544728844288 InnoDB: Doing recovery: scanned up to log sequence number 59544734087168 InnoDB: Doing recovery: scanned up to log sequence number 59544739330048 InnoDB: Doing recovery: scanned up to log sequence number 59544741029020 InnoDB: 2 transaction(s) which must be rolled back or cleaned up InnoDB: in total 3202269 row operations to undo InnoDB: Trx id counter is 29297500928 2016-03-02 15:57:34 140195577857984 [Note] InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: In a MySQL replication slave the last master binlog file InnoDB: position 0 3705580, file name mysql-bin.038679 InnoDB: Last MySQL binlog file position 0 769286263, file name /data/bigmomma/mysql/log/mysql-bin.056767 2016-03-02 15:57:43 140195577857984 [ERROR] InnoDB: Table ./VoorafgaandComputerboek_Klanten in the InnoDB data dictionary has tablespace id 1239896, but tablespace with that id or name does not exist. Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automatically removed, but the table still exists in the InnoDB internal data dictionary. InnoDB: Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html InnoDB: for how to resolve the issue. 2016-03-02 15:57:43 140195577857984 [ERROR] InnoDB: Table ./VoorafgaandJuridischboek_Klanten in the InnoDB data dictionary has tablespace id 1239897, but tablespace with that id or name does not exist. Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automatically removed, but the table still exists in the InnoDB internal data dictionary. InnoDB: Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html InnoDB: for how to resolve the issue. 2016-03-02 15:57:43 140195577857984 [ERROR] InnoDB: Table ./VoorafgaandManagementboek_Klanten in the InnoDB data dictionary has tablespace id 1239537, but tablespace with that id or name does not exist. Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automatically removed, but the table still exists in the InnoDB internal data dictionary. InnoDB: Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html InnoDB: for how to resolve the issue. 2016-03-02 15:57:43 140195577857984 [Note] InnoDB: 128 rollback segment(s) are active. InnoDB: Starting in background the rollback of uncommitted transactions 2016-03-02 15:57:43 7f7410bff700 InnoDB: Rolling back trx with id 29297500661, 1 rows to undo 2016-03-02 15:57:43 140195577857984 [Note] InnoDB: Waiting for purge to start 2016-03-02 15:57:43 140136473949952 [Note] InnoDB: Rollback of trx with id 29297500661 completed 2016-03-02 15:57:43 7f7410bff700 InnoDB: Rolling back trx with id 29297327221, 3202268 rows to undo InnoDB: Progress in percents: 12016-03-02 15:57:43 140195577857984 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.28-76.1 started; log sequence number 59544741029020 2016-03-02 15:57:45 140136163542784 [Note] InnoDB: Dumping buffer pool(s) not yet started 2016-03-02 15:57:45 140195577857984 [Note] Plugin 'FEEDBACK' is disabled. 2016-03-02 15:57:45 140195577857984 [Note] Recovering after a crash using /data/bigmomma/mysql/log/mysql-bin 2016-03-02 15:57:47 140195577857984 [Note] Starting crash recovery... 2016-03-02 15:57:47 140195577857984 [Note] Crash recovery finished. 2016-03-02 15:57:47 140195577857984 [Note] Server socket created on IP: '0.0.0.0'. 2016-03-02 15:57:47 140195577857984 [ERROR] Can't open shared library 'libmysqllevenshtein.so' (errno: 0, /usr/lib/mysql/plugin/libmysqllevenshtein.so: cannot open shared object file: No such file or directory) 2016-03-02 15:57:47 140195577857984 [ERROR] Can't open shared library 'murmur_udf.so' (errno: 0, /usr/lib/mysql/plugin/murmur_udf.so: cannot open shared object file: No such file or directory) 2016-03-02 15:57:47 140195576604416 [Note] Event Scheduler: scheduler thread started with id 2 2016-03-02 15:57:47 140195577857984 [Note] Reading of all Master_info entries succeded 2016-03-02 15:57:47 140195577857984 [Note] Added new Master_info '' to hash table 2016-03-02 15:57:47 140195577857984 [ERROR] Error reading master configuration 2016-03-02 15:57:47 140195577857984 [ERROR] Failed to initialize the master info structure 2016-03-02 15:57:47 140195577857984 [ERROR] Failed to allocate memory for the Master Info structure 2016-03-02 15:57:47 140195577857984 [Note] /usr/sbin/mysqld: ready for connections. Version: '10.1.12-MariaDB-1~trusty' socket: '/var/run/mysqld/mysqld.sock' port: 3306 mariadb.org binary distribution 2 3 4 5 6 7 8 9 102016-03-02 15:58:16 140136072906496 [Note] Start binlog_dump to slave_server(345), pos(mysql-bin.056767, 769290109) 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 422016-03-02 16:00:09 140136126273280 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction 2016-03-02 16:00:09 140136126273280 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction 43 44 45 462016-03-02 16:00:25 140136076605184 [ERROR] Event Scheduler: [sander@%][Managementboek_Klanten.run_vieruur] Incorrect argument type to variable 'group_concat_max_len' 2016-03-02 16:00:25 140136076605184 [Note] Event Scheduler: [sander@%].[Managementboek_Klanten.run_vieruur] event execution failed. 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 1002016-03-02 16:03:30 140136473949952 [Note] InnoDB: Rollback of trx with id 29297327221 completed 2016-03-02 16:03:30 7f7410bff700 InnoDB: Rollback of non-prepared transactions completed 2016-03-02 16:05:01 140136126273280 [Warning] Aborted connection 726 to db: 'unconnected' user: 'site' host: 'kantoor' (Unknown error) 2016-03-02 16:05:01 140136463349504 [Warning] Aborted connection 756 to db: 'unconnected' user: 'site' host: 'kantoor' (Unknown error) 2016-03-02 16:05:01 140137335285504 [Warning] Aborted connection 2029 to db: 'unconnected' user: 'site' host: 'kantoor' (Unknown error) 2016-03-02 16:05:01 140136129971968 [Warning] Aborted connection 1638 to db: 'unconnected' user: 'site' host: 'kantoor' (Unknown error) 2016-03-02 16:13:59 140136114120448 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction 2016-03-02 16:13:59 140136114120448 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction 2016-03-02 16:17:56 140135504967424 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction 2016-03-02 16:17:56 140135504967424 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction 160302 16:21: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.1.12-MariaDB-1~trusty key_buffer_size=16777216 read_buffer_size=131072 max_used_connections=199 max_threads=502 thread_count=62 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1118998 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f73e0a2f008 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 = 0x7f73f9d26df0 thread_stack 0x80000 /usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x7f81d332d05e] /usr/sbin/mysqld(handle_fatal_signal+0x38d)[0x7f81d2e5a1bd] /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7f81d13b0340] /usr/sbin/mysqld(+0x75241d)[0x7f81d2ffc41d] /usr/sbin/mysqld(+0x75f69d)[0x7f81d300969d] /usr/sbin/mysqld(+0x374476)[0x7f81d2c1e476] /usr/sbin/mysqld(_ZN4JOIN14optimize_innerEv+0x818)[0x7f81d2d2c9e8] /usr/sbin/mysqld(_ZN4JOIN8optimizeEv+0x1b)[0x7f81d2d2f1bb] /usr/sbin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x8f)[0x7f81d2d2f30f] /usr/sbin/mysqld(_Z18mysql_multi_updateP3THDP10TABLE_LISTP4ListI4ItemES6_PS4_y15enum_duplicatesbP18st_select_lex_unitP13st_select_lexPP12multi_update+0x122)[0x7f81d2d76fc2] /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x6bc6)[0x7f81d2cdf236] /usr/sbin/mysqld(_ZN13sp_instr_stmt9exec_coreEP3THDPj+0x15)[0x7f81d2f667c5] /usr/sbin/mysqld(_ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr+0x83)[0x7f81d2f6d373] /usr/sbin/mysqld(_ZN13sp_instr_stmt7executeEP3THDPj+0x204)[0x7f81d2f6d924] /usr/sbin/mysqld(_ZN7sp_head7executeEP3THDb+0x786)[0x7f81d2f697f6] /usr/sbin/mysqld(_ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE+0x617)[0x7f81d2f6aea7] /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x6889)[0x7f81d2cdeef9] /usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x26d)[0x7f81d2ce1fed] /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x2460)[0x7f81d2ce5330] /usr/sbin/mysqld(_Z10do_commandP3THD+0x169)[0x7f81d2ce5ae9] /usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x18a)[0x7f81d2da90fa] /usr/sbin/mysqld(handle_one_connection+0x40)[0x7f81d2da92d0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7f81d13a8182] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f81d0acb47d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f74276e1260): is an invalid pointer Connection ID (thread ID): 20526 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. 2016-03-02 16:21:50 139625406162880 [Note] Using unique option prefix 'myisam-recover' is error-prone and can break in the future. Please use the full name 'myisam-recover-options' instead. 2016-03-02 16:21:50 139625406162880 [Note] InnoDB: Using mutexes to ref count buffer pool pages 2016-03-02 16:21:50 139625406162880 [Note] InnoDB: The InnoDB memory heap is disabled 2016-03-02 16:21:50 139625406162880 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2016-03-02 16:21:50 139625406162880 [Note] InnoDB: Memory barrier is not used 2016-03-02 16:21:50 139625406162880 [Note] InnoDB: Compressed tables use zlib 1.2.8 2016-03-02 16:21:50 139625406162880 [Note] InnoDB: Using Linux native AIO 2016-03-02 16:21:50 139625406162880 [Note] InnoDB: Using SSE crc32 instructions 2016-03-02 16:21:50 139625406162880 [Note] InnoDB: Initializing buffer pool, size = 50.0G 2016-03-02 16:21:52 139625406162880 [Note] InnoDB: Completed initialization of buffer pool 2016-03-02 16:21:52 139625406162880 [Note] InnoDB: Highest supported file format is Barracuda. 2016-03-02 16:21:52 139625406162880 [Note] InnoDB: Log scan progressed past the checkpoint lsn 59548822872940 2016-03-02 16:21:52 139625406162880 [Note] InnoDB: Database was not shutdown normally! 2016-03-02 16:21:52 139625406162880 [Note] InnoDB: Starting crash recovery. 2016-03-02 16:21:52 139625406162880 [Note] InnoDB: Reading tablespace information from the .ibd files... 2016-03-02 16:21:52 139625406162880 [Note] InnoDB: Restoring possible half-written data pages 2016-03-02 16:21:52 139625406162880 [Note] InnoDB: from the doublewrite buffer... InnoDB: Doing recovery: scanned up to log sequence number 59548828115456 InnoDB: Doing recovery: scanned up to log sequence number 59548833358336 InnoDB: Doing recovery: scanned up to log sequence number 59548838601216 InnoDB: Doing recovery: scanned up to log sequence number 59548843844096 InnoDB: Doing recovery: scanned up to log sequence number 59548849086976 InnoDB: Doing recovery: scanned up to log sequence number 59548854329856 InnoDB: Doing recovery: scanned up to log sequence number 59548859572736 InnoDB: Doing recovery: scanned up to log sequence number 59548864815616 InnoDB: Doing recovery: scanned up to log sequence number 59548870058496 InnoDB: Doing recovery: scanned up to log sequence number 59548875301376 InnoDB: Doing recovery: scanned up to log sequence number 59548880544256 InnoDB: Doing recovery: scanned up to log sequence number 59548885787136 InnoDB: Doing recovery: scanned up to log sequence number 59548891030016 InnoDB: Doing recovery: scanned up to log sequence number 59548896272896 InnoDB: Doing recovery: scanned up to log sequence number 59548901515776 InnoDB: Doing recovery: scanned up to log sequence number 59548906758656 InnoDB: Doing recovery: scanned up to log sequence number 59548912001536 InnoDB: Doing recovery: scanned up to log sequence number 59548917244416 InnoDB: Doing recovery: scanned up to log sequence number 59548922487296 InnoDB: Doing recovery: scanned up to log sequence number 59548927730176 InnoDB: Doing recovery: scanned up to log sequence number 59548932973056 InnoDB: Doing recovery: scanned up to log sequence number 59548938215936 InnoDB: Doing recovery: scanned up to log sequence number 59548943458816 InnoDB: Doing recovery: scanned up to log sequence number 59548948701696 InnoDB: Doing recovery: scanned up to log sequence number 59548953944576 InnoDB: Doing recovery: scanned up to log sequence number 59548959187456 InnoDB: Doing recovery: scanned up to log sequence number 59548964430336 InnoDB: Doing recovery: scanned up to log sequence number 59548969673216 InnoDB: Doing recovery: scanned up to log sequence number 59548974916096 InnoDB: Doing recovery: scanned up to log sequence number 59548980158976 InnoDB: Doing recovery: scanned up to log sequence number 59548985401856 InnoDB: Doing recovery: scanned up to log sequence number 59548990644736 InnoDB: Doing recovery: scanned up to log sequence number 59548995887616 InnoDB: Doing recovery: scanned up to log sequence number 59549001130496 InnoDB: Doing recovery: scanned up to log sequence number 59549006373376 InnoDB: Doing recovery: scanned up to log sequence number 59549011616256 InnoDB: Doing recovery: scanned up to log sequence number 59549016859136 InnoDB: Doing recovery: scanned up to log sequence number 59549022102016 InnoDB: Doing recovery: scanned up to log sequence number 59549027344896 InnoDB: Doing recovery: scanned up to log sequence number 59549032587776 InnoDB: Doing recovery: scanned up to log sequence number 59549037830656 InnoDB: Doing recovery: scanned up to log sequence number 59549043073536 InnoDB: Doing recovery: scanned up to log sequence number 59549048316416 InnoDB: Doing recovery: scanned up to log sequence number 59549053559296 InnoDB: Doing recovery: scanned up to log sequence number 59549058802176 InnoDB: Doing recovery: scanned up to log sequence number 59549064045056 InnoDB: Doing recovery: scanned up to log sequence number 59549069287936 InnoDB: Doing recovery: scanned up to log sequence number 59549074530816 InnoDB: Doing recovery: scanned up to log sequence number 59549079773696 InnoDB: Doing recovery: scanned up to log sequence number 59549085016576 InnoDB: Doing recovery: scanned up to log sequence number 59549090259456 InnoDB: Doing recovery: scanned up to log sequence number 59549095502336 InnoDB: Doing recovery: scanned up to log sequence number 59549100745216 InnoDB: Doing recovery: scanned up to log sequence number 59549105988096 InnoDB: Doing recovery: scanned up to log sequence number 59549111230976 InnoDB: Doing recovery: scanned up to log sequence number 59549116473856 InnoDB: Doing recovery: scanned up to log sequence number 59549121716736 InnoDB: Doing recovery: scanned up to log sequence number 59549126959616 InnoDB: Doing recovery: scanned up to log sequence number 59549132202496 InnoDB: Doing recovery: scanned up to log sequence number 59549135890958 InnoDB: Transaction 29298010167 was in the XA prepared state. InnoDB: Transaction 29298010167 was in the XA prepared state. InnoDB: 3 transaction(s) which must be rolled back or cleaned up InnoDB: in total 2387694 row operations to undo InnoDB: Trx id counter is 29298010624 2016-03-02 16:22:05 139625406162880 [Note] InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: In a MySQL replication slave the last master binlog file InnoDB: position 0 3705580, file name mysql-bin.038679 InnoDB: Last MySQL binlog file position 0 551405498, file name /data/bigmomma/mysql/log/mysql-bin.056768 2016-03-02 16:22:14 139625406162880 [ERROR] InnoDB: Table ./VoorafgaandComputerboek_Klanten in the InnoDB data dictionary has tablespace id 1239896, but tablespace with that id or name does not exist. Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automatically removed, but the table still exists in the InnoDB internal data dictionary. InnoDB: Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html InnoDB: for how to resolve the issue. 2016-03-02 16:22:14 139625406162880 [ERROR] InnoDB: Table ./VoorafgaandJuridischboek_Klanten in the InnoDB data dictionary has tablespace id 1239897, but tablespace with that id or name does not exist. Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automatically removed, but the table still exists in the InnoDB internal data dictionary. InnoDB: Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html InnoDB: for how to resolve the issue. 2016-03-02 16:22:14 139625406162880 [ERROR] InnoDB: Table ./VoorafgaandManagementboek_Klanten in the InnoDB data dictionary has tablespace id 1239537, but tablespace with that id or name does not exist. Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automatically removed, but the table still exists in the InnoDB internal data dictionary. InnoDB: Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html InnoDB: for how to resolve the issue. 2016-03-02 16:22:14 139625406162880 [Note] InnoDB: 128 rollback segment(s) are active. InnoDB: Starting in background the rollback of uncommitted transactions 2016-03-02 16:22:14 7eef4fbff700 InnoDB: Rolling back trx with id 29298006971, 3 rows to undo 2016-03-02 16:22:14 139625406162880 [Note] InnoDB: Waiting for purge to start 2016-03-02 16:22:14 139566300264192 [Note] InnoDB: Rollback of trx with id 29298006971 completed 2016-03-02 16:22:14 7eef4fbff700 InnoDB: Rolling back trx with id 29297737950, 2387691 rows to undo InnoDB: Progress in percents: 12016-03-02 16:22:14 139625406162880 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.28-76.1 started; log sequence number 59549135890958 2016-03-02 16:22:17 139625406162880 [Note] Plugin 'FEEDBACK' is disabled. 2016-03-02 16:22:17 139625406162880 [Note] Recovering after a crash using /data/bigmomma/mysql/log/mysql-bin 2016-03-02 16:22:17 139565989857024 [Note] InnoDB: Dumping buffer pool(s) not yet started 2016-03-02 16:22:18 139625406162880 [Note] Starting crash recovery... 2016-03-02 16:22:18 7efd12bc67c0 InnoDB: Starting recovery for XA transactions... 2016-03-02 16:22:18 7efd12bc67c0 InnoDB: Transaction 29298010167 in prepared state after recovery 2016-03-02 16:22:18 7efd12bc67c0 InnoDB: Transaction contains changes to 9 rows 2016-03-02 16:22:18 7efd12bc67c0 InnoDB: 1 transactions in prepared state after recovery 2016-03-02 16:22:18 139625406162880 [Note] Found 1 prepared transaction(s) in InnoDB 2016-03-02 16:22:18 139625406162880 [Note] Crash recovery finished. 2016-03-02 16:22:18 139625406162880 [Note] Server socket created on IP: '0.0.0.0'. 2016-03-02 16:22:18 139625406162880 [ERROR] Can't open shared library 'libmysqllevenshtein.so' (errno: 0, /usr/lib/mysql/plugin/libmysqllevenshtein.so: cannot open shared object file: No such file or directory) 2016-03-02 16:22:18 139625406162880 [ERROR] Can't open shared library 'murmur_udf.so' (errno: 0, /usr/lib/mysql/plugin/murmur_udf.so: cannot open shared object file: No such file or directory) 2016-03-02 16:22:18 139625406162880 [ERROR] mysqld: Table './mysql/event' is marked as crashed and should be repaired 2016-03-02 16:22:18 139625406162880 [ERROR] mysqld: Table 'event' is marked as crashed and should be repaired 2016-03-02 16:22:18 139625406162880 [Warning] Checking table: './mysql/event' 2016-03-02 16:22:18 139625406162880 [ERROR] mysql.event: 1 client is using or hasn't closed the table properly 2016-03-02 16:22:18 139625404909312 [Note] Event Scheduler: scheduler thread started with id 2 2016-03-02 16:22:18 139625406162880 [Note] Reading of all Master_info entries succeded 2016-03-02 16:22:18 139625406162880 [Note] Added new Master_info '' to hash table 2016-03-02 16:22:18 139625406162880 [ERROR] Error reading master configuration 2016-03-02 16:22:18 139625406162880 [ERROR] Failed to initialize the master info structure 2016-03-02 16:22:18 139625406162880 [ERROR] Failed to allocate memory for the Master Info structure 2016-03-02 16:22:18 139625406162880 [Note] /usr/sbin/mysqld: ready for connections. Version: '10.1.12-MariaDB-1~trusty' socket: '/var/run/mysqld/mysqld.sock' port: 3306 mariadb.org binary distribution 2 3 4 5 6 7 8 9 10 11 12 132016-03-02 16:22:50 139625387042560 [Note] Start binlog_dump to slave_server(345), pos(mysql-bin.056768, 551408679) 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 782016-03-02 16:25:24 139625311483648 [ERROR] mysqld: Deadlock found when trying to get lock; try restarting transaction 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 1002016-03-02 16:26:29 139566300264192 [Note] InnoDB: Rollback of trx with id 29297737950 completed 2016-03-02 16:26:29 7eef4fbff700 InnoDB: Rollback of non-prepared transactions completed 160302 16:26:31 [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.1.12-MariaDB-1~trusty key_buffer_size=16777216 read_buffer_size=131072 max_used_connections=190 max_threads=502 thread_count=48 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1118998 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7eef29cbd008 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 = 0x7eef37b02df0 thread_stack 0x80000 /usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x7efd1251305e] /usr/sbin/mysqld(handle_fatal_signal+0x38d)[0x7efd120401bd] /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7efd10596340] /usr/sbin/mysqld(+0x75241d)[0x7efd121e241d] /usr/sbin/mysqld(+0x75f69d)[0x7efd121ef69d] /usr/sbin/mysqld(+0x374476)[0x7efd11e04476] /usr/sbin/mysqld(_ZN4JOIN14optimize_innerEv+0x818)[0x7efd11f129e8] /usr/sbin/mysqld(_ZN4JOIN8optimizeEv+0x1b)[0x7efd11f151bb] /usr/sbin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x8f)[0x7efd11f1530f] /usr/sbin/mysqld(_Z18mysql_multi_updateP3THDP10TABLE_LISTP4ListI4ItemES6_PS4_y15enum_duplicatesbP18st_select_lex_unitP13st_select_lexPP12multi_update+0x122)[0x7efd11f5cfc2] /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x6bc6)[0x7efd11ec5236] /usr/sbin/mysqld(_ZN13sp_instr_stmt9exec_coreEP3THDPj+0x15)[0x7efd1214c7c5] /usr/sbin/mysqld(_ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr+0x83)[0x7efd12153373] /usr/sbin/mysqld(_ZN13sp_instr_stmt7executeEP3THDPj+0x204)[0x7efd12153924] /usr/sbin/mysqld(_ZN7sp_head7executeEP3THDb+0x786)[0x7efd1214f7f6] /usr/sbin/mysqld(_ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE+0x617)[0x7efd12150ea7] /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x6889)[0x7efd11ec4ef9] /usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x26d)[0x7efd11ec7fed] /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x2460)[0x7efd11ecb330] /usr/sbin/mysqld(_Z10do_commandP3THD+0x169)[0x7efd11ecbae9] /usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x18a)[0x7efd11f8f0fa] /usr/sbin/mysqld(handle_one_connection+0x40)[0x7efd11f8f2d0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7efd1058e182] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7efd0fcb147d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7eef191a2260): is an invalid pointer Connection ID (thread ID): 2085 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. 2016-03-02 16:26:32 140159224838080 [Note] Using unique option prefix 'myisam-recover' is error-prone and can break in the future. Please use the full name 'myisam-recover-options' instead. 2016-03-02 16:26:32 140159224838080 [Note] InnoDB: Using mutexes to ref count buffer pool pages 2016-03-02 16:26:32 140159224838080 [Note] InnoDB: The InnoDB memory heap is disabled 2016-03-02 16:26:32 140159224838080 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2016-03-02 16:26:32 140159224838080 [Note] InnoDB: Memory barrier is not used 2016-03-02 16:26:32 140159224838080 [Note] InnoDB: Compressed tables use zlib 1.2.8 2016-03-02 16:26:32 140159224838080 [Note] InnoDB: Using Linux native AIO 2016-03-02 16:26:32 140159224838080 [Note] InnoDB: Using SSE crc32 instructions 2016-03-02 16:26:32 140159224838080 [Note] InnoDB: Initializing buffer pool, size = 50.0G 2016-03-02 16:26:33 140159224838080 [Note] InnoDB: Completed initialization of buffer pool 2016-03-02 16:26:34 140159224838080 [Note] InnoDB: Highest supported file format is Barracuda. 2016-03-02 16:26:34 140159224838080 [Note] InnoDB: Log scan progressed past the checkpoint lsn 59549662732841 2016-03-02 16:26:34 140159224838080 [Note] InnoDB: Database was not shutdown normally! 2016-03-02 16:26:34 140159224838080 [Note] InnoDB: Starting crash recovery. 2016-03-02 16:26:34 140159224838080 [Note] InnoDB: Reading tablespace information from the .ibd files... 2016-03-02 16:26:34 140159224838080 [Note] InnoDB: Restoring possible half-written data pages 2016-03-02 16:26:34 140159224838080 [Note] InnoDB: from the doublewrite buffer... InnoDB: Doing recovery: scanned up to log sequence number 59549667975680 InnoDB: Doing recovery: scanned up to log sequence number 59549673218560 InnoDB: Doing recovery: scanned up to log sequence number 59549678461440 InnoDB: Doing recovery: scanned up to log sequence number 59549683704320 InnoDB: Doing recovery: scanned up to log sequence number 59549688947200 InnoDB: Doing recovery: scanned up to log sequence number 59549694190080 InnoDB: Doing recovery: scanned up to log sequence number 59549699432960 InnoDB: Doing recovery: scanned up to log sequence number 59549704675840 InnoDB: Doing recovery: scanned up to log sequence number 59549709918720 InnoDB: Doing recovery: scanned up to log sequence number 59549715161600 InnoDB: Doing recovery: scanned up to log sequence number 59549720404480 InnoDB: Doing recovery: scanned up to log sequence number 59549725647360 InnoDB: Doing recovery: scanned up to log sequence number 59549730890240 InnoDB: Doing recovery: scanned up to log sequence number 59549736133120 InnoDB: Doing recovery: scanned up to log sequence number 59549741376000 InnoDB: Doing recovery: scanned up to log sequence number 59549746618880 InnoDB: Doing recovery: scanned up to log sequence number 59549751861760 InnoDB: Doing recovery: scanned up to log sequence number 59549757104640 InnoDB: Doing recovery: scanned up to log sequence number 59549762347520 InnoDB: Doing recovery: scanned up to log sequence number 59549767590400 InnoDB: Doing recovery: scanned up to log sequence number 59549772833280 InnoDB: Doing recovery: scanned up to log sequence number 59549778076160 InnoDB: Doing recovery: scanned up to log sequence number 59549783319040 InnoDB: Doing recovery: scanned up to log sequence number 59549788561920 InnoDB: Doing recovery: scanned up to log sequence number 59549793804800 InnoDB: Doing recovery: scanned up to log sequence number 59549799047680 InnoDB: Doing recovery: scanned up to log sequence number 59549804290560 InnoDB: Doing recovery: scanned up to log sequence number 59549809533440 InnoDB: Doing recovery: scanned up to log sequence number 59549814776320 InnoDB: Doing recovery: scanned up to log sequence number 59549820019200 InnoDB: Doing recovery: scanned up to log sequence number 59549825262080 InnoDB: Doing recovery: scanned up to log sequence number 59549830504960 InnoDB: Doing recovery: scanned up to log sequence number 59549835747840 InnoDB: Doing recovery: scanned up to log sequence number 59549840990720 InnoDB: Doing recovery: scanned up to log sequence number 59549846233600 InnoDB: Doing recovery: scanned up to log sequence number 59549851476480 InnoDB: Doing recovery: scanned up to log sequence number 59549856719360 InnoDB: Doing recovery: scanned up to log sequence number 59549861962240 InnoDB: Doing recovery: scanned up to log sequence number 59549867205120 InnoDB: Doing recovery: scanned up to log sequence number 59549872448000 InnoDB: Doing recovery: scanned up to log sequence number 59549877690880 InnoDB: Doing recovery: scanned up to log sequence number 59549882933760 InnoDB: Doing recovery: scanned up to log sequence number 59549888176640 InnoDB: Doing recovery: scanned up to log sequence number 59549893419520 InnoDB: Doing recovery: scanned up to log sequence number 59549898662400 InnoDB: Doing recovery: scanned up to log sequence number 59549903905280 InnoDB: Doing recovery: scanned up to log sequence number 59549909148160 InnoDB: Doing recovery: scanned up to log sequence number 59549914391040 InnoDB: Doing recovery: scanned up to log sequence number 59549919633920 InnoDB: Doing recovery: scanned up to log sequence number 59549924876800 InnoDB: Doing recovery: scanned up to log sequence number 59549930119680 InnoDB: Doing recovery: scanned up to log sequence number 59549935362560 InnoDB: Doing recovery: scanned up to log sequence number 59549940605440 InnoDB: Doing recovery: scanned up to log sequence number 59549945848320 InnoDB: Doing recovery: scanned up to log sequence number 59549951091200 InnoDB: Doing recovery: scanned up to log sequence number 59549956334080 InnoDB: Doing recovery: scanned up to log sequence number 59549961576960 InnoDB: Doing recovery: scanned up to log sequence number 59549966819840 InnoDB: Doing recovery: scanned up to log sequence number 59549972062720 InnoDB: Doing recovery: scanned up to log sequence number 59549977305600 InnoDB: Doing recovery: scanned up to log sequence number 59549982548480 InnoDB: Doing recovery: scanned up to log sequence number 59549987791360 InnoDB: Doing recovery: scanned up to log sequence number 59549993034240 InnoDB: Doing recovery: scanned up to log sequence number 59549998277120 InnoDB: Doing recovery: scanned up to log sequence number 59550003520000 InnoDB: Doing recovery: scanned up to log sequence number 59550008762880 InnoDB: Doing recovery: scanned up to log sequence number 59550014005760 InnoDB: Doing recovery: scanned up to log sequence number 59550015124697 2016-03-02 16:26:41 140159224838080 [Note] InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: In a MySQL replication slave the last master binlog file InnoDB: position 0 3705580, file name mysql-bin.038679 InnoDB: Last MySQL binlog file position 0 46762652, file name /data/bigmomma/mysql/log/mysql-bin.056769 2016-03-02 16:27:02 140159224838080 [ERROR] InnoDB: Table ./VoorafgaandComputerboek_Klanten in the InnoDB data dictionary has tablespace id 1239896, but tablespace with that id or name does not exist. Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automatically removed, but the table still exists in the InnoDB internal data dictionary. InnoDB: Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html InnoDB: for how to resolve the issue. 2016-03-02 16:27:02 140159224838080 [ERROR] InnoDB: Table ./VoorafgaandJuridischboek_Klanten in the InnoDB data dictionary has tablespace id 1239897, but tablespace with that id or name does not exist. Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automatically removed, but the table still exists in the InnoDB internal data dictionary. InnoDB: Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html InnoDB: for how to resolve the issue. 2016-03-02 16:27:02 140159224838080 [ERROR] InnoDB: Table ./VoorafgaandManagementboek_Klanten in the InnoDB data dictionary has tablespace id 1239537, but tablespace with that id or name does not exist. Have you deleted or moved .ibd files? This may also be a table created with CREATE TEMPORARY TABLE whose .ibd and .frm files MySQL automatically removed, but the table still exists in the InnoDB internal data dictionary. InnoDB: Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html InnoDB: for how to resolve the issue. 2016-03-02 16:27:02 140159224838080 [Note] InnoDB: 128 rollback segment(s) are active. 2016-03-02 16:27:02 140159224838080 [Note] InnoDB: Waiting for purge to start 2016-03-02 16:27:02 140159224838080 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.28-76.1 started; log sequence number 59550015124697 2016-03-02 16:27:07 140099819902720 [Note] InnoDB: Dumping buffer pool(s) not yet started 2016-03-02 16:27:07 140159224838080 [Note] Plugin 'FEEDBACK' is disabled. 2016-03-02 16:27:07 140159224838080 [Note] Recovering after a crash using /data/bigmomma/mysql/log/mysql-bin 2016-03-02 16:27:07 140159224838080 [Note] Starting crash recovery... 2016-03-02 16:27:07 140159224838080 [Note] Crash recovery finished. 2016-03-02 16:27:07 140159224838080 [Note] Server socket created on IP: '0.0.0.0'. 2016-03-02 16:27:07 140159224838080 [ERROR] Can't open shared library 'libmysqllevenshtein.so' (errno: 0, /usr/lib/mysql/plugin/libmysqllevenshtein.so: cannot open shared object file: No such file or directory) 2016-03-02 16:27:07 140159224838080 [ERROR] Can't open shared library 'murmur_udf.so' (errno: 0, /usr/lib/mysql/plugin/murmur_udf.so: cannot open shared object file: No such file or directory) 2016-03-02 16:27:07 140159223584512 [Note] Event Scheduler: scheduler thread started with id 2 2016-03-02 16:27:07 140159224838080 [Note] Reading of all Master_info entries succeded 2016-03-02 16:27:07 140159224838080 [Note] Added new Master_info '' to hash table 2016-03-02 16:27:07 140159224838080 [ERROR] Error reading master configuration 2016-03-02 16:27:07 140159224838080 [ERROR] Failed to initialize the master info structure 2016-03-02 16:27:07 140159224838080 [ERROR] Failed to allocate memory for the Master Info structure 2016-03-02 16:27:07 140159224838080 [Note] /usr/sbin/mysqld: ready for connections. Version: '10.1.12-MariaDB-1~trusty' socket: '/var/run/mysqld/mysqld.sock' port: 3306 mariadb.org binary distribution