VPS Can't connect to local MySQL server through socket - mysql

the mysql in my VPS hosting has connection problem. I think it was due to my server drive has fail and my hosting has replace and rebuild a new drive. So I thought that my MySQL installation may have been corrupted, so I upgrade the mysql but the problem persist. How to fix this ? Thank you
root#user [~]# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.1.68-cll MySQL Community Server (GPL)
Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> use testdb
No connection. Trying to reconnect...
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
ERROR:
Can't connect to the server
mysql>
Here is the error log generated in /var/lib/mysql/domain.err
Version: '5.1.68-cll' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (GPL)
130303 17:28:49 InnoDB: Assertion failure in thread 2965224304 in file fsp/fsp0fsp.c line 3341
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.1/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
09:28:49 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=8384512
read_buffer_size=131072
max_used_connections=0
max_threads=500
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 = 1099543 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+0x25)[0x848d5e5]
/usr/sbin/mysqld(handle_fatal_signal+0x42a)[0x82dd84a]
[0xb775c500]
/lib/libc.so.6(abort+0x17a)[0xb75513da]
/usr/sbin/mysqld(fseg_free_step_not_header+0x1a1)[0x83afab1]
/usr/sbin/mysqld[0x8409078]
/usr/sbin/mysqld[0x84094d0]
/usr/sbin/mysqld(trx_purge_fetch_next_rec+0x7a)[0x840960a]
/usr/sbin/mysqld(row_purge_step+0x37)[0x83eefb7]
/usr/sbin/mysqld(que_run_threads+0x4f7)[0x83de467]
/usr/sbin/mysqld(trx_purge+0x32f)[0x840787f]
/usr/sbin/mysqld(srv_master_thread+0x417)[0x8400267]
/lib/libpthread.so.0(+0x6a49)[0xb773ca49]
/lib/libc.so.6(clone+0x5e)[0xb760763e]
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.
130303 17:28:49 mysqld_safe Number of processes running now: 0
130303 17:28:49 mysqld_safe mysqld restarted
130303 17:28:49 [Warning] '--log_slow_queries' is deprecated and will be removed in a future release. Please use ''--slow_query_log'/'--slow_query_log_file'' instead.
130303 17:28:49 [Warning] '--safe-show-database' is deprecated and will be removed in a future release. Please use 'GRANT SHOW DATABASES' instead.
130303 17:28:49 [Warning] '--log' is deprecated and will be removed in a future release. Please use ''--general_log'/'--general_log_file'' instead.
130303 17:28:49 [Note] Plugin 'FEDERATED' is disabled.
130303 17:28:49 InnoDB: Initializing buffer pool, size = 8.0M
130303 17:28:49 InnoDB: Completed initialization of buffer pool
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
130303 17:28:49 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...
130303 17:28:49 InnoDB: Started; log sequence number 0 1605434197
130303 17:28:49 [Warning] 'user' entry 'root#s1.replace.com' ignored in --skip-name-resolve mode.
130303 17:28:49 [Warning] 'user' entry 'root#xx1.no-ip.org' ignored in --skip-name-resolve mode.
130303 17:28:49 [Note] Event Scheduler: Loaded 0 events
130303 17:28:49 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.68-cll' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (GPL)
130303 17:28:50 InnoDB: Assertion failure in thread 2965224304 in file fsp/fsp0fsp.c line 3341
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.1/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
Computer info
root#user [~]# uname -a
Linux domain.com 2.6.32-042stab072.10 #1 SMP Wed Jan 16 18:54:05 MSK 2013 i686 i686 i386 GNU/Linux
root#user [~]# free -m
total used free shared buffers cached
Mem: 2560 1323 1236 0 0 826
-/+ buffers/cache: 497 2062
Swap: 0 0 0
root#user [~]# cat /etc/my.cnf
[mysqld]
max_connections=500
log-slow-queries
log-error
safe-show-database
bind-address=xx.x.xx.xxx
skip-name-resolve
connect_timeout= 10
log=1
log_warnings = 2
max_allowed_packet = 64M

