innodb二阶段日志提交机制,innodb日志提交分分快

作者:分分快三全天计划网站

 # 0:如果innodb_flush_log_at_trx_commit的值为0,log buffer每秒就会被刷写日志文件到磁盘,提交事务的时候不做任何操作(执行是由mysql的master thread线程来执行的。
 # 主线程中每秒会将重做日志缓冲写入磁盘的重做日志文件(REDO LOG)中。不论事务是否已经提交)默认的日志文件是ib_logfile0,ib_logfile1
 # 1:当设为默认值1的时候,每次提交事务的时候,都会将log buffer刷写到日志。
 # 2:如果设为2,每次提交事务都会写日志,但并不会执行刷的操作。每秒定时会刷到日志文件。要注意的是,并不能保证100%每秒一定都会刷到磁盘,这要取决于进程的调度。
 # 每次事务提交的时候将数据写入事务日志,而这里的写入仅是调用了文件系统的写入操作,而文件系统是有 缓存的,所以这个写入并不能保证数据已经写入到物理磁盘
 # 默认值1是为了保证完整的ACID。当然,你可以将这个配置项设为1以外的值来换取更高的性能,但是在系统崩溃的时候,你将会丢失1秒的数据。
 # 设为0的话,mysqld进程崩溃的时候,就会丢失最后1秒的事务。设为2,只有在操作系统崩溃或者断电的时候才会丢失最后1秒的数据。InnoDB在做恢复的时候会忽略这个值。
 # 总结
 # 设为1当然是最安全的,但性能页是最差的(相对其他两个参数而言,但不是不能接受)。如果对数据一致性和完整性要求不高,完全可以设为2,如果只最求性能,例如高并发写的日志服务器,设为0来获得更高性能

innodb二阶段日志提交机制,innodb日志提交

前些天在查看关于innodb_flush_log_at_trx_commit的官网解释时产生了一些疑问,关于innodb_flush_log_at_trx_commit参数的详细解释参见官网:

其中有一段是这么写的: With a value of 2, the contents of the InnoDB log buffer are written to the log file after each transaction commit and the log file is flushed to disk approximately once per second. 意思是:如果innodb_flush_log_at_trx_commit的值设为2,那么log buffer里的内容会在每次提交时被写入log file,然后logfile也会被flush到disk。 由于innodb的log file据我所知是在硬盘上的ib_logfile,所以对于这里的log file被flush到disk很疑惑,难道log buffer和disk之间还存在了一层可以缓存log file的结构?   在查阅了大量中英文资料后,总算有了初步的了解,暂总结于此。   一、名词解释 在innodb存储引擎中,有一种独有的log file,即redo log file,因此对于innodb存储引擎来说,就存在两种logfile:redo log和binlog. redo log:即data目录下的ib_logfile0,ib_logfile1(个数由innodb_log_files_in_group控制),innodb存储引擎特有,在内存中有相应的redo log buffer。 因此写redo时的3层结构为:redo log buffer--->文件系统缓存中的redo logfile--->disk上的redo log file binlog:默认在data目录下,也可以通过log_bin参数直接指定路径,文件名为默认为<hostname>-bin前缀的文件,在内存中没有log buffer。 因此写binlog时的2层结构为:文件系统缓存中的binlog--->disk上的binlog   二、二阶段日志写的流程 原图来自: 分分快三全天计划网站 1 当开启binlog后,如果会话发出了commit的请求,那么在committed之前,一系列的流程为: 1.prepare阶段: 将log buffer的事务更改和事务commit信息写入文件系统缓存中的redo log file,注意log buffer和undo buffer(也叫undo page)是在事务执行过程中就即时生成的(undo默认在系统表空间中,5.6以后也可以自己指定独立的表空间),文件系统缓存中的redo log 是否flush到disk,取决于innodb_flush_log_at_trx_commit参数。 innodb_flush_log_at_trx_commit:

  • 此值为0表示:redo log buffer的内容每秒会被写入文件系统缓存的redo log里,同时被flush(固化)到disk上的redo log file中。
  • 此值为1表示:redo log buffer的内容会在事务commit时被写入文件系统缓存的redo log里,同时被flush(固化)到disk上的redo log file中。

  • 此值为2表示:redo log buffer的内容会在事务commit时被写入文件系统缓存的redo log里,而文件系统缓存的redo log每秒一次被flush(固化)到disk上的redo log file中。

2.写binlog阶段: 此阶段调用两个方法write()和fsync(),前者负责写文件系统缓存中的binlog,后者负责将文件系统缓存中的binlog写入disk上的bin log,前者在此阶段一定会被调用,后者的调用机制由sync_binlog参数控制。 关于sync_binlog参数:

  • sync_binlog=0:表示fsync()的调用完全交给操作系统,即文件系统缓存中的binlog是否刷新到disk完全由操作系统控制。

  • sync_binlog=1:表示在事务提交时,binlog一定会被固化到disk

  • sync_innodb二阶段日志提交机制,innodb日志提交分分快三全天计划网站。binlog=N(N>1):数据库崩溃时,可能会丢失N-1个事务,具体原理也详见

