- 浏览: 7912985 次
- 性别:
- 来自: 广州
文章分类
- 全部博客 (2425)
- 软件工程 (75)
- JAVA相关 (662)
- ajax/web相关 (351)
- 数据库相关/oracle (218)
- PHP (147)
- UNIX/LINUX/FREEBSD/solaris (118)
- 音乐探讨 (1)
- 闲话 (11)
- 网络安全等 (21)
- .NET (153)
- ROR和GOG (10)
- [网站分类]4.其他技术区 (181)
- 算法等 (7)
- [随笔分类]SOA (8)
- 收藏区 (71)
- 金融证券 (4)
- [网站分类]5.企业信息化 (3)
- c&c++学习 (1)
- 读书区 (11)
- 其它 (10)
- 收藏夹 (1)
- 设计模式 (1)
- FLEX (14)
- Android (98)
- 软件工程心理学系列 (4)
- HTML5 (6)
- C/C++ (0)
- 数据结构 (0)
- 书评 (3)
- python (17)
- NOSQL (10)
- MYSQL (85)
- java之各类测试 (18)
- nodejs (1)
- JAVA (1)
- neo4j (3)
- VUE (4)
- docker相关 (1)
最新评论
-
xiaobadi:
jacky~~~~~~~~~
推荐两个不错的mybatis GUI生成工具 -
masuweng:
(转)JAVA获得机器码的实现 -
albert0707:
有些扩展名为null
java 7中可以判断文件的contenttype了 -
albert0707:
非常感谢!!!!!!!!!
java 7中可以判断文件的contenttype了 -
zhangle:
https://zhuban.me竹板共享 - 高效便捷的文档 ...
一个不错的网络白板工具
mysql中的innodb_flush_log_at_trx_commit 和 sync_binlog是两个重要的参数,
分别解析如下:
innodb_flush_log_at_trx_commit = N:
N=0 – 每隔一秒,把事务日志缓存区的数据写到日志文件中,以及把日志文件的数据刷新到磁盘上;
log buffer 会 每秒写入到日志文件并刷写(flush)到磁盘。但每次事务提交不会有任何影响,也就是 log buffer 的刷写操作和事务提交操作没有关系。在这种情况下,MySQL性能最好,但如果 mysqld 进程崩溃,通常会导致最后 1s 的日志丢失
N=1 – 每个事务提交时候,把事务日志从缓存区写到日志文件中,并且刷新日志文件的数据到磁盘上;
当取值为 1 时,每次事务提交时,log buffer 会被写入到日志文件并刷写到磁盘。这也是默认值。这是最安全的配置,但由于每次事务都需要进行磁盘I/O,所以也最慢。
N=2 – 每事务提交的时候,把事务日志数据从缓存区写到日志文件中;每隔一秒,刷新一次日志文件,但不一定刷新到磁盘上,而是取决于操作系统的调度;
当取值为 2 时,每次事务提交会写入日志文件,但并不会立即刷写到磁盘,日志文件会每秒刷写一次到磁盘。这时如果 mysqld 进程崩溃,由于日志已经写入到系统缓存,所以并不会丢失数据;在操作系统崩溃的情况下,通常会导致最后 1s 的日志丢失。
上面说到的「最后 1s」并不是绝对的,有的时候会丢失 更多数据。有时候由于调度的问题,每秒刷写(once-per-second flushing)并不能保证 100% 执行。对于一些数据一致性和完整性要求不高的应用,配置为 2 就足够了;如果为了最高性能,可以设置为 0。有些应用,如支付服务,对一致性和完整性要求很高,所以即使最慢,也最好设置为 1.
当我们设置为2 的时候,Log Thread 会在我们每次事务结束的时候将数据写入事务日志,但是这里的写入仅仅是调用了文件系统的文件写入操作。而我们的文件系统都是有缓存机制的,所以Log Thread 的这个写入并不能保证内容真的已经写入到物理磁盘上面完成持久化的动作。文件系统什么时候会将缓存中的这个数据同步到物理磁盘文件Log Thread 就完全不知道了。所以,当设置为2 的时候,MySQL Crash 并不会造成数据的丢失,但是OS Crash 或者是主机断电后可能丢失的数据量就完全控制在文件系统上了。各种文件系统对于自己缓存的刷新机制各不一样,大家可以自行参阅相关的手册。
二
sync_binlog = N:
N>0 — 每向二进制日志文件写入N条SQL或N个事务后,则把二进制日志文件的数据刷新到磁盘上;
N=0 — 不主动刷新二进制日志文件的数据到磁盘上,而是由操作系统决定;
推荐配置组合:
N=1,1 — 适合数据安全性要求非常高,而且磁盘IO写能力足够支持业务,比如充值消费系统;
N=1,0 — 适合数据安全性要求高,磁盘IO写能力支持业务不富余,允许备库落后或无复制;
N=2,0或2,m(0<m<100) — 适合数据安全性有要求,允许丢失一点事务日志,复制架构的延迟也能接受;
N=0,0 — 磁盘IO写能力有限,无复制或允许复制延迟稍微长点能接受,例如:日志性登记业务;
在http://blog.itpub.net/22664653/viewspace-1063134/中谈到了一个评测:
当两个参数设置为双1的时候,写入性能最差,sync_binlog=N (N>1 ) innodb_flush_log_at_trx_commit=2 时,(在当前模式下)MySQL的写操作才能达到最高性能。
三 安全
当innodb_flush_log_at_trx_commit和sync_binlog 都为 1 时是最安全的,在mysqld 服务崩溃或者服务器主机crash的情况下,binary log 只有可能丢失最多一个语句或者一个事务。但是鱼与熊掌不可兼得,双11 会导致频繁的io操作,因此该模式也是最慢的一种方式。
当innodb_flush_log_at_trx_commit设置为0,mysqld进程的崩溃会导致上一秒钟所有事务数据的丢失。
当innodb_flush_log_at_trx_commit设置为2,只有在操作系统崩溃或者系统掉电的情况下,上一秒钟所有事务数据才可能丢失。
双1适合数据安全性要求非常高,而且磁盘IO写能力足够支持业务,比如订单,交易,充值,支付消费系统。双1模式下,当磁盘IO无法满足业务需求时 比如11.11 活动的压力。推荐的做法是 innodb_flush_log_at_trx_commit=2 ,sync_binlog=N (N为500 或1000) 且使用带蓄电池后备电源的缓存cache,防止系统断电异常。
分别解析如下:
innodb_flush_log_at_trx_commit = N:
N=0 – 每隔一秒,把事务日志缓存区的数据写到日志文件中,以及把日志文件的数据刷新到磁盘上;
log buffer 会 每秒写入到日志文件并刷写(flush)到磁盘。但每次事务提交不会有任何影响,也就是 log buffer 的刷写操作和事务提交操作没有关系。在这种情况下,MySQL性能最好,但如果 mysqld 进程崩溃,通常会导致最后 1s 的日志丢失
N=1 – 每个事务提交时候,把事务日志从缓存区写到日志文件中,并且刷新日志文件的数据到磁盘上;
当取值为 1 时,每次事务提交时,log buffer 会被写入到日志文件并刷写到磁盘。这也是默认值。这是最安全的配置,但由于每次事务都需要进行磁盘I/O,所以也最慢。
N=2 – 每事务提交的时候,把事务日志数据从缓存区写到日志文件中;每隔一秒,刷新一次日志文件,但不一定刷新到磁盘上,而是取决于操作系统的调度;
当取值为 2 时,每次事务提交会写入日志文件,但并不会立即刷写到磁盘,日志文件会每秒刷写一次到磁盘。这时如果 mysqld 进程崩溃,由于日志已经写入到系统缓存,所以并不会丢失数据;在操作系统崩溃的情况下,通常会导致最后 1s 的日志丢失。
上面说到的「最后 1s」并不是绝对的,有的时候会丢失 更多数据。有时候由于调度的问题,每秒刷写(once-per-second flushing)并不能保证 100% 执行。对于一些数据一致性和完整性要求不高的应用,配置为 2 就足够了;如果为了最高性能,可以设置为 0。有些应用,如支付服务,对一致性和完整性要求很高,所以即使最慢,也最好设置为 1.
当我们设置为2 的时候,Log Thread 会在我们每次事务结束的时候将数据写入事务日志,但是这里的写入仅仅是调用了文件系统的文件写入操作。而我们的文件系统都是有缓存机制的,所以Log Thread 的这个写入并不能保证内容真的已经写入到物理磁盘上面完成持久化的动作。文件系统什么时候会将缓存中的这个数据同步到物理磁盘文件Log Thread 就完全不知道了。所以,当设置为2 的时候,MySQL Crash 并不会造成数据的丢失,但是OS Crash 或者是主机断电后可能丢失的数据量就完全控制在文件系统上了。各种文件系统对于自己缓存的刷新机制各不一样,大家可以自行参阅相关的手册。
二
sync_binlog = N:
N>0 — 每向二进制日志文件写入N条SQL或N个事务后,则把二进制日志文件的数据刷新到磁盘上;
N=0 — 不主动刷新二进制日志文件的数据到磁盘上,而是由操作系统决定;
推荐配置组合:
N=1,1 — 适合数据安全性要求非常高,而且磁盘IO写能力足够支持业务,比如充值消费系统;
N=1,0 — 适合数据安全性要求高,磁盘IO写能力支持业务不富余,允许备库落后或无复制;
N=2,0或2,m(0<m<100) — 适合数据安全性有要求,允许丢失一点事务日志,复制架构的延迟也能接受;
N=0,0 — 磁盘IO写能力有限,无复制或允许复制延迟稍微长点能接受,例如:日志性登记业务;
在http://blog.itpub.net/22664653/viewspace-1063134/中谈到了一个评测:
当两个参数设置为双1的时候,写入性能最差,sync_binlog=N (N>1 ) innodb_flush_log_at_trx_commit=2 时,(在当前模式下)MySQL的写操作才能达到最高性能。
三 安全
当innodb_flush_log_at_trx_commit和sync_binlog 都为 1 时是最安全的,在mysqld 服务崩溃或者服务器主机crash的情况下,binary log 只有可能丢失最多一个语句或者一个事务。但是鱼与熊掌不可兼得,双11 会导致频繁的io操作,因此该模式也是最慢的一种方式。
当innodb_flush_log_at_trx_commit设置为0,mysqld进程的崩溃会导致上一秒钟所有事务数据的丢失。
当innodb_flush_log_at_trx_commit设置为2,只有在操作系统崩溃或者系统掉电的情况下,上一秒钟所有事务数据才可能丢失。
双1适合数据安全性要求非常高,而且磁盘IO写能力足够支持业务,比如订单,交易,充值,支付消费系统。双1模式下,当磁盘IO无法满足业务需求时 比如11.11 活动的压力。推荐的做法是 innodb_flush_log_at_trx_commit=2 ,sync_binlog=N (N为500 或1000) 且使用带蓄电池后备电源的缓存cache,防止系统断电异常。
发表评论
-
让 InnoDB 多任务运行
2018-09-06 16:06 769今天偶然看到的一招,记录下 如果服务器上的参数 innodb_ ... -
mysql中查询连接工作状态
2018-05-31 15:13 667#!/bin/bash while true do mysql ... -
MYSQL BACKUP的SHELL相关语句
2018-05-25 20:33 536#!/bin/bash ###############Basi ... -
MySQL This function has none of DETERMINISTIC, NO SQL...错误1418 的原因分析及解决方法
2018-05-08 11:17 601MySQL开启bin-log后,调用存储过程或者函数以及触发器 ... -
NUMA的选择
2018-04-24 09:52 1385现在的机器上都是有 ... -
关于MYSQL 5.7线程池的好文收集
2018-03-27 10:57 1513来自腾讯工程师的好文: https://www.jianshu ... -
MYSQL 的审计日志插件
2017-11-30 10:19 1264MYSQL 的审计日志插件,可惜目前只是LINUX用: 来自M ... -
(转)MySQL InnoDB缓冲池配置详解
2017-10-09 16:55 4048一、InnoDB缓冲池 InnoDB维护一个称为缓冲池的内存 ... -
(转)MySQL 5.7默认SQL模式带来的问题总结
2017-10-05 18:46 1851http://www.ywnds.com/?p=8865 在 ... -
(转)MySQL 5.7默认ONLY_FULL_GROUP_BY语义介绍
2017-10-05 18:45 1172http://www.ywnds.com/?p=8184 ON ... -
MySQL 5.6 新功能之 Index Condition Pushdown (ICP)
2017-10-05 15:52 772http://www.cnblogs.com/zhoujiny ... -
mysql 5.7中的MBR和BKA算法
2017-10-03 15:11 1712一、什么是MRR MMR全称是Multi-Range Re ... -
(收藏)万字总结:学习MySQL优化原理,这一篇就够了!
2017-09-30 23:37 1174http://dbaplus.cn/news-155-1531 ... -
(转)MySQL中NULL和空值的区别
2017-09-23 15:57 2208MySQL中NULL和空值的区别 http://www.yw ... -
mysql 5.7中关于count(*)的优化
2017-09-20 19:15 2336在mysql 5.7中,对于select count(*) f ... -
MySQL 索引设计概要
2017-09-12 21:12 495<<MySQL 索引设计概要>>,不错 ... -
10分钟学会理解和解决MySQL乱码问题
2017-07-22 18:21 530http://cenalulu.github.io/mysql ... -
MySQL的or/in/union与索引优化
2017-07-22 08:29 929https://mp.weixin.qq.com/s/ZWez ... -
MYSQL中查看某个表或库的大小语句
2017-04-02 09:12 1938在information_schema.tables中有相关记 ... -
(收藏)MYSQL大表方案
2017-01-09 19:58 1427https://segmentfault.com/a/1190 ...
相关推荐
MySQL 数据库中的 `innodb_flush_log_at_trx_commit` 和 `sync_binlog` 是两个非常重要的配置参数,它们直接影响到数据库的性能与数据安全性。理解并合理设置这两个参数对于优化数据库系统至关重要。 首先,`innodb...
在实际应用中,通常会将`sync_binlog`设置为一个较大的值,比如100到1000之间,而`innodb_flush_log_at_trx_commit`通常设置为1,以确保在异常情况下的数据完整性。 总的来说,MySQL通过binlog和redo log的组合使用...
- `innodb_flush_log_at_trx_commit` 设置为2,这意味着每次提交事务时,重做日志缓冲区会被写入日志文件,但不立即同步到磁盘,提供了一定的性能和数据安全平衡。 - `innodb_file_per_table` 开启,每个表的索引...
5. 磁盘IO优化:通过调整磁盘IO参数,例如sync_binlog、innodb_flush_log_at_trx_commit等,来提高MYSQL数据库的性能。 MYSQL数据库慢SQL定位与分析 MYSQL数据库慢SQL定位与分析是MYSQL数据库性能优化的重要步骤。...
* innodb_flush_log_at_trx_commit:日志提交方式(关键参数) + 0 每秒写 1 次日志,将数据刷入磁盘,相当于每秒提交一次事务 + 1 每次提交事务写日志,同时将刷新相应磁盘,默认参数 + 2 每提交事务写一次日志...
- **innodb_flush_log_at_trx_commit=2**:控制InnoDB日志刷新频率。 - **binlog_format=row**:二进制日志格式设置为行级别。 - **log_bin=/data/mysqldata/3307/binlog/mysql-bin**:指定二进制日志文件的位置。 -...
MYSQL数据库技术分享 ...* innodb_flush_log_at_trx_commit:以什么方式刷新日志到磁盘。 这些参数的设置可以影响MYSQL数据库的性能和安全性。通过合理的参数设置,可以提高数据库的性能和可靠性。
在MySQL配置中,针对单机环境,设置`innodb_flush_log_at_timeout`和`innodb_flush_log_at_trx_commit`参数有助于保证数据的持久化。前者控制redo log刷新到磁盘的频率,后者控制事务提交时是否将数据刷新到磁盘。...
2. innodb_flush_log_at_trx_commit:控制redo log的刷盘策略,不同的设置平衡了性能与数据安全性。 3. sync_binlog:控制binlog的刷盘策略,它和上面的参数一样,调整这个值会影响系统的事务安全性和性能。 4. ...
innodb_flush_log_at_trx_commit=2 sync_binlog=1000 transaction-isolation=READ-COMMITTED innodb_flush_method=O_DIRECT innodb_io_capacity_max=4000 innodb_log_buffer_size=8M innodb_log_file_size=...
22. `innodb_flush_log_at_trx_commit`: 控制事务日志刷新策略,以平衡性能和数据一致性。 23. `innodb_log_buffer_size`, `innodb_log_file_size`, `innodb_log_files_in_group`: InnoDB 事务日志相关参数,用于...
对于redo日志和binlog的刷盘策略,如innodb_flush_log_at_trx_commit和sync_binlog,应根据应用的事务安全性和性能需求进行调整。内存分配方面,可以选用jemalloc或tcmalloc等高效内存管理库。 Schema优化主要包括...
- `innodb_flush_log_at_trx_commit`:控制事务日志的刷新策略,确保数据的一致性。 - `sync_binlog`:控制二进制日志的同步频率,影响故障恢复的可靠性。 6. **查询缓存**: - `query_cache_size`:查询缓存的...
- `innodb_flush_log_at_trx_commit`: 控制事务日志刷新策略,可能设置为1(强一致性),0(性能优先)或2(平衡模式)。 - `query_cache_size`: 查询缓存大小,可能需要根据查询特性调整,也可能禁用(设为0)。 ...
接下来,文档中提到了一些具体的数据库参数和配置项,例如“innodb_flush_log_at_trx_commit”、“bufferpool”、“logbuffer”、“oscache”、“sync_binlog=1”等。这些参数的设置对MySQL数据库的事务日志记录和...
- innodb_flush_log_at_trx_commit:控制事务日志刷新时机,影响事务的持久性和性能。 - sync_binlog:这个变量控制二进制日志的刷新频率,影响数据同步和恢复的可靠性。 - innodb_flush_method:这个设置可以...
- `innodb_flush_log_at_trx_commit`决定事务提交后如何同步InnoDB的日志,以确保数据一致性。 这些参数的优化对于MySQL数据库的性能、稳定性和安全性至关重要。正确调整这些参数可以帮助数据库更好地应对高并发、...
4. **innodb_flush_log_at_trx_commit**: 调整此参数可平衡事务日志的持久性和性能,一般推荐设置为1或2。 5. **log_bin**: 开启二进制日志记录有助于实现数据恢复和主从复制。 6. **expire_logs_days**: 根据实际...