InnoDB log file 设置多大合适?

简介:

数据库的东西,往往一个参数就牵涉N多知识点。所以简单的说一下。大家都知道innodb是支持事务的存储引擎。事务的四个特性ACID即原子性(atomicity),一致性(consistency),隔离性(isolation),持久性(durability)。其中原子性,一致性,持久性通过redo
log 和 undo来实现。redo log称为重做日志,用来保证事务的原子性和持久性。undo
log用来保证事务的一致性。 当事务提交时,必须先将该事务的所有日志写入到重做日志文件(redo
log)进行持久化(当然先写到日志缓冲区,而不是直接写文件,关于什么时候刷新到磁盘文件,是一个比较复杂的问题,同学们自行查阅资料),待事务提交操作才算完成。innodb的redo
log是顺序I/O,所以设置合适的值能够大大提高数据库性能。那么是不是设置的越大越好呢?

设置的太小:当一个日志文件写满后,innodb会自动切换到另外一个日志文件,而且会触发数据库的检查点(Checkpoint),这会导致innodb缓存脏页的小批量刷新,会明显降低innodb的性能。

设置的太大:设置很大以后减少了checkpoint,并且由于redo
log是顺序I/O,大大提高了I/O性能。但是如果数据库意外出现了问题,比如意外宕机,那么需要重放日志并且恢复已经提交的事务,如果日志很大,那么将会导致恢复时间很长。甚至到我们不能接受的程度。

那么我们如何估算log file该设置为多大?通常我们可以通过观察show
status中innodb_os_log_written状态变量来查看innodb对日志文件写出了多少数据。一个好用的经验是,查看10-100秒间隔的数字,然后记录峰值。可以用这个判断日志缓冲是否设置的正好。例如,若看到峰值是每秒写100kb数据到日志,那么1MB的日志缓冲已经足够了。也可以使用这个衡量标准来决定日志文件设置多大会比较好。如果峰值是100KB/s,那么256M的日志文件足够存储至少2560秒的日志记录。一般来说,日志文件的全部大小,应该足够容纳服务器一个小时的活动内容。

下面看实际的测试(由于是虚拟机,所以使用sysbench模拟据量写入,生产环境选择数据库最繁忙的时候测试):

[[email protected] ~]# sysbench --test=oltp --oltp-table-size=100000 --oltp-read-only=off --init-rng=on --num-threads=16 --max-requests=0 --oltp-dist-type=uniform --max-time=180 --mysql-user=root --mysql-socket=/tmp/mysqld.sock --mysql-password=123456 --db-driver=mysql --mysql-table-engine=innodb --oltp-test-mode=complex prepare    

1.首先计算innodb每分钟产生的日志量:


(root@yayun-mysql-server) [(none)]>pager grep sequence
PAGER set to ‘grep sequence‘
(root@yayun-mysql-server) [(none)]>show engine innodb status\G select sleep(60); show engine innodb status\G
Log sequence number 6377275259
1 row in set (0.00 sec)

1 row in set (1 min 0.00 sec)

Log sequence number 6403945555
1 row in set (0.00 sec)

(root@yayun-mysql-server) [(none)]>nopager
PAGER set to stdout
(root@yayun-mysql-server) [(none)]>select (6403945555 - 6377275259) / 1024 / 1024 as MB_per_min;
+-------------+
| MB_per_min |
+-------------+
| 25.43477631 |
+-------------+
1 row in set (0.02 sec)

(root@yayun-mysql-server) [(none)]>

注意Log sequence
number,这是写入事务日志的总字节数。所以,现在你可以看到每分钟有多少MB日志写入(这里的技术适用于所有版本的MySQL,在5.0及更高版本,你可以从SHOW
GLOBAL STATUS的输出看Innodb_os_log_written的值) 。

通过计算后得到每分钟有25M的日志写入。

根据经验法则。通常我们设置redo log size足够大,能够容纳1个小时的日志写入量。

1小时日志写入量=25M *
60=1500M,大约等于1.5G。由于默认有两个日志重做日志文件ib_logfile0和ib_logfile1。在日志组中的每个重做日志文件的大小一致,并以循环的方式写入。innodb存储引擎先写重做日志文件0,当达到文件的最后时,会切换到重做日志1,并checkpoint。以此循环。

所以我们可以大约设置innodb_log_file_size=800M。注意:在innodb1.2.x版本之前,重做日志文件总的大小不得大于等于4G,而1.2.x版本将该限制扩大到了521G。

innodb_log_file_size = 800M

[[email protected] mysql]# du -sh ib_logfile*
801M ib_logfile0
801M ib_logfile1
[[email protected]-mysql-server mysql]#

对于innodb 1.2.x版本之前如果设置大于4G则报错


[[email protected] mysql]# tail -n 10 yayun-mysql-server.err
140511 1:01:15 InnoDB: Completed initialization of buffer pool
140511 1:01:15 InnoDB: Error: combined size of log files must be < 4 GB
140511 1:01:15 [ERROR] Plugin ‘InnoDB‘ init function returned error.
140511 1:01:15 [ERROR] Plugin ‘InnoDB‘ registration as a STORAGE ENGINE failed.
140511 1:01:15 [ERROR] Failed to initialize plugins.
140511 1:01:15 [ERROR] Aborting

140511 1:01:15 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete

140511 01:01:15 mysqld_safe mysqld from pid file /data/mysql/yayun-mysql-server.pid ended
[[email protected]-mysql-server mysql]#

而innodb 1.2.x以后版本则不会:


