I've been working with a MAMP installation for several weeks now, and when I started it up today it would not start. No mysql process was running so I checked the error log which shows the following when I start the server:
130826 14:19:55 mysqld_safe Starting mysqld daemon with databases from /Applications/MAMP/db/mysql
130826 14:19:55 [Warning] You have forced lower_case_table_names to 0 through a command-line option, even though your file system '/Applications/MAMP/db/mysql/' is case insensitive. This means that you can corrupt a MyISAM table by accessing it with different cases. You should consider changing lower_case_table_names to 1 or 2
130826 14:19:55 [Warning] One can only use the --user switch if running as root
130826 14:19:55 [Note] Plugin 'FEDERATED' is disabled.
130826 14:19:55 InnoDB: The InnoDB memory heap is disabled
130826 14:19:55 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130826 14:19:55 InnoDB: Compressed tables use zlib 1.2.3
130826 14:19:55 InnoDB: Initializing buffer pool, size = 128.0M
130826 14:19:55 InnoDB: Completed initialization of buffer pool
130826 14:19:55 InnoDB: highest supported file format is Barracuda.
130826 14:19:55 InnoDB: Waiting for the background threads to start
130826 14:19:56 InnoDB: 1.1.8 started; log sequence number 4057202289
/Applications/MAMP/Library/bin/mysqld: File './mysql-bin.000025' not found (Errcode: 2)
130826 14:19:56 [ERROR] Failed to open log (file './mysql-bin.000025', errno 2)
130826 14:19:56 [ERROR] Could not open log file
130826 14:19:56 [ERROR] Can't init tc log
130826 14:19:56 [ERROR] Aborting
130826 14:19:56 InnoDB: Starting shutdown...
130826 14:19:57 InnoDB: Shutdown completed; log sequence number 4057202289
130826 14:19:57 [Note] /Applications/MAMP/Library/bin/mysqld: Shutdown complete
130826 14:19:57 mysqld_safe mysqld from pid file /Applications/MAMP/tmp/mysql/mysql.pid ended
So it's clear that a certain log file cannot be found, but I don't know why that happened, or how to fix it.
It seems that one of the binary log files, Applications/MAMP/db/mysql/mysql-bin.000025, got corrupted or deleted (it was no longer there, and I did not manually delete it).
After doing some research and finding this post, I was able to fix this by navigating to /Applications/MAMP/db/mysql and manually editing
mysql-bin.index to no longer include the missing log file.
I'm still a little confused what led to this issue originally though, since I shut down my MAMP server normally and never touched the binary log files...
For MySQL 8.0 the file mysql-bin.index changed to binlog.index. In this case a deletion and restarting MySQL solves the problem.
For me, from /var/lib/mysql/ running cat mysql-logbin.index showed binary (gibberish).
At first I thought this meant that it was just a binary file, but that file is not supposed to be binary, as far as I know it's supposed to contain something like a single line of text indicating the name of the current logbin file.
I renamed it to mysql-logbin.index.old and tried starting the service and it started successfully, recreating that file.
Related
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.
I was merrily installing wordpress with MAMP pro when my Mac crashed. Now I cannot start MySql. Most stuff I read online tells me to throw some terminal commands at it, trying to kill the process.
killall -9 mysqld
But terminal report "No matching processes belonging to you were found"
So I have had a look in the log and can see this from the time of the first restart attempt after the crash
150506 21:11:33 mysqld_safe Starting mysqld daemon with databases from /Library/Application Support/appsolute/MAMP PRO/db/mysql
150506 21:11:33 [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.
150506 21:11:33 [Warning] Setting lower_case_table_names=2 because file system for /Library/Application Support/appsolute/MAMP PRO/db/mysql/ is case insensitive
150506 21:11:33 [Note] Plugin 'FEDERATED' is disabled.
150506 21:11:33 InnoDB: The InnoDB memory heap is disabled
150506 21:11:33 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150506 21:11:33 InnoDB: Compressed tables use zlib 1.2.3
150506 21:11:33 InnoDB: Initializing buffer pool, size = 128.0M
150506 21:11:33 InnoDB: Completed initialization of buffer pool
InnoDB: The first specified data file ./ibdata1 did not exist:
InnoDB: a new database to be created!
150506 21:11:33 InnoDB: Setting file ./ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
150506 21:11:33 InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
150506 21:11:33 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...
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: 127 rollback segment(s) active.
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
150506 21:11:34 InnoDB: Waiting for the background threads to start
150506 21:11:35 InnoDB: 5.5.42 started; log sequence number 0
150506 21:11:35 [Note] Event Scheduler: Loaded 0 events
150506 21:11:35 [Note] /Applications/MAMP/Library/bin/mysqld: ready for connections.
Version: '5.5.42' socket: '/Applications/MAMP/tmp/mysql/mysql.sock' port: 0 Source distribution
150506 21:16:44 [Note] /Applications/MAMP/Library/bin/mysqld: Normal shutdown
So Table Space size error.. I am very much a front end guy and have no idea where to begin with this...??
Help please, I really can't afford to loose the last week of work.
Thanks you
As you pointed out InnoDB tablespace is corrupt, so InnoDB fails to start.
InnoDB can tolerate some errors if you start it with option innodb_force_recovery. Try values from 1 to 6 until MySQL starts.
If you're lucky and MySQL starts with innodb_force_recovery then dump all tables into an sql file with mysqldump and re-create MySQL database from scratch. I.e. move existing files to some safe place, start mysql_install_db, change file permissions and start MySQL. Then load the database back.
If you're less lucky and MySQL doesn't start with innodb_force_recovery=6 then check how to Recover Corrupt MySQL Database .
And to avoid this experience in future use XtraBackup for Mac OS to take backups.
Please see her:
MAMP PRO crashes; MySQL will not start on reboot
Thanks for the heads up with Xtrabackup for MacOS, one to keep an eye on that.
I got the problem with starting my mysql server, it was working fine until I copied the "ready" mysql configuration file (/usr/local/share/mysql/my-huge.cnf) to the /etc/my.cnf, then I restarted my mysql server and unfortunatelly it stopped , instead of restarted.
I dont have any console errors, but this appear in my /var/db/mysql/hostname.pid file:
120312 17:57:43 mysqld_safe mysqld from pid file /var/db/mysql/hostname.pid ended
120312 17:58:09 mysqld_safe Starting mysqld daemon with databases from /var/db/mysql
120312 17:58:09 InnoDB: The InnoDB memory heap is disabled
120312 17:58:09 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120312 17:58:09 InnoDB: Compressed tables use zlib 1.2.3
120312 17:58:09 InnoDB: Initializing buffer pool, size = 128.0M
120312 17:58:09 InnoDB: Completed initialization of buffer pool
120312 17:58:09 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!
120312 17:58:09 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...
120312 17:58:09 InnoDB: Assertion failure in thread 34387018176 in file fsp0fsp.c line 2040
InnoDB: Failing assertion: inode
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.
17:58:09 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=8388608
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 = 338444 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
120312 17:58:09 mysqld_safe mysqld from pid file /var/db/mysql/hostname.pid ended
Whats wrong?
Your ibdata file is the wrong size.
More exactly, your ibdata file is a different file size from what you have specified in the new my.cnf file. Check the values for ibdata (and bin log files, while you're at it) in the old and new versions of the my.cnf files - you'll see they're different.
You will have to use the old values to get the db to start; check other innodb values in there as well: make all the significant ones the same (you'll change them back after you get it working). Once you've got it started, dump your dbs and then shutdown mysqld. Edit the my.cnf file, delete ibdata, restart the db, and re-import your dbs. Presto - fixed.
It looks like your my.cnf file is bad or has some bad entries in it. Do you have a copy of the my.cnf you replaced with my-huge.cnf? I would try running a diff on the two files and see what is going on.
Maybe the Innodb logs are corrupt. You should backup renaming this logs and restart mysqld again, then mysqld creates the new logs and hopefully restart correctly.
Yesterday I was working using MySQL installed on my computer.
I downloaded xampp, so I have I changed on my.cnf file the path to the socket:
/opt/lampp/var/mysql/mysql.sock
That file was just there. Today I wanted to keep working on it, and I found that file is not there anymore, so I am getting the following error while I am starting mysql server:
ERROR 2002 (HY000):
Can't connect to local MySQL server through socket
'/opt/lampp/var/mysql/mysql.sock' (2)
Here are some tests I made:
mujeresponja#ubuntu:~$ ps -fea | grep mysqld
1000 15707 15615 0 16:28 pts/1 00:00:00 grep --color=auto mysqld
mujeresponja#ubuntu:~$ ps -fea | grep mysql
1000 15709 15615 0 16:29 pts/1 00:00:00 grep --color=auto mysql
As a possible solution I uninstalled xampp and reinstall it, and also a new MySQL server, just in case. Anyway, that file is not there anymore.
EDIT
Where the mysql.sock should be, instead there are two files mysql_upgrade_info (Which contains just 5.5.8) and another binary file called ubuntu.err:
mujeresponja#ubuntu:/opt/lampp/var/mysql$ sudo cat ubuntu.err
110403 17:28:52 mysqld_safe Starting mysqld daemon with databases from /opt/lampp/var/mysql
110403 17:28:52 [Note] Plugin 'FEDERATED' is disabled.
/opt/lampp/sbin/mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
110403 17:28:52 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use InnoDB's own implementation
InnoDB: Compressed tables use zlib 1.2.3
110403 17:28:52 InnoDB: Initializing buffer pool, size = 16.0M
110403 17:28:52 InnoDB: Completed initialization of buffer pool
110403 17:28:52 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name /opt/lampp/var/mysql/ibdata1
InnoDB: File operation call: 'create'.
InnoDB: Cannot continue operation.
110403 17:28:52 mysqld_safe mysqld from pid file /opt/lampp/var/mysql/ubuntu.pid ended
110403 17:29:22 mysqld_safe Starting mysqld daemon with databases from /opt/lampp/var/mysql
110403 17:29:22 [Note] Plugin 'FEDERATED' is disabled.
/opt/lampp/sbin/mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
110403 17:29:22 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use InnoDB's own implementation
InnoDB: Compressed tables use zlib 1.2.3
110403 17:29:22 InnoDB: Initializing buffer pool, size = 16.0M
110403 17:29:22 InnoDB: Completed initialization of buffer pool
110403 17:29:22 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name /opt/lampp/var/mysql/ibdata1
InnoDB: File operation call: 'create'.
InnoDB: Cannot continue operation.
110403 17:29:22 mysqld_safe mysqld from pid file /opt/lampp/var/mysql/ubuntu.pid ended
(Sorry, I don't know how to show terminal messages in an appropiuate way)
Can anybody help me on this? Thanks in advance!
You can locate the actual socket file and create a symbolic link leading to it as follows:
# check path to socket from mysql settings
mysqladmin | grep d.sock
# create a symbolic link
ln -s path_to_mysql_socket /opt/lampp/var/mysql/mysql.sock
Although the test you did is a bit garbled, Im going to assume that the test just prove mysql isnt running.
Depending on how the mysql configured itself there should be a startup file somewhere, usually around the /etc/rc.* directories, and you would need to run the rc.mysql start (or it could be a S<nn>MySQL in an rc3.d directory for example
I didn't find a certain reason for my problem.
I just unisntalled and reinstalled, and then everything went Ok.
That is not a real solution, but it worked. Good luck
I came in the same situation when I made a grant to *.* to other user. Mysql tried to give permissions over the mysql database and that provoked the disaster: instantly, the mysql.sock file disappeared.
this happened with the version 5.6
I had the same problem with you, and I found some useful information:
2015-08-14 10:51:17 30934 [ERROR] InnoDB: Unable to lock /opt/lampp/var/mysql/ibdata1, error: 11
2015-08-14 10:51:17 30934 [Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
So, I rebooted the computer and restarted XAMPP, and the problem was resolved.
I installed mysql version 5.5.9 on my mac and I tried to start it using this command :
sudo /usr/local/mysql/support-files/mysql.server start
mysql didn't start with this command. I checked the localhost.err file in data directory and it was like this :
110227 22:51:14 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/data
110227 22:51:14 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive
110227 22:51:14 [Note] Plugin 'FEDERATED' is disabled.
/usr/local/mysql/bin/mysqld: Table 'mysql.plugin' doesn't exist
110227 22:51:14 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
110227 22:51:14 InnoDB: The InnoDB memory heap is disabled
110227 22:51:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins
110227 22:51:14 InnoDB: Compressed tables use zlib 1.2.3
110227 22:51:14 InnoDB: Initializing buffer pool, size = 128.0M
110227 22:51:14 InnoDB: Completed initialization of buffer pool
110227 22:51:14 InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
110227 22:51:14 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...
110227 22:51:15 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!
110227 22:51:15 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...
110227 22:51:15 InnoDB: Waiting for the background threads to start
110227 22:51:16 InnoDB: 1.1.5 started; log sequence number 1595916
110227 22:51:16 [ERROR] /usr/local/mysql/bin/mysqld: unknown option '--skip-locking'
110227 22:51:16 [ERROR] Aborting
110227 22:51:16 InnoDB: Starting shutdown...
110227 22:51:16 InnoDB: Shutdown completed; log sequence number 1595916
110227 22:51:16 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete
110227 22:51:16 mysqld_safe mysqld from pid file /usr/local/mysql/data/localhost.pid ended
I deleted the two ib_log files, I changed my.cnf file and I got nothing.
--skip-locking was removed in MySQL 5.5. See here.
Edit your my.cnf file and change "skip-locking" to "skip-external-locking".
I had this same issue on mac, I have other MySQL instances installed from MAMP and XAMP.
Do a locate in terminal: locate my.cnf
Take note of any other my.cnf files not located in your AMPPS directory.
I found that when i removed /private/etc/my.cnf, MySQL started with no issues.
sudo mv /private/etc/my.cnf /private/etc/my-old.cnf
1 ) in the terminal , launch command : mysql_upgrade ( to create the tables that are non existent )
2 ) edit /etc/my.cnf , comment out the --skip-locking statement
that's all , happy SQLing