##innodb correlate
innodb_flush_log_at_trx_commit
value: 0,[1],2
effect: control the flush operations of redo log buffer to redo logfile on disk.
detail:
0,redo log buffer won't be flushed to disk after transaction commit.
1,guarantee the redo log buffer will be flushed to disk immediately as soon as transaction finish commit.it's recommend value in high consistency required system.whereas,the performance will be a little bit reduced.
2,the flush time depends on the OS cache.It's possible to loss transaction when OS crashs.
sync_binlog
value: 0,[1]~2**32-1
effect: control the amount of binlog commit groups which will be synchronized to disk.
detail:
0,innodb won't synchronize the binlog to disk spontaneously merely depends on the machenism of OS cache to flush them in a certain time which cannot ensure the transaction to be safe.
1,all the binlogs will be flushed to disk as soon as transactions have committed.
2 or above,flush operations base on the number of group commit taking place.
as the existence of binlog group commit in MySQL 5.6,notice that we cannot say the number is equal to the transactions.let's suppose in the scenario that there're three sessions who have started transaction in turn.they have different begin time of transaction respectively.that is,the "sequence number" is also different,but they implement commit simultaneously what means they have the same "last commit" number.thus,they can be committed together by means of group commit.eventually,we'll get three transactions but only one group commit here.if the value of the "sync_bin" is 1,the binlog will be flushed to disk only once instead of three times.in any case the value is more than 1,the flush operation is still based on the number of group commit(not number of single transaction).
innodb_force_recovery
value: [0],1,2,3,4,5,6
effect: control the startup mode of innodb,try to begin with 0 then increase the number every time to start successfully.
detail:
1 (SRV_FORCE_IGNORE_CORRUPT) ignore corrupt index and data pages.
2 (SRV_FORCE_NO_BACKGROUND) prevent master thread & purge threads from running.
3 (SRV_FORCE_NO_TRX_UNDO) won't rollback transaction after recovery
4 (SRV_FORCE_NO_IBUF_MERGE) stop running insert buffer,need to recreate all the secondary indexes.
5 (SRV_FORCE_NO_UNDO_LOG_SCAN) ignore undo log,transanctions will be forcedly commited even if they havn't committed.
6 (SRV_FORCE_NO_LOG_REDO) ignore redo log,method like failover in oracle database.
look out,value of 4~6 will corrupt the datafiles,need to set innodb read only.
innodb_fast_shutdown
value: 0,[1],2
effect: control the operation when shutdown，value 0 is the slowest mode while shutting down.
detail:
0，a full purge and change buffer merge before shutting down.
1，skip above two operations,but still will flush dirty page due to starp checkpoint.
2，only flush log buffers to logfiles and shutdown like crash，don't flush dirty pages which will lead to quite a long time to startup netxtime to rollback the uncommited transactions.
innodb_io_capacity
value: 100~[200]~2**64-1(64 bit)
effect: control the gross of IOPS such as flush pages(shared by all innodb buffer pool instances).
detail:
specify it as an appropiate value according to the disk performance is better than a rather hige value.only if the IOPS is the bottleneck while flushing pages,try to increase it little by little is a practical way.usually,200~400 is recommended value.when using regular disk drive.
notice,the parameter is relevent with "innodb_flush_sync" which can lead to being ignored.
innodb_io_capacity_max
value: depends on the OS platform
effect: the upper limit of "innodb_io_capacity".
detail:
it will be twice as the velue of "innodb_io_capacity" and the default minimum value is "2000" if you don't specify it explicitly in "my.cnf",it cannot be set lower than "innodb_io_capacity".
innodb_flush_sync
value: [on],off
effect: prevent bursts IO operations caused by a high value in "innodb_io_capacity" when doing checkpoint.
detail:
it may result in an inefficient value which you've set in "innodb_io_capacity",disable it can be a workaround,but the influence may occur while doing checkpoint(especially there're huge amount of dirty pages to be flushed).
to be continueously updated...