Recovering a MySQL database from a non-booting Raspbian system SD card - mysql

I have a Raspberry Pi that does not boot anymore on which I have an hosted website.
My plan is to reinstall the whole Raspbian system on it, but before that, I would like to recover my Wordpress website that is installed on it. So I managed to mount the SD on my laptop (under Manjaro Linux), from which I have to recover the website folder that I already manage to copy (/var/www/html/mywebsite).
The problem concerns the SQL database linked to this website that is stored into /var/lib/mysql/mywebsitedb. I would like to save it as a .sql file. But I cannot use the mysqldump function that I could use for it if I was able to run the Raspberry Pi and ssh access.
The option I found was to clone the database from the folder of the SD card /run/media/$USER/rootfs/var/www/html/mywebsite, to my laptop repository /var/lib/mysql this way :
rsync -av /run/media/$USER/rootfs/var/lib/mysql/mywebsitedb /var/lib/mysql
sudo chown --recursive mysql:mysql /var/lib/mysql/mywebsitedb # Giving access to mysql
I did it and it worked without any problem. When I do,
USE mywebsitedb;
SHOW TABLES;
I have no problem to see the tables. But the problem comes when I try to extract mywebsitedb with mysqldump this way :
mysqldump -u root -p mywebsitedb > /home/$USER/mywebsitedb.sql
I receive the following error message :
mysqldump: Got error: 1932: "Table 'mywebsitedb.mywebsite_commentmeta' doesn't exist in engine" when using LOCK TABLES
And I did not find a solution to this problem until now.
Thanks in advance !
EDIT
The tables are made of a mix of .idb and .frm files. For each .idb file there is a .frm file of the same name.
ls -lah mywebsitedb # Gives the following :
drwx------ 2 mysql mysql 4,0K 21 nov. 21:52 .
drwx------ 6 mysql mysql 4,0K 12 déc. 14:02 ..
[...]
-rw-rw---- 1 mysql mysql 3,6K 21 nov. 21:52 mywebsite_terms.frm
-rw-rw---- 1 mysql mysql 128K 4 déc. 18:05 mywebsite_terms.ibd
-rw-rw---- 1 mysql mysql 2,2K 21 nov. 21:52 mywebsite_term_taxonomy.frm
-rw-rw---- 1 mysql mysql 128K 4 déc. 18:05 mywebsite_term_taxonomy.ibd
-rw-rw---- 1 mysql mysql 3,0K 21 nov. 21:52 mywebsite_usermeta.frm
-rw-rw---- 1 mysql mysql 128K 10 déc. 21:28 mywebsite_usermeta.ibd
-rw-rw---- 1 mysql mysql 6,8K 21 nov. 21:52 mywebsite_users.frm
-rw-rw---- 1 mysql mysql 144K 4 déc. 18:05 mywebsite_users.ibd
-rw-rw---- 1 mysql mysql 67 21 nov. 21:49 db.opt

Related

myisampack no access to data files

Fresh install of Ubuntu 20.04 on AWS.
Using ubuntu logon under /home/ubuntu/dev.
Created database myFiles.
Added MYISAM table with static data and tried....
myisampack /var/lib/mysql/myFiles/table01.MYI
and this failed with :
var/lib/mysql/myFiles/table01.MYI gave error 13 on open
permissions are :
-rw-r----- 1 mysql mysql 2340864 Nov 15 00:25 table01.MYI
parent folders :
drwxr-x--- 2 mysql mysql 4096 Nov 15 00:25 myFiles
.. and ..
drwx------ 7 mysql mysql 4096 Nov 15 00:05 mysql
so I lose permissions at /var/lib/mysql
What is the canonical way to perform this?
I have tried adding ubuntu to the mysql group (group has read at least, and execute on the folders).
Running as sudo gives a "140" (Wrong create options).
I have tried running from the /opt folder.
I know this may be an obscure usage, but I am hoping someone has had had to sweat over this already.
I don't want to chmod the tree as the permissions are probably carefully considered.
Plan A:
$ sudo myisampack /var/lib/mysql/myFiles/table01.MYI
Plan B:
$ su mysql myisampack /var/lib/mysql/myFiles/table01.MYI
Plan C:
Don't use MyISAM; then you won't need myisampack. Use InnoDB.
Plan D:
Run OPTIMIZE TABLE while connected to the server.
C is the preferred approach.

how to find securely all mysql databases on a linux server