Your MySQL server process either isn't running or the InnoDB assertion right after MySQL started listening for connections has hung the process. Note these lines:
130303 17:28:49 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.68-cll' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (GPL)
130303 17:28:50 InnoDB: Assertion failure in thread 2965224304 in file fsp/fsp0fsp.c line 3341
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.1/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
Go to the InnoDB Recovery page listed in that output and follow the instructions for forcing an InnoDB recovery. It looks like you have a corrupt InnoDB database.

Related

Mysql service would not restart anymore

My mysql server couldn' t not restart anymore
i was doing the installation of a wordpress plugin, it crashed, then i tried to relaunch the service, I have the error:
root#ns3371000:~# /etc/init.d/mysql start
[FAIL] Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!
This is the log when i launch it in safe mode:
mysqld_safe Logging to '/var/log/mysql.err'.
180822 16:33:07 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180822 16:33:07 [Note] Plugin 'FEDERATED' is disabled.
180822 16:33:07 InnoDB: The InnoDB memory heap is disabled
180822 16:33:07 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180822 16:33:07 InnoDB: Compressed tables use zlib 1.2.7
180822 16:33:07 InnoDB: Using Linux native AIO
180822 16:33:07 InnoDB: Initializing buffer pool, size = 128.0M
180822 16:33:07 InnoDB: Completed initialization of buffer pool
180822 16:33:07 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 12059835
180822 16:33:07 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: Error: tried to read 65536 bytes at offset 0 2358272.
InnoDB: Was only able to read 1024.
InnoDB: Fatal error: cannot read from file. OS error number 17.
180822 16:33:10 InnoDB: Assertion failure in thread 140608317830944 in file os0file.c line 2549
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.
14:33:10 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+0x29)[0x56449ac71dc9]
/usr/sbin/mysqld(handle_fatal_signal+0x3d8)[0x56449ab57dc8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x7fe1ec9460a0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7fe1eb1d6125]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x180)[0x7fe1eb1d93a0]
/usr/sbin/mysqld(+0x67926b)[0x56449ada926b]
/usr/sbin/mysqld(+0x63eca0)[0x56449ad6eca0]
/usr/sbin/mysqld(+0x66b906)[0x56449ad9b906]
/usr/sbin/mysqld(+0x670eb7)[0x56449ada0eb7]
/usr/sbin/mysqld(+0x5ce70f)[0x56449acfe70f]
/usr/sbin/mysqld(+0x59aa2f)[0x56449accaa2f]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x56449ab5a151]
/usr/sbin/mysqld(+0x336507)[0x56449aa66507]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xa73)[0x56449aa69553]
/usr/sbin/mysqld(+0x2bb695)[0x56449a9eb695]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x45b)[0x56449a9ec30b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7fe1eb1c2ead]
/usr/sbin/mysqld(+0x2b2c89)[0x56449a9e2c89]
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.
I don' t want to loose all my current databases, anything pointing me to sort out the issues would be greatful
Thanks
If the database is broken you can try to access it in a recovery mode.
In your configuration file (my.ini) try to add:
[mysqld]
innodb_force_recovery = N
where N is from 1 to 6. Then, restart the server.
More information here: https://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
At least, you should be able to access the database in read-only mode to do the dump.

MariaDB/MySQL resource limit was exceeded

