在 my.cnf 里面 有一些经常用到的 有关binlog 和innodb 设置的参数
有那位知道下面这些参数的具体用法 和赋值的参考依据
请给予指点 感谢
--binlog---
log-bin-trust-function-creators
max_binlog_cache_size
max_binlog_size
sync_binlog
expire_logs_days
log-slave-updates
max_relay_log_size
log-bin-trust-function-creators
binlog-row-event-max-size
binlog_direct_non_transactional_updates ---innodb---
innodb_log_group_home_dir
innodb_log_files_in_group
innodb_checksums
innodb_support_xa
innodb_doublewrite
innodb_thread_concurrency
innodb_concurrency_tickets
innodb_locks_unsafe_for_binlog
transaction-isolation
innodb_file_per_table
innodb_max_dirty_pages_pct
innodb_log_file_size (buffer pool 的25%)
inndb_buffer_pool_size 主内存的50%~80%
innodb_additional_mem_pool_size (数据字典和数据结构的存储器组合 memory pool)
sync_binlog:这个参数很重要，表示写binlog文件的时机
sync_binlog=0表示不做强制性的磁盘刷新指令 filesystem自己决定
sync_binlog=N表示N个事务后将binlog文件缓存写到磁盘 If the value of this variable is greater than 0, the MySQL server synchronizes its binary log to disk (using fdatasync()) after every sync_binlog writes to the binary log. There is one write to the binary log per statement if autocommit is enabled, and one write per transaction otherwise. The default value of sync_binlog is 0, which does no synchronizing to disk. A value of 1 is the safest choice, because in the event of a crash you lose at most one statement or transaction from the binary log. However, it is also the slowest choice (unless the disk has a battery-backed cache, which makes synchronization very fast).
sync、fsync和fdatasync函数
传统的UNIX实现在内核中设有缓冲区高速缓存或页面高速缓存，大多数磁盘I/O都通过缓冲进行。当将数据写入文件时，内核通常先将该数据复制到其中一个缓冲区中，如果该缓冲区尚未写满，则并不将其排入输出队列，而是等待其写满或者当内核需要重用该缓冲区以便存放其他磁盘块数据时，再将该缓冲排入输出队列，然后待其到达队首时，才进行实际的I/O操作。这种输出方式被称为延迟写（delayed write）（Bach [1986]第3章详细讨论了缓冲区高速缓存）。
延迟写减少了磁盘读写次数，但是却降低了文件内容的更新速度，使得欲写到文件中的数据在一段时间内并没有写到磁盘上。当系统发生故障时，这种延迟可能造成文件更新内容的丢失。为了保证磁盘上实际文件系统与缓冲区高速缓存中内容的一致性，UNIX系统提供了sync、fsync和fdatasync三个函数。
sync函数只是将所有修改过的块缓冲区排入写队列，然后就返回，它并不等待实际写磁盘操作结束。
通常称为update的系统守护进程会周期性地（一般每隔30秒）调用sync函数。这就保证了定期冲洗内核的块缓冲区。命令sync(1)也调用sync函数。
fsync函数只对由文件描述符filedes指定的单一文件起作用，并且等待写磁盘操作结束，然后返回。fsync可用于数据库这样的应用程序，这种应用程序需要确保将修改过的块立即写到磁盘上。
fdatasync函数类似于fsync，但它只影响文件的数据部分。而除数据外，fsync还会同步更新文件的属性。log_bin_trust_function_creators
信任子程序的创建者，禁止创建、修改子程序时对SUPER权限的要求，设置log_bin_trust_routine_creators全局系统变量为1。
log-bin=mysql-bin //启动数据库更新二进制日志记录，日志文件名前缀为mysql-binlog-slave-updates //当Slave从Master数据库读取日志时将跟新写入日志中log-bin 用于启动数据库的跟新日记，当针对启动这个选项的数据库本身进行数据更新时更新操作将被记录。
log-slave-updates 告诉Slave在二进制记录中记录从主数据库同步到的更新数据。
如果只启动log-bin 而没有启动log-slave-updates 则Slave只记录针对自己数据库操作的更新。
innodb-relay-log
binlog传到slave服务器被写到relaylog里，slave服务器的slave sql线程从relaylog里读取然后应用到本地。
relay-log日志记录的是从服务器I/O线程将主服务器的二进制日志读取过来记录到从服务器本地文件，然后SQL线程会读取relay-log日志的内容并应用到从服务器
1、查看relay log文件的大小
1）show variables like '%relay%' ，其中max_relay_log_size，标记relay log 允许的最大值
如果该值为0，则默认值为max_binlog_size(1G)；如果不为0，则max_relay_log_size则为最大的relay_log文件大小；
2）select @@max_relay_log_size;
3）select @@max_binlog_size;innodb_log_group_home_dir
The directory path to the InnoDB redo log files. If you do not specify any InnoDB log variables, the default is to create two 5MB files named ib_logfile0 and ib_logfile1 in the MySQL data directory.
InnoDB 重做日志 文件的目录路径 如果你不指定任何日志InnoDB变量,默认是在MySQL数据目录下创建两个5 MB的文件命名ib_logfile0和ib_logfile1redo log
重做日志
undo log
撤消日志
重做日志：每当有操作执行前，将数据真正更改时，先前相关操作写入重做日志。这样当断电，或者一些意外，导致后续任务无法完成时，系统恢复后，可以继续完成这些更改
撤消日志：当一些更改在执行一半时，发生意外，而无法完成，则可以根据撤消日志恢复到更改之前的壮态
redo的原因是：每次commit时，将数据的修改立即写到online redo中，但是并不一定同时将该数据的修改写到数据文件中。因为该数据已经提交，但是只存在联机日志文件中，所以在恢复时需要将数据从联机日志文件中找出来，重新应用一下，使已经更改数据在数据文件中也改过来！innodb_log_files_in_group
The number of log files in the log group. InnoDB writes to the files in a circular fashion. The default (and recommended) value is 2.
日志组中日志文件的数量 InnoDB以一个循环的方式写到文件中。默认的(和推荐)值是2。innodb_lock_wait_timeout
mysql可以自动地检测行锁导致并进行相应的处理 但是对表锁导致的死锁不能自动检测 所以该参数主要被用于在出现类似情况的时候等待指定的时间后回滚 系统默认50秒 innodb_checksums
InnoDB可以在所有对磁盘的页面读取上使用校验和验证以确保额外容错防止硬件损坏或数据文件.这个验证是默认启用.然而,在一些罕见的情况下(如当运行基准测试)这种额外的安全特性是不必要的,可以被禁用,skip-innodb-checksums。
. 用--skip-innodb-checksums来关闭
Dynamic Variable(No)expire_logs_daysexpire_logs_days 是动态参数,不需要重新启动.
expire_logs_days=2 的意思是尽保留过去两天加今天的binlog设置7天，也就是保留7+1的结果，弄明白其参数的意义与作用触发点
有了过期日期，还需要有一件事情的发生，那就是必须有二进制发生切换的时候，才会去检查是否日志过去的问题
等切换了再去看 或者你执行flush logsshow global variables like 'exp%';
show binary logs;expire_logs_days
设置完这个参数之后需要执行flush logsThe number of days for automatic binary log file removal. The default is 0, which means “no automatic removal.” Possible removals happen at startup and when the binary log is flushed. Log flushing occurs as indicated in Section 5.2, “MySQL Server Logs”.
To remove binary log files manually, use the PURGE BINARY LOGS statement. See Section 12.5.1.1, “PURGE BINARY LOGS Syntax”.In addition, the binary log is flushed when its size reaches the value of the max_binlog_size system variable.max_binlog_size
If a write to the binary log causes the current log file size to exceed the value of this variable, the server rotates the binary logs (closes the current file and opens the next one). The minimum value is 4096 bytes. The maximum and default value is 1GB.You might face sutch a problem if the mysql-bin.index file is no longer matching the reality (for exemple, if you manually deleted logs files).cat your /var/log/mysql/mysql-bin.index (or whatever your .index file is), it is a text file that contains the names of all used binary log files. There shouldn't be a difference between its content and the list of log files on your filesystem.You might try this (changing the paths according to your configuration) :
# /bin/ls -1 /var/log/mysql/mysql-bin.[0-9]* | diff /var/log/mysql/mysql-bin.index -
If there is a difference, try this :
- stop your mysql server
- backup your mysql-bin.index file
- re-create a file with the logs that still exists
- start your mysql serverExample (again, you might change the paths according to your own configuration) :
# /etc/init.d/mysql stop
# cd /var/log/mysql
# cp mysql-bin.index mysql-bin.index-
# ls -1 /var/log/mysql/mysql-bin.[0-9]* > mysql-bin.index
# /etc/init.d/mysql start
二进制日志缓冲区（Binlog Buffer）：二进制日志缓冲区主要用来缓存由于各种数据变更操做所产生的 Binary Log 信息。为了提高系统的性能，MySQL 并不是每次都是将二进制日志直接写入 Log File，而是先将信息写入 Binlog Buffer 中，当满足某些特定的条件（如 sync_binlog参数设置）之后再一次写入 Log File 中。我们可以通过 binlog_cache_size 来设置其可以使用的内存大小，同时通过 max_binlog_cache_size 限制其最大大小（当单个事务过大的时候 MySQL 会申请更多的内存）。当所需内存大于 max_binlog_cache_size 参数设置的时候，MySQL 会报错：“Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes of storage”。 线程栈信息使用内存(thread_stack)：主要用来存放每一个线程自身的标识信息，如线程id，线程运行时基本信息等等，我们可以通过 thread_stack 参数来设置为每一个线程栈分配多大的内存。 排序使用内存(sort_buffer_size)：MySQL 用此内存区域进行排序操作（filesort），完成客户端的排序请求。当我们设置的排序区缓存大小无法满足排序实际所需内存的时候，MySQL 会将数据写入磁盘文件来完成排序。由于磁盘和内存的读写性能完全不在一个数量级，所以sort_buffer_size参数对排序操作的性能影响绝对不可小视。排序操作的实现原理请参考：MySQL Order By 的实现分析。 Join操作使用内存(join_buffer_size)：应用程序经常会出现一些两表（或多表）Join的操作需求，MySQL在完成某些 Join 需求的时候（all/index join），为了减少参与Join的“被驱动表”的读取次数以提高性能，需要使用到 Join Buffer 来协助完成 Join操作（具体 Join 实现算法请参考：MySQL 中的 Join 基本实现原理）。当 Join Buffer 太小，MySQL 不会将该 Buffer 存入磁盘文件，而是先将Join Buffer中的结果集与需要 Join 的表进行 Join 操作，然后清空 Join Buffer 中的数据，继续将剩余的结果集写入此 Buffer 中，如此往复。这势必会造成被驱动表需要被多次读取，成倍增加 IO 访问，降低效率。 顺序读取数据缓冲区使用内存(read_buffer_size)：这部分内存主要用于当需要顺序读取数据的时候，如无发使用索引的情况下的全表扫描，全索引扫描等。在这种时候，MySQL 按照数据的存储顺序依次读取数据块，每次读取的数据快首先会暂存在read_buffer_size中，当 buffer 空间被写满或者全部数据读取结束后，再将buffer中的数据返回给上层调用者，以提高效率。 随机读取数据缓冲区使用内存(read_rnd_buffer_size)：和顺序读取相对应，当 MySQL 进行非顺序读取（随机读取）数据块的时候，会利用这个缓冲区暂存读取的数据。如根据索引信息读取表数据，根据排序后的结果集与表进行Join等等。总的来说，就是当数据块的读取需要满足一定的顺序的情况下，MySQL 就需要产生随机读取，进而使用到 read_rnd_buffer_size 参数所设置的内存缓冲区。 连接信息及返回客户端前结果集暂存使用内存(net_buffer_size)：这部分用来存放客户端连接线程的连接信息和返回客户端的结果集。当 MySQL 开始产生可以返回的结果集，会在通过网络返回给客户端请求线程之前，会先暂存在通过 net_buffer_size 所设置的缓冲区中，等满足一定大小的时候才开始向客户端发送，以提高网络传输效率。不过，net_buffer_size 参数所设置的仅仅只是该缓存区的初始化大小，MySQL 会根据实际需要自行申请更多的内存以满足需求，但最大不会超过 max_allowed_packet 参数大小。 批量插入暂存使用内存(bulk_insert_buffer_size)：当我们使用如 insert … values(…),(…),(…)… 的方式进行批量插入的时候，MySQL 会先将提交的数据放如一个缓存空间中，当该缓存空间被写满或者提交完所有数据之后，MySQL 才会一次性将该缓存空间中的数据写入数据库并清空缓存。此外，当我们进行 LOAD DATA INFILE 操作来将文本文件中的数据 Load 进数据库的时候，同样会使用到此缓冲区。 临时表使用内存(tmp_table_size)：当我们进行一些特殊操作如需要使用临时表才能完成的 Order By，Group By 等等，MySQL 可能需要使用到临时表。当我们的临时表较小（小于 tmp_table_size 参数所设置的大小）的时候，MySQL 会将临时表创建成内存临时表，只有当 tmp_table_size 所设置的大小无法装下整个临时表的时候，MySQL 才会将该表创建成 MyISAM 存储引擎的表存放在磁盘上。不过，当另一个系统参数 max_heap_table_size 的大小还小于 tmp_table_size 的时候，MySQL 将使用 max_heap_table_size 参数所设置大小作为最大的内存临时表大小，而忽略 tmp_table_size 所设置的值。而且 tmp_table_size 参数从 MySQL 5.1.2 才开始有，之前一直使用 max_heap_table_size。