Mysqld changes pid - mysql

I have this really strange problem.
To give you some context, I've have a script that setsup my dev env which contains mysql and percona server and some other things using brew on OSX.
I've re-runned it to do some reconfiguration that got messed up.
But after the re-run mysql won't stay up. Every time I check the mysqld pid I get a different result. I checked the mysql logs and the problem is "mysqld_safe A mysqld process already exists".
So I decided to delete everything related to mysql. I followed the gist from https://gist.github.com/vitorbritto/0555879fe4414d18569d but somehow, the mysql and mysqld process still starts after I restart my laptop.
How is this possible? Has anyone else had this problem? How do I fix it without reinstalling OSX?

So tadman was right. I managed to get my environment to work, I still don't know what that zombie process is, but because it's not affecting me, I don't care.
The problem was that my script was installing the latest version of MySQL and percona-server#5.6. and there is a conflict with InnoDB.
After reinstalling manually everything in the MySQL log there was something along the lines:
[ERROR] Plugin 'InnoDB' init function returned error.
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB
[ERROR] Aborting
After installing MySQL#5.6 everything seems to work as expected.
Thanks tadman.

Related

mysql 8.0 errors - how to run mysql_upgrade

on my dev machine (Ubuntu 20.04, mysql-server 8.0.29-0ubuntu0.20.04.3) my laptop needed to be turned off, and since that mysql does not start.
I've table corruption errors like this:
2022-07-01T12:13:08.666633Z 0 [Warning] [MY-013139] [Server] Cannot load from
mysql.proxies_priv. The table is probably corrupted!
2022-07-01T12:13:08.666748Z 0 [ERROR] [MY-010316] [Server] Fatal error: Could not
read the column 'authentication_string' from table 'mysql.user'. Please perform the
MySQL upgrade procedure.
2022-07-01T12:13:08.666825Z 0 [ERROR] [MY-010952] [Server] The privilege system
failed to initialize correctly. For complete instructions on how to upgrade MySQL to
a new version please see the 'Upgrading MySQL' section from the MySQL manual.
2022-07-01T12:13:08.667187Z 0 [ERROR] [MY-010119] [Server] Aborting
I'd be happy to run mysql_upgrade, however:
The mysql_upgrade client is now deprecated. The actions executed by the upgrade client are now done by the server.
To upgrade, please start the new MySQL binary with the older data directory. Repairing user tables is done automatically. Restart is not required after upgrade.
The upgrade process automatically starts on running a new MySQL binary with an older data directory. To avoid accidental upgrades, please use the --upgrade=NONE option with the MySQL binary. The option --upgrade=FORCE is also provided to run the server upgrade sequence on demand.
It may be possible that the server upgrade fails due to a number of reasons. In that case, the upgrade sequence will run again during the next MySQL server start. If the server upgrade fails repeatedly, the server can be started with the --upgrade=MINIMAL option to start the server without executing the upgrade sequence, thus allowing users to manually rectify the problem.
It seems mysql_upgrade is not supported at this version. What can I do to solve this problem?
Thanks.
https://dev.mysql.com/blog-archive/mysql-8-0-16-mysql_upgrade-is-going-away/ says:
From MySQL 8.0.16 onwards:
Shutdown the server and install the new binaries
Start the server and let the server upgrade the data dictionary tables and system tables.
Read the article I linked to for more details.
You may have to force the MySQL Server to apply the upgrades to tables, by using mysqld --upgrade=FORCE as mentioned in the article. Another user reports having to do that here.

mysql 5.7 to 5.8 upgrade bump into upgrade error "Unknown storage engine 'partition'"

