做专利网站的重要点,点击网站出现微信二维码的链接怎么做,网站建设玖首选金手指,wordpress页面设置red log buffer、data buffer、binlog cache。在O和M中#xff0c;讲究日志先行策略#xff0c;就是一条DML语句进入数据库之后#xff0c;都会先写日志#xff0c;再写数据文件。 1.red log#xff0c; 重做日志文件#xff0c;用于记录事务操作的变化#xff0c;记录的…red log buffer、data buffer、binlog cache。在O和M中讲究日志先行策略就是一条DML语句进入数据库之后都会先写日志再写数据文件。 1.red log 重做日志文件用于记录事务操作的变化记录的是数据修改之后的值不管事务是否提交都会记录下来。在实例和介质失败时重做日志文件就能派上用场如数据库掉电InnoDB存储引擎会使用重做日志恢复到掉电前的时刻以此来保证数据的完整性。 默认情况下至少有两个red log文件在磁盘上用ib_logfile(0-N)命名。 red log写的方式是顺序和循环写当写满最后一个文件时会重新从第一个文件开始写写满日志文件会产生切换操作并执行 checkpoint,触发脏页的刷新。MySQL数据库重启过程中如果参数文件中的red log值大小与当前redo log值不一致会把现有redo log 删除并按照参数文件中设置的大小重新生成新的redo log文件。 1在磁盘中生成 red log文件之前数据是先写在red log buffer中的。 通过innodb_flush_log_at_trx_commit参数来控制。该参数分别为0120的含义:red log thread每隔1秒会将red log buffer中的数据写入red log文件同时进行刷盘操作。保证数据确实写入磁盘。在此参数下每次事务提交并不会触发red log thread将日志缓冲中的数据写入red log文件。1的含义:每次事务提交时都会触发redo log thread将日志缓冲中的数据写入文件并flush到磁盘。该设置下是最安全的模式。保证数据库在主机断电OS crash下不会丢失任何已提交的数据。2的含义:每次事务提交时都会把redo log buffer的数据写入redo log 文件但是不会同时刷新到磁盘。三种模式下 0性能最好但是不安全MySQL进程一旦崩溃会导致丢失一秒的数据。 1是安生性最高但数据库性能最慢。 2是介于两者之间。 2master thread:每秒进行刷新 3redo log buffer:使用超过一半的时候会触发刷新。 2.binlog DML语句既会写red log 文件也会写binlog文件。功能主要用于备份恢复和主从复制。 从binlog cache刷新到磁盘的binlog文件中需要通过sync_binlog参数来决定。 a.sync_binlog0,当事务提交之后MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息来到磁盘而让Filesystem自行决定什么时候来做同步或都cache满了之后才同步到磁盘。 b.sync_binlogN,每进行N次事务提交之后MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。 red log和binlog区别 两都都是记录了对数据真实的修改的语句。同时有以下区别 1.记录内容的不同。 binlog是逻辑日志记录所有数据的改变信息。 red log记录的是物理日志记录所有InnoDB表数据的变化。 2.记录内容的时间不同。 binlog 记录commit完毕之后的DML和DDLSQL语句。 red log记录事务发起之后的DML和DDL SQL语句。 3.文件使用方式的不同。 binlog不是循环使用在写满或者实例重启之后会生成新的binlog文件。 red log是循环使用最后一个文件写满之后会重新写第一个文件。 4.作用不同。 binlog可以作为恢复数据使用主从复制搭建。 red log作为异常宕机中都介质故障后的数据恢复使用。 有以下关联 在主从环境中从库需要通过二进制日志来应用主库提交的事务但如果主库red log已经提交而二进制日志没有保持一致则会造成从库数据丢失主从数据不一致的情况见以下分析 MySQL两阶段提交过程 a.准备阶段transaction prepare:事务SQL语句先写入redo log buffer,然后做一个事务准备标记再将log buffer中的数据刷新到redo log. b.提交阶段(commit):将事务产生的binlog写入文件刷入磁盘。 再在redo log中做一个事务提交的标记并把binlog写成功的标记也一并写入red log文件。 结合以下两场景分析两阶段如何保持数据库的一致性: Sense one: 准备阶段redo log刷新到磁盘了但是binlog写盘前发生了MySQL实例crash,这是会发生怎么的操作呢 即使redo log写盘成功了但由于binlog未写入成功我们需要执行回滚操作来保证数据的一致性。 Sense two: 提交阶段binlog写盘成功了此时MySQL实例发生crash,此时binlog已经确保写成功了我们在重启实例进行恢复时只需要让redo log重做一次就可以了。 总结一下 其实只要binlog写入完成则在主从复制环境中都会正常完成事务。 最后看一下脏页的刷新条件 1重做日志ib_logfile文件写满后在切换的过程中会执行checkpoint会触发脏页的刷新。 2通过innodb_max_dirty_pages_pct参数的值控制。该参数是指在buffer pool中dirty page所占的百分比达到设置的值就会触发脏页的刷新。 3由innodb_adaptive_flushing参数控制。转载于:https://www.cnblogs.com/chinaops/p/9634780.html
