After running the wordpress installation and tried to login to wp-admin on my Ubuntu server, I got "error establishing connection to db" error. This is the error.log after running the WP install:
170708 6:05:02 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full n$
170708 6:05:02 [Note] Plugin 'FEDERATED' is disabled.
170708 6:05:02 InnoDB: The InnoDB memory heap is disabled
170708 6:05:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170708 6:05:02 InnoDB: Compressed tables use zlib 1.2.8
170708 6:05:02 InnoDB: Using Linux native AIO
170708 6:05:02 InnoDB: Initializing buffer pool, size = 128.0M
170708 6:05:02 InnoDB: Completed initialization of buffer pool
170708 6:05:02 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 1332282360
170708 6:05:02 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 1332887786
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 13E200
170708 6:05:02 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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 6$
InnoDB: Apply batch completed
InnoDB: Cleaning up trx with id 13DA6A
170708 6:05:02 InnoDB: Waiting for the background threads to start
170708 6:05:03 InnoDB: 5.5.37 started; log sequence number 1332887786
170708 6:05:03 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
170708 6:05:03 [Note] - '127.0.0.1' resolves to '127.0.0.1';
170708 6:05:03 [Note] Server socket created on IP: '127.0.0.1'.
170708 6:05:03 InnoDB: Assertion failure in thread 139675398293248 in file trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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:05:03 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 = 346700 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)[0x7f08d3614c70]
170708 6:05:03 [Note] Event Scheduler: Loaded 0 events
170708 6:05:03 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.37-0ubuntu0.14.04.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x7f08d34ff6d5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7f08d2291340]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39)[0x7f08d18e7f79]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f08d18eb388]
/usr/sbin/mysqld(+0x588b65)[0x7f08d36aeb65]
/usr/sbin/mysqld(+0x5896b9)[0x7f08d36af6b9]
/usr/sbin/mysqld(+0x64acdf)[0x7f08d3770cdf]
/usr/sbin/mysqld(+0x641595)[0x7f08d3767595]
/usr/sbin/mysqld(+0x58b525)[0x7f08d36b1525]
/usr/sbin/mysqld(+0x57d13c)[0x7f08d36a313c]
/usr/sbin/mysqld(+0x581213)[0x7f08d36a7213]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7f08d2289182]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f08d19ac30d]
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.
170708 6:05:04 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full n$
170708 6:05:04 [Note] Plugin 'FEDERATED' is disabled.
170708 6:05:04 InnoDB: The InnoDB memory heap is disabled
170708 6:05:04 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170708 6:05:04 InnoDB: Compressed tables use zlib 1.2.8
170708 6:05:04 InnoDB: Using Linux native AIO
170708 6:05:04 InnoDB: Initializing buffer pool, size = 128.0M
170708 6:05:04 InnoDB: Completed initialization of buffer pool
170708 6:05:04 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 1332284392
170708 6:05:04 InnoDB: Database was not shut down normally!
Then I tried to start my MySQL:
sudo /etc/init.d/mysql start
And I got this in the error.log:
170708 06:06:23 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
170708 6:06:23 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
170708 6:06:23 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full n$
170708 6:06:23 [Note] Plugin 'FEDERATED' is disabled.
170708 6:06:23 InnoDB: The InnoDB memory heap is disabled
170708 6:06:23 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170708 6:06:23 InnoDB: Compressed tables use zlib 1.2.8
170708 6:06:23 InnoDB: Using Linux native AIO
170708 6:06:23 InnoDB: Initializing buffer pool, size = 128.0M
170708 6:06:23 InnoDB: Completed initialization of buffer pool
170708 6:06:23 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 1332284392
170708 6:06:23 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 1332887786
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 13E200
170708 6:06:23 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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 6$
InnoDB: Apply batch completed
InnoDB: Cleaning up trx with id 13DA6A
170708 6:06:23 InnoDB: Waiting for the background threads to start
170708 6:06:24 InnoDB: 5.5.37 started; log sequence number 1332887786
170708 6:06:24 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
170708 6:06:24 [Note] - '127.0.0.1' resolves to '127.0.0.1';
170708 6:06:24 [Note] Server socket created on IP: '127.0.0.1'.
170708 6:06:24 InnoDB: Assertion failure in thread 140384662005504 in file trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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:06:24 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 = 346700 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)[0x7fadf2b5bc70]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x7fadf2a466d5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7fadf17d8340]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39)[0x7fadf0e2ef79]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fadf0e32388]
/usr/sbin/mysqld(+0x588b65)[0x7fadf2bf5b65]
/usr/sbin/mysqld(+0x5896b9)[0x7fadf2bf66b9]
/usr/sbin/mysqld(+0x64acdf)[0x7fadf2cb7cdf]
/usr/sbin/mysqld(+0x641595)[0x7fadf2cae595]
/usr/sbin/mysqld(+0x58b525)[0x7fadf2bf8525]
/usr/sbin/mysqld(+0x57d13c)[0x7fadf2bea13c]
/usr/sbin/mysqld(+0x581213)[0x7fadf2bee213]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7fadf17d0182]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fadf0ef330d]
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.
170708 06:06:24 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
These errors don't mean anything to me, please point me in the right direction to troubleshoot this problem.
Cheers
Related
I have seen about 20 pages pertaining to this error on StackExchange's sites (and others) and they all point towards doing:
C:\wamp64\bin\mariadb\mariadb10.4.10\my.ini: max_allowed_packet = 128M (or higher)`
C:\wamp64\bin\mariadb\mariadb10.4.10\my.ini: wait_timeout = 28800 (or higher)
which we have tried, but it's still reporting the "mysql has gone away" error.
We have also tried those config settings under the [wampmariadb64] and [mysqld] sections, to which we discovered that the [wampmariadb64] takes presidence when using WAMP, and those settings were applied, but no we're still getting the error intermittently..
There was also a suggestion to try to set ssl settings:
$cfg['Servers'][$i]['ssl'] = false;
But that didn't work.
They also suggest that we might have a loop problem in our php, which it originally was, but then we fixed it, and we're still getting the error.
Hints:
a) We've only been getting the error since the PHP loop problem which we've fixed.
b) Our log files in WAMP's "C:\wamp64\bin\mariadb\mariadb10.4.10\data" are maxed out to 64Mb, which is what we set it to, but it maxes out on the initial use (on startup and first loading a statement). Is this normal? The log files are named: "ib_logfile0" and "ib_logfile1".
c) About 50 (or so) singular statements after startup it gives the error. The error goes away after an hour of no statement executions, apprx (not always but just about an hour or two later).
Could I please just get some pages to read on troubleshooting the error like this page:
http://ronaldbradford.com/: mysql server has gone away 2013-01-02
Thanks.
Update
I was meaning that we've been editing and trying to change the settings in the C:\wamp64\bin\mariadb\mariadb10.4.10\my.ini file, and not the php.ini sorry. Have corrected above sentences to clarify.
Update
I discovered that a script that automates the creation of a database.sql via mysqydump has sometimes been creating 0kb .sql files, which is required for the other scripts to move on.
I'm looking at the following command, which I have just removed 2>&1 from and going to try that:
exec("mysqldump --port={$GLOBALS['SQL_Port']} --user={$GLOBALS['SQL_Username']} --password={$GLOBALS['SQL_Password']} --host={$GLOBALS['SQL_Host_NoPort']} {$Database} --result-file={$DumpDatabase}.sql");
// 2>&1
Update
This error is now showing up:
Error in processing request
Error code: 200
Error text: OK (rejected)
It seems that the connection to server has been lost. Please check your network connectivity and server status.
Update
Discovered the mariadb logs but they don't say much:
InnoDB: using atomic writes.
2020-07-23 19:16:23 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2020-07-23 19:16:23 0 [Note] InnoDB: Uses event mutexes
2020-07-23 19:16:23 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2020-07-23 19:16:23 0 [Note] InnoDB: Number of pools: 1
2020-07-23 19:16:23 0 [Note] InnoDB: Using SSE2 crc32 instructions
2020-07-23 19:16:23 0 [Note] InnoDB: Initializing buffer pool, total size = 256M, instances = 1, chunk size = 128M
2020-07-23 19:16:23 0 [Note] InnoDB: Completed initialization of buffer pool
2020-07-23 19:16:23 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2020-07-23 19:16:23 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2020-07-23 19:16:23 0 [Note] InnoDB: Setting file '.\ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2020-07-23 19:16:23 0 [Note] InnoDB: File '.\ibtmp1' size is now 12 MB.
2020-07-23 19:16:23 0 [Note] InnoDB: Waiting for purge to start
2020-07-23 19:16:23 0 [Note] InnoDB: 10.4.10 started; log sequence number 140336; transaction id 21
2020-07-23 19:16:23 0 [Note] InnoDB: Loading buffer pool(s) from c:\wamp64\bin\mariadb\mariadb10.4.10\data\ib_buffer_pool
2020-07-23 19:16:23 0 [Note] Plugin 'FEEDBACK' is disabled.
2020-07-23 19:16:23 0 [Note] InnoDB: Buffer pool(s) load completed at 200723 19:16:23
2020-07-23 19:16:23 0 [Note] Server socket created on IP: '::'.
2020-07-23 19:16:23 0 [Note] Reading of all Master_info entries succeeded
2020-07-23 19:16:23 0 [Note] Added new Master_info '' to hash table
2020-07-23 19:16:23 0 [Note] wampmariadb64: ready for connections.
Version: '10.4.10-MariaDB' socket: '' port: 3306 mariadb.org binary distribution
2020-07-23 19:27:43 0 [Note] wampmariadb64 (initiated by: unknown): Normal shutdown
2020-07-23 19:27:43 0 [Note] Event Scheduler: Purging the queue. 0 events
2020-07-23 19:27:43 0 [Note] InnoDB: FTS optimize thread exiting.
2020-07-23 19:27:43 0 [Note] InnoDB: Starting shutdown...
2020-07-23 19:27:43 0 [Note] InnoDB: Dumping buffer pool(s) to c:\wamp64\bin\mariadb\mariadb10.4.10\data\ib_buffer_pool
2020-07-23 19:27:43 0 [Note] InnoDB: Buffer pool(s) dump completed at 200723 19:27:43
2020-07-23 19:27:44 0 [Note] InnoDB: Shutdown completed; log sequence number 140345; transaction id 22
2020-07-23 19:27:44 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2020-07-23 19:27:44 0 [Note] wampmariadb64: Shutdown complete
It had something to do with starting WAMP in Windows 10 Scheduled Task Manager, starting it as a new task. Probably because I didn't start it with Administrator privileges.
Once I removed the Scheduled Task: Start WAMP # Logon -it seemed to work again.
When I started the MYSQL from Xampp it crashed. It gave me this error:
8:32:33 AM [mysql] Attempting to start MySQL app...
8:32:33 AM [mysql] Status change detected: running
8:32:37 AM [mysql] Status change detected: stopped
8:32:37 AM [mysql] Error: MySQL shutdown unexpectedly.
8:32:37 AM [mysql] This may be due to a blocked port, missing dependencies, 8:32:37 AM [mysql] improper privileges, a crash, or a shutdown by another method. 8:32:37 AM [mysql] Press the Logs button to view error logs and check
8:32:37 AM [mysql] the Windows Event Viewer for more clues 8:32:37 AM [mysql] If you need more help, copy and post this
8:32:37 AM [mysql] entire log window on the forums
error log InnoDB: using atomic writes.
2020-05-13 8:26:07 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2020-05-13 8:26:07 0 [Note] InnoDB: Uses event mutexes
2020-05-13 8:26:07 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2020-05-13 8:26:07 0 [Note] InnoDB: Number of pools: 1
2020-05-13 8:26:07 0 [Note] InnoDB: Using SSE2 crc32 instructions
2020-05-13 8:26:07 0 [Note] InnoDB: Initializing buffer pool, total size = 16M, instances = 1, chunk size = 16M
2020-05-13 8:26:07 0 [Note] InnoDB: Completed initialization of buffer pool
2020-05-13 8:26:07 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2020-05-13 8:26:07 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2020-05-13 8:26:07 0 [Note] InnoDB: Setting file 'C:\xampp\mysql\data\ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2020-05-13 8:26:07 0 [Note] InnoDB: File 'C:\xampp\mysql\data\ibtmp1' size is now 12 MB.
2020-05-13 8:26:07 0 [Note] InnoDB: Waiting for purge to start
2020-05-13 8:26:07 0 [Note] InnoDB: 10.4.11 started; log sequence number 73242724; transaction id 45388
2020-05-13 8:26:07 0 [Note] InnoDB: Loading buffer pool(s) from C:\xampp\mysql\data\ib_buffer_pool
2020-05-13 8:26:07 0 [Note] Plugin 'FEEDBACK' is disabled.
2020-05-13 8:26:07 0 [Note] Server socket created on IP: '::'.
Can someone please help me and tell what actually is happening
Probably your port is busy. If you use Linux you can try to run "lsof -i" to detect what is using your port.
Well I also used to get this kind of problem. I resolved this error like this:
1) Open the Xampp control panel and click Services
2)Find the MYSQL08 option. It might show the service is started.
3)Stop the service and try starting the mysql again
Hope so it might help you.
I have a problem with MySQL. WAMP is orange with service online, but not MySQL. It displays the following error:
#2002 - No connection could be made because the target machine actively refused it.
This is the log error:
2015-11-18 22:13:24 7408 [Note] Plugin 'FEDERATED' is disabled.
2015-11-18 22:13:24 7408 [Note] InnoDB: Using atomics to ref count buffer pool pages
2015-11-18 22:13:24 7408 [Note] InnoDB: The InnoDB memory heap is disabled
2015-11-18 22:13:24 7408 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2015-11-18 22:13:24 7408 [Note] InnoDB: Compressed tables use zlib 1.2.3
2015-11-18 22:13:24 7408 [Note] InnoDB: Not using CPU crc32 instructions
2015-11-18 22:13:24 7408 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2015-11-18 22:13:24 7408 [Note] InnoDB: Completed initialization of buffer pool
2015-11-18 22:13:24 7408 [Note] InnoDB: Highest supported file format is Barracuda.
2015-11-18 22:13:24 7408 [Note] InnoDB: The log sequence numbers 101407365 and 101407365 in ibdata files do not match the log sequence number 101451472 in the ib_logfiles!
2015-11-18 22:13:24 7408 [Note] InnoDB: Database was not shutdown normally!
2015-11-18 22:13:24 7408 [Note] InnoDB: Starting crash recovery.
2015-11-18 22:13:24 7408 [Note] InnoDB: Reading tablespace information from the .ibd files...
2015-11-18 22:13:24 7408 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace catalog_estudio/ost_qacomments uses space ID: 70 at filepath: .\catalog_estudio\ost_qacomments.ibd. Cannot open tablespace osticket/ost_content which uses space ID: 70 at filepath: .\osticket\ost_content.ibd
InnoDB: Error: could not open single-table tablespace file .\osticket\ost_content.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
I tried to find my.cnf but it doesn't exist. I removed the .ibd files but the issue remains the same.
MySQL port on the server is either firewalled, or mysql isn't listening on that port. "actively refusing" means the target machine returned a "connection refused".
Change this file: "C:\wamp\bin\mysql[mysql_version]\my.ini"
[client]
#password = your_password
port = 3306
socket = /tmp/mysql.sock
and MySQL server
[wampmysqld]
port = 3306
socket = /tmp/mysql.sock
You could change port number default 3306 to 3309 like.
UPDATE
mysql.sock is not a simple file which you can just create. MySQL will create on the start by "itself".
Try to start MySQL and then provide us with a full mysqld.log.
I assume that it`s the following and workaround/solution can be found here itself in it:
InnoDB: Error: could not open single-table tablespace file .\mysql\slave_worker_info.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.
1) If there is a permission problem in the file and mysqld cannot open the file, you should modify the permissions.
2) If the table is not needed, or you can restore it from a backup, then you can remove the .ibd file, and InnoDB will do a normal crash recovery and ignore that table.
3) If the file system or the disk is broken, and you cannot remove the .ibd file, you can set innodb_force_recovery > 0 in my.cnf and force InnoDB to continue crash recovery here:
1) In [mysqld] section, add the following line:
innodb_force_recovery = 1
2) Save the file and try starting MySQL.
3) when recovery is finished, remove that line which you just added and restart MySQL.
My computer has turned off due to power loss while the wamp server is running, now when I am trying to turn the server on it remains orange the http requests to server is working, but when I am trying to log in to MySQl I am getting the following error :
#2002 Cannot log in to the MySQL server
I have done some search and all the results was to remove it and reinstall is there any other way?
I am still a beginner so I don't actually know which files I need to show you in order to help me please comment of anything I need to show.
My last log in attempt in mysql log :
2015-11-11 11:08:03 8052 [Note] Plugin 'FEDERATED' is disabled.
2015-11-11 11:08:03 8052 [Note] InnoDB: The InnoDB memory heap is disabled
2015-11-11 11:08:03 8052 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2015-11-11 11:08:03 8052 [Note] InnoDB: Compressed tables use zlib 1.2.3
2015-11-11 11:08:03 8052 [Note] InnoDB: Not using CPU crc32 instructions
2015-11-11 11:08:03 8052 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2015-11-11 11:08:03 8052 [Note] InnoDB: Completed initialization of buffer pool
2015-11-11 11:08:03 8052 [Note] InnoDB: Highest supported file format is Barracuda.
2015-11-11 11:08:03 8052 [Note] InnoDB: The log sequence numbers 2671283 and 2671283 in ibdata files do not match the log sequence number 2671293 in the ib_logfiles!
2015-11-11 11:08:03 8052 [Note] InnoDB: Database was not shutdown normally!
2015-11-11 11:08:03 8052 [Note] InnoDB: Starting crash recovery.
2015-11-11 11:08:03 8052 [Note] InnoDB: Reading tablespace information from the .ibd files...
2015-11-11 11:08:03 8052 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace coldatabase/item uses space ID: 3 at filepath: .\coldatabase\item.ibd. Cannot open tablespace mysql/slave_relay_log_info which uses space ID: 3 at filepath: .\mysql\slave_relay_log_info.ibd
InnoDB: Error: could not open single-table tablespace file .\mysql\slave_relay_log_info.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.
I had similar problems and i solved it by two methods and i am mentioning the better one of the two.
copy c:\wamp folder to any other safe location
let the orginal c:\wamp folder stay in its place
install the wamp server from the same package that you used to install before
start the wamp server
DONE...!!!
(The copy of c:\wamp folder to any other safe location was just for emergency, in case something goes wrong).
I've installed Drupal on my local XAMPP Server. It worked all fine, no problems with including and working with the database/site till i restarted XAMPP. Since then I get the following at my logfile:
2013-09-02 16:18:46 2544 [Note] Plugin 'FEDERATED' is disabled.
2013-09-02 16:18:46 3e8 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2013-09-02 16:18:46 2544 [Note] InnoDB: The InnoDB memory heap is disabled
2013-09-02 16:18:46 2544 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2013-09-02 16:18:46 2544 [Note] InnoDB: Compressed tables use zlib 1.2.3
2013-09-02 16:18:46 2544 [Note] InnoDB: Not using CPU crc32 instructions
2013-09-02 16:18:46 2544 [Note] InnoDB: Initializing buffer pool, size = 16.0M
2013-09-02 16:18:46 2544 [Note] InnoDB: Completed initialization of buffer pool
2013-09-02 16:18:46 2544 [Note] InnoDB: Highest supported file format is Barracuda.
2013-09-02 16:18:47 2544 [Note] InnoDB: The log sequence numbers 1600614 and 1600614 in ibdata files do not match the log sequence number 1600644 in the ib_logfiles!
2013-09-02 16:18:47 2544 [Note] InnoDB: Database was not shutdown normally!
2013-09-02 16:18:47 2544 [Note] InnoDB: Starting crash recovery.
2013-09-02 16:18:47 2544 [Note] InnoDB: Reading tablespace information from the .ibd files...
2013-09-02 16:18:47 2544 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace drupal/variable uses space ID: 2 at filepath: .\drupal\variable.ibd. Cannot open tablespace mysql/innodb_index_stats which uses space ID: 2 at filepath: .\mysql\innodb_index_stats.ibd
InnoDB: Error: could not open single-table tablespace file .\mysql\innodb_index_stats.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.
I looked for a solution via google but it seems to be a problem just with the drupal database because it's able to connect with MySQL if I remove the database.
I hope someone could help me :(.
Move (DON'T DELETE) those files, into another folder:
innodb_index_stats.frm
innodb_table_stats.frm
slave_master_info.frm
slave_relay_log_info.frm
slave_worker_info.frm
and .ibd files with the same filename:
innodb_index_stats.ibd
innodb_table_stats.ibd
slave_master_info.ibd
slave_relay_log_info.ibd
slave_worker_info.ibd
Try start MySQL.
You can solve this problem by adding a line in your mysql config file: my.cnf or my.ini (depends on your distro)
just under [mysqld] add this line: innodb_force_recovery = 1
..
[mysqld]
innodb_force_recovery = 1
..
Then restart your MySql Server.
You could have lost some data but you'll get the server working again with your data.
Regards,
dev_khan,
try restarting MySQL in Read-Only mode with the innodb_force_recovery option enabled:
Edit my.cnf - find the line: # innodb_force_recovery = 2
Comment the line in (remove the #)
Restart MySQL to let the MySQL engine repair itself.
Comment the innodb_force_recovery line in again (add #)
Restart MySQL again and you have full access again without a Read-Only-Restriction.
Greetings from Germany
This happens with Wordpress too. It only seems to happen with the latest version as I've rolled back to previous versions of AMPPS and it works fine without throwing up this innodb issue.