According to the mysql documentation (Docs), in order to change innodb-log-file-size in step #4 I need to delete the binary logs. I have some concerns and questions about this. My current value for innodb-log-file-size is 5MB. So I would assume my binary log files are 5MB each (max). When I look at the bin-log directory I have a bunch of file names like 'mysql-bin.000001', 'mysql-bin.000002', etc. I believe these are the binary log files, but they are all quite a bit larger than 5MB. There are 2 files (ib_logfile0, ib_logfile1) that are 5 MB. So my question is
Which of those files is my 'binary log'?
Which of those do I need to delete?
Thanks in advance
The InnoDB log is in ib_logfile0 and ib_logfile1. These are the files sized by innodb_log_file_size.
To resize the InnoDB logs, you first need to shut down mysqld cleanly. That will make sure that any changes in the log have already been flushed into your tablespaces. The clean shutdown is important, because if you don't do this step, you have a high chance of losing data.
After you have shut down mysqld cleanly, the ib_logfiles are superfluous. You must rm them to change their size.
As you restart mysqld, InnoDB notices that the files are missing, and creates new file at the new size according to the innodb_log_file_size variable in your my.cnf file. So make sure you edit that file before you restart, or else it'll just create new 5MB files.
MySQL 5.6 makes this process a little bit simpler. You don't need to rm the log files, but you do need to restart mysqld to make a new log file size take effect. The way it works in 5.6 is that if the size of these files is different from the config variable, MySQL automatically does another clean restart (to make sure the files don't contain any changes that are unflushed), and then InnoDB resizes the files upon the final startup.
The other files (mysql-bin.000001, etc.) are binary logs. These may grow up to max_binlog_size (which is 1GB by default), but the binary logs vary in size because new logs are created whenever you restart mysqld or execute FLUSH LOGS. Anyway, they have nothing to do with the InnoDB logs.
PS: You might like this article: How to calculate a good InnoDB log file size.
As per official document and it works for me for MySQL 5.7.30
To change the number or the size of your InnoDB redo log files, perform the following steps:
Stop the MySQL server and make sure that it shuts down without errors.
Edit my.cnf to change the log file configuration. To change the log file size, configure innodb_log_file_size. To increase the number of log files, configure innodb_log_files_in_group.
Start the MySQL server again.
If InnoDB detects that the innodb_log_file_size differs from the redo log file size, it writes a log checkpoint, closes and removes the old log files, creates new log files at the requested size, and opens the new log files.
Related
I was trying to create a table in MySQL, then got error 1206 (total number of locks exceeds lock table size).
I understand I need to increase innodb_buffer_pool_size. (The current setting is about 100m)
and my dataset is quite large.
The table I intended to create should return more than 1 million rows with lots of textual returns.
I am a historian and not very experienced in changing MySQL option files.
Add this to your config file
innodb_buffer_pool_size=1G
Then restart the mysql service. You should ensure that your logfiles are of minimum 250M.
Since the variable innodb_buffer_pool_size is of type read-only, you have to set the value in the config file and restart the service.
Edit
Step by Step
Find the config file on the MySQL server. (my.cnf or my.ini)
Change the innodb_buffer_pool_size=1G
Make sure your innodb_log_file_size=250M (minimum, log file size should be minimum 25% of buffer_pool)
Delete the old log files
Restart your service!
Download MySQL workbench from MySQL.com, install on the server and it will help you doing edits in the config file
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.
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
I want to purge the ibdata1, ib_logfile0 and ib_logfile1 files in MySQL. Because these files are taking too much space of my C:\ disk. And I don't want to move these files anywhere else in the Hard disk. I heard about purging which can shrink the data. I am using Windows Vista. What are the steps to be done to purge the data ?
The log files can be removed anytime. Only the most recent log is kept open/locked. However, deleting id_data will trash all of your InnoDB databases - that's the actual data store.
As pointed out by MarcB, you can delete the (old) logfiles without problems; MySQL does not need them to run.
The data file ibdata* must not be deleted, it contains the actual database data.
I will grow as the database grows; unfortunately there is not way to shrink it, even if you later delete data from the database. The only way is to dump and reimport the whole database.
Also see this question: MySQL data file won't shrink
It explains various options to better cope with growing data files.
Short answer: There's no way to reduce the size of the ibdata files once they grew to a certain size. MySQL recommends dumping all innodb type data, shutting down mysql, deleting the ibdata files and restarting, then loading the data again. A one-click "compact" solution like other systems have is still missing.
The short question:
Is it safe skip ib_logfile* files while creating custom-made backup of MySQL installation with InnoDB engine used?
Custom-made backup is just copy all (or subset of) /var/lib/mysql + /etc/my.cnf to safe place.
As I know ib_logfile* files are recreated by MySQL on start + the files are really huge, so that may not be wise to store them in backup. And yes, assume MySQL is (correctly) stopped before backup.
It's not safe to back up a database in the manner you're describing.
The reason is that you cannot know if some data pages are still in MySQL Server's memory, pending an I/O flush to disk. So copying the files has a good chance of copying garbage, whether or not you include the ib_log files.
Don't do what you're doing. Use mysqlbackup or InnoDB's Hot Backup product.
edit:
Read Farhan Mashraqi's blog article about InnoDB Performance Optimization, in which he says you can delete the ib_log files if you have shut down MySQL Server.
InnoDB log resizing: is not as simple
as changing option and restarting. You
need to shut down MySQL server and
make sure it shuts down normally
(check error log for errors to
confirm). Then move away InnoDB log
files ib_log*. Then start the MySQL
server and check error log files to
see if it successfully created new log
files.
So yes, you should be able to do a filesystem copy of the ibdata files only. You don't need to include the ib_log files, because they should be recreated as MySQL Server starts up. I reiterate, however, that I do not recommend backing up databases with filesystem copy.
Suppose you back up a database today in this manner, using MySQL 5.0. Someday later you need to restore the backup, but by that time you'll be using some future version like MySQL 6.5 for example. Do the ib_data files still use the same internal format in that future version? Will MySQL 6.5 read those files you backed up today? You can't be sure. The backup format is intended to be more portable.