The post's title says almost everything:
How do I get a list of all mysql databases on a linux server?
I have read somewhere that there could be restrictions on the view a mysql user has on the list of available databases.
But I need a complete list of all mysql databases installed on a particular linux server (OpenSuse 13.1 in this case).
You will need to use SHOW DATABASES
SHOW {DATABASES | SCHEMAS}
[LIKE 'pattern' | WHERE expr]
SHOW DATABASES lists the databases on the MySQL server host. SHOW
SCHEMAS is a synonym for SHOW DATABASES. The LIKE clause, if present,
indicates which database names to match. The WHERE clause can be given
to select rows using more general conditions
However, you can see only those databases for which you have some kind of privilege, unless you have the global SHOW DATABASES privilege.
Another alternative is using mysqlshow client.
The mysqlshow client can be used to quickly see which databases
exist, their tables, or a table's columns or indexes.
You list all databases by executing:
mysql -u<username> -p<password> -e"SHOW DATABASES"
If you do not have access to the mysql server you could also check which databases exists by checking the /var/lib/mysql folder, which will contain a separate folder for each database:
ls -l /var/lib/mysql
total 28692
-rw-r--r-- 1 mysql mysql 0 May 24 2017 debian-5.5.flag
-rw-rw---- 1 mysql mysql 5242880 Oct 6 16:50 ib_logfile0
-rw-rw---- 1 mysql mysql 5242880 Jul 10 2015 ib_logfile1
-rw-rw---- 1 mysql mysql 18874368 Jan 17 2018 ibdata1
drwx------ 2 mysql mysql 4096 May 24 2017 mysql
-rw-rw---- 1 mysql mysql 6 May 24 2017 mysql_upgrade_info
drwx------ 2 mysql mysql 4096 May 24 2017 performance_schema
drwx------ 2 mysql mysql 4096 Jul 10 2015 scotchbox
drwx------ 2 mysql mysql 4096 Jan 17 2018 wp
As you can see in the above output there is 4 databases: mysql, performance_schema, scotchbox and wp.

ERROR 1018 (HY000): Can't read dir of './<db>/' (errno: 13) - *not* a permission issue

Today I updated openssl (due to the recent heartbleed vulnerability) and all of a sudden mysql is acting strangely. I was recently able to modify tables, but now when I try to add a column I get:
ERROR 1005 (HY000): Can't create table '#sql-34f_872b' (errno: 13)
And trying to do show tables results in:
ERROR 1018 (HY000): Can't read dir of './<db>/' (errno: 13)
During the openssl upgrade there was a prompt asking about an upgrade to mysql. It was asking if I want to keep my current /etc/my.cnf or if I wanted to replace with the new one - I selected to keep.
Typically this would be a permissions issue, and I've tried and tested the permissions on the mysql datadir (using this answer from a similar question).
A few other strange things:
When I try these commands, I'm using the mysql command client and logged in as root
I am able to insert new rows into existing tables
I feel like the openssl upgrade is too much of a coincidence to ignore, and I'm not keen on the idea of restarting mysqld without really knowing that the server will definitely come back up (since there's an unknown issue going on here).
Any ideas?
Reply to comments and questions:
Output of ls -ltrFa:
remy#ip-10-168-9-52:~$ ls -ltrFa /vol/mysql/
total 49367084
-rwxr-xr-x 1 mysql mysql 0 Feb 11 2013 debian-5.5.flag*
drwxr-xr-x 2 mysql mysql 4096 Feb 11 2013 test/
drwxr-xr-x 2 mysql mysql 4096 Feb 11 2013 performance_schema/
drwxr-xr-x 2 mysql mysql 4096 Feb 11 2013 mysql/
-rwxr-xr-x 1 mysql mysql 6 Feb 11 2013 mysql_upgrade_info*
-rwxr-xr-x 1 mysql mysql 25 Feb 12 2013 slave-relay-bin.index*
-rwxr-xr-x 1 mysql mysql 126 Feb 12 2013 slave-relay-bin.000001*
drwxr-xr-x 6 mysql mysql 4096 Oct 14 14:35 ./
drwxr-xr-x 2 mysql mysql 4096 Apr 3 15:50 jsbin/
drwxrwxrwx 5 root root 4096 Apr 9 16:07 ../
-rwxr-xr-x 1 mysql mysql 50417631232 Apr 9 17:24 ibdata1*
-rwxr-xr-x 1 mysql mysql 67108864 Apr 9 17:24 ib_logfile0*
-rwxr-xr-x 1 mysql mysql 67108864 Apr 9 17:25 ib_logfile1*
Output of ps aux | grep mysql:
mysql 847 1.4 83.9 16342212 14681964 ? Ssl 2013 3646:34 /usr/sbin/mysqld
remy 4038 0.0 0.0 101816 2824 pts/0 S+ 16:58 0:00 mysql -uroot -px xxxxx jsbin
Note that I've also tried running mysql using sudo -u mysql mysql -uroot -pxxx jsbin and it results in the same issue.
Here is the the log from the apt-get upgrade openssl which shows mysql being included in the update: https://gist.github.com/remy/10291829
Server is ubuntu-precise-12.04-amd64 (installations are all via apt-get rather than manually compiled).
Versions of mysql:
$ mysqld --version
mysqld Ver 5.5.29-0ubuntu0.12.04.1 for debian-linux-gnu on x86_64 ((Ubuntu))
$ mysql --version
mysql Ver 14.14 Distrib 5.5.35, for debian-linux-gnu (x86_64) using readline 6.2
The following worked for me :
rm /var/lib/mysql/ib_logfile*
/etc/init.d/mysql restart
So it turns out that apt-get upgrade openssl actually upgrades everything else in it's wake - along with openssl. So somehow MySQL got caught in that update.
By accident (an AWS backup actually) the machine was rebooted, and all problems went away.
I'm pretty sure this is because some of MySQL's libraries had been updated, but the server that was loaded in memory was somehow incompatible.
I wouldn't generally recommend a random restart to fix these issues, but in this particular situation, it did the job.
The most-likely reason I can think of for this is due to some upgrade process or script trying to alter table defaults and/or one of the dependent tools adding a table and immediately altering it. This could step on a documented limitation in MySQL that prevents you from adding and dropping foreign keys in the same ALTER statement.:
* http://bugs.mysql.com/bug.php?id=68286
Can you check your logs to see what was running when the failure happened and then manually edit the update script or manually make the change so it's skipped?
I think keeping your my.cnf was the right way to go too. But if you can't get enough info from the logs as noted above, you could try disabling FK checks in there, https://dev.mysql.com/doc/refman/5.6/en/create-table-foreign-keys.html
...that does risk some trash data though, so use as a last resort.
As for OpenSSL, this was triggered by the update but not specific to OpenSSL. Any update to 5.5.29 that ran a complex ALTER might have triggered this

