mysql binlog和redolog

binglog

• binglog参数配置：sync_binlog

sync_binlog=0 的时候，表示每次提交事务都只写page cache ,不会持久化到硬盘
sync_binlog=1 的时候，表示每日提交事务之后都会写page cache，并且持久化到硬盘
sync_binlog=N 的时候，表示当积累N次事务之后就会一次性写入硬盘

心得
1，如果不是什么特别重要的数据，且并发比较高的时候可以把snc_binlog设置成100-1000中的某个值，这样可以提高性能
2，如果是对特别重要的数据，例如订单数据则建议将sync_binlog的值设置为1，这样能够保证哪怕数据库挂了，也可以保证不丢数据
3，当sync_binglog设置为0的时候，mysql会根据操作系统自动进行写入且mysql默认这个值就是0

redolog

• redolog参数配置

• innodb_flush_log_at_trx_commit

• 设置为 0 的时候，表示每次事务提交时都只是把 redo log 留在 redo log buffer 中 ;
  设置为 1 的时候，表示每次事务提交时都将 redo log 直接持久化到磁盘；
  设置为2 的时候，表示每次事务提交都只是吧redolog写到page cache

• 1 redolog和binlog是怎么关联起来的
  答：他们有一个共同的数据字段叫做xid，这样在崩溃恢复的，会按照顺序的扫描redolog
  - 如果碰到既有prepare的又有commit的事务，就直接提交
  - 如果只有prepare的，而没有commit的的事务，则拿着xid去binlog找相对应的事务

• 2 有了redolog为什么还要有binlog？

  1. 因为redolog他是循环写，大小限制会导致一部分历史数据丢失，binlog的话则会是一直持久化
  2. 如果只有binglog的话，就不能做崩溃恢复了，历史原因是：myisam原生是不支持崩溃恢复的，而innodb在加入mysql引擎家族之前他就是支持的。 然后innodb接入mysql后发现既然binlog没有崩溃恢复的能力，那就用innodb原有的redo log了
  3. 如果直接用binglog，那么可能binlog写了，但是还没有commit，然后crash了，这样的话事务本身没有提交，但是从库如果是读binlog那就是已经读过去用了（做分布式啦）

未完待续-----

整个数据流程

• 1, sql= update table_test set c=c+1 where id=3
• 2, 取出id=3的数据（看是否在内存，如果是的话就直接取，不是的话再从磁盘里面读）
• 3，将行值+1 然后写入新行
• 4，新行更新到内存
• 5, 写入redolog，处于prepare阶段
• 6，写binlog
• 7, 提交事务，处于commit状态