I've got ~ 30 sites worth of databases data on a volume on my server in the following directory /mnt/volume0/var/lib/mysql
The directory contains a 6.2G ibdata1 file and directories containing .frm files for each of the websites.
I'm trying to get dumps of the databases so I can move them to another server, however accessing mysql only shows the default databases (as datadir in /etc/mysql/mysql.conf.d/mysqld.cnf is set to /var/lib/mysql)
I've tried changing the datadir in /etc/mysql/mysql.conf.d/mysqld.cnf to /mnt/volume0/var/lib/mysql but mysql fails to start.
It was complaining about "failed to set datadir" which I fixed by running chown mysql:mysql mysql/ -R on /mnt/volume0/var/lib/mysql but now it's complaining about Failed password for root from xxx.xx.xxx.xx port 19192 ssh2
Any help is greatly appriciated!
Thanks
You can try to reset your password
mysqld_safe --skip-grant-tables
if you have here an error, then you have a bigger problem
mysql --user=root mysql
update user set Password=PASSWORD('your new password') where user='root';
flush privileges;
exit;
I ended up solving this issue by replacing the contents of /var/lib/mysql/ on my local machine with the contents of /mnt/volume0/var/lib/mysql/ (from the server).
I then encountered an error whilst trying to start MySQL Table 'performance_schema.session_variables' doesn't exist which I solved by upgrading MySQL on my local machine and restarting: https://stackoverflow.com/a/20262826/8231049
Now I'm able to dump the databases from my local machine :)
Edit: Can't accept my answer before waiting 2 days. Will do then.
Related
I've a Galera Cluster Installation with three nodes. As requirement my MariaDB installation must be in different path that default, and user cannot be mysql. So I've moved all mysql data path and I've created a new user and group to manage the mysql service.
MariaDB service is working fine, but I've noticed that a mysql-slow.log has been created with permissions to mysql:root for a third program installation that monitor queries. Opening mysql.err I've found the following error:
[ERROR] Could not use mysql-slow.log for logging (error 13).Turning logging off for the whole duration of the MySQL server process. To turn it on again: fix the cause, shutdown the MySQL server and restart it.
So I've made chown myuser:mygroup mysql-slow.log and restart the service, but there still having same permissions. Then I've set in my.cnf the slow_query_log=1, in order to try that the myuser create the file at start, but the wrong permission still there also after remove the files and restart.
All the files, in my mariadb data path, are not managed by mysql:mysql user, in my installation are managed by myuser:mygroup so when the mysql-slow.log is created the permissions mysql:root are assigned so I have not permission to write there with myuser:mygroup and if I assign them manually there is not effect because are override with mysql:root after mysql restart.
Somebody knows if there are any way to set by default the user and group owners of the mysql-slow.log file when created?
Thanks.
Regards,
Sergio
Fix the permissions:
chmod 666 mysql-slow.log
See what your script is doing; perhaps it needs fixing, too.
I have a LAMP stack setup. Occasionally, I get the following error message when I open some page from the browser:
Error creating the connection!: SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
I think the server was configured correctly. The problem happens about every two months. Every time when I reboot the Linux server, or restart mysql, the problem was gone. I want to fix this problem permanently. Can anyone give me some idea?
Much appreciated.
EDIT
The problem occurs again and I checked the mysqld.sock file, it was not there. Do you have any idea how to fix the problem? – Ryan Jul 23 at 16:24
If your file my.cnf (usually in the /etc/mysql/ folder) is correctly configured with
socket=/var/run/mysqld/mysqld.sock
modified
#bind-address = 127.0.0.1
to
bind-address = localhost
you can check if mysql is running with the following command:
mysqladmin -u root -p status
try changing your permission to mysql folder. If you are working locally, you can try:
sudo chmod -R 755 /var/run/mysqld/
And then restart the mysql.
Good luck.
Could it be the log file getting too large and rebooting flushes it. See this in docs on server maintenance and logfiles. Also see discussion at digital ocean. Appears to be confirmed by discussion at serverfault
You could try change the permission of your MySQL sock file like this:
chmod 777 '/var/run/mysqld/mysqld.sock'
It is a test to see if whatever user mysqld is using, it will acess your mysqld.sock file. So, reboot your MySQL and change the permission of mysqld.sock. And you need to check that if your sock folder can be accessed through any mysqld process.
If the mysqld.sock file doesn't exist, that is to say your config file is not correct.Check your mysql config file in /etc/mysql/my.conf, find the socket config just as Vanya Avchyan says.
I think the socket config is /var/run/mysqld/mysqld.sock, but in fact your mysql process runs in other place sock file.
I used to met that problem, the real socket file exists in /tmp/mysqld.sock.
So run
sudo find / -name 'mysqld.sock'
to find the real sock file and change my.conf to this real place, restart your mysql. May have work.
I installed MySQL community server 5.7.10 using binary zip. I extracted the zip in c:\mysql and created the data folder in c:\mysql\data. I created the config file as my.ini and placed it in c:\mysql (root folder of extracted zip). Below is the content of the my.ini file
# set basedir to your installation path
basedir=C:\mysql
# set datadir to the location of your data directory
datadir=C:\mysql\data
I'm trying to start MySQL using mysqld --console, but the process is aborted with the below error.
2015-12-29T18:04:01.141930Z 0 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.user' doesn't exist
2015-12-29T18:04:01.141930Z 0 [ERROR] Aborting
Any help on this will be appreciated.
You have to initialize the data directory by running the following command
mysqld --initialize [with random root password]
mysqld --initialize-insecure [with blank root password]
The mysql_install_db script also needs the datadir parameter:
mysql_install_db --user=root --datadir=$db_datapath
On Maria DB you use the install script mysql_install_db to install and initialize. In my case I use an environment variable for the data path. Not only does mysqld need to know where the data is (specified via commandline), but so does the install script.
mysqld --initialize to initialize the data directory then mysqld &
If you had already launched mysqld& without mysqld --initialize you might have to delete all files in your data directory
You can also modify /etc/my.cnf to add a custom path to your data directory like this :
[mysqld]
...
datadir=/path/to/directory
As suggested above, i had similar issue with mysql-5.7.18, i did this in this way
1. Executed this command from "MYSQL_HOME\bin\mysqld.exe --initialize-insecure"
2. then started "MYSQL_HOME\bin\mysqld.exe"
3. Connect workbench to this localhost:3306 with username 'root'
4. then executed this query "SET PASSWORD FOR 'root'#'localhost' = 'root';"
password was also updated successfully.
I had the same problem. For some reason --initialize did not work.
After about 5 hours of trial and error with different parameters, configs and commands I found out that the problem was caused by the file system.
I wanted to run a database on a large USB HDD drive. Drives larger than 2 TB are GPT partitioned! Here is a bug report with a solution:
https://bugs.mysql.com/bug.php?id=28913
In short words: Add the following line to your my.ini:
innodb_flush_method=normal
I had this problem with mysql 5.7 on Windows.
My problem was caused by an incorrect db restore.
When I dumed the db it also picked up the system mysql tables because I added a space after -p as mentioned here: mysqldump is dumping undesired system tables
Launching the docker instance would work, then I'd restore (and corrupt) the db and it would still keep running, but after restarting it would Exit with error code 1.
The solution was to dump and restore properly without the system tables.
I face the same issue with version Mysql 5.7.33 when the server has rebooted. I fix it by copy other server user files scp /var/lib/mysql/mysql/user.* root#dest:/var/lib/mysql/mysql.
After upgading MySQL to newer version I have error when I want to connect to server:
ERROR 1524 (HY000): Plugin '0' is not loaded
Any ideas?
This looks like a Bug in MySQL as Bug #60432
Modifying mysql.user table can deny users from logging in . Which states that:
If database manager accidentally (or deliberately) modifies mysql.user
table by adding any column in position lower (or equal) than
"max_user_connections", then after reloading privileges no one is
allowed to log in.
Workaround: Undoing the modification made in user table.
Run following commands
sudo /etc/init.d/mysql stop
sudo mkdir -p /var/run/mysqld; sudo chown mysql /var/run/mysqld
sudo mysqld_safe --skip-grant-tables &
and then press enter
now your password get reset, you can change your password again
This works for me
This is indeed a bug with MySQL and a changed user table structure. Unfortunately, if you don't know what changed, you can't change it back. Also, if you cannot login, you cannot fix anything either.
I fixed this as follows. Please be careful with these instructions as they may not work entirely for your setup and you could lose your data if this goes wrong. Don't blame me if it does!
1. Back-up old data dir
Back-up your old data dir somewhere. This allows you to restore the tables at the end. To find out where your data dir is, you can try to initialise mysql. It will give you an error because the data dir already exists:
mysqld initialize
Output:
mysqld: Can't create directory '/usr/local/mysql/data/' (Errcode: 13 - Permission denied)
Now backup your data dir somewhere:
cp -r /usr/local/mysql/data ~/backup-dir/
2. Re-initialize MySQL
With your data dir safely backed up, remove it and re-initialize mysql. It will give you a new temporary password which you can change later.
rm -rf /usr/local/mysql/data
mysqld initialise
The output will give you a new password for 'root'. If you get permission errors, use sudo (not sure about the drawbacks).
Start the server using mysqld_safe to be sure it works the first time:
mysqld_safe
Optionally, change the root password by logging in to mysql and running alter table:
mysql -u root -p
<enter password>
ALTER USER 'root'#'localhost' IDENTIFIED BY 'New Password';
3.Restore data
Stop the mysql server
mysqld stop
Copy all the backup files to the new data dir (run this for every db you need to restore):
cp -r ~/backup-dir/data/<dbname> /usr/local/mysql/data/
For MyISAM tables, this is enough. If you have InnoDB tables, you also need to copy the InnoDB table space from your backup:
cp ~/backup-dir/data/ibdata* /usr/local/mysql/data/
Then, fix permissions (look at the files already present in /usr/local/mysql/data for the right permissions, mine were 'mysql' for both user and group):
chown -R mysql:mysql /usr/local/mysql/data/*
Start the mysql server
mysqld start
All done! You should be able to login again and your tables should be back containing all data, too.
I found a way to fix this...
change the configuration file --my.cnf (usually in /etc/my.cnf)
add "skip-grant-tables" below [mysqld]
now you can login the mysql! backup your database and re-install mysql
I think this will completely repair the problems.
(Plugin 0 is not loaded, i found i cant backup the database then..so you need to add something in mysql.cnf)
I restarted my MySql server and Apache web server and it worked.
I installed LAMP on Ubuntu 11.04 and copy project from Windows.
PHP directory (/ci/) to var/www/
and
MySQL project directory (/ci/) to var/lib/mysql/
Full text of error that i get:
A Database Error Occurred
Error Number: 1017
Can't find file: './ci/users.frm' (errno: 13)
SELECT COUNT(*) AS `numrows` FROM (`users`) WHERE `email` = 'admin#localsite.com'
I googled that its permission problem, but don't know what do next.
Log from /var/log/mysql/error.log:
110622 19:27:21 [ERROR] /usr/sbin/mysqld: Can't find file: './ci/users.frm' (errno: 13)
Permissions problem meaning the permissions on the file. MySQL probably can't read it. Just change the owner and group to mysql and it should work.
chown mysql:mysql /var/lib/mysql/ci/*
As well as the files being readable by the MySQL user, the directory containing the .MYI files needs to be read, write and executable by the MySQL user. On my system this was achieved by:
chown -R mysql:mysql /var/lib/mysql/dbname
chmod -R 660 /var/lib/mysql/dbname
chown mysql:mysql /var/lib/mysql/dbname
chmod 700 /var/lib/mysql/dbname
This is an old topic, but I didn't find anything that worked for me so for anyone running into the same problem, yet the above file permission suggestions still don't change the "Can't find file" errors, here's what worked for me and my particular issue.
I was doing a rescue from one CentOS server to another using a recovery image, which had a different OS than the original OS and the original filesystem was mounted on a temporary dir. While I had access to the original /var/lib/mysql files, I didn't have access to the mysql admin or dump utilities, which requires the server to be running anyway (it's not automatically included when doing a recovery from a read-only image). Backups were a week old and I wanted to see if I could get the most recent data possible.
Changing the standard file permissions on these still kept giving "Can't find file" for nearly all of the database tables, however I could see that the tables were there. Turns out it was related to SELinux context on the files I had moved over using rysnc. All of the rescued dirs and files looked like this:
$ ls -alZ
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_dev
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_local
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_production
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_staging
The -Z flag notes the security context of files and dirs. Notice the unconfined_u and admin_home_t context. These are different from what they should be:
drwx------. mysql mysql system_u:object_r:mysqld_db_t:s0 mysql
Changing these database files to the proper context solved the problem and gave proper access to mysqld using the chcon command:
$ chcon -R -u system_u -t mysqld_db_t somedb_*
This changed all my custom databases to the proper SELinux context and the files could now be recognized by mysqld. I recommend running the chcon commad while the database server is not active, just as a precaution.
Hope that helps someone running into the same problem I had! Of course, you can turn off SELinux temporarily to test if this is fact this issue, but I didn't want turning off SELinux as a permanent solution.
I followed this steps:
Stop the mysql service.
Modify the my.cnf line datadir to my custom location.
Deleted all the files ib_data* , ib_logfile* in our new custom location
Change the permissions of the entire folder with your sentence:
chown mysql:mysql -R /custom_location/mysql/*
Start again the mysql service.
It works!!
Thanks
This error also occurs if the table is not in the database; so if you changed permissions of the directory and are still running into issues check your database and make sure the table is there.
So let's say you got an error like the OP:
Can't find file: './ci/users.frm'
ci is the database name
users is the table name
So in this case if you changed permissions and still had this issue you would verify that the users table is in the ci database.
#Brent Baisley It does work in XAMPP for Linux, but the location is different.
I did upgrade the Kernel today to fix the new Linux “Dirty Cow” Vulnerability (CVE-2016-5195). After the reboot I got the 'frm' permission error too.
So, if you get the following error:
Can't find file: 'yourtablename.frm' (errno: 13 - Permission denied) SQL query :...
You can do:
chown mysql:mysql /opt/lampp/var/mysql/yourDBname/*.frm
This will resolve your issue.
If you'd like to check, if your permission to any of the files has been modified before you execute the permission change, do:
ls -l /opt/lampp/var/mysql/yourDBname/*.frm
Hope that helps someone.
If you have failed RENAME TABLE statement, it could leave MySQL metadata in bad state. The solution is to recreate schema or to recreate table.