MySQL - 几种 log 的深入解析
mysql> show global variables like "%log%";
+--------------------------------------------+------------------------------------------------------+
| Variable_name | Value |
+--------------------------------------------+------------------------------------------------------+
| back_log | 80 |
| binlog_cache_size | 4194304 |
| binlog_checksum | CRC32 |
| binlog_direct_non_transactional_updates | OFF |
| binlog_error_action | ABORT_SERVER |
| binlog_format | ROW |
| binlog_group_commit_sync_delay | 0 |
| binlog_group_commit_sync_no_delay_count | 0 |
| binlog_gtid_simple_recovery | ON |
| binlog_max_flush_queue_time | 0 |
| binlog_order_commits | ON |
| binlog_row_image | FULL |
| binlog_rows_query_log_events | ON |
| binlog_stmt_cache_size | 32768 |
| binlog_transaction_dependency_history_size | 25000 |
| binlog_transaction_dependency_tracking | COMMIT_ORDER |
| expire_logs_days | 7 |
| general_log | OFF |
| general_log_file | /testdata/mysql/t3-dtpoc-dtpoc-web04.log |
| innodb_api_enable_binlog | OFF |
| innodb_flush_log_at_timeout | 1 |
| innodb_flush_log_at_trx_commit | 1 |
| 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 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | ./ |
| innodb_log_write_ahead_size | 8192 |
| innodb_max_undo_log_size | 1073741824 |
| innodb_online_alter_log_max_size | 134217728 |
| innodb_undo_log_truncate | OFF |
| innodb_undo_logs | 128 |
| log_bin | ON |
| log_bin_basename | /testdata/mysql/log/bin/mysql-bin |
| log_bin_index | /testdata/mysql/log/bin/mysql-bin.index |
| log_bin_trust_function_creators | ON |
| log_bin_use_v1_row_events | OFF |
| log_builtin_as_identified_by_password | OFF |
| log_error | /testdata/mysql/mysql.err |
| log_error_verbosity | 3 |
| log_output | FILE |
| log_queries_not_using_indexes | OFF |
| log_slave_updates | OFF |
| log_slow_admin_statements | OFF |
| log_slow_slave_statements | OFF |
| log_statements_unsafe_for_binlog | ON |
| log_syslog | OFF |
| log_syslog_facility | daemon |
| log_syslog_include_pid | ON |
| log_syslog_tag | |
| log_throttle_queries_not_using_indexes | 0 |
| log_timestamps | UTC |
| log_warnings | 2 |
| max_binlog_cache_size | 21474836480 |
| max_binlog_size | 1073741824 |
| max_binlog_stmt_cache_size | 18446744073709547520 |
| max_relay_log_size | 0 |
| relay_log | |
| relay_log_basename | /testdata/mysql/t3-dtpoc-dtpoc-web04-relay-bin |
| relay_log_index | /testdata/mysql/t3-dtpoc-dtpoc-web04-relay-bin.index |
| relay_log_info_file | relay-log.info |
| relay_log_info_repository | FILE |
| relay_log_purge | ON |
| relay_log_recovery | OFF |
| relay_log_space_limit | 0 |
| slow_query_log | OFF |
| slow_query_log_file | /testdata/mysql/t3-dtpoc-dtpoc-web04-slow.log |
| sql_log_off | OFF |
| sync_binlog | 1 |
| sync_relay_log | 10000 |
| sync_relay_log_info | 10000 |
+--------------------------------------------+------------------------------------------------------+
73 rows in set (0.00 sec)
在 MySQL基础概念 主要有以下几种日志
重做日志 (redo log)和回滚日志 (undo log)
二进制日志 (binlog)
错误日志 (errorlog)
慢查询日志 (slow log)
一般查询日志 (general log)
重做日志 (redo log)和回滚日志 (undo log)：
默认是在 ib_logfile0 和 ib_logfile1 循环来回写的
innodb_log_file_size：设置每个 redo log 文件的大小，默认是 50331648 byte，也就是 48 MB
nnodb_log_files_in_group：设置 redo log 文件的数量，默认是 2，最大值是 100
在执行 SQL 语句时, 其实仅仅生成了 redo log, 还生成了 binlog
binlog 的概念 : binlog 记录了数据库表结构和表数据变更, 比如 insert, delete, update, create 等, 不会记录查询，主要有两个作用数据恢复, 主从复制
想一想你们 DBA 平时是怎么恢复数据, 还原数据的, 我们回到 binlog, 是不是只需要找到前一时间点的 binlog 重放一下就可以还原了，在主从复制的场景也是同一个原理, master 将 binlog 发送给 slave, slave 执行 binlog 那么就复制了
binlog 记录的是 insert, delete, update, create 等 SQL 语句, 而 redo log 记录的是物理修改内容，可以理解为, binlog 记录的是逻辑变化, redo log 记录的是物理变化
刚才有提到 redo log 和 binlog 都会在执行 update 的时候写入, 那么他应该是怎么写入的呢 ?
写入 : redo log (prepare)
写入 : binlog
写入 : redo log（commit)
为什么写入 redo log 需要两段式提交, 而不是一次性写入呢 ? 我们可以分为两种情况分析一下
先写入 redo log, 再写入 binlog
如果 redo log 写入成功, 写入 binlog 失败了, 此时出现宕机情况, 我们根据上面的知识, master 库采用 redo log 恢复数据, 但是因为 binlog 写入失败了, 没有 binlog, 那么从库就没有这些数据, 导致主从不一致现象
先写入 binlog, 再写入 redo log
与上面的类似, 只不过会反过来, binlog 存在而 redo log 不存在, 会导致从库的数据是最新的, 而主库出现问题
两段式提交 :
先写入 redo log, 如果失败了, 回滚, 不再继续写入 binlog
如果 redo log 写入成功, binlog 写入失败, 回滚, 删除无效的 binlog
只有当 redo log 和 binlog 都写入成功了, 此次事务才会提交
也就是说, MySQL 需要保证 redo log 和 binlog 是一致的
general query log
普通查询日志, 记录了 MySQL 接收到的所有查询或命令操作, 无论是正确还是错误的都会进行记录, 因为记录的比较频繁, 产生开销较大所以默认是关闭的
slow query log
慢查询日志记录的是执行时间超过 long_query_time 和没有使用索引的查询语句, 只记录成功的语句
相关参数 :
slow_query_log : 1. 开启; 0. 关闭
long_query_time : 慢查询阈值
log_output : 输出方式
我们可以通过如下方式配置慢查询 :
show variables like '%slow_query_log%';
set global slow_query_log=1;
show variables like '%slow_query_log%';
要注意的是, 此处修改只对当前数据库生效, 在 MySQL 重启后会失效, 如果需要配置永久生效需要修改 my.cnf 文件
errorlog
从名字就可以看出来, 是错误日志, 记录着 MySQL 启动, 运行期间, 停止时的错误相关信息, 默认情况下这个是关闭的
我们可以指定 errorlog 的输出路径 :
编辑 my.cnf 写入 log-error = [path]
通过命令参数错误日志 mysqld_safe –user=mysql –log-error=[path] &