赞
踩
我们知道 redo log 的写入机制是事务中有更新操作时就会将更新操作记录在 redo log buffer 中,在事务提交时,根据相关参数的设定,按照不同逻辑持久化到磁盘文件。由于多个事务共用一个 redo log buffer,当有其他并行事务提交时,未提交的事物的 redo log 也会被持久化到磁盘。这个时候,崩溃恢复时因为两阶段提交的机制不会导致未提交事务数据被恢复。
binlog 区别于 redo log,每个事务所在的线程都会存在一个 binlog cache,并且只有事务提交时会持久化到磁盘文件(binlog file)。注意磁盘文件是共用的,只有 binlog cache 是单个线程一个。具体流程是事务执行过程中先把日志写到 binlog cache 中,在事务提交的时候持久化到磁盘文件。
由于一个事务的 binlog 是不能被拆开的,因此不论这个事务多大,也要确保一次性写入,这就涉及到了binlog cache保存这个事务binlog 的能力
参数 binlog_cache_size 用于控制单个线程的 binlog cache 大小,当一个事务的 binlog 数据超过了设定的大小,则需要暂存到磁盘,等事务提交的时候,再把 binlog cache 中的完整的事务持久化到磁盘。
与 redo log buffer 持久化到磁盘一样,binlog cache 也可以设置持久化到磁盘的操作,即可以延迟写。
binlog有三种格式:Statement、Row 以及 Mixed。从安全性来看,ROW(最安全)、MIXED(不推荐)、STATEMENT(不推荐)。
redo log 是物理日志,记录的是在某个表做了什么修改,用于 MySQL 异常重启时数据恢复,所以恢复速度比 bin log 更快。
binlog_cache_size
用于控制单个线程内 binlog cache 所占内存的大小。sync_binlog
控制的。sync_binlog=0 的时候,表示每次提交事务都只 write,不 fsync;
sync_binlog=1 的时候,表示每次提交事务都会执行 fsync;
sync_binlog=N(N>1) 的时候,表示每次提交事务都 write,但累积 N 个事务后才 fsync。
binlog_cache_size
,用于控制每个线程 binlog cache 的大小将 sync_binlog 设置为一个比较大的数,可以有效提升性能,但是同时会带来一个问题,主机发生异常重启会丢失一部分 binlog 数据。通常设置为 100~1000。
innodb_flush_log_at_trx_commit
0:表示每次事务提交时都只是把 redo log 留在 redo log buffer 中 ;
1:表示每次事务提交时都将 redo log 直接持久化到磁盘;
2:表示每次事务提交时都只是把 redo log 写到 page cache。
innodb_log_file_size
innodb_log_files_in_group
innodb_log_buffer_size
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。