I am having some real difficulties finding out exactly what a certain file in the MySQL data directory is used for. (Using Google with its file name is pointless!)
Basically, I need to create some space on the drive that hosts all MySQL data and have noticed a file almost 16GB in size!!
I cant see any reference to a Query file in my config file nor can I match its size up to that of any log files, etc (in case its a log file missing the .log extension). I'm totally stumped!
I would like to know what this file is and how to reduce its size if at all possible?
Thanks in advance for your assistance!
That could be the general query log (I said "could" because the name can be configured by yourself). Look in your my.ini for an entry
log=/path/to/query
Or start the MySQL Administrator, goto "Startup Variables->Log Files" and look for "Query Logfile"
That file is completely unnessasary for your server to run (if you confirmed that the entry log=... exists in your config.
It is just good for debugging.
Try stopping your mysql server, delete it and restart your server again. The file will be recreated.
I also noticed that the slow-query-log ("diamond-slow-log") is large, too.
That file only logs queries that take longer than x seconds (2 by default). That file can be deleted or deactivated, too. But I would keep it since it contains queries that could easily be optimized with an extra index.
Update
there is another way, to confirm that this is the general query log.
Download a windows port of the tail unix command. E.g. this one http://tailforwin32.sourceforge.net/
I often use this on my dev machine to see what is goning on.
Open a shell (cmd.exe) and navigate the folder where that file exists.
Then type
tail -f query
That will print the last few lines of the file and if the file changes every new line.
So if you do a SELECT * FROM table you should see the query in the console output.
Related
I'm using mysql, and I want to enable saving queries to text files in any location. Currently, when I run the mysql command:
show variables like 'secure_file_priv';
I receive the value for 'secure_file_priv':
/var/lib/mysql-files/
I am able to save my queries to files in this location but nowhere else of course. (I'm also having trouble accessing this folder, even when I try to access it as root)
I found my 'my.cnf' file in '/etc/my.cnf', but it doesn't contain the variable 'secure_file_priv'!
I added it in myself as:
secure_file_priv=""
But this didn't do anything.
I also tried changing it through the mysql terminal, but it is a readonly variable, so I wasn't able to.
Where is this variable located and how can I change it to allow me to write the results of queries to files anywhere?
I am a little confused about start up scripts and the command line options. I am building a small raspberry pi based server for my node applications. In order to provide maximum protection against power failures and flash write corruption, the root file system is read only, and that embraces the home directory of my main user, were the production versions of my apps (two of them) are stored. Because the .pm2 directory here is no good for logs etc I currently set PM2_HOME environment variable to a place in /var (which has 512kb unused space around it to ensure writes to i. The eco-system.json file reads this environment variable also to determine where to place its logs.
In case I need to, I also have a secondary user with a read write home directory in another (protected by buffer space around it) partition. This contains development versions of my application code which because of the convenience of setting environments up etc I also want to monitor with PM2. If I need to investigate a problem I can log in to that user and run and test the application there.
Since this is a headless box, and with watchdog and kernel panic restarts built in, I want pm2 to start during boot and at minimum restart the two production apps. Ideally it should also starts the two development versions of the app also but I can live without that if its impossible.
I can switch the read only root partition to read/write - indeed it does so automatically when I ssh into my production user account. It switches back to read only automatically when I log out.
So I went to this account to try and create a startup script. It then said (unsurprisingly) that I had to run a sudo command like so:-
sudo su -c "env PATH=$PATH:/usr/local/bin pm2 startup ubuntu -u pi --hp /home/pi"
The key issue for me here is the --hp switch. I went searching for some clue as to what it means. Its clearly a home directory, but it doesn't match PM2_HOME - which is set to /var/pas in my case to take it out of the read only area. I don't want to try and and spray my home directory with files that shouldn't be there. So am asking for some guidance here
I found out by experiment what it does with an "ubuntu" start up script. It uses it to set PM2_HOME in the script by appending "/.pm2" to it.
However there is nothing stopping you editing the script once it has created it and setting PM2_HOME to whatever you want.
So effectively its a helper for the script, but only that and nothing more special.
UPDATE: The sysadmin in my company deleted the /tmp directory and created a
symbolic link to a mounted drive (e.g. ln -s /mnt/somewhere /tmp).
MySQL apparently didn't like this symbolic link.
Once a real /tmp directory on the local filesystem was created the problem went away.
I'm running a process (rake db:migrate) which causes MySQL to try to create a temp file.
However, the following error is appearing:
Mysql::Error: Can't create/write to file '/tmp/#sql_196_0.MYI' (Errcode: 13):
SHOW FIELDS FROM `user_rules`
Errcode 13 apparently is a file permission issue.
The user that is running the process has write permissions to the /tmp directory.
I also searched the web, and someone mentioned that the issue could be the file be prefixed with a pound sign (e.g. '#").
I went to the /tmp directory and tried to create the file and noticed that in certain cases I can't create the file. So I'm wondering if indeed the pound sign is causing the problem. And if it is, how can use MySQL or Rails to fix the problem:
cd /tmp
echo "Hello" > #sql_123
touch #sql_123
echo "Hello" > "#sql_123"
touch "#sql_123"
The 2nd and 3rd commands (without quotes) are failing. The 4th and 5th lines (with quotes) are working. So maybe the failure is because of the pound sign not being in quotes or escaped with a backslash. But again, even if that is the cause, I'm not sure how to tell MySQL or Rails how to deal with it.
Any ideas?
In a shell you need quotes because # introduces a comment, unless escaped by a backslash or quotes. Those #sql_123 files with a prefix of a pound-sign are temporary files owned by mysql, they are normal. You cannot move them however and whenever they are present you cannot move your database using the binary files, you either need to shutdown and move; or do a mysqldump to SQL.
Now for your sysadmin, did he delete /tmp while mysql was running? Mysql opens files in /tmp and then deletes them from the directory leaving the file-handle open. You would see differences in disk space while the server is up or down. MySQL creates all temporary files as hidden files. This ensures that the temporary files are removed if mysqld is terminated. The disadvantage of using hidden files is that you do not see a big temporary file that fills up the file system in which the temporary file directory is located.
So if you would like to keep the symlink (i.e. to a larger disk) then you would better shutdown mysql, create the link, and then start mysql to find it has no problem with symlinks.
When I want to execute an update query on my table I got an error saying:
1036 - Table data is read only.
How can I fix that?
Table attributes in /var/db/mysql are set to 777.
'Repair Table' function doesnt seems to help.
Is there anything I can do with that?
In my case, mysql config file had innodb_force_recovery = 1. Commenting that out solved the issue. Hope it helps someone.
who owns /var/db/mysql and what group are they in, should be mysql:mysql. you'll also need to restart mysql for changes to take affect
also check that the currently logged in user had GRANT access to update
(This answer is related to the headline, but not to the original question.)
In case you (like me) are trying to temporarily alter data via the MySQL Workbench interface:
If the table does not have a primary key, MySQL Workbench has no way of identifying the row you are trying to alter, so therefore you cannot alter it.
Solution in that case is to either alter the data via another route, or simply to add a primary key to the table.
In any case, I hope it helps someone :)
You should change owner to MYSQL:MYSQL.
Use this command: chown -Rf mysql:mysql /var/lib/mysql/DBNAME
My situation is everytime I needed to edit "innodb_force_recovery = 1" in my.ini to force mysql to start, and the error log showed some error said:
Attempted to open a previously opened tablespace. Previous tablespace mysql/innodb_table_stats uses space ID: 1 at filepath: .\mysql\innodb_table_stats.ibd. Cannot open tablespace profile/profile_commentmeta which uses space ID: 1 at filepath: .\profile\profile_commentmeta.ibd
I didn't know why this file was not able to open and it caused so many other"table read only" problems to other databases too.
So here is how I fixed this problem in a simple way without hurting other files.
1
First of all, make sure if you add innodb_force_recovery = 1
below [mysqld] in my.ini file, and it is working, under path: X:\xampp\mysql\bin\my.ini
2
Then next step, export all the databases through localhost/phpmyadmin under the export tab, and store them somewhere, like this:
3 comment out the data filefolder to data-bak, then create a new data filefolder,
4 Next step, import all .sql database back from phpmyadmin panel, please also copy phpmyadmin filefolder from the old data-bak filefolder to the new data filefolder. If any file is necessary, go back to data-bak filefolder to copy and paste.
Now all fixed and done, don't need to force mysql to start everytime.
Hope this also works for you.
MySQL doesn't have write access to the database file. Check the permissions and the owner of the file.
On windows I use Xampp server I comment the line in my.ini
innodb_force_recovery = 1 to #innodb_force_recovery = 1 the problem resolved
I solved the same issue by editing app. armour configuration file. Found the answer here: https://stackoverflow.com/a/14563327/31755661
maybe you get read only error from your table storage engine.
Check you Storage Engine, maybe if it is MRG_MYISAM change it to MyISAM and try again.
If you are running selinux in enforcing mode then check your /var/log/messages for audit faults. If you see the tell-tale "****" messages about selinux blocking write access to your table files in / then you need to relabel those files so that they have this label:
system_u:object_r:mysqld_db_t:s0
What you could have is a broken label from copying those files over from a user directory (such as during a recovery attempt).
There's a great resource for selinux here:
https://docs.fedoraproject.org/en-US/Fedora/11/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-SELinux_Contexts_Labeling_Files-Persistent_Changes_semanage_fcontext.html
Just remember that you will need to do this for all of those files, which could be many. Then you will want to run the "restorecon -R -v " command to get the recursive (-R) application of the new labels. There is no support for -R in the semanage command, as far as I could tell.
For reference, the semanage command to relabel looks like this:
semanage fcontext -a -t mysqld_db_t 'filename'
The quoting of the file name is critical for the command to work.
In my case there was a table with read-only state set and when I tried to restart mysql service it would not even start again and with no descriptive error.
Solution was to run fsck on the drive (with many fixes), which was advised after Ubuntu reboot.
I'm running Ubuntu in VirtualBox under Windows and it often hangs or is having functionality problems.
One other way to receive this error is to create your table with a "Like" statement and use as source a merged table. That way the newly create table is read-only and can't "receive" any new records.
so
CREATE TABLE ic.icdrs_kw37 LIKE ic.icdrs ... #<- a merged table.
then:
REPLACE INTO ic.icdrs_kw37 ... # -> "Table is read-only"
bug or feature?
I would like to know how to retrieve a file using Vi in MySQL. I logged in using:
mysql -uuser -p -hserver -A database
Then I do:
\e
The editor opens and I type my query of 200 lines, then I :wq and \G (if I save the file it says: /tmp/sql9SbYQZ saved) and I see the result.
Now, if I make a mistake or run a different query and I try to type \e again, the query is lost.
ll /tmp/sql9SbYQZ
ls: /tmp/sql9SbYQZ: No such file or directory
Is there a way to retrieve the lost file?
Here's what I added to my .vimrc in order to save the current query in case i made a mistake.
nmap <F7> :w! /tmp/query.sql\| wq!<CR>
This will create a map to the F7 key (you can change it of course). So every time you open a file either using edit or \e, you change it use the F7 key.
This will save a backup of your current query to /tmp/query.sql and then save and close the temporary file. This way, if you make a mistake, you just re-open the backup file and try again.
Here's also a link you might like: http://vim.wikia.com/wiki/Open_the_last_edited_file
With the vi/m editor used with mysql, crontab, and many others, the work is done in a tmp file, as you see from your messages.
Edit (Big doah!, remove cruft about ls -l /tmp/..., you already did that!)
In the future the solution is to tell vim to w the buffer to a file name of your chosing, i.e.
w! /home/you/scripts/mysql2.sql
Then close the editor with
q
Note you may not need the ! after w.
I hope this helps.
Here is something you can try:
In Linux, do the following
$ cd
$ cp .mysql_history mystuff.txt
$ vi mystuff.txt
You should see the file .mysql_history. The mysql client records all queries and commands executed. Hopefully, your query is in there.
Give it a Try !!!