In the /var/log/mysql I found that are many large files
-rw-rw---- 1 mysql adm 104875724 Nov 16 2016 mysql-bin.002982
-rw-rw---- 1 mysql adm 104900467 Nov 16 2016 mysql-bin.002983
...............
-rw-rw---- 1 mysql adm 104919093 Nov 23 2016 mysql-bin.003118
-rw-rw---- 1 mysql adm 104857817 Nov 23 2016 mysql-bin.003119
-rw-rw---- 1 mysql adm 104858056 Nov 23 2016 mysql-bin.003120
-rw-rw---- 1 mysql adm 9184221 Nov 23 2016 mysql-bin.003121
-rw-rw---- 1 mysql adm 104907549 Nov 23 2016 mysql-bin.003122
......
-rw-rw---- 1 mysql adm 6272 Nov 25 2016 mysql-bin.index
Can I delete them?
Update
I don't use a replication for the database
better not do it manually, you can do it through mysql.
PURGE BINARY LOGS TO 'binlogname';
PURGE BINARY LOGS BEFORE 'datetimestamp';`
for example to delete everything before a week ago run:
PURGE BINARY LOGS BEFORE DATE(NOW() - INTERVAL 3 DAY) + INTERVAL 0 SECOND;
or (even better) edit the my.cnf and set this parameter
[mysqld]
expire_logs_days=7
These large files are MYSQL BINARY LOG, stores query event such as add, delete and update in a very details way. The Binary Log is used for two main purposes:
For replication, the binary log on a replication source server provides a record of the data changes to be sent to replicas. The source sends the events contained in its binary log to its replicas, which execute those events to make the same data changes that were made on the source.
Certain data recovery operations require use of the binary log. After a backup has been restored, the events in the binary log that were recorded after the backup was made are re-executed. These events bring databases up to date from the point of the backup.
There are several ways to remove or clean up MySQL Binary Log, it’s not recommend to clean up the file manually, you need to use PURGE BINARY LOGS statement to safely purge binary log files:
On each replica, use SHOW SLAVE STATUS to check which log file it is reading.
Obtain a listing of the binary log files on the replication source server with SHOW BINARY LOGS.
Determine the earliest log file among all the replicas. This is the target file. If all the replicas are up to date, this is the last log file on the list.
Make a backup of all the log files you are about to delete. (This step is optional, but always advisable.)
Purge all log files up to but not including the target file.
Since you have not set up a backup, do the following:
you can also remove the binary older than a specific date, such as 2019-04-02 22:46:26,
PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2019-04-02 22:46:26';
PURGE BINARY LOGS statement structure:
PURGE { BINARY | MASTER } LOGS {
TO 'log_name'
| BEFORE datetime_expr
}
It's directly from the official website
You can also delete them with a 1 liner.
It deletes all binary logs safely through MySQL except for the ones you are using in your current session.
purge binary logs before curdate();
Ѕіmрlеѕt wау іѕ tо run thе unіvеrѕаl МуЅQL сlеаnuр соmmаnd: rm -rf /
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
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.
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.
I am having a very big problem with mysql. I have a form in which the users fill a field that corresponds to a datetime attribute in the database. The problem I am having is that the form had a bad format for the datetime field, and all the records are filled with '0000-00-00 00:00:00' in the database.
Is there a way I can recover the data the user submitted? Maybe from a log/binary log?
I have checked the general log and it is empty.
Thanks in advance! I really will appreciate your help.
The mysqlbinlog utility can be used to convert the binary log binary format to text format.
http://dev.mysql.com/doc/refman/5.5/en/mysqlbinlog.html
Note that the binary logs may contain statements (those changes will be apparaent in the output from the mysqlbinlog urility. It may also contain binary changes, or they may be a mixture. What was recorded in the binary logs depends on the setting of the binlog_statement system variable. The default value depends on the version of MySQL.
http://dev.mysql.com/doc/refman/5.5/en/binary-log-setting.html
(This question might better be asked on dba.stackexchange.com.)
FOLLOWUP
The MySQL binary logs are not the InnoDB log files (ib_logfile0, ib_logfile1).
The binary logs (on one of my installs) are written to the MySQL data directory:
SHOW VARIABLES LIKE 'datadir'
e.g.
> ls -l /opt/mysql/data/mysql-bin*
-rw-rw---- 1 mysql mysql 1074553753 2014-05-28 22:39 /opt/mysql/data/mysql-bin.003907
-rw-rw---- 1 mysql mysql 1073745289 2014-05-29 01:22 /opt/mysql/data/mysql-bin.003908
-rw-rw---- 1 mysql mysql 280683262 2014-05-29 01:55 /opt/mysql/data/mysql-bin.003909
-rw-rw---- 1 mysql mysql 520382482 2014-05-29 05:55 /opt/mysql/data/mysql-bin.003910
-rw-rw---- 1 mysql mysql 705774048 2014-05-29 15:26 /opt/mysql/data/mysql-bin.003911
-rw-rw---- 1 mysql mysql 817 2014-05-29 05:55 /opt/mysql/data/mysql-bin.index
Note that the binary logs are written only if binary logging is enabled. You can check whether binary logging is currently enable by querying the log_bin system variable:
SHOW VARIABLES LIKE 'log_bin'
Variable_name Value
------------- --------
log_bin ON
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