I recently try to upgrade my MySQL server from 5.6 to 8.0. Since we cannot skip major version, I first upgraded 5.6 to 5.7. The upgrade process took a while but it was a success (windows server OS, using zip archive replacement).
However after I replaced 5.7 with 8.0 binaries and start the mysql service, it ran into error that I could not figure out what is wrong:
[System] [MY-011012] [Server] Starting upgrade of data directory.
[ERROR] [MY-013140] [Server] Unknown storage engine 'partition'
[ERROR] [MY-013140] [Server] Can't find file: '.\some_db\some_table.frm' (errno: 0 - No error)
[ERROR] [MY-013137] [Server] Can't find file: '.\some_db\some_table.frm' (OS errno: 0 - No error)
[ERROR] [MY-010348] [Server] Error in reading file .\some_db\some_table.frm
[ERROR] [MY-010758] [Server] Error in creating TABLE_SHARE from some_table.frm file.
I understand server partitions no longer supported in mysql 8, however "some_table" is a table with innodb partitioning. It is using Innodb storage engine. I do not understand why the error says 'partition' storage engine, as well as unable to find the .frm file. anyone encounter similar issue before?
For record, I found the rootcause after going thru mysql documentation again. Looks like the latest mysql 5.7 (5.7.21) does not perform partition upgrade or partition check. I have to perform below command on all affected tables prior to upgrading the server to 8.0.
ALTER TABLE some_db.some_table UPGRADE PARTITIONING;
Once this is done in all tables (very quick process, just metadata changes), the upgrade to 8.0 has no issue whatsoever. The thing that I do not understand is why later version of 5.7.x does not complete this step in mysql_upgrade, and I am not sure what was done in those partitioned tables during mysql_upgrade that took almost 2 days to complete. Maybe MySQL dev team has a reason for it, but to me this just make no sense.

MAMP4 not launching MySQL