I'm trying to connect to MariaDB/Mysql installed on my CentOS 7 and get the following error when trying to connect using: mysql -u root -p.
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111)
I have tried connecting to it by specifying the IP Address instead of using localhost but I get the same error.
When I try to get the MariaDB status, I get the following message (/bin/systemctl status mariadb.service):
mariadb.service - MariaDB database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
Active: failed (Result: resources)
And starting it yields the following error (/bin/systemctl start mariadb.service):
Job for mariadb.service failed because a configured resource limit was exceeded. See "systemctl status mariadb.service" and "journalctl -xe" for details.
I also looked into the logs located at /var/log/mariadb/mariadb.log
160408 12:21:00 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
160408 16:11:01 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
160408 16:11:01 [Note] /usr/libexec/mysqld (mysqld 5.5.47-MariaDB) starting as process 3054 ...
160408 16:11:02 InnoDB: The InnoDB memory heap is disabled
160408 16:11:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160408 16:11:02 InnoDB: Compressed tables use zlib 1.2.7
160408 16:11:02 InnoDB: Using Linux native AIO
160408 16:11:02 InnoDB: Initializing buffer pool, size = 128.0M
160408 16:11:02 InnoDB: Completed initialization of buffer pool
160408 16:11:02 InnoDB: highest supported file format is Barracuda.
160408 16:11:04 InnoDB: Waiting for the background threads to start
160408 16:11:05 Percona XtraDB (http://www.percona.com) 5.5.46-MariaDB-37.6 started; log sequence number 54018416776
160408 16:11:06 [Note] Plugin 'FEEDBACK' is disabled.
160408 16:11:07 [Note] Server socket created on IP: '0.0.0.0'.
160408 16:11:07 [Note] Event Scheduler: Loaded 0 events
160408 16:11:07 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.47-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server
160409 6:26:06 InnoDB: Error: Write to file ./ibdata1 failed at offset 9 615514112.
InnoDB: 1048576 bytes should have been written, only 585728 were written.
InnoDB: Operating system error number 28.
InnoDB: Check that your OS and file system support files of this size.
InnoDB: Check also that the disk is not full or a disk quota exceeded.
InnoDB: Error number 28 means 'No space left on device'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/operating-system-error-codes.html
160409 6:26:06 InnoDB: Assertion failure in thread 140463216400128 in file os0file.c line 4377
Anyone has any ideas on how to fix this error?
Thank you :)
> perror 28
OS error code 28: No space left on device
Need I say more?

XAMPP: MySQL does not start after crash

