I have a mysql log file that regularly goes over 30gb, this sucks when you realise that your server is full because of this file. I need a simple solution to limit this file to about 1gb, i don't need logs that run that long, and i'd rather avoid this problem in the future.
Any ideas? Thanks
To specify it in the my.cnf file, backup your current my.cnf file (always recommended), stop slave, stop the MySQL server and place the following option:
# relay log restrictions
relay-log-space-limit=15G
Then save and quit the file and start MySQL. Unless you configured differently, MySQL will automatically start the slave thread.
Related
I did a backup of the data folder from mysql server to keep all databases information.
C:\ProgramData\MySQL\MySQL Server 5.7\Data
I uninstalled MySQL server in Control Panel. I copied the data folder and pasted it back where it should be.
I am then trying to reinstall the service using MySQL installer. However, it is stuck on Starting Server... forever and sometimes will pop a message saying it is taking too long than expected. I tried this solution but it does not work for me.
When I remove the ibdata1, Mysql server installs, starts and runs. However, whenever I try to run a query on a table I get database_name.table does not exist.
Clearly to me the problem is ibdata1... So what should I do, if I really need to restore all the databases?
Do you still keep ibdata1 ? Reclean and copy back your ibdata1 and your data
For starting mysql, you should config Innodb force recovery (increase this value from 1 to 6). This will give you detail information https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
Remember, in recovery mode you can read data only and cannot update, insert or delete
Update:
Find your my.ini (on linux my.cnf) add this line to your [mysql]
innodb_force_recovery = 1
Try to increase it from 1 -> 6 until you can start your mysql server. Then you can perform dump to backup your server remember you cannot update/insert/delete in recovery mode
Does restarting the MySQL service on Linux, disables the already enabled general query logging?
There was a log file getting generated inside the data folder, and it was growing exponentially. The db has 100 requests per minute.
Initially i guessed, some transaction had broken in between, that made the logs to swell.
So i restarted the service, which stopped adding to that log file.
I checked the global variables and got to know the path was assigned for general_log_file. But now it was showing 'OFF'.
Hence my query
It's a common issue that people will set configuration of MySQL through dynamic (global) variables and forget to set the variables in the options file (my.conf). In that case, when the server is restarted, MySQL will revert to default settings.
The default setting for general_log is OFF. To immediately enable the general query log, set the global variable to ON. Then set the value for general-log in your my.conf file to ensure that the setting is applied whenever you restart MySQL server.
No, Restarting the server doesn't make the binary logs to OFF...
It may be the case that you changed the configuration file before and now restart takes that file...
MySQL will start with whatever options are in the file configuration. If you switched any of the global server variables before, they will be reverted to what is set in the file.
I have problem with wammp server.
In directory "..\WampServer\bin\mysql\mysql5.5.8\data" was created files with very large size.
Full size of this directory is 50GB. What is these files? How can I fix this problem?
The names of files are:
mysql-bin.000001
mysql-bin.000002
................
mysql-bin.000227
The size of all files is 49GB
Thanks in advance!
By default whenever you make a change to a MySQL database it creates a log of the query and stores it in a file simlare to mysql-bin.000001. The MySQL database does this so that you can recover or replicate a database. Most applications this is a good things to have enabled just like doing regular backups.
If you want to disable MySQL from creating these binary logs:
Open my.ini
Search for this line log-bin=mysql-bin
Comment this line out by adding a hash mark: # log-bin=mysql-bin
Save and restart the MySQL database
You can now safely delete these files from that directory.
I did another thing on my wamp...
http://dev.mysql.com/doc/refman/5.0/en/purge-binary-logs.html
Start a command prompt and goto directory wamp\bin\mysql\mysql5.5.16 or whatever version number you got
type:
mysql.exe -u root
SHOW BINARY LOGS;
a list with all the log files will be show up. We need the last one.
In my case was mysql-bin.000412
so i typed
PURGE BINARY LOGS TO 'mysql-bin.000412';
and you are ok!
I have tried several commands (FLUSH LOGS, PURGE MASTER) but none deletes the log files (when previously activated) or the log tables (mysql/slow_log.CSV and mysql/general_log.CSV and their .frm and .CSM counterparts).
SHOW BINARY LOGS returns "You are not using binary logging".
Edit: I found this simple solution to clear the table logs (but not yet the file logs using a mysql command):
TRUNCATE mysql.general_log;
TRUNCATE mysql.slow_log;
FLUSH LOGS just closes and reopens log files. If the log files are large, it won't reduce them. If you're on Linux, you can use mv to rename log files while they're in use, and then after FLUSH LOGS, you know that MySQL is writing to a new, small file, and you can remove the old big files.
Binary logs are different. To eliminate old binlogs, use PURGE BINARY LOGS. Make sure your slaves (if any) aren't still using the binary logs. That is, run SHOW SLAVE STATUS to see what binlog file they're working on, and don't purge that file or later files.
Also keep in mind that binlogs are useful for point-in-time recovery in case you need to restore from backups and then reapply binlogs to bring the database up to date. If you need to use binlogs in this manner, don't purge the binlogs that have been written since your last backup.
If you are on amazon RDS, executing this twice will do the trick:
PROMPT> CALL mysql.rds_rotate_slow_log;
PROMPT> CALL mysql.rds_rotate_general_log;
Source: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.MySQL.html
It seems binary logging is not enabled in your server .And i guess you want to delete the old log files which were used/created at the time of binary logging is enabled . you can delete them manually using 'rm' command if you want . if you want to enable the binary logging you can do the same by updating the configuaration file ( but it needs restart of the server if it is already running) . You can refer below links.
http://dev.mysql.com/doc/refman/5.0/en/replication-options-binary-log.html#option_mysqld_log-bin
http://dev.mysql.com/doc/refman/5.0/en/replication-options-binary-log.html#sysvar_log_bin
Does MySQL keep a transaction log and if so where could I find it?
A number of rows have mysteriously been deleted from a table and I want to try and see how and when it occurred.
If you turned on - mysql can track binary log, which contains all the modifications (to be clear - it contains the queries that had changed something).
But anyway, it is useless if you do not have the initial dump, which precedes the binlog turning on. Also i suppose if you made the dump and turned on binlog - you would not ask such question :-S
Short answer: not by default.
In order to have accurate logging results, you need to have started the server in binary logging mode first, using the parameter --log-bin=your-file-name. It then creates a binary log file {your-file-name.seq} where seq is a sequence number for subsequent log files (recommended to put your file name there, with explicit directory location).
More information on the MySQL site explaining all the details: https://dev.mysql.com/doc/refman/5.7/en/binary-log.html
If you're using MySql on Windows, there's a file located in C:\Program Files\MySQL\MySQL Server 5.0\data (assuming a C: drive for the installation target and MySql version 5.0), that is called %COMPUTERNAME%.log that contains the commands that have been executed.