MySQL日志

MySQL的日志

  以下6个日志，上4个日志归属于MySQL中的server，无论选择哪种存储引擎，都会存在，最后两个日志undolog和undolog归属于Innodb存储引擎，其他的存储引擎均不包含该日志信息。

slowlog

  设置具体的时间，把执行超时的sql记录在日志文件中，方便进行优化调整。

binlog

  主要用来进行数据库之间的主从同步。假设有两台机器，分别为master、slaver，主从数据库之间要保证数据一致，正常情况下，主要对master进行操作，slaver和master进行数据同步是通过binlog进行的。

  具体操作流程：当执行DML操作的时候，在master中会生成一个binlog日志文件，此时，IOThread线程会拉取binlog中内容，放入slaver中，slaver中通过relaylog进行接收暂存（假设现在需要进行DML并发操作的事务很多，那么如果每次生成一条然后slaver处理一条，线程可能处理不过来，所以需要暂存到slaver一块区域中）。暂存在终极日志中relaylog中。slaver中的SQL Thread（每次执行完毕后会进行休眠，等待下一次唤醒）会读取relaylog中的内容，解析成具体的操作并进行重放，使其和主数据库保持一致。

errorlog

  记录数据库进程中的一些错误信息。

relaylog

  在slaver机器中暂存同步过来的binlog数据。

undolog

  回滚日志，记录的是数据库的历史版本信息，用来保证事务的原子性和MVCC。

redolog

  前滚日志。

  存在原因：当将内存中的数据写入到磁盘中时，中间过程会有时间消耗。比如执行一条update语句，1、判断内存是否有数据；2、如果没有数据，需要从磁盘读取并加载到内存中；3、在内存中改变数据；4、将内存中更新得到的数据写入磁盘中，整个过程相对较为耗时，而且在第4步中，采用随机读写的方式写入到磁盘中，比较耗时。如果在这个中间过程中，突然断电，可能会出现只有一部分数据写入到磁盘中，还有一部分数据未写入进来，这会造成问题，违背了事务的特性。

  改动：在将内存中的数据写入到磁盘前，将需要进行的操作预先写到redolog中。当出现上面提到的断电情况时，通过redolog恢复数据的写入操作。

  如果redolog丢失了，那数据就真正丢失了。redolog是一个循环写的过程，如果日志中没有额外的存储空间时，会将之前的内容删除或者说覆盖掉。

什么是两阶段提交，如何保证宕机时数据的一致性？

  当binlog和redolog同时存在时，会存在一个先写和后写的过程。

假设先写redolog，再写binlog

  假设执行DML操作，先写redolog，再写binlog。假设写完了redolog，此时断电，没来得及写binlog。如果处于一个分布式环境中，master断电之后进行数据恢复，而master的redolog中记录了+1操作，而binlog中没有记录+1操作。数据恢复后master和slaver之间的数据不再同步，主从复制就没有任何意义了。

假设先写binlog，再写redolog

  执行DML操作，先写binlog，再写redolog。假设写完了binlog，此时断电，没来得及写redolog。如果处于一个分布式环境中，master的binlog中会有一个+1操作，redolog中没有记录一个+1的操作。master按照redolog进行数据恢复，发现redolog中没有+1的操作，然后slaver却有+1的操作，此时master和slaver之间的数据不再同步，主从复制仍旧没有意义。

两阶段提交

• 假设在写完redolog（prepare）后，突然断电了。此时redolog是prepare状态，slaver不会同步master的数据，并且master在恢复数据时，会检测redolog的状态，如果是prepare状态，去binlog中查找是否有与redolog中匹配的记录，如果没有，将该条记录丢弃。
• 假设写完binlog后，突然断电了。因为binlog已经成功写完，slaver会同步master的数据。master在恢复数据的时候，检测到redolog处于prepare状态，去binlog中查找发现有与之匹配的记录，则将redolog改成commit状态。