There are aready several questions regarding that MySQL fails to start when running XAMPP, but unfortunately I couldn't figure out a solution from these.
Here is my case:
I installed XAMPP for Linux 5.6.14-3 and when I ran it yesterday everything worked fine.
Today, I ran XAMPP again:
/opt/lampp$ sudo ./xampp start
Starting XAMPP for Linux 5.6.14-3...
XAMPP: Starting Apache...ok.
XAMPP: Starting MySQL...ok.
XAMPP: Starting ProFTPD...ok.
Then I open localhost in the browser bringing me to the xampp dashboard. There I click on the phpMyAdmin menu entry, which gives me:
Error
MySQL said:
Cannot connect: invalid settings.
Connection for controluser as defined in your configuration failed.
phpMyAdmin tried to connect to the MySQL server,
and the server rejected the connection.
You should check the host, username and password
in your configuration and make sure that they
correspond to the information given by the
administrator of the MySQL server.
I think that I made sure that the control user has the right pass.
The problem rather seems to be that MySQL does not really start although it says 'ok' (see above). Since, when I stop XAMPP, I get:
/opt/lampp$ sudo ./xampp stop
Stopping XAMPP for Linux 5.6.14-3...
XAMPP: Stopping Apache...ok.
XAMPP: Stopping MySQL...not running.
XAMPP: Stopping ProFTPD...ok.
Looking at the error_log of xampp, there is a single entry, which looks suspicious (though I don't really understand it), saying:
[Sun Nov 15 11:38:59.737875 2015] [mpm_prefork:notice] [pid 6217] AH00169: caught SIGTERM, shutting down
So, if anybody is able to locate the problem or give me hints for a fix, I would really apreciate. Thanks already!
Edit - problem "fixed" (without knowing, what I've really done, though)
Here's the MySQL error-log (located at /opt/lampp/var/mysql/[computername].err):
2015-11-15 15:52:44 10864 mysqld_safe Starting mysqld daemon with databases from /opt/lampp/var/
2015-11-15 15:52:44 140410457307008 [Note] Using unique option prefix 'key_buffer' is error-prone and can break in the future. Please use the full name 'key_buffer_size' instead.
2015-11-15 15:52:44 140410457307008 [Note] /opt/lampp/sbin/mysqld (mysqld 10.1.8-MariaDB) starting as process 11011 ...
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: The InnoDB memory heap is disabled
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Memory barrier is not used
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Compressed tables use zlib 1.2.8
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Using CPU crc32 instructions
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Initializing buffer pool, size = 16.0M
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Completed initialization of buffer pool
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Highest supported file format is Barracuda.
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: The log sequence numbers 3813213 and 3813213 in ibdata files do not match the log sequence number 9929741 in the ib_logfiles!
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Database was not shutdown normally!
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Starting crash recovery.
2015-11-15 15:52:44 140410457307008 [Note] InnoDB: Reading tablespace information from the .ibd files...
2015-11-15 15:52:44 140410457307008 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace bitnami_joomla/jos_content_frontpage uses space ID: 14 at filepath: ./bitnami_joomla/jos_content_frontpage.ibd. Cannot open tablespace phpmyadmin/pma__bookmark which uses space ID: 14 at filepath: ./phpmyadmin/pma__bookmark.ibd
2015-11-15 15:52:44 7fb3db6e3780 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
InnoDB: Error: could not open single-table tablespace file ./phpmyadmin/pma__bookmark.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.
2015-11-15 15:52:44 10864 mysqld_safe mysqld from pid file /opt/lampp/var/mysql/[computername].pid ended
First try: I made a backup of the directory /opt/lampp/var/mysql/phpmyadmin/ and added
innodb_force_recovery = 1
at the end of /opt/lampp/etc/my.conf. That gave me still the same error when starting MySQL again.
Next try was removing the file pma__bookmarks.idb from the directory, which had the effect that the error now complained about pma__favorites instead.
Finally, I removed all pma__*.idb-files and voila! MySQL is running, and I can access the phpMyAdmin-pages.
Works for me, though I don't know what was lost be removing the pma-databases? (They were not restored in any way, as it seems...)
Probably, the database-files were corrupted, when my computer went down, and they were still running!?
You must check whether mysqld process exist in top and then either try to connect with mysql command line client or review MySQL Error log. Sometimes xampp may be confused by MySQL Server which e.g. comes pre-installed with OS.

Getting error "Plugin 'InnoDB' registration as a STORAGE ENGINE failed" when starting MySQL

I found many similar question on Stackoverflow but didn't get the exact error solution.
My issue is when starting MySQL service on one of the Dedicated Centos 6.5 machine, I am getting error :
141018 05:13:46 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
141018 5:13:47 [Warning] Can't create test file /var/lib/mysql/ip-184-168-73-83.lower-test
141018 5:13:47 [Warning] Can't create test file /var/lib/mysql/ip-184-168-73-83.lower-test
/usr/libexec/mysqld: Can't create/write to file '/tmp/ibkTWnhE' (Errcode: 28)
141018 5:13:48 InnoDB: Error: unable to create temporary file; errno: 28
141018 5:13:48 [ERROR] Plugin 'InnoDB' init function returned error.
141018 5:13:48 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
141018 5:13:48 [ERROR] Can't start server : Bind on unix socket: No space left on device
141018 5:13:48 [ERROR] Do you already have another mysqld server running on socket: /var/lib/mysql/mysql.sock ?
141018 5:13:48 [ERROR] Aborting
141018 5:13:48 [Note] /usr/libexec/mysqld: Shutdown complete
141018 05:13:48 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
Here are free command status:
free -m
total used free shared buffers cached
Mem: 3743 3631 111 0 2705 21
-/+ buffers/cache: 905 2838
Swap: 2047 0 2047
This error also happens when your Database data is corrupt. You may fix this issue by moving your Db data files (ib_logfile0 and ib_logfile1) mentioned below to another location. ib_logfile0 and ib_logfile1 are system tablespace for the InnoDB infrastructure. These files contains several classes for information vital for InnoDB. You may read about these files here.
Before following below steps please keep a copy of files (ib_logfile0 and ib_logfile1) so you may restore your data in case it is lost:
Follow below steps:
Login to server via SSH with root access.
Navigate to /var/lib/mysql.
If you see files like, ib_logfile0 and ib_logfile1, rename or move them to some other folder.
Stop and start the MySQL service by running sudo service mysql stop and sudo service mysql start
These files will be recreated after you restart the server and the issue will be fixed hopefully.
Thanks
I have the same problems, this my solution:
Add more RAM to the server
Decrease the value of innodb-buffer-pool size in the config file:
sudo nano /etc/mysql/my.cnf
innodb_buffer_pool_size = 10M
After save /etc/mysql/my.cnf.
Restart mysql service:
sudo service mysql restart
exit
This is frequently occurred issue. Do following -
delete/move out these "aria_log_contro, ib_logfile0, ib_logfile1, ib_data1" files from location "..\xampp\mysql\data" and also from "..\xampp\mysql\backup".
stop and start apache server and mysql form xampp control panel
This should fix the issue; actually it worked for me.
NOTE: THIS IS GOING TO RESET THE DB IN MANY CASES BE VERY CAREFUL
Changing the values of innodb_buffer_pool_size and innodb_log_file_size didn't work for me.
Moving ib_logfile0 and ib_logfile1 files didn't help either.
What did help was:
> service mysql stop
Edit my.cfg and add innodb_force_recovery = 1
> service mysql start
> service mysql stop
Comment the innodb_force_recovery = 1 line.
> service mysql start
And voilá. (I should note that I have no idea if this involves any data loss or not)
Although late but putting answer here so that solution that helped me can help someone. I took following steps:
Added more RAM to sever
Decrease the value of innodb-buffer-pool size
Set innodb_log_file_size
Restart mysql
Example of addition to my.cnf:
innodb_buffer_pool_size = 10M
innodb_log_file_size = 1000M
After few unsuccess hours, i checked the disk space... and was full...
I was getting below mysql error log:-
[Note] Plugin 'FEDERATED' is disabled.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Using Linux native AIO
InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
InnoDB: Completed initialization of buffer pool
InnoDB: Fatal error: cannot allocate memory for the buffer pool
[ERROR] Plugin 'InnoDB' init function returned error.
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB
[ERROR] Aborting
[Note] /usr/libexec/mysqld: Shutdown complete
I found out there are two solutions which are:-
1)Set innodb_log_file_size equal to the actual size of the existing InnoDB log files.
To see what size of innoDB log allocated, login mysql and enter following cmd:-
SHOW GLOBAL VARIABLES LIKE 'innodb_log_file_size';
Expected result example:- 5242880
After that, insert that value in my.cnf:-
vi /etc/my.cnf
innodb_log_file_size =5242880
2)Rename or move both the ./ib_logfile0 and ./ib_logfile1 files, and then start the MySQL server.This normally will be located at /var/lib/mysql. After start mysql, it create new innoDB log file and restore possible half-written data from the file of .ibd.
The expexted mysql log example:-
InnoDB: Database physically writes the file full: wait...
161216 9:58:54 InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
161216 9:58:54 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
161216 9:58:54 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...
161216 9:58:54 InnoDB: Waiting for the background threads to start
161216 9:58:55 InnoDB: 5.5.50 started; log sequence number 1589772
161216 9:58:55 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
161216 9:58:55 [Note] - '0.0.0.0' resolves to '0.0.0.0';
161216 9:58:55 [Note] Server socket created on IP: '0.0.0.0'.
161216 9:58:55 [Note] Event Scheduler: Loaded 0 events
161216 9:58:55 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.50' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (GPL) by Remi
References:-
JUSTIN KULESZA (2011). MySQL: Failed Registration of InnoDB as a Storage Engine. Available at: https://spin.atomicobject.com/2011/05/09/mysql-failed-registration-of-innodb-as-a-storage-engine/.
RolandoMySQLDBA (2014). MySQL my.cnf: innodb_log_file_size is missing. Available at: https://dba.stackexchange.com/questions/75688/mysql-my-cnf-innodb-log-file-size-is-missing/158325#158325
Changing the Number or Size of InnoDB Redo Log Files. Available at: http://dev.mysql.com/doc/refman/5.7/en/innodb-data-log-reconfiguration.html
Nothing was working with reinstalls, removes, and others (I had no data to keep, not a fix; more of a data destruction process, big caveat there):
1005 mysql_install_db
1007 /usr/bin/mysqld_safe --datadir='/var/lib/mysql
1008 /usr/bin/mysqld_safe --datadir='/var/lib/mysql' (^z)
1009 bg
1010 mysql
1011 mysql_secure_installation
1012 mysql
1013 mysql -p
And viola; actually usable database.
for me the solution was to change the config to add
innodb_use_native_aio = 0
in mysql config
Just move this log file (ib_logfile0) to some other place for safer side and start the mysql services it worked for me.
I also met the same issue when restore a backup set made via innobackupex to a new instance. Finally ,the root cause is innodb_log_file_size doesn't match original instance that take the backup, and fix steps by steps like below:
Get innodb_log_file_size value from oragin instance via below command:
mysql uroot -ppasswd -NBe "show global variables like 'innodb_log_file_size';"
Modify the /etc/my.cnf of new instance with last get value:
vim /etc/my.cnf
Restart mysqld via :
systemctl restart mysqld

