mysql log理解

目录

Log分类：

Binlog与redo log配置： 

更新语句的底层执行过程：

分库分表与binlog：

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来控制。主要作用是保证mysql innodb引擎的缓冲池中的数据不丢失（mysql崩溃恢复），mysql优化点：将mysql缓冲池设置为可用内存的60%~80%，以提高mysq的性能。redo log在事务提交之后才写入磁盘，回滚不会写入。
• binlog：肯定也是事务开始后就生成binlog（先放到缓冲区中），事务commit的时候写到磁盘，由属性sync_binlog来控制，这个值建议设置为1，每次提交都fsync，将log刷到磁盘。怎样保证磁盘中的数据库数据不丢失（数据恢复，比如删库跑路）？？？首先要有数据备份，然后要有binlog（binlog中不要再执行删库的sql语句）。binlog在事务提交之后才写入磁盘，回滚不会写入。

Binlog与redo log配置： 

什么叫双一配置？

指的是redo log和binlog的配置，配置innodb_flush_log_at_trx_commit和sync_binlog这两个属性的值，更好的保证了数据的安全，虽然效率有所降低，但是能够满足我们业务的要求。双1配置就是说在配置binlog和redo log的时候，其对应的参数值sync_binlog和innodb_flush_log_at_trx_commit都设置为1，表示每次事务提交都刷写磁盘。

Redo log：

redo log属性innodb_flush_log_at_trx_commit的3种设置：

此图更详尽：

属性值为0：update的时候，redo log已经被写入redo log buffer。事务提交时，不会将redo log刷盘，等待主线程按时（1秒钟）刷盘。在该值下，写入效率最高，但是数据安全最低。
属性值为1：update的时候，redo log已经被写入redo log buffer。事务提交时，会将redo log buffer中的redo log 先写入OS层的文件系统缓存（OS缓存），然后刷盘（调用OS层的文件系统的fdatasync()），也就是说每次提交都要刷盘，所以最安全，将文件系统缓冲中的数据真正写入磁盘存储，确保不会出现数据丢失。在该值下，写入效率最低，但是数据安全最高。一般建议将该属性值设置为1，以获得较高的数据安全性，而且也只有设置为1，才能保证事务的持久性。
属性值为2：update的时候，redo log已经被写入redo log buffer。事务提交时，将redo log buffer中的redo log写入到OS层的文件系统缓存（OS缓存），但是不会调用fdatasync()，而是让文件系统自己去判断何时将缓存写入磁盘。在该值下，写入效率和数据安全性都是中等水平。

更新语句的底层执行过程：

一条更新语句是怎样执行的？其中redo log是怎样生成的？

​更详细的信息，请查看文章： 

MySQL更新数据时，日志（redo log、binlog）执行流程_知难行难1985的博客-CSDN博客

分库分表与binlog：

主从同步原理： 用到binlog

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

怎样解决主从同步延迟？

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