在数据库中,binlog和redolog有什么区别

发布网友 发布时间：2022-04-09 02:36

我来回答

共3个回答

懂视网 时间：2022-04-09 06:58

mysql如何保证redolog和binlog的一致性,安全性,效率。

和数据安转相关的参数

sync_binlog:控制binlog的刷新方式(写入到磁盘)

innodb_flush_log_at_trx_commit:在innodb下控制着redo的写入方式

innodb_support_xa:外部事务,用来保证binlog和redo一致性的,俗称两段式提交

binlog_order_commits:按照binlog的写入顺序提交事务,保证redo和binlog的已执行

binlog_max_flush_queue_time: leader线程搜集binlog的超时时间

2pc提交(官方支持)

(redo日志在prepare阶段就已经sync),绝大部分都比较支持这种说法

http://dev.mysql.com/doc/refman/5.6/en/binary-log.html

http://blog.itpub.net/15480802/viewspace-1411356

http://www.linuxidc.com/Linux/2015-11/124942.htm

http://www.2cto.com/database/201306/221413.html

2pc流程:(sync_binlog = 1,innodb_flush_log_at_trx_commit = 1 )

1.prepare阶段:sync redo 日志(未sync的redo存放于innodb_log_buffer_size中),系统自动完成

获取prepare_commit_mutex(一个全局锁,一次只能被一个事务获取)

2.生成binlog,将binlog写入文件系统(未提交之前binlog存放在binlog_cache_size中),sync binlog,这一步受sync_binlog控制

3.提交commit 将commit标志sync ,释放prepare_commit_mutex(这一步应该受innodb_flush_log_at_trx_commit的控制)

违背了这个参数的定义:innodb_flush_log_at_trx_commit

观点二:redo日志在最后的commit的时候才sync

http://blog.itpub.net/28218939/viewspace-1975809

2pc流程:(官方没有明显的支持这种说法)

1.prepare阶段:获取prepare_commit_mutex

2.生成binlog,将binlog写入文件系统(未提交之前binlog存放在binlog_cache_size中),sync binlog

3.提交commit 将redo log sync ,释放prepare_commit_mutex

这种方式会造成binlog的日志记录多余redo日志记录,在恢复的时候是如何恢复? 难道是以binlog为准,

不管这个事务的redo有没有提交 ,只要写binlog就认为该事务以提交(现阶段还没有找到有关该说法).

innodb数据恢复流程

1.查找未提交的redo日志(找xid)

2.用xid去binlog查找对应的日志记录

3.如果有就认为这个事务是提交的,并补充commit。如果没有就认为是没有提交的,在恢复的时候就rollback事务

###################################################################################################

以上2pc日志写入方式是在 mysql5.6之前的方式,当sync_binlog=1的时候 系统的性能非常糟糕。

从5.6 之后就开始采用BLGC方式写2pc日志,来提升性能

BLGC具体流程如下：(每一个阶段只有一个活跃的线程)

flush stage:搜集多个线程产生的binlog,依次放入flush队列的末尾,

sync stage:flush队列超时(binlog_max_flush_queue_time)或者没有线程产生binlog了 ,flush队列开始sync队列,将binlog写入磁盘(合并io)  

commit stage:队列进入提交阶段(这里只做提交操作,redo日志的写入已经在prepare写入)

个人理解：

flush stage:队列中的第一个线程为leader线程,后面的线程为follower线程,leader线程主要负责收集待提交binlog的线程,并且放入

flush 队列的末尾,直到没有找到需要提交binog的线程,或者超时(binlog_max_flush_queue_time),才进入sync stage

sync stage:如果flush stage队列为空,则之前leader线程依然为leader线程,负责binlog的sync,否则变成follower线程(合并执行sync)

commit stage:sync完binlog的线程被放入commit队列的末尾,等待提交

5.7 的组提交：

Step1. InnoDB Prepare，记录当前的LSN到thd中。 

Step2. 进入 Group Commit 的flush stage；Leader搜集队列，同时算出队列中最大的LSN。 

Step3. 将InnoDB的redo log write/fsync到指定的LSN  

Step4. 写Binlog并进行随后的工作(sync Binlog, InnoDB commit 

也就是将 redo log的write/sync延迟到了 binlog group commit的 flush stage 之后，sync binlog之前。

通过延迟写redo log的方式，显式的为redo log做了一次组写入(redo log group write)，并减少了(redo log) log_sys->mutex的竞争。

组提交

http://www.tuicool.com/articles/rEZr2q

http://mysqllover.com/?p=581

http://www.csdn.net/article/2015-01-16/2823591(淘宝内部mysql交流)

innodb数据丢失的问题：

http://www.360doc.com/content/14/1019/00/12904276_418041635.shtml

组提交的理解：

http://www.bitscn.com/pdb/mysql/201407/226226.html

本文出自 “SQLServer MySQL” 博客，请务必保留此出处http://dwchaoyue.blog.51cto.com/2826417/1784509

mysql如何保证redolog和binlog的一致性,安全性,效率。

标签：mysql 原理

热心网友 时间：2022-04-09 04:06

说说binlog

当启动Binlog后，事务会产生BinlogEvent，这些Event被看做事务数据的一部分。因此要保证事务的BinlogEvent和InnoDB引擎中的数据的一致性。所以带Binlog的CrashSafe要求MySQL宕机重启后能够保证：

- 所有已经提交的事务的数据仍然存在。

- 所有没有提交的事务的数据自动回滚。

- 所有已经提交了的事务的Binlog Event也仍然存在。

- 所有没有提交事务没有记录Binlog Event。

这些要求很好理解，如果重启后数据还在，但是Binlog Event没有了，就没办法复制到其他节点上了。如果重启后，数据没了，但是Binlog Event还在，那么不存在的数据就会被复制到其他节点上，从而导致主从的不一致。

为了保证带Binlog的CrashSafe，MySQL内部使用的两阶段提交(Two Phase Commit)。

Redo Log记录的是redo，那么redo是什么呢？通俗来讲，redo记录的是对应的记录改变的物理操作。说实话，过去的很长一段时间内，我对redo的认识也仅限于此，并没有好好深入理解redo记录的到底是什么。这次从redo的物理结构上深入理解下redo到底是什么。

Redo Log逻辑&物理结构

从逻辑上来讲，redo log记录是连续递增的，但是对应到物理文件就不一样了，考虑到磁盘空间，redo log被设计成了多个可循环写入的文件。InnoDB要求Redo Log，文件至少有2个，初始文件为 ib_logfile0和 ib_logfile1， ib_logfile0写完以后写 ib_logfile1，等到 ib_logfile1也写完了，从头又开始写 ib_logfile0，这样就形成了一个环形写入的结构。但是覆盖写入的前提是要确定哪个位置点是可以覆盖写的，哪些位置是不能覆盖写的，这个就是check point的工作了

热心网友 时间：2022-04-09 05:24