mysql log理解

常用的mysql数据库log包括下面几种：undo log, redo log, binlog

• undo log: 在事务开始之前记录当前数据，主要用于事务失败时的回滚，以及MVCC中用于版本控制
• redo log：WAL(write ahead log)，事务开始之后就生成redo log，可以用于事务提交失败时，保证事务的一致性，事务提交失败，导致缓冲池中有脏页没有刷到磁盘，从而导致数据不一致，但是因为有了redo log，可以将数据恢复。由属性innodb_flush_log_at_trx_commit来控制，
• binlog：肯定也是事务开始后就生成binlog，事务commit的时候写到磁盘，由属性sync_binlog来控制，这个值建议设置为1，每次提交都fsync，将log刷到磁盘

redo log属性innodb_flush_log_at_trx_commit的3种设置：

什么叫双一配置？

指的是redo log和binlog的配置，配置innodb_flush_log_at_trx_commit和sync_binlog这两个属性的值，更好的保证了数据的安全，虽然效率有所降低，但是能够满足我们业务的要求。

主从同步原理： 用到binlog

binlog的写入和从数据库IO线程对其的读取都是顺序的。也就是说对主数据库binlog的读写都是顺序的，速度很快，然后从库拿到binlog之后，是不能直接写入数据库的，因为对数据库数据的增删改查是随机读写，速度会远远慢于获取binlog的速度，所以需要先将其存储到从数据库的Relay log中，相当于存储到MQ中，削峰填谷。

怎样解决主从同步延迟？

我们看到目前在slave端，只有一个SQL thread在工作，而在master端，一般会有多个并发事务向binlog里面写入数据，这样自然会造成主从同步延迟，怎样解决呢？ 从mysql5.7之后有了MTS(multi thread slave)，让多个线程并行去处理，我们知道sql的操作肯定是有顺序的，多个线程怎样保证顺序呢？解决的方案叫做组提交