ppt下载模板免费网站,门户网站建设企业,工程项目管理软件有哪些,创建网站怎么收费我们先简单了解一下大致的刷盘时机#xff0c;然后配合两阶段提交和组提交来看
redo log的刷盘时机
MySQL 正常关闭时#xff1b;当 redo log buffer 中记录的写入量大于 redo log buffer内存空间的一半时#xff0c;会触发落盘#xff1b; PS#xff1a;为什么这里要到…我们先简单了解一下大致的刷盘时机然后配合两阶段提交和组提交来看
redo log的刷盘时机
MySQL 正常关闭时当 redo log buffer 中记录的写入量大于 redo log buffer内存空间的一半时会触发落盘 PS为什么这里要到一半就要刷了因为redo log buffer是一个环状的内存结构会被反复利用InnoDB 的后台线程每隔 1 秒将 redo log buffer 持久化到磁盘。由系统参数innodb_flush_log_at_trx_commit 参数控制。 其中innodb_flush_log_at_trx_commit 参数控制可取的值有0、1、2默认值为 1这三个值分别代表的策略如下 1、当设置该参数为 0 时表示每次事务提交时将 redo log 留在 redo log buffer 中 该模式下在事务提交时不会主动触发写入磁盘的操作。 2、当设置该参数为 1 时表示每次事务提交时都将缓存在 redo log buffer 里的 redo log 直接持久化到磁盘这样可以保证 MySQL 异常重启之后数据不会丢失。 3、当设置该参数为 2时表示每次事务提交时都只是缓存在 redo log buffer 里的 redo log 写到 redo log 文件这并不意味着写入到了磁盘而是写到了操作系统的Page Cache。 参数为1的时候会主动持久化到磁盘但是0和2不会那么这两个什么时候持久化到磁盘呢 InnoDB 的后台线程每隔 1 秒 1针对参数 0 会把缓存在 redo log buffer 中的 redo log 通过调用 write() 写到操作系统的 Page Cache然后调用 fsync() 持久化到磁盘。所以参数为 0 的策略MySQL 进程的崩溃会导致上一秒钟所有事务数据的丢失; 2针对参数 2 调用 fsync将缓存在操作系统中 Page Cache 里的 redo log 持久化到磁盘。所以参数为 2 的策略较取值为 0 情况下更安全因为 MySQL 进程的崩溃并不会丢失数据只有在操作系统崩溃或者系统断电的情况下上一秒钟所有事务数据才可能丢失。 我们可以通过系统变量来查看这个参数
mysql show variables like %innodb_flush_log_at_trx_commit%;
---------------------------------------
| Variable_name | Value |
---------------------------------------
| innodb_flush_log_at_trx_commit | 1 |
---------------------------------------
1 row in set (0.00 sec)好了,redo log介绍完了接着我们来介绍bin log的刷盘时机。
bin log的刷盘时机
每个线程有自己 binlog cache最终会都写到同一个 binlog 文件。
binlog的刷盘过程 1 write指的就是指把日志写入到 binlog 文件但是并没有把数据持久化到磁盘因为数据还缓存在文件系统的 page cache 里write 的写入速度还是比较快的因为不涉及磁盘 I/O。 2fsync才是将数据持久化到磁盘的操作这里就会涉及磁盘 I/O所以频繁的 fsync 会导致磁盘的 I/O 升高。
那么什么时候刷盘呢 通过sync_binlog 参数来控制数据库的 binlog 刷到磁盘上的频率 1、sync_binlog 0 的时候表示每次提交事务都只 write不 fsync后续交由操作系统决定何时将数据持久化到磁盘 2、sync_binlog 1 的时候表示每次提交事务都会 write然后马上执行 fsync 3、sync_binlog N (N1) 的时候表示每次提交事务都 write但累积 N 个事务后才 fsync。 我们通过命令行来查看参数
mysql show variables like %sync_binlog%;
----------------------
| Variable_name | Value |
----------------------
| sync_binlog | 1 |
----------------------
1 row in set (0.00 sec)两次提交、组提交、双参数配合实现了两个日志的同步
有了前面两个刷盘时机为什么还要有两次提交因为我们需要保证redo log和bin log的一致性。 两阶段提交的过程是如何的 具体的取决于我们的参数参数一共有四个分别如下所示
mysql show variables like %sync_binlog%;
----------------------
| Variable_name | Value |
----------------------
| sync_binlog | 1 |
----------------------
1 row in set (0.00 sec)mysql show variables like %innodb_flush_log_at_trx_commit%;
---------------------------------------
| Variable_name | Value |
---------------------------------------
| innodb_flush_log_at_trx_commit | 1 |
---------------------------------------
1 row in set (0.00 sec)mysql show variables like %binlog_group%;
--------------------------------------------------
| Variable_name | Value |
--------------------------------------------------
| binlog_group_commit_sync_delay | 1000000 |
| binlog_group_commit_sync_no_delay_count | 10 |
--------------------------------------------------
2 rows in set (0.00 sec)其中我们看到了两个新参数他们是组提交参数 1、 binlog_group_commit_sync_delay N表示在等待 N 微妙后直接调用 fsync将处于文件系统中 page cache 中的 binlog 刷盘也就是将binlog 文件持久化到磁盘。表中值为1000000 (即1e6)就是1s。 2、 binlog_group_commit_sync_no_delay_count N表示如果队列中的事务数达到 N个就忽视binlog_group_commit_sync_delay 的设置直接调用 fsync将处于文件系统中 page cache中的 binlog 刷盘。 不同的参数效果都是不一样的。
1、我们先来看最经典的双1配置 此刻事务提交时需要花费1.00 sec因为binlog_group_commit_sync_delay设置的是1sbinlog_group_commit_sync_no_delay_count和binlog_group_commit_sync_delay满足其中一条即可
2、在双1的基础上如果我们把innodb_flush_log_at_trx_commit改了呢 每次redo log都没有刷盘我们默认就成功了。
3、在双1的基础上如果我们把sync_binlog改了呢 此时事务提交只需要0.00sec可以判定提交的瞬间未刷盘但是提交成功了。因为sync_binlogN在后续的1~N-1的事务commit都是很快第N个事务commit所消耗的时间是1s左右。也就是在第N次时候进行了刷盘。 这时候有人疑惑了那么我的组提交参数有啥用 我们来看结论 开启两个并行的窗口这两个窗口同时commit提交并设置binlog_group_commit_sync_no_delay_count 2我们发现刷盘了。 也就是说组提交在事务并行的时候才有效果。为什么要在并行事务的时候才有效果 原来早期的 MySQL 版本中通过使用 prepare_commit_mutex 锁来保证事务提交的顺序在一个事务获取到锁时才能进入 prepare 阶段一直到 commit 阶段结束才能释放锁下个事务才可以继续进行 prepare 操作。 通过加锁虽然完美地解决了顺序一致性的问题但在并发量较大的时候就会导致对锁的争用性能不佳。 所以sync_binlog和组提交之间是相互配合而不是冲突矛盾的关系在事务并发时组提交生效而在没有并发时候syc_binlog就发挥了巨大作用。
好了关于日志刷盘的内容就到这了。
