mysql binlog binlog_cache_size
数据库事务
1 begin
2 写binlog buffer
3 commit
4 返回到 client
5 binlog buffer 刷盘
6 binlog dump 数据
以上6件事到底是什么顺序？
Mysql有很多系统变量可以设置，系统变量设置不同，会导致系统运行状态的不同。因此mysql提供两组命令，分别查看系统设置和运行状态。
1、系统设置：
SHOW [GLOBAL | SESSION] VARIABLES [like_or_where]
SHOW VARIABLES shows the values of MySQL system variables.
2、运行状态：
SHOW [GLOBAL | SESSION] STATUS [like_or_where]
SHOW STATUS provides server status information.
参数：binlog_cache_size ：一个事务，在没有提交（uncommitted）的时候，产生的日志，记录到Cache中；等到事务提交（committed）需要提交的时候，则把日志持久化到磁盘。
接着，binlog_cache_size设置多大呢？答案是：也需要权衡！
设置太大的话，会比较消耗内存资源（Cache本质就是内存），更加需要注意的是：binlog_cache是不是全局的，是按SESSION为单位独享分配的，也就是说当一个线程开始一个事务的时候，Mysql就会为这个SESSION分配一个binlog_cache （备注：我想之所以以SESSION为单位分配binlog_cache是有道理的，因为不同的mysql请求，产生的binlog数量不一样的，批量插入数据必然产生大量的binlog，而简单注册一个用户，产生的binlog有限，那么JDBC连接上能否设置binlog_cache_size呢？）。
设置太小的话，如果用户提交一个“长事务（long_transaction）”，比如：批量导入数据。那么该事务必然会产生很多binlog，这样cache可能不够用（默认binlog_cache_size是32K），不够用的时候mysql会把uncommitted的部分写入临时文件（临时文件cache的效率必然没有内存cache高），等到committed的时候才会写入正式的持久化日志文件。
Binlog_cache_use 表示binlog_cache内存方式被用上了多少次，Binlog_cache_disk_use表示binlog_cache临时文件方式被用上了多少次。
mysql> show status like 'binlog_%';
+-----------------------+------------+
| Variable_name | Value |
+-----------------------+------------+
| Binlog_cache_disk_use | 102374 |
| Binlog_cache_use | 1549499037 |
+-----------------------+------------+mysql> show variables like "%bin%";
+-----------------------------------------+------------+
| Variable_name | Value |
+-----------------------------------------+------------+
| binlog_cache_size | 32768 |
| binlog_direct_non_transactional_updates | OFF |
| binlog_format | ROW |
| innodb_locks_unsafe_for_binlog | OFF |
| log_bin | ON |
| log_bin_trust_function_creators | OFF |
| log_bin_trust_routine_creators | OFF |
| max_binlog_cache_size | 2147483648 |
| max_binlog_size | 524288000 |
| sql_log_bin | ON |
| sync_binlog | 0 |
+-----------------------------------------+------------+log_bin：表示开启binlog。二进制日志包含所有更新数据的语句。LOG_BIN可以指定日志文件，如果不指定文件名，LOG_BIN将自己产生缺省的文件名。这个参数要在MY.CNF中修改。通过show master status命令可以看到binlog最新的日志文件名和偏移量（也是文件大小byte表示）。
mysql> show master status;
+------------------+-----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.002353 | 222164625 | | |
+------------------+-----------+--------------+------------------+sync_binlog:This makes MySQL synchronize the binary log’s contents to disk each time it commits a transaction 默认情况下，并不是每次写入时都将binlog与硬盘同步。因此如果操作系统或机器(不仅仅是MySQL服务器)崩溃，有可能binlog中最后的语句丢失了。要想防止这种情况，你可以使用sync_binlog全局变量(1是最安全的值，但也是最慢的)，使binlog在每N次binlog写入后与硬盘同步。即使sync_binlog设置为1,出现崩溃时，也有可能表内容和binlog内容之间存在不一致性。如果使用InnoDB表，MySQL服务器处理COMMIT语句，它将整个事务写入binlog并将事务提交到InnoDB中。如果在两次操作之间出现崩溃，重启时，事务被InnoDB回滚，但仍然存在binlog中。[[可以用--innodb-safe-binlog选项来增加InnoDB表内容和binlog之间的一致性。(注释：在MySQL 5.1中不需要--innodb-safe-binlog；由于引入了XA事务支持，该选项作废了），该选项可以提供更大程度的安全，使每个事务的 binlog(sync_binlog =1)和(默认情况为真)InnoDB日志与硬盘同步，该选项的效果是崩溃后重启时，在滚回事务后，MySQL服务器从binlog剪切回滚的 InnoDB事务。这样可以确保binlog反馈InnoDB表的确切数据等，并使从服务器保持与主服务器保持同步(不接收 回滚的语句)。]] 方括号里的没有见过啊！！！
expire_logs_days：保存的binlog日志的天数, 这个默认是0，也就是logs不过期，可通过设置全局的参数，使他临时生效：
set global expire_logs_days=7;
设置了只保留7天BINLOG, 下次重启mysql这个参数默认会失败，所以需在my.cnf中设置
expire_logs_days = 7
另外也可以使用PURGE语句手动删除binlog日志文件，具体不举例子了 参考 http://www.g78.net/?p=191
max_binlog_size: 5242800=500M binlog的最大值，一般设置为512M或1G,一般不能超过1G。此参数不能非常严格控制binlog的大小，特别是在遇到大事务时，而binlog日志又到达了尾部，为了保证事务完整性，不切换日志，把所有sql都写到当前日志。这根oracle redo日志有点不一样（感兴趣的可以google）。Mysql记录的是mysql数据库逻辑变化信息，称之为event，实际上就是引起数据库变化的query语句。
转自 http://eyesmore.iteye.com/blog/1508385