[[email protected] mysql5.6]# tail -f yayun-mysql-server.err
2014-05-11 01:06:47 5205 [Note] InnoDB: Using Linux native AIO
2014-05-11 01:06:47 5205 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2014-05-11 01:06:47 5205 [Note] InnoDB: Completed initialization of buffer pool
2014-05-11 01:06:47 5205 [Note] InnoDB: Highest supported file format is Barracuda.
2014-05-11 01:06:47 5205 [Warning] InnoDB: Resizing redo log from 2*3072 to 2*327680 pages, LSN=1085681253
2014-05-11 01:06:47 5205 [Warning] InnoDB: Starting to delete and rewrite log files.
2014-05-11 01:06:47 5205 [Note] InnoDB: Setting log file ./ib_logfile101 size to 5120 MB
InnoDB: Progress in MB: 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 1900 2000 2100 2200 2300 2400 2500 2600 2700 2800 2900 3000 3100 3200 3300 3400 3500 3600 3700 3800 3900 4000 4100 4200 4300 4400 4500 4600 4700 4800 4900 5000 5100
2014-05-11 01:12:40 5205 [Note] InnoDB: Setting log file ./ib_logfile1 size to 5120 MB
InnoDB: Progress in MB: 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 1900 2000 2100 2200 2300 2400 2500 2600 2700 2800 2900 3000 3100

参考资料

http://www.mysqlperformanceblog.com/2008/11/21/how-to-calculate-a-good-innodb-log-file-size/

时间: 2024-12-14 05:20:21

InnoDB log file 设置多大合适?的相关文章

JVM内存设置多大合适?Xmx和Xmn如何设置?

JVM内存设置多大合适?Xmx和Xmn如何设置? 问题:新上线一个java服务,或者是RPC或者是WEB站点, 内存的设置该怎么设置呢?设置成多大比较合适,既不浪费内存,又不影响性能呢? 分析:依据的原则是根据Java Performance里面的推荐公式来进行设置. 296d1509689688.png 具体来讲:Java整个堆大小设置,Xmx 和 Xms设置为老年代存活对象的3-4倍,即FullGC之后的老年代内存占用的3-4倍永久代 PermSize和MaxPermSize设置为老年代存活

How to calculate a good InnoDB log file size

Peter wrote a post a while ago about choosing a good InnoDB log file size.  Not to pick on Peter, but the post actually kind of talks about a lot of things and then doesn’t tell you how to choose a good log file size!  So I thought I’d clarify it a

InnoDB: Error: log file .\ib_logfile0 is of different size 0 10485760 bytes

启动WAMP Server的时候报例如以下的错误: 140618 23:12:32 [Note] Plugin 'FEDERATED' is disabled. 140618 23:12:32 InnoDB: The InnoDB memory heap is disabled 140618 23:12:32 InnoDB: Mutexes and rw_locks use Windows interlocked functions 140618 23:12:32 InnoDB: Compres

报错问题:InnoDB: Error: log file ./ib_logfile0 is of different size

在使用xtrabackup对mysql执行备份操作的时候,出现下面的报错:.....................xtrabackup: innodb_log_file_size = 50331648InnoDB: Error: log file ./ib_logfile0 is of different size 33554432 bytesInnoDB: than specified in the .cnf file 50331648 bytes! 解决办法:可以计算一下33554432的

mariadb:InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes

mariadb 启动中 InnoDB: Error: log file ./ib_logfile0 is of different size 0 起因:线上正在运行的系统,因为需要调整性能,变更了my.cnf参数的innodb_log_file_size大小,重启MySQL时err日志输出如下InnoDB: Error: log file ./ib_logfile0 is of different size 0 xxxx bytes 停掉mariadb 解决办法:移除原有ib_logfile#m

Oracle db file parallel write 和 log file parallel write 等待事件

一. db file parallel write等待事件 引自如下blog: http://oradbpedia.com/wiki/Wait_Events_-_db_file_parallel_write db文件并行写 db文件并行写等待事件属于Oracle数据库写入程序(DBWR)进程,因为它是将块从SGA写入数据文件的唯一进程.当是写入时,DBWR进程编译一组脏块,将批处理交给操作系统,并等待db文件并行写事件以完成I / O.虽然用户会话从来没有遇到db文件并行写等待事件,但这并不意味

ORACLE AWR报告之 log file sync等待事件优化的总结【转自ITPUB】

来自白大师(白鳝)对log file sync等待事件优化的总结,供各位puber们学习参考: 一. log file sync平均等待事件时间超过7ms,如果等待时间过长,说明log write每次写入的时间过长,如果能够优化redo日志文件存储,使之存放在更快的磁盘上,就可以减少这个等待事件的单次等待时间.(RAID 5--> RAID 10)   当无法通过优化redo日志的I/O性能来解决问题,或者优化了redo日志的I/O性能后还是无法达到我们的预期,那么该如何处理呢? 二. 有经验的

Oracle之 等待事件log file sync + log file parallel write (awr优化)

这是3月份某客户的情况,原因是server硬件故障后进行更换之后,业务翻译偶尔出现提交缓慢的情况.我们先来看下awr的情况. 我们能够看到,该系统的load profile信息事实上并不高,每秒才21个transaction.先来看看top5events: 从top 5event,我们能够发现,log file sync的avg wait很之高,高达124ms.大家应该知道,对于绝大多数情况 下,log file sync的平均等待时间是小于5ms的,这个值有点高的离谱. 我们知道,产生log

oracle之 等待事件LOG FILE SYNC (awr)优化

log file sycn是ORACLE里最普遍的等待事件之一,一般log file sycn的等待时间都非常短 1-5ms,不会有什么问题,但是一旦出问题,往往都比较难解决.什么时候会产生log file sync等待?常见有以下几种:1)commit操作2)rollback操作3)DDL操作(DDL操作实施前都会首先进行一次commit)4)DDL操作导致的数据字典修改所产生的commit5)某些能递归修改数据字典的操作:比如查询SEQ的next值,可能会导致修改数据字典.一个典型的情况是,