Downloaded MAMP4 and installed over MAMP1.9.4 (I know, it's old) with Mac OSX Sierra. Apache server launches, but not MySQL. Warned that previous db was copied to a folder named mysql56 and that on starting up MySQL need to convert db. But MySQL doesn't even start up! Activity Monitor shows no other mysql process going on. MAMP error log:
2017-01-16 12:35:13 47394 [ERROR] InnoDB: auto-extending data file ./ibdata1 is of a different size 640 pages (rounded down to MB) than specified in the .cnf file: initial 768 pages, max 0 (relevant if non-zero) pages!
2017-01-16 12:35:13 47394 [ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data!
2017-01-16 12:35:13 47394 [ERROR] Plugin 'InnoDB' init function returned error.
2017-01-16 12:35:13 47394 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2017-01-16 12:35:13 47394 [ERROR] Unknown/unsupported storage engine: InnoDB
2017-01-16 12:35:13 47394 [ERROR] Aborting
I tried using the same ports as I used with MAMP1.9.4 (80 & 3306), then switched to default. Webserver address was pointing to my directory where I keep my websites. Changed it back to Applications/MAMP/htdocs. Nothing is working. :( Any help would be very much appreciated.
Oh, on my old machine running Snow Leopard, it's all still working with MAMP1.9.4.
Found the solution at http://rat32.com/rat32/2016/11/29/how-to-solve-mysql-not-starting-in-mamp-problem/#comment-175889. Removed all files except folders from Applications/MAMP/db/mysql56. Then restarted. MAMP immediately connected to the MySQL server and prompted me to upgrade my databases. All is well.
I tried other suggestions. The most common was to check for any other MySQL processes that might be running and to kill them via Terminal command. Another suggestion was to rename the files ib_logfile0 and ib_logfile1 in /Library/Application Support/MAMP PRO/db/mysql56, but as I had not initiated MAMP PRO, that folder did not exist. I had renamed the two files in Applications/MAMP/db/mysql56, but that didn't solve the problem. Only when I actually removed those two files and a third, then MAMP was able to connect to the MySQL server.
So it seems silly to answer my own question, but just want to put it here in case others run into the same problem.
Using MAMP 4.1 with Mac OSX Sierra.

Maddening Intermittent Wordpress: Error establishing database connection

Every day or so our Wordpress sites stop responding, the pages begin returning the dreaded 'Error establishing database connection'. There is nothing in the MySQL logs, and I'm at a loss as to what could be causing the issue. We don't have a lot of site visitors, and the machine is a Medium EC2 instance. Anyone have any ideas on how to resolve this?
There's not a whole lot to work with here. But ... I had the same issue with my micro instance. My problem was that the server kept running out of memory and then the mysql server would stop. It would start again when restarting the computer but it was only a matter of time before it would crash again.
Here's what I was getting in my MySQL logs.
151023 6:15:44 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
151023 6:15:44 InnoDB: Completed initialization of buffer pool
151023 6:15:44 InnoDB: Fatal error: cannot allocate memory for the buffer pool
151023 6:15:44 [ERROR] Plugin 'InnoDB' init function returned error.
151023 6:15:44 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
151023 6:15:44 [ERROR] Unknown/unsupported storage engine: InnoDB
151023 6:15:44 [ERROR] Aborting
You might want to check for something similar. I use Ubuntu and the log is at /var/log/mysql/ by default.
I solved the problem by setting up a swap file as per Amazon EC2, mysql aborting start because InnoDB: mmap (x bytes) failed; errno 12. The AWS instances don't come with a swap space setup by default (whereas the install I downloaded from Ubuntu back in the day did). You need to set it up manually. Here's the method -
ssh into your AWS instance. Then:
Run dd if=/dev/zero of=/swapfile bs=1M count=1024
Run mkswap /swapfile
Run swapon /swapfile
Add this line /swapfile swap swap defaults 0 0 to /etc/fstab
Read the linked question for more details. Hope that helps!
I had a similar issue with intermittent crashing of MySQL. It turned out to be Apache configurations. Bots were brute forcing the site and eventually caused Apache to crash (check your logs: $ cat /var/log/apache2/access.log). Apache automatically restarts, but there isn't enough spare memory to restart MySQL too, hence the Database Connection error. The short fix is to reduce the number of RequestWorkers in Apache to better fit the amount of RAM you have.
You can run a diagnostic on your apache configuration using Apache2Buddy. It'll calculate how many Apache Workers you can run given the amount of RAM you have and how big your application is:
$ curl -L http://apache2buddy.pl/ | perl
It's probably going to recommend changing MaxRequestWorkers (or MaxClients on older Apache systems) in your MPM-Prefork configurations. That file is at /etc/apache2/mods-available/mpm_prefork.conf on my system. After changing the value to what Apache2Buddy recommends, just restart Apache and you should be good to go.
I wrote an article on this situation if you want a deeper explanation, a method to stress test, or ideas on how to block some of the bot traffic: http://brunzino.github.io/blog/2016/05/21/solution-how-to-debug-intermittent-error-establishing-database-connection/
When I tried to install local wordpress the same error
error establishing database connection
occurred because I forget to stop the SQL and Apache which was started in xampp. I stopped it and reinstalled the wordpress for Windows and it worked.

InnoDB: Unable to lock ./ibdata1 error: 35

I'm trying to start MySQL in safe mode but the log file just keeps spitting out:
[ERROR] InnoDB: Unable to lock ./ibdata1 error: 35
[Note] InnoDB: Check that you do not already have another mysqld process using the same InnoDB data or log files.
Notes:
I've stopped all mysql processes and have checked using the ps command
I've read this having repeated trouble with MySQL and Snow Leopard - Unable to lock ./ibdata1, error: 35
Just had this issue with MAMP Pro. Couldn't stop or start MySQL. Typed ps aux | grep mysql, then kill [process id] for each line. Then I could successfully launch MySQL again from MAMP Pro.
Strange error codes, both from MySQL and the operating system, can be explained by running a shell command perror which is a part of MySQL distribution. On Linux, for example, perror 35 returns OS error code 35: Resource deadlock avoided. I do not have an OSX system handy to test, but from this:
http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/sys/errno.h
I gather that error 35 is "Resource temporarily unavailable", meaning that some other process (possibly another instance of mysqld?) has already locked the file.
To debug, first I would check if there is another MySQL process running by chance (looks like you already have), and if not, reboot for good measure to make sure there are no strange stale file locks, and then try again.
Somebody has run into this error before, and found a solution:
mysql_install_db, error: 35, on a Mac OS X 10.9.1
I had a similar issue after updating MAMP from 4.x to 5.x
Unfortunately the only way that I could manage to resolve this was by manually removing all of my database files (moving them into another directory) then starting MySQL via MAMP; this seemed to work.
The files in question (for me) were in:
/Library/Application Support/appsolute/MAMP PRO/db/mysql57
All of the files in this directory (except the mysql directory) need moving somewhere else. I was then able to start MySQL.
I realise this isn't a very useful answer for most situations, but if this is a local development environment (like MAMP, as in my case) then I think losing the local databases is probably acceptable.