Foreword
MySQL MySQL database log records the daily operation and error messages. MySQL There are different types of log files (each store different types of logs), which can query the log from the operation of the MySQL database, the user's operation, the wrong information.
MySQL log into the following four categories:
- Error Log: record start mysql service, occur when you run or stop the mysql service issues;
- Query Log: record the statement and execution of client connections established;
- Binary log: a record of all changes to the data of the statement can be used to copy data;
- Slow query log: a record of all queries or queries without using an index of all time performed over the long_query_time.
By default, all logs are created in the MySQL data directory, refresh the log, you can force MySQL to close and reopen the log file, Flush logs refresh the log or execute mysqladmin flush-logs If you are using MySQL replication capabilities, can be maintained on replicated servers For more log files, which we call logs succeed log. Start logging may impair the performance of the MySQL database.
1) to view system settings
<!--查看全局的系统状态-->
mysql> show global variables\G
mysql> show global variables like '%log%';
<!--查看当前会话的系统状态-->
mysql> show session variables\G
mysql> show session variables like '%log%';To modify the view out of the above parameters, the field can be written to mysqld MySQL main configuration file, as: binlog_cache_size = 1M. Or may be temporarily modified in the MySQL database: set global binlog_cache_size = 1048576, which temporarily modify MySQL will expire after the restart.
2) check the running status
<!--查看全局的运行状态-->
mysql> show global status\G
<!--查看当前会话的运行状态-->
mysql> show session status;
<!--查看MySQL的版本-->
[root@mysql ~]# mysql -V
mysql> status;
mysql> select version();1, the error log
In the mysql database, error logging is enabled by default. By default, error logs are stored in the data directory mysql database. The error log file is usually the name of hostname.err. Where, hostname represents the hostname of the server. Error log information can be configured themselves, the error log is recorded can be defined by log-error and log-warnings, which the log-error is defined whether the storage location of the error log and error log function is enabled, log- warnings is to define whether a warning message will also be defined to the error log. Error log to record information about the following aspects of the default: server startup and shutdown process information (not necessarily the wrong information, such as how to start mysql InnoDB tablespace files, how to initialize its own storage engine, etc.), error message the server is running, the information generated when the event scheduler to run an event, the information generated when the server process is started from the server, MySQL there are many system variables can be set up, the system variable settings are different, it will cause the system to run state different. So mysql command provides two sets, respectively, view system settings and operating status.
In general, the log level definition no session state variables are just the error log is defined in the global level:
mysql> show global variables like '%log_error%';
+---------------------+----------------------------------+
| Variable_name | Value |
+---------------------+----------------------------------+
| binlog_error_action | ABORT_SERVER |
| log_error | /usr/local/mysql/data/mysqld.err |
| log_error_verbosity | 3 |
+---------------------+----------------------------------+
3 rows in set (0.01 sec)Log_error which is defined as the error log file path, log_error_verbosity worth following meanings:
| Verbosity | Message |
|---|---|
| 1 | Error only |
| 2 | Error and warnings |
| 3 | Errors, warnings,and notes(default) |
Error log storage path specified in the main configuration file my.cnf, as it follows:
In order to facilitate maintenance needs, sometimes want the contents of the error log for backup and start recording again, this time you can take advantage of the MySQL FLUSH LOGS command tells MySQL backup old log files and generate a new log file. Backup file name to ".old" at the end.
Delete the error log
before mysql5.5.7: database administrator can delete the error log before long, to ensure that the hard disk space on the server mysql. mysql database, you can use mysqladmin command to open a new error log. mysqladmin command syntax is as follows: mysqladmin -u root -p flush-logs can also log in mysql database using FLUSH LOGS statement to open a new error log. After mysql5.5.7: The server will disable this feature. Use only renaming the original error log file, manually flush the log to create a new, as follows:
[root@mysql ~]# cd /usr/local/mysql/data/
[root@mysql data]# mv mysqld.err{,.old}
[root@mysql data]# mysqladmin -uroot -p flush-logs
Enter password: 2, the binary log
MySQL binary log records major changes in the database, in an efficient binary log format, and is a transaction-safe way to update the information contained in the logs available. The binary log contains all the data has been updated or has the potential to update the data. Also contains statements regarding the execution time of each update the database, it does not contain the statement does not modify any data. The main purpose of using the binary log is most likely to restore the database.
1) Start the binary log (by default, the binary log is off)
[root@mysql data]# vim /etc/my.cnf #编辑主配置文件
[mysqld]
basedir=/usr/local/mysql
datadir=/usr/local/mysql/data
port=3306
server_id=1
socket=/usr/local/mysql/mysql.sock
log-error=/usr/local/mysql/data/mysqld.err
log-bin=/usr/local/mysql/data/binary_log #指定二进制日志的路径及名称
expire_logs_days=10 #清除日志的天数
max_binlog_size=100M #单个日志文件的大小限制，超出会新建一个日志文件
[root@mysql data]# systemctl restart mysqld #重启MySQL使配置生效
[root@mysql data]# ll | grep binary #会在指定的路径下生成以下两个文件
-rw-r----- 1 mysql mysql 154 12月 30 20:59 binary_log.000001
-rw-r----- 1 mysql mysql 40 12月 30 20:59 binary_log.index
Log on to the database can also view, as follows:
2) Check the binary log
MySQL binary log stores all of the information changes, MySQL binary logs are often used. When MySQL binary log file is created, first of all to create a 'filename' is the name to '.index' suffix to the file; in order to create a 'filename' is the name to '.000001' suffix to the file. When the MySQL service restarts once to '.000001' suffix of a file may increase and extension plus 1
increments. If the log length exceeds the upper limit max_binlog_size will create a new log. Show binary logs; you can view the current binary log file name and file number. Binary log and can not directly see, if you want to view the contents of the log,
Can be viewed mysqlbinlog command:
mysql> show binary logs; <!---->
+-------------------+-----------+
| Log_name | File_size |
+-------------------+-----------+
| binary_log.000001 | 154 |
+-------------------+-----------+
1 row in set (0.00 sec)
You can also use the exit MySQL mysqlbinlog command in the command line:
[root@mysql data]# mysqlbinlog binary_log.000001 3) Delete the binary log
MySQL的二进制文件可以配置自动删除，同时MySQL提供了手动删除二进制文件的方法：
RESET MASTER：删除所有的二进制日志文件；
PURGE MASTER LOGS：只删除部分二进制日志文件；
Reset master：删除所有二进制日志 ；
Purge master logs to ‘二进制名’ ：删除单个二进制日志之前的。
mysql> purge master logs to "binary_log.000003"; <!--删除...03之前的二进制日志文件-->
mysql> purge master logs before '20180101'; <!--删除2018-01-01之前的日志文件-->4）通过二进制日志还原MySQL数据
关于通过二进制日志还原的具体过程，还是参考我之前的博文吧！如下：
MySQL的备份与恢复详解
3、事务日志
事务日志（InnoDB特有的日志，因为只有Innodb支持事务）可以帮助提高事务的效率。使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据本身持久到磁盘。事务日志采用追加的方式，因此写日志的操作是磁盘上一小块区域内的顺序I/O，而不像随机I/O需要在磁盘的多个地方移动磁头，所以采用事务日志的方式相对来说要快得多。事务日志持久以后，内存中被修改的数据在后台可以慢慢的刷回到磁盘。目前大多数的存储引擎都是这样实现的。 如果数据的修改已经记录到事务日志并持久化，但数据本身还没有写回磁盘，此时系统崩溃，存储引擎在重启时能够自动恢复这部分修改的数据。具有的恢复方式则视存储引擎而定。
1）查看事务日志的定义
mysql> show global variables like 'innodb_lo%';在上述指令输出的部分内容解释如下：
| innodb_flush_log_at_trx_commit | 1 #在事务提交时innodb是否同步日志从缓冲区到文件
中，当这个值为1（默认值）之时，在每个事务提交时，日志缓冲被写到日志文件，对日志文件做到磁盘操作的刷新，性能会很差造成大量的磁盘I/O但这种方式最安全；如果设为2,每次提交事务都会写日志，但并不会执行刷的操作。每秒定时会刷到日志文件。要注意的是，并不能保证100%每秒一定都会刷到磁盘，这要取决于进程的调度。每次事务提交的时候将数据写入事务日志，而这里的写入仅是调用了文件系统的写入操作，而文件系统是有缓存的，所以这个写入并不能保证数据已经写入到物理磁盘。设置为0，日志缓冲每秒一次地被写到日志文件，并且对日志文件做到磁盘操作的刷新，但是在一个事务提交不做任何操作。
注：刷写的概念
刷写其实是两个操作，刷（flush）和写（write），区分这两个概念是很重要的。在大多数的操作系统中，把Innodb的log buffer（内存）写入日志（调用系统调用write），只是简单的把数据移到操作系统缓存中，操作系统缓存同样指的是内存。并没有实际的持久化数据。
| 所以，通常设为0和2的时候，在崩溃或断电的时候会丢失最后一秒的数据，因为这个时候数据只是存在于操作系统缓存。之所以说“通常”，可能会有丢失不只1秒的数据的情况，比如说执行flush操作的时候阻塞了。 总结 设为1当然是最安全的，但性能页是最差的（相对其他两个参数而言，但不是不能接受）。如果对数据一致性和完整性要求不高，完全可以设为2,如果只最求性能，例如高并发写的日志服务器，设为0来获得更高性能。 |
innodb_locks_unsafe_for_binlog | OFF | innodb_log_buffer_size | 16777216 | innodb_log_checksums | ON | |||
|---|---|---|---|---|---|---|---|---|---|
| innodb_log_compressed_pages | ON | ||||||||
| innodb_log_file_size | 50331648 # log file size | ||||||||
| innodb_log_files_in_group | 2 # DB set several groups of the transaction log, the default is 2 | ||||||||
| innodb_log_group_home_dir | ./ defined position # innodb transaction logs group, this position is set as the default for MySQL datadir. |
Each transaction log is a file size of 50 megabytes (different versions of mysql difference): default to ib_logfile0, ib_logfile1 name exists in mysql.
<!---->