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.
Related
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
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.
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
Problem
I'm running MySQL 5.5.23 on Mac OS 10.8.2 and am unable to drop a particular database, but I can drop others.
When I attempt to drop the specific table I get this error:
#1548 - Cannot load from mysql.proc. The table is probably corrupted
Attempted Fixes
I have restarted the system
I have tried to restart MySQL via CLI
$ sudo /usr/local/mysql/support-files/mysql.server stop
but received this error ERROR! MySQL server PID file could not be found!
I have repaired the mysql.proc table.
REPAIR TABLE mysql.proc
REPAIR TABLE mysql.proc USE_FRM
I have repaired all mysql.* tables.
REPAIR TABLE mysql.*
When running mysqlcheck from the Command Line
mysqlcheck --repair --all-databases
mysqlcheck --repair specific-db
I received this error : mysqlcheck: Got error: 2002: Can't connect to local MySQL server through socket '/var/mysql/mysql.sock' (2) when trying to connect
Current Status
I still cannot drop the original specific database, but can drop others.
Update[1] 2013-01-05 11:15 am [New York]
Logs and Feedback (per #Thomas in comments)
To find all logs, I ran (cli):
$(ps auxww|sed -n '/sed -n/d;/mysqld /{s/.* \([^ ]*mysqld\) .*/\1/;p;}') --verbose --help|grep '^log'
I received this feedback:
130105 11:35:21 [Warning] Can't create test file /usr/local/mysql-5.5.23-osx10.6-x86_64/data/wills-mbp.lower-test
130105 11:35:21 [Warning] Can't create test file /usr/local/mysql-5.5.23-osx10.6-x86_64/data/wills-mbp.lower-test
130105 11:35:21 [Note] Plugin 'FEDERATED' is disabled. /usr/local/mysql/bin/mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
130105 11:35:21 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
I'm looking into the mysql_upgrade.
Update[2] 2013-01-05 4:04 pm [New York]
I ran this :
sudo /usr/local/mysql/support-files/mysql.server stop
And received this error:
ERROR! MySQL server PID file could not be found!
Update[2.1] 2013-01-05 5:37 pm [New York]
I ran ps auxww | grep mysql and found the mysqld process and killed it (sudo kill [process id]). I was then able to restart mysql successfully. However, I'm still having no luck dropping that specific database mentioned above.
Resolved
After trying to manually repair the corruption and many of the suggestions and the other answer listed here, reinstalling mySQL was the only thing that solved my problem.
On a Mac (running 10.8.2) I also had to do some manual deletions for a clean install:
sudo rm /usr/local/mysql
sudo rm -rf /usr/local/mysql*
sudo rm -rf /Library/StartupItems/MySQLCOM
sudo rm -rf /Library/PreferencePanes/My*
sudo rm -rf /Library/Receipts/mysql*
sudo rm -rf /Library/Receipts/MySQL*
sudo rm /etc/my.cnf
Articles consulted
MySQL duplicates with CONCAT error 1548 - Cannot load from mysql.proc. The table is probably corrupted
SQL error: BIGINT UNSIGNED value is out of range in (…), but it doesn't make sense
How to repair corrupted table
MySQL manager or server PID file could not be found
PHP/MySQL issue after security update 2010-005
mysql problems after Mac OS X software update
How to remove MySQL completely Mac OS X Leopard
I ran into an issue that queries on my databases (named: caloriecalculator) was taking too long and it won't drop at all. I followed these steps below and it fixed my issue:
See all MySQL processes: mysqladmin processlist -u root -p
Kill all processes relating to caloriecalculator as it was blocking my next queries to be executed.
mysqladmin -u root -p kill 4
Now run: drop database caloriecalculator;
I would try:
Backup/save any databases that have important data.
Remove mySQL
Reinstall mySQL
Restore any backed up databases.
I had this happen to me on a Linux server, and the cause was a corrupted database directory.
UPDATE: one thing to do is to go into MySQL database directory and perform a ls -la, to verify that the evil DB is the same as the others as regards permissions, ownership and so on. For example here the 'original' database cannot be dropped (it was created by a stupid tool ran as root):
drwx------ 2 mysql mysql 4096 Aug 27 2015 _db_graph
drwx------ 2 mysql mysql 4096 Jul 13 11:58 _db_xatex
drwxrw-rw- 2 root root 12288 May 18 14:27 _db_xatex_original
drwx------ 2 mysql mysql 12288 Jun 9 08:23 _db_xatex_contab
drwx------ 2 mysql mysql 12288 May 18 17:58 _db_xatex_copy
drwx------ 2 mysql mysql 4096 Nov 24 2016 _db_xatex_test
Running chown mysql:mysql _db_xatex_original; chmod 700 _db_xatex_original would fix the problem (but check inside the directory to verify there too permissions and ownerships are copacetic).
In the end, I employed the following ugly hack (after trying stopping, restarting and repairing whatever could be targeted by a REPAIR):
created a database "scapegoat"
stopped MySQL Server
copied the directory created by MySQL Server, /var/lib/mysql/scapegoat, to /tmp
restarted MySQL Server, dropped the database "scapegoat", stopped the server
Now I had a copy of a clean, empty DB dir that MySQL no longer knew anything about.
moved the "evildb" directory to /tmp (so that if thing went wrong I could put it back)
moved the "scapegoat" directory to /var/lib/mysql renaming it to "evildb"
started MySQL Server
not sure if I ran any more repairs at this point
and the "evildb" database became droppable!
My explanation is that when asked to drop a database, MySQL Server first performs some checks on the files in the database directory. If these checks fail, the drop also fails. These checks must be subtly different from the ones performed by REPAIR. Maybe in the affected directory there is something unexpected.
I think this was on a MySQL 5.1 or 5.2 on a SuSE 11.2 Linux distribution. Hope it helps.
UPDATE
On thinking back, I don't remember getting errors about "proc". So I'm less sure that the problem lies in the directory. It might be connected with the proc table, without being a table corruption. Have you tried visually inspecting the proc database table, in order to find something there that belongs to the evil DB?
USE mysql;
SELECT * FROM proc;
That, or any errors therefrom, could help in solving the problem. You might, who know, have some lines with the wrong db column. In a pinch, you could export the proc table and reload it after cleaning (either through SQL or via a disk file).
TEST
I have partial verification for the above update. By intentionally inserting rubbish into the proc table apropos a newly created database evil, I partially reproduced your symptoms (undroppable database, MySQL connection crashes on attempt). Error number is not 1548 though; but maybe it would be, if I inserted the right rubbish in that table... anyway, the useful bit is that by removing all references to the evil db, the latter became droppable again:
mysql> drop database evil;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql> use mysql;
No connection. Trying to reconnect...
Connection id: 1
Current database: *** NONE ***
Database changed
mysql> DELETE FROM proc WHERE db = 'evil';
Query OK, 2 rows affected (0.00 sec)
mysql> drop database evil;
Query OK, 0 rows affected (0.00 sec)
I had the same problem and all I did was to delete the database directory from the mysql data directory.
If you using xampp In windows
you can also drop your database using phpmyadmin
go to home -> databases -> click on your [database name] -> drop
OR
you can also drop your database manually
go to xampp -> mysql -> data -> [database name]
delete your [database name] now.
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>;