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?
- 因为redolog他是循环写,大小限制会导致一部分历史数据丢失,binlog的话则会是一直持久化
- 如果只有binglog的话,就不能做崩溃恢复了,历史原因是:myisam原生是不支持崩溃恢复的,而innodb在加入mysql引擎家族之前他就是支持的。 然后innodb接入mysql后发现既然binlog没有崩溃恢复的能力,那就用innodb原有的redo log了
- 如果直接用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状态