PHPmyAdmin – Update from PHP 5 to PHP 7.0 and Resolve Two Server Logins Issue

You need to restart mysql from the Linux command line like this:

service mysql restart --skip-grant-tables --skip-networking

If you are using Windows, add the two options in the mysqld section of my.ini:

[mysqld]
skip-grant-tables
skip-networking

and then run

net stop mysql (wait 10 seconds)
net start mysql

This will allow immedidate login without authentication and without any remoye connection sneaking in on you.

INSERT INTO mysql.user SET
Host='localhost',
User='mynewuser',
Password=PASSWORD('whateverpassword'),
Select_priv='Y',
Insert_priv='Y',
Update_priv='Y',
Delete_priv='Y',
Create_priv='Y',
Drop_priv='Y',
Reload_priv='Y',
Shutdown_priv='Y',
Process_priv='Y',
File_priv='Y',
Grant_priv='Y',
References_priv='Y',
Index_priv='Y',
Alter_priv='Y',
Show_db_priv='Y',
Super_priv='Y',
Create_tmp_table_priv='Y',
Lock_tables_priv='Y',
Execute_priv='Y',
Repl_slave_priv='Y',
Repl_client_priv='Y';

then

service mysql restart

At least you will have a localhost user named mynewuser with enough privileges to login.

You should then run this query:

select user,host,password from mysql.user;

and see if any new users were added by a hacker. If you see any remote users that should not be there, you can remove them with:

DELETE FROM mysql.user WHERE ...;
FLUSH PRIVILEGES;

If you are using Windows, please remember to remove skip-grants-tables and skip-networking from my.ini, then stop and start mysql service.

CAVEAT

Make a backup of /var/lib/mysql/mysql before you do anything.

UPDATE 2011-09-26 10:41 EDT

If the INSERT INTO mysql.user query does not work, it simply means the query is not compatible with the version of mysql I took this example from.

In order to know the correct INSERT query to user, please run this query:

desc mysql.user;

You will see all columns with the type ENUM('Y','N') for each privilege. Adjust the INSERT query to match all columns and then run that INSERT.

To get the exact columns to set to Y for all privileges, user this query:

SELECT CONCAT('SET ... ',GROUP_CONCAT(CONCAT(column_name,'=''Y'''),';'))
FROM information_schema.columns
WHERE table_schema='mysql'
AND table_name='user'
AND column_type='enum(''N'',''Y'')'
ORDER BY ORDINAL_POSITION\G

This will present to columns to set regardless of the version of MySQL you are using.

Please review my answer to this recent question. I believe the circumstances are identical.

Do not change your MySQL configuration at this point, as MySQL is not the problem -- it's only a symptom of the problem... which is that you appear to have a system with a small amount of memory and zero swap space.

Your server is not crashing "because" memory can't be allocated for the buffer pool. Your server is crashing... and then is unable to subsequently restart due to the unavailability of system memory. All of the memory configured for the InnoDB buffer pool is requested from the system at mysql startup.

When you see this log message...

120926 08:00:51 mysqld_safe Number of processes running now: 0

...your server has already died. If it hasn't logged anything prior to this, it's not going to log anything about the first crash. The subsequent logs are from after the automatic attempt to restart.

Check your syslog and you should find messages where the kernel went looking for processes to kill due to an extreme out-of-memory condition.

Step 1 would probably be to add some swap space and/or allocating RAM if at all possible.

If that isn't possible, you might actually consider decreasing the innodb-buffer-pool size in your configuration. (I never thought I'd actually hear myself say that). As long as your database is small and your traffic is light, you may not need a buffer pool that large... and since the InnoDB Buffer Pool memory is all allocated at startup whether it's needed or not, this would free up some of your system's memory for whatever else is demanding it. (The 75% to 80%-of-total-RAM recommendation for sizing the buffer pool is only true if the whole server is dedicated to MySQL.)

Step 2 will be to review Apache's forking model and what you might need to do differently in the configuration to prevent it from overwhelming your server. It is pretty likely that uncontrolled growth in quantity or memory requirements of the Apache child processes is starting a cascade of events, resulting in the kernel killing MySQL to try to avoid a complete crash of the entire server.

Depending on how much flexibility you have, you might even consider two separate virtual machines for Apache and MySQL.