Mysql日志

发表于 更新于 分类于

redolog

redo log又称重做日志文件，用于记录事务操作的变化，记录的是数据修改之后的值，不管事务是否提交都会记录下来。在实例和介质失败（media failure）时，redo log文件就能派上用场，如数据库掉电，InnoDB存储引擎会使用redo log恢复到掉电前的时刻，以此来保证数据的完整性。

redo日志文件名

每个InnoDB存储引擎至少有1个重做日志文件组（group），每个文件组至少有2个重做日志文件，如默认的ib_logfile0和ib_logfile1。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kHz7zVve-1584783729916)(https://i.imgur.com/wbDzJFm.png)]

尽量保持Redo Log存储在一段连续的空间上。因此在系统第一次启动时就会将日志文件的空间完全分配。 以顺序追加的方式记录Redo Log,通过顺序IO来改善性能

未提交的事务和回滚了的事务也会记录Redo Log

影响redo log参数

  • innodb_log_file_size：指定每个redo日志大小，默认值48MB
  • innodb_log_files_in_group：指定日志文件组中redo日志文件数量，默认为2
  • innodb_log_group_home_dir：指定日志文件组所在路劲，默认值./，指mysql的数据目录datadir
  • innodb_mirrored_log_groups：指定日志镜像文件组的数量，默认为1，此功能属于未实现的功能，在5.6版本中废弃，在5.7版本中删除了

binlog

binlog记录了对MySQL数据库执行更改的所有操作，但是不包括SELECT和SHOW这类操作，因为这类操作对数据本身并没有修改。然后，若操作本身并没有导致数据库发生变化，那么该操作也会写入二进制日志

影响binlog的参数

  • max_binlog_size:指定单个binlog文件最大值。默认值为1g，最大值1g，如果超过该值，则产生新的binlog文件，后缀名+1，并记录到.index文件。
  • binlog_cache_size：使用事务表存储引擎（如innodb存储引擎）时，所有未提交的binlog日志会被记录到一个缓存中去，等事务提交时再将缓存中的binlog写入到binlog文件中。缓存的大小由binlog_cache_size决定，默认大小为32K
  • max_binlog_cache_size:如果事务需要的内存超过很多字节，则服务器会生成多于“max_binlog_cache_size”字节的存储错误所需的并发事务。 最小值为4096字节，最大可能值为16EB（exabytes）。 建议的最大值为4GB; 这是因为MySQL目前无法使用大于4GB的二进制日志位置。
  • expire_logs_days：表示binlog文件自动删除N天前的文件。默认值为0，表示不自动删除，最大值99.要手动删除binlog文件，可以使用purge binary logs语句
  • sync_binlog：sync_binlog=[N]表示没写缓冲N次就同步到磁盘，如果将N设为1，即sync_binlog表示采用同步写磁盘的方式来写二进制日志，在MySQL5.7.7后，默认为1。会对数据库的IO系统带来一定影响，但可以得到最大的高可用行。
  • binlog_checksum：该参数目的就是写入binlog进行校验，有两个值[crc32|none],默认为crc32
  • binlog-do-db：表示需要写入日志的数据库，默认为空，表示同步所有库
  • binlog-ignore-db：表示忽略写入日志的数据库，默认为空，表示同步所有库
  • log-slave-update:表示从master端取得并执行的binlog，写入自己的binlog文件中，一般应用在master=>slave=>slave架构
  • binlog_format：记录binlog的格式。[statement,row,mixed],在MySQL5.7.7之后，默认为row

redo log与binlog的区别

  • redo log是在InnoDB存储引擎层产生，而binlog是MySQL数据库的上层产生的，并且二进制日志不仅仅针对INNODB存储引擎，MySQL数据库中的任何存储引擎对于数据库的更改都会产生二进制日志。
  • 内容形式不同。MySQL的binlog是逻辑日志，其记录是对应的SQL语句。而innodb存储引擎层面的重做日志是物理日志。
  • 写入磁盘的时间点不同，二进制日志只在事务提交完成后进行一次写入。而innodb存储引擎的重做日志在事务进行中不断地被写入，并日志不是随事务提交的顺序进行写入的。
  • 二进制日志仅在事务提交时记录，并且对于每一个事务，仅在事务提交时记录，并且对于每一个事务，仅包含对应事务的一个日志。而对于innodb存储引擎的重做日志，由于其记录是物理操作日志，因此每个事务对应多个日志条目，并且事务的重做日志写入是并发的，并非在事务提交时写入，其在文件中记录的顺序并非是事务开始的顺序。
  • binlog不是循环使用，在写满或者重启之后，会生成新的binlog文件，redo log是循环使用。
  • binlog可以作为恢复数据使用，主从复制搭建，redo log作为异常宕机或者介质故障后的数据恢复使用

undo

事务开始之前，将当前事务的版本生成undo-log，当事务提交之后，undo log并不能立马被删除，而是放入待清理的链表，由purge线程判断是否由其他事务在使用undo段中表的上一个事务之前的版本信息，决定是否可以清理undo log的日志空间

异步复制（Asynchronous replication)
半同步复制（Semisynchronous replication）
全同步复制（Fully synchronous replication）