Unable to modify a table

I'm having trouble with mysql. I can read and write, but now I want to add some fields to a table. I run this command:
ALTER TABLE Pubs ADD COLUMN issue tinyint AFTER volume;
but get this error message:
ERROR 7 (HY000): Error on rename of './user_acct/Pubs.MYI' to './user_acct/#sql2-cb0-76f2.MYI' (Errcode: 13)
I created this table a few months ago, modified it a little bit, so it worked then. I can still update and insert items, but I just can't modify the table anymore.
Any help would be appreciated.
--Dave
You can use perror to undesrtand mysql error:
$ perror 13
OS error code 13: Permission denied
Do the MySQL user on the system have write permission to the ./user_acct/ folder?
Only the access permission is the issue
Error:
mysql> rename table BL_Backup.TMP_BL_transaction_02 to BL_Backup.BL_transaction_02;
ERROR 7 (HY000): Error on rename of './BL_Backup/TMP_BL_transaction_02.MYI' to './BL_Backup/BL_transaction_02.MYI' (Errcode: 13)
Solution
[root#s4 Db_Backup]# ll
total 52
drwxr-xr-x 2 root root 4096 Sep 28 18:19 BL_Backup
drwx------ 2 mysql mysql 49152 May 19 15:59 mauj_2010_2011
[root#s4 Db_Backup]# chown mysql:mysql BL_Backup
[root#s4 Db_Backup]# ll
total 52
drwxr-xr-x 2 mysql mysql 4096 Sep 28 18:19 BL_Backup
drwx------ 2 mysql mysql 49152 May 19 15:59 mauj_2010_2011
mysql> rename table TMP_BL_transaction_02 to BL_transaction_02;
Query OK, 0 rows affected (0.00 sec)
I just ran into this. I was getting errcode 13 when I tried to do anything which would change the .frm of my older MyISAM tables, but no newer ones.
It was because the ubuntu update process (done a few weeks before) had somehow gotten mysql to check permissions on a file deep in /tmp which it didn't have persmissions to.
root root /tmp/upgrade-XX-X/var/.wh..wh.afs
I discovered this by using 'dmesg' and seeing the permission denied error.
[111111111.222222] type=1503 audit(1862.6:7): operation="link"
pid=<> parent=1 profile="/usr/sbin/mysqld" requested_mask="::l"
denied_mask="::l" fsuid=<> ouid=<>
name="/tmp/upgrade-XX-X/var/lib/mysql/<dbname>"
name2="/tmp/upgrade-XX-X/var/.wh..wh.aufs"
And wondering why in the world mysql was trying to get information about this file?
chmod 777 on this .wh file didn't help, but chown mysql:mysql did.

how to drop database

i used the following sytanx
drop database filmo;
and got the following error:
ERROR 1010 (HY000): Error dropping database (can't rmdir './filmo/', errno: 17)
any ideas..
It means there are files in that directory not relating to MySQL. Another issue, although I doubt it, is insufficient permissions. You may delete that directory from the filesystem.
Got same error. This fixed it for me in Ubuntu 10.04:
stop mysql
rm -rf /var/lib/mysql/XXXXX
start mysql
Where XXXXX is the offending database name.
sudo rm -rf /var/lib/mysql/db_production
where
db_production is the name of the database
Remember to use "sudo".
I've changed the permissions on mysql folder ( windows server c:\xampp\mysql ) and is working now, I've created and dropped databases without any error.
This is what I do on Mac OS X Mavericks:
Stop the MySQL service
Remove the directory at /usr/local/mysql/data
1) rm -rf /var/lib/mysql/data/***
keep the data dir , rm the contents of data/
2) use
mysql -uxxx -pyyy
$ drop database data;
then it would be ok to recreate the data database again.
hopefully it will help,
Attention , direct remove data dir is useless, whatever you restart mysqld or not .
Here is a way to simulate your error
1.create a directory on MySQL data directory
mkdir /data/mysql/data/filmo
2.check the last item
[root#linux]# ls -ltrh /data/mysql/data/
总用量 173M
-rw-rw---- 1 mysql mysql 48M 4月 17 11:00 ib_logfile1
drwx------ 2 mysql mysql 4.0K 4月 17 11:00 performance_schema
drwx------ 2 mysql mysql 4.0K 4月 17 11:00 mysql
-rw-rw---- 1 mysql mysql 56 4月 18 06:01 auto.cnf
drwxr-xr-x 2 root root 4.0K 4月 18 07:25 backup
-rw-rw---- 1 mysql mysql 19 4月 23 07:29 mysql-bin.index
-rw-rw---- 1 mysql mysql 5 4月 23 07:29 oldboylinux.pid
-rw-rw---- 1 mysql mysql 19K 4月 23 07:29 error.log
-rw-rw---- 1 mysql mysql 76M 4月 23 09:56 ibdata1
-rw-rw---- 1 mysql mysql 48M 4月 23 09:56 ib_logfile0
-rw-rw---- 1 mysql mysql 5.9K 4月 23 10:21 mysql-bin.000001
drwxr-xr-x 2 root root 4.0K 4月 23 10:36 filmo
3.create a dump file in it
[root#linux]# mysqldump -uroot -p123456 -B mysql>/data/mysql/data/filmo/dump_file.sql
4.MySQL will believe filmo is a database
[root#linux]# mysql -uroot -p123456 -e"show databases;"
+--------------------+
| Database |
+--------------------+
| information_schema |
| backup |
| filmo |
| mysql |
| performance_schema |
+--------------------+
5.when I drop this "database",here is your error
[root#linux]# mysql -uroot -p123456 -e"drop database filmo;"
ERROR 1010 (HY000) at line 1: Error dropping database (can't rmdir './filmo/', errno: 17)
This is amazingly old, but another thing to check is the data folder. On Windows, that should be C:\ProgramData\MySQL<Version>\Data. IN my case, I was getting a 'cannot find folder' error.
I found that somehow the data folder for my database had been deleted. I imagine it was user error. I added a blank folder with the database name, and when I went back the DROP the table, it went as expected. Took me a while to find out what had happened, but hopefully this will save someone else the heartache.
do you have write permission on that directory (and the parent)? you may need to recursively make the directory writable (security tab in windows or chmod in nix) and delete any non-db files like "Thumbs.db"
I had this problem and it seems to be about your mysql user permissions.
try doing it by root user if it did work use this command as root to grand drop permission to your user:
grant drop
execute on *.* to 'your-user-name'#'user-ip';
That error usually comes when you have wrong TABLESPACE in ibdata1 file (that's for innodb engine)
innodb engine store some settings inside ibdata1 file
if you have recently copied / moved your files to other server or tried to restore then you should move ibdata1 file aswell then you can delete the db.
I assume you are having issue like table doesn't exist and now deleting db?
if yes then stop mysql service then delete files and then create db again, that will help you.
Further here this might help you
[Error Dropping Database (Can't rmdir '.test\', errno: 17)
Not sure where I got this answer from (apologies) but, although similar to the above, it has the additional info of how to find the mysql data directory:
mysql -e "select ##datadir"
This, I assume, is generic and returns the path to mysql/data. If you move to that directory (unix/linux/macOS command):
cd path_to_mysql/data
you will find the database you want to remove, which on nix can be done by:
sudo rm -rf DB_NAME
On MacOS X (10.9.5) I did not have to stop MySQL, but this may differ on other platforms.
drop database <database_name>;