At one point, mysql stopped starting. In the logs it is constantly going
May 7 12:54:19 web kernel: [1269.241113] init: mysql post-start process (14969) terminated with status 1
May 7 12:54:21 web kernel: [1271.702334] init: mysql main process (15036) terminated with status 1
May 7 12:54:21 web kernel: [1271.702353] init: mysql main process ended, respawning
Ubuntu 14 mysql-server-5.5.
Reinstalling the package did not change anything. Dpkg-reconfigure does not work.
Logs to /var/log/mysql/error.log
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files ...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer ...
InnoDB: Doing recovery: scanned up to log sequence number 39937467241
InnoDB: 1 transaction (s) which must be rolled back or cleaned up
InnoDB: in total 1 row operations to undo
InnoDB: Trx id counter is 11EE800
200507 13:38:36 InnoDB: Starting an apply batch of log records to the database ...
InnoDB: Progress in percents: 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: Starting in background the rollback of uncommitted transactions
200507 13:38:37 InnoDB: Rolling back trx with id 11EE62A, 1 rows to undo
200507 13:38:37 InnoDB: Waiting for the background threads to start
200507 13:38:37 InnoDB: Assertion failure in thread 140283091519232 in file fut0lst.ic line 83
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset & gt; = FIL_PAGE_DATA
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
10:38:37 UTC - mysqld got signal 6;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
key_buffer_size = 16777216
read_buffer_size = 131072
max_used_connections = 0
max_threads = 151
thread_count = 0
connection_count = 0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size) * max_threads = 346701 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong ...
stack_bottom = 0 thread_stack 0x30000
/ usr / sbin / mysqld (my_print_stacktrace + 0x20) [0x55c8dd3c0740]
/ usr / sbin / mysqld (handle_fatal_signal + 0x3d5) [0x55c8dd2a8ea5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330) [0x7f9a6e9b2330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37) [0x7f9a6e005c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7f9a6e009028]
/ usr / sbin / mysqld (+ 0x2764cf) [0x55c8dd1404cf]
/ usr / sbin / mysqld (+ 0x5d4e98) [0x55c8dd49ee98]
/ usr / sbin / mysqld (+ 0x55f809) [0x55c8dd429809]
/ usr / sbin / mysqld (+ 0x573b7a) [0x55c8dd43db7a]
/ usr / sbin / mysqld (+ 0x56c324) [0x55c8dd436324]
/ usr / sbin / mysqld (+ 0x56d4d0) [0x55c8dd4374d0]
/ usr / sbin / mysqld (+ 0x567fbf) [0x55c8dd431fbf]
/ usr / sbin / mysqld (+ 0x615e2a) [0x55c8dd4dfe2a]
/ usr / sbin / mysqld (+ 0x6164b4) [0x55c8dd4e04b4]
/ usr / sbin / mysqld (+ 0x566863) [0x55c8dd430863]
/ usr / sbin / mysqld (+ 0x566de3) [0x55c8dd430de3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184) [0x7f9a6e9aa184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f9a6e0cd03d]
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.
200507 13:38:38 [Warning] Using Unique Option Prefix Myisam-Recover Instead of Myisam-Recover-Options Is Deprecated and Wil L Be Removed in a Future Release. Please Use the Full Name Instead.
200507 13:38:38 [note] plugin 'federated' is disabled.
200507 13:38:38 Innodb: The Innodb Memory Heap is Disabled
200507 13:38:38 Innodb: mutexes and rw_locks use gcc atomic builtins
200507 13:38:38 Innodb: Compressed Tables USE ZLIB 1.2.8
200507 13:38:38 Innodb: Using Linux Native Aio
200507 13:38:38 Innodb: Initializing Buffer Pool, Size = 16.0g
200507 13:38:39 Innodb: Completed Initialization Of Buffer Pool
200507 13:38:39 Innodb: Highest Supported File Format Is Barracuda.
Innodb: Log Scan Progressed Past The Checkpoint LSN 39937450229
200507 13:38:39 Innodb: Database Was Not Shut Down Normally!
with Innodb_force_Recovery = 3 MySQL started. But do something either through the web does not work. Going “Got Error -1 error from Storage Engine”. And to different bases.
In this mode, it does not give anything to the database. What is better to do? Full removal of broken databases and return to normal mode?
Uponcing MySqlCheck –all-Databases All bases are indicated as ok.
And all the same, the problem is saved. MySQL table does not work normally. Does not touch it completely. Not loading from backup.
Answer 1
launched MySQL with Innodb_force_Recovery = 6 part of the data stacked in the table with which work was performed. After that, it removed the parameter and MySQL started correctly the data was removed and replaced from the backup.