"ERROR 2013 (HY000): Lost connection to MySQL server during query" while dropping database

I have an empty database that I cannot drop. Initially, it contained a table that I couldn't SELECT from. So I DROP'ed all tables from that database and tried to DROP the database without success :
mysql> drop database my_database;
ERROR 2013 (HY000): Lost connection to MySQL server during query
Now I have an empty database that I cannot remove in my server.
I check the mysql error.log, here is the output :
130812 10:02:45 InnoDB: Assertion failure in thread 140409656780544 in file row0mysql.c line 3682
InnoDB: Failing assertion: table
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.
14:02:45 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=3
max_threads=151
thread_count=3
connection_count=3
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346685 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x7fb3ad55d030
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 = 7fb3abb71e60 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x29)[0x7fb3ac1516b9]
/usr/sbin/mysqld(handle_fatal_signal+0x3d8)[0x7fb3ac039318]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7fb3aab96cb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7fb3aa1ff425]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7fb3aa202b8b]
/usr/sbin/mysqld(+0x561acd)[0x7fb3ac192acd]
/usr/sbin/mysqld(+0x542c63)[0x7fb3ac173c63]
/usr/sbin/mysqld(+0x40837f)[0x7fb3ac03937f]
/usr/sbin/mysqld(_Z24plugin_foreach_with_maskP3THDPFcS0_P13st_plugin_intPvEijS3_+0x165)[0x7fb3abf4daa5]
/usr/sbin/mysqld(_Z11mysql_rm_dbP3THDPcbb+0x300)[0x7fb3abf23580]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x203c)[0x7fb3abf418ac]
/usr/sbin/mysqld(+0x31301e)[0x7fb3abf4401e]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19e7)[0x7fb3abf46247]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x105)[0x7fb3abfe0405]
/usr/sbin/mysqld(handle_one_connection+0x50)[0x7fb3abfe0520]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7fb3aab8ee9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fb3aa2bcccd]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7fb388004b90): is an invalid pointer
Connection ID (thread ID): 59
Status: NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
130812 10:02:45 [Note] Plugin 'FEDERATED' is disabled.
130812 10:02:45 InnoDB: The InnoDB memory heap is disabled
130812 10:02:45 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130812 10:02:45 InnoDB: Compressed tables use zlib 1.2.7
130812 10:02:45 InnoDB: Using Linux native AIO
130812 10:02:45 InnoDB: Initializing buffer pool, size = 128.0M
130812 10:02:45 InnoDB: Completed initialization of buffer pool
130812 10:02:45 InnoDB: highest supported file format is Barracuda.
130812 10:02:45 InnoDB: Waiting for the background threads to start
130812 10:02:46 InnoDB: 5.5.32 started; log sequence number 25852489043
130812 10:02:46 InnoDB: !!! innodb_force_recovery is set to 4 !!!
130812 10:02:46 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
130812 10:02:46 [Note] - '127.0.0.1' resolves to '127.0.0.1';
130812 10:02:46 [Note] Server socket created on IP: '127.0.0.1'.
130812 10:02:46 [Note] Event Scheduler: Loaded 0 events
130812 10:02:46 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.32-0ubuntu0.12.10.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
I tried to put the configuration innodb_force_recovery = 4 and restart MySQL but it had no effect at all.
Reinstalling the server is not an option here. It happened on many machines (2 Ubuntu and 2 CentOS), but I cannot reproduce the problem right now.
I believe it has to do with InnoDB table corruption. I too had a similar issue and was able to pinpoint it to a single table. I'm still in the process of correcting the issue through duplicating the table and removing the single record that is bad in my case.
This link helped me significantly:
Recovering InnoDB Table Corruption
Sorry for incomplete answer, but this helped me quite a bit once I found it.