目录
- 前言
- 1. 什么是redo log？
- 1.1 redo日志文件名
- 1.2 影响redo log参数
- 1.3 redo log大小怎么设置？
- 2. 什么是binlog
- 2.1 binlog文件名
- 2.2 影响binlog的参数
- 2.3 查看binlog
- 3. redo log与binlog的区别
- 总结
前言
mysql中有六种日志文件，分别是：重做日志（redo log）、回滚日志（undo log）、二进制日志（binlog）、错误日志（errorlog）、慢查询日志（slow query log）、一般查询日志（general log），中继日志（relay log）。本文将详细介绍mysql redo log与binlog区别，下面来一起看看详细的介绍吧
1. 什么是redo log？
redo log又称重做日志文件，用于记录事务操作的变化，记录的是数据修改之后的值，不管事务是否提交都会记录下来。在实例和介质失败（media failure）时，redo log文件就能派上用场，如数据库掉电，innodb存储引擎会使用redo log恢复到掉电前的时刻，以此来保证数据的完整性。
1.1 redo日志文件名
每个innodb存储引擎至少有1个重做日志文件组（group），每个文件组至少有2个重做日志文件，如默认的ib_logfile0和ib_logfile1。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-khz7zvve-1584783729916)(https://i.imgur.com/wbdzjfm.png)]
1.2 影响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版本中删除了。
以下显示了一个关于redo日志组的配置：
mysql> show variables like 'innodb%log%'; +----------------------------------+------------+ | variable_name | value | +----------------------------------+------------+ ... | innodb_log_file_size | 2147483648 | | innodb_log_files_in_group | 2 | | innodb_log_group_home_dir | ./ | ... +----------------------------------+------------+ 15 rows in set (0.00 sec)
1.3 redo log大小怎么设置？
redo log文件的大小设置对于innodb存储引擎的性能有着非常大的影响。
- 设置的太大
设置很大以后减少了checkpoint，并且由于redo log是顺序i/o，大大提高了i/o性能。但是如果数据库意外出现了问题，比如意外宕机，那么需要重放日志并且恢复已经提交的事务，如果日志很大，那么将会导致恢复时间很长。甚至到我们不能接受的程度。
- 设置的太小
当一个日志文件写满后，innodb会自动切换到另外一个日志文件，而且会触发数据库的检查点（checkpoint），这会导致innodb缓存脏页的小批量刷新，会明显降低innodb的性能。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6gu4thaz-1584783729918)(https://i.imgur.com/y2m7cca.png)]
- 怎么设置？
参考官方文档’optimizing innodb redo logging’章节
把重做日志文件设置很大，甚至与缓冲池一样大。当innodb将重做日志文件写满时，它会触发数据库的检查点，把缓冲池的脏数据写入磁盘。小的重做日志文件会导致许多不必要的磁盘写入。虽然在以前版本中，大的重做日志文件导致冗长的恢复时间，但现在恢复速度更快，可以放心地使用大型重做日志文件。
考虑增加日志缓冲区的大小。 大型日志缓冲区可以在事务提交之前运行大型事务，而无需将日志写入磁盘。 因此，如果您有更新，插入或删除许多行的事务，则使日志缓冲区更大可以节省磁盘i/o. 使用innodb_log_buffer_size配置选项配置日志缓冲区大小。
设置innodb_log_write_ahead_size参数，表示redo log写前的块大小。innodb以512字节一个block的方式对齐写入ib_logfile文件，但文件系统一般以4096字节为一个block单位。如果即将写入的日志文件块不在os cache时，就需要将对应的4096字节的block读入内存，修改其中的512字节，然后再把该block写回磁盘。当 当前写入文件的偏移量不能整除该值时，则补0，多写一部分数据。这样当写入的数据是以磁盘block size对齐时，就可以直接write磁盘，而无需read-modify-write这三步了。
2. 什么是binlog
binlog记录了对mysql数据库执行更改的所有操作，但是不包括select和show这类操作，因为这类操作对数据本身并没有修改。然后，若操作本身并没有导致数据库发生变化，那么该操作也会写入二进制日志。例如：
root@localhost [(none)] 08:30:14>set binlog_format = 'statement'; root@localhost [(none)] 08:30:26>use test; database changed root@localhost [test] 08:30:33>select * from account; +----------+---------+ | acct_num | amount | +----------+---------+ | 138 | 14.98 | | 141 | 1937.50 | | 97 | -100.00 | +----------+---------+ 3 rows in set (0.00 sec) root@localhost [test] 08:30:53>show master status; +----------------------+----------+--------------+------------------+--------------------------------------------+ | file | position | binlog_do_db | binlog_ignore_db | executed_gtid_set | +----------------------+----------+--------------+------------------+--------------------------------------------+ | my3306_binlog.000052 | 471 | | | e4382832-949d-11e8-97ba-080027793430:1-205 | +----------------------+----------+--------------+------------------+--------------------------------------------+ root@localhost [test] 08:31:04>update account set acct_num=139 where amount=14; query ok, 0 rows affected (0.01 sec) rows matched: 0 changed: 0 warnings: 0 root@localhost [test] 08:31:35>show binlog events in 'my3306_binlog.000052'; +----------------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------+ | log_name | pos | event_type | server_id | end_log_pos | info | +----------------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------+ | my3306_binlog.000052 | 4 | format_desc | 1003306 | 123 | server ver: 5.7.23-log, binlog ver: 4 | | my3306_binlog.000052 | 123 | previous_gtids | 1003306 | 194 | e4382832-949d-11e8-97ba-080027793430:1-204 | | my3306_binlog.000052 | 194 | gtid | 1003306 | 259 | set @@session.gtid_next= 'e4382832-949d-11e8-97ba-080027793430:205' | | my3306_binlog.000052 | 259 | query | 1003306 | 331 | begin | | my3306_binlog.000052 | 331 | table_map | 1003306 | 384 | table_id: 108 (test.account) | | my3306_binlog.000052 | 384 | update_rows | 1003306 | 440 | table_id: 108 flags: stmt_end_f | | my3306_binlog.000052 | 440 | xid | 1003306 | 471 | commit /* xid=14 */ | | my3306_binlog.000052 | 471 | gtid | 1003306 | 536 | set @@session.gtid_next= 'e4382832-949d-11e8-97ba-080027793430:206' | | my3306_binlog.000052 | 536 | query | 1003306 | 615 | begin | | my3306_binlog.000052 | 615 | query | 1003306 | 736 | use `test`; update account set acct_num=139 where amount=14 | | my3306_binlog.000052 | 736 | query | 1003306 | 816 | commit | +----------------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------+ 11 rows in set (0.01 sec)
从上述例子中可以看到，mysql数据库首先进行update操作，从返回的结果看到changed为0，这意味着该操作并没有导致数据库的变化。但是通过show binlog events in ‘…’可以看出在二进制日志中的确进行了记录。
如果想记录select和show操作，那只能使用查询日志–general_log[={0|1}](1为启用)
2.1 binlog文件名
通过配置参数–log-bin[=name]可以启动二进制日志。如果不指定那么，则默认binlog日志文件名为主机名，后缀名为binlog的序列号，默认路劲为数据目录(datadir).你也可以指定绝对路径，如：
# cat /etc/my.cnf|grep log-bin log-bin = /data/mysql/mysql3306/logs/my3306_binlog # cd /data/mysql/mysql3306/logs # ls -l total 60 -rw-r----- 1 mysql mysql 194 aug 15 10:04 my3306_binlog.000045 -rw-r----- 1 mysql mysql 1552 aug 16 10:01 my3306_binlog.000046 -rw-r----- 1 mysql mysql 2953 aug 17 09:56 my3306_binlog.000047 -rw-r----- 1 mysql mysql 1239 aug 20 10:29 my3306_binlog.000048 -rw-r----- 1 mysql mysql 217 aug 20 10:29 my3306_binlog.000049 -rw-r----- 1 mysql mysql 19567 aug 21 10:24 my3306_binlog.000050 -rw-r----- 1 mysql mysql 194 aug 22 08:01 my3306_binlog.000051 -rw-r----- 1 mysql mysql 816 aug 22 08:31 my3306_binlog.000052 -rw-r----- 1 mysql mysql 384 aug 22 08:01 my3306_binlog.index
2.2 影响binlog的参数
- max_binlog_size:指定单个binlog文件最大值。默认值为1g，最大值1g，如果超过该值，则产生新的binlog文件，后缀名+1，并记录到.index文件。
- binlog_cache_size：使用事务表存储引擎（如innodb存储引擎）时，所有未提交的binlog日志会被记录到一个缓存中去，等事务提交时再将缓存中的binlog写入到binlog文件中。缓存的大小由binlog_cache_size决定，默认大小为32k。
binlog_cache_size是基于session的，也就是说，当一个线程开始一个事务时，mysql会自动分配一个大小为binlog_cache_size的缓存，因此该值的设置需要非常小心，不能设置过大。
当一个事务的记录大于设定的binlog_cache_size时，mysql会把缓存中的日志写入一个临时文件中，因此该值又不能设的太小。
那怎么设置呢？
通过show global status命令查看binlog_cache_use,binlog_cache_disk_use的状态，以判断当前binlog_cache_size设置是否合适。
通过show global status命令查看binlog_cache_use,binlog_cache_disk_use的状态，以判断当前binlog_cache_size设置是否合适。 binlog_cache_use：记录了使用缓存写binlog次数 binlog_cache_disk_use：记录了使用临时文件写binlog次数。 示例： root@localhost [(none)] 09:55:48>show variables like 'binlog_cache_size'; +-------------------+---------+ | variable_name | value | +-------------------+---------+ | binlog_cache_size | 32768 | +-------------------+---------+ 1 row in set (0.00 sec) root@localhost [(none)] 09:53:26>show global status like 'binlog_cache%'; +-----------------------+-------+ | variable_name | value | +-----------------------+-------+ | binlog_cache_disk_use | 0 | | binlog_cache_use | 33553 | +-----------------------+-------+ 2 rows in set (0.00 sec) 使用缓存次数为33553，临时文件使用次数为0。说明32kb的缓存大小对于当前mysql数据库是够用的。
- 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语句。例如：
purge { binary | master } logs
{ to 'log_name' | before datetime_expr }
purge binary logs to 'mysql-bin.010';
purge binary logs before '2008-04-02 22:46:26';
purge binary logs before now() - interval 3 days;
- binlog_rows_query_log_events：默认为不启用，启用binlog_rows_query_log_events时，可以在binary log中记录原始的sql语句
root@localhost [test] 08:07:52>show binlog events in 'my3306_binlog.000056'; +----------------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------+ | log_name | pos | event_type | server_id | end_log_pos | info | +----------------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------+ | my3306_binlog.000056 | 4 | format_desc | 1003306 | 123 | server ver: 5.7.23-log, binlog ver: 4 | | my3306_binlog.000056 | 123 | previous_gtids | 1003306 | 194 | e4382832-949d-11e8-97ba-080027793430:1-206 | | my3306_binlog.000056 | 194 | gtid | 1003306 | 259 | set @@session.gtid_next= 'e4382832-949d-11e8-97ba-080027793430:207' | | my3306_binlog.000056 | 259 | query | 1003306 | 331 | begin | | my3306_binlog.000056 | 331 | table_map | 1003306 | 375 | table_id: 108 (test.t) | | my3306_binlog.000056 | 375 | update_rows | 1003306 | 421 | table_id: 108 flags: stmt_end_f | | my3306_binlog.000056 | 421 | xid | 1003306 | 452 | commit /* xid=16 */ | | my3306_binlog.000056 | 452 | gtid | 1003306 | 517 | set @@session.gtid_next= 'e4382832-949d-11e8-97ba-080027793430:208' | | my3306_binlog.000056 | 517 | query | 1003306 | 589 | begin | | my3306_binlog.000056 | 589 | table_map | 1003306 | 633 | table_id: 108 (test.t) | | my3306_binlog.000056 | 633 | write_rows | 1003306 | 673 | table_id: 108 flags: stmt_end_f | | my3306_binlog.000056 | 673 | xid | 1003306 | 704 | commit /* xid=18 */ | | my3306_binlog.000056 | 704 | gtid | 1003306 | 769 | set @@session.gtid_next= 'e4382832-949d-11e8-97ba-080027793430:209' | | my3306_binlog.000056 | 769 | query | 1003306 | 841 | begin | | my3306_binlog.000056 | 841 | rows_query | 1003306 | 887 | # insert into t select 3 | | my3306_binlog.000056 | 887 | table_map | 1003306 | 931 | table_id: 108 (test.t) | | my3306_binlog.000056 | 931 | write_rows | 1003306 | 971 | table_id: 108 flags: stmt_end_f | | my3306_binlog.000056 | 971 | xid | 1003306 | 1002 | commit /* xid=24 */ | +----------------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------+ # insert into t select 3 就是开启binlog_rows_query_log_events选项后，记录的原始sql语句。
- 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。
存储引起对binlog格式的支持情况：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-drzplzha-1584783729919)(https://i.imgur.com/nfgk19h.png)]
2.3 查看binlog
使用mysqlbinlog程序进行查看，例如：
[root@mysqldb1 10:58:18 /data/mysql/mysql3306/logs] # mysqlbinlog -v --base64-output=decode-rows my3306_binlog.000052|more /*!50530 set @@session.pseudo_slave_mode=1*/; /*!50003 set @old_completion_type=@@completion_type,completion_type=0*/; delimiter /*!*/; # at 4 #180822 8:01:00 server id 1003306 end_log_pos 123 crc32 0xcbe20047 start: binlog v 4, server v 5.7.23-log created 180822 8:01:00 at startup # warning: this binlog is either in use or was not closed properly. rollback/*!*/; # at 123 #180822 8:01:00 server id 1003306 end_log_pos 194 crc32 0xb1bda518 previous-gtids # e4382832-949d-11e8-97ba-080027793430:1-204 # at 194 #180822 8:10:59 server id 1003306 end_log_pos 259 crc32 0xeced9ada gtid last_committed=0 sequence_number=1 rbr_only=yes /*!50718 set transaction isolation level read committed*//*!*/; set @@session.gtid_next= 'e4382832-949d-11e8-97ba-080027793430:205'/*!*/; # at 259 #180822 8:10:59 server id 1003306 end_log_pos 331 crc32 0x6da7802a query thread_id=2 exec_time=0 error_code=0 set timestamp=1534896659/*!*/; set @@session.pseudo_thread_id=2/*!*/; set @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; set @@session.sql_mode=1436549152/*!*/; set @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\c utf8 *//*!*/; set @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=45/*!*/; set @@session.lc_time_names=0/*!*/; set @@session.collation_database=default/*!*/; begin /*!*/; # at 331 #180822 8:10:59 server id 1003306 end_log_pos 384 crc32 0xf239dd79 table_map: `test`.`account` mapped to number 108 # at 384 #180822 8:10:59 server id 1003306 end_log_pos 440 crc32 0xef6460fe update_rows: table id 108 flags: stmt_end_f ### update `test`.`account` ### where ### @1=137 ### @2=14.98 ### set ### @1=138 ### @2=14.98 # at 440 #180822 8:10:59 server id 1003306 end_log_pos 471 crc32 0x360f05d0 xid = 14 commit/*!*/; # at 471 #180822 8:31:35 server id 1003306 end_log_pos 536 crc32 0x662c8f17 gtid last_committed=1 sequence_number=2 rbr_only=no set @@session.gtid_next= 'e4382832-949d-11e8-97ba-080027793430:206'/*!*/; # at 536 #180822 8:31:35 server id 1003306 end_log_pos 615 crc32 0xa728a60a query thread_id=3 exec_time=0 error_code=0 set timestamp=1534897895/*!*/; begin /*!*/; # at 615 #180822 8:31:35 server id 1003306 end_log_pos 736 crc32 0x7513aa73 query thread_id=3 exec_time=0 error_code=0 use `test`/*!*/; set timestamp=1534897895/*!*/; update account set acct_num=139 where amount=14 /*!*/; # at 736 #180822 8:31:35 server id 1003306 end_log_pos 816 crc32 0x1cd7f41c query thread_id=3 exec_time=0 error_code=0 set timestamp=1534897895/*!*/; commit /*!*/; set @@session.gtid_next= 'automatic' /* added by mysqlbinlog */ /*!*/; delimiter ; # end of log file /*!50003 set completion_type=@old_completion_type*/; /*!50530 set @@session.pseudo_slave_mode=0*/;
3. redo log与binlog的区别
第一:redo log是在innodb存储引擎层产生，而binlog是mysql数据库的上层产生的，并且二进制日志不仅仅针对innodb存储引擎，mysql数据库中的任何存储引擎对于数据库的更改都会产生二进制日志。
第二：两种日志记录的内容形式不同。mysql的binlog是逻辑日志，其记录是对应的sql语句。而innodb存储引擎层面的重做日志是物理日志。
第三：两种日志与记录写入磁盘的时间点不同，二进制日志只在事务提交完成后进行一次写入。而innodb存储引擎的重做日志在事务进行中不断地被写入，并日志不是随事务提交的顺序进行写入的。
二进制日志仅在事务提交时记录，并且对于每一个事务，仅在事务提交时记录，并且对于每一个事务，仅包含对应事务的一个日志。而对于innodb存储引擎的重做日志，由于其记录是物理操作日志，因此每个事务对应多个日志条目，并且事务的重做日志写入是并发的，并非在事务提交时写入，其在文件中记录的顺序并非是事务开始的顺序。
第四：binlog不是循环使用，在写满或者重启之后，会生成新的binlog文件，redo log是循环使用。
第五：binlog可以作为恢复数据使用，主从复制搭建，redo log作为异常宕机或者介质故障后的数据恢复使用。
总结
到此这篇关于mysql中redo log与binlog区别的文章就介绍到这了,更多相关mysql redo log与binlog区别内容请搜索www.887551.com以前的文章或继续浏览下面的相关文章希望大家以后多多支持www.887551.com！