3.最终commit阶段: 此阶段主要包含:server告诉存储引擎,binlog和redo log都已写好(至少在文件系统缓存级别已经写好),按正常机制提交数据吧,然后向会话返回committed的确认提交信息。   三、故障恢复解析 1.如果在一阶段后崩溃,那么由于binlog未写,数据显然未能提交,算是失败的事务,无需前滚或回滚。(对于oracle数据库则情况更为复杂,有些大事务即便未提交也可能有已经固化的数据,那么就需要进行回滚。还不清楚mysql的大事务是否也有未提交数据提前写入disk的机制) 2.如果在二阶段后崩溃,那么只有一种情况可以保证数据完全不丢失,即:innodb_flush_log_at_trx_commit和sync_binlog都设置为1,此时redo log和binlog都被固化到磁盘,可以保证commit后未写入的数据在recovery时被前滚提交。如果任意一个不为1,那么都可能造成binlog和redo log不一致的情况,此时很可能丢失事务。 因此,为保证主从完全一致,主库的innodb_flush_log_at_trx_commit和sync_binlog都必须设置为1。   至于5.6以后的为解决并发事务提交异常而出现的3阶段组提交机制,有待继续研究。

 

前些天在查看关于 innodb_flush_log_at_trx_innodb二阶段日志提交机制,innodb日志提交分分快三全天计划网站。commit的官网解释时产生了一些疑问,关于 innodb_flush_log_at_t...

 

innodb二阶段日志提交机制,innodb日志提交分分快三全天计划网站。  注:

 innodb_flush_log_at_trx_commit 可选值:

       这个mysql得配置文件my.cnf,是我现在环境里常用得,包含基础配置及一些优化,本来一直在我得有道笔记里记录着,之前一直没有写博客的习惯,最近刚开始注册博客,就将这些东西贴出来,供需要得朋友拿来使用及学习。

[client]
port=3306
socket =/data/mysqldata/mysql.sock
[mysql]
default-character-set=utf8
[mysqld]
user=mysql
port=3306
character-set-server=utf8
basedir=/usr/local/mysql
datadir=/data/mysqldata
socket =/data/mysqldata/mysql.sock
log-error =/usr/local/mysql/log/error.log
#是否开启慢查询日志,默认状态为开启,1 ,关闭 0
slow_query_log
#慢查询日志得超时时间
long_query_time=3
#是否记录不使用索引得查询记录(将会写入到慢查询日志中)
log_queries_not_using_indexes = 0
#慢查询日志得日志路径,需配合上面参数使用
log-slow-queries=/usr/local/mysql/log/log-slow-queries.log
pid-file =/data/mysqldata/mysql.pid
#设置默认数据库引擎
default-storage-engine=INNODB
#设置sql模式:禁止grant创建密码为空得用户,如果需要的存储引擎被禁用或未编译,那么抛出错误,一种严格得select查询GROUP BY操作,详细可参考网络上得解释
sql-mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,ONLY_FULL_GROUP_BY"
#最大连接数
max_connections=300
#指定查询结果缓存大小
query_cache_size=32M
#指定表的高速缓存,每打开一个表,表都会放入这里,可以加速访问,此值设置可以参考open_tables的值,若两者相等,则此值应该增加
table_open_cache=512
#设置线程缓存数,此值小的话,MySQL频繁创建线程,会消耗资源,配置的值参考:1G 8 、2G 16 、3G 32 。。。
thread_cache_size=38
#如果临时文件会变得超过索引,不要使用快速排序索引方法来创建一个索引
myisam_max_sort_file_size=1G
#MyISAM设置恢复表之时使用的缓冲区,REPAIR TABLE或用CREATE INDEX创建索引或ALTER TABLE过程中排序 MyISAM索引分配的缓冲区
myisam_sort_buffer_size=64M 
#设置索引块的缓冲区大小
key_buffer_size=290M 
#读查询操作的缓冲区大小
read_buffer_size = 1M 
#设置随机读缓冲区大小
read_rnd_buffer_size = 8M 
#设置MySQL执行排序的时候使用的大小
sort_buffer_size = 1M 
#如下注解
innodb_flush_log_at_trx_commit=2 
#innodb日志缓冲区大小,建议为1-8M
innodb_log_buffer_size=4M 
#innodb缓冲区大小,此值越大,可以减少磁盘IO,一般设置为内存的80%
innodb_buffer_pool_size=2G 
#设置innodb的日志文件大小,过大的话,将来做数据恢复会很慢
innodb_log_file_size=512M
# 并发数限制,设置为0则表示不限制并发
innodb_thread_concurrency=18 
#设置innodb为独立表空间模式,也就是每个表单独使用一个表空间,易于维护,
innodb_file_per_table = 1 
#设置innodb文件格式
innodb_file_format = Barracuda
#交互式连接的超时时间,单位为秒,默认8小时
interactive_timeout = 86400
#非交互式连接的超时时间
wait_timeout = 2147482 
#最大允许的包大小,
max_allowed_packet = 12M
#不使用DNS对连接进行解析
skip_name_resolve 
#以下两个选项用来设置读写IO的线程数,根据CPU核数来设置
innodb_write_io_threads = 4
innodb_read_io_threads = 4
# binlog
log-bin = /data/mysqldata/mysql-client-bin
server-id= 1
[mysqldump]  
max_allowed_packet = 512M

写在开篇:

本文由分分快三计划发布,转载请注明来源

关键词